Ещё я люблю сам строить предложения и спрашивать AI корявое оно или нет. Обычно AI вежливо отбрыкивает 70% моих стараний и указывает почему. Что полезно. Например:
В немецком полтора года назад получил B1 сертификат (279 баллов из 300). С тех пор недалеко ушёл, т.к. было много отвлекающих факторов, которые съедали почти всё время. Пора навёрстывать.
В английском сложно сказать, в разы лучше. Думаю где-то B2+. До C1 недотягиваю. Но возможно смогу сдать экзамен, если пару недель усердно буду готовиться. Английский у меня на работе, поэтому я его целенаправленно не учу, он сам учится. Просто периодически заношу интересные слова или выражения.
все равно и новые слова
У меня иногда даже получается создавать комбинированные предложения, где разом по 2-3 слова из недавно-встреченных. Ну и простой рецепт составления карточек - это тюнить предложения под свои хотелки уточнениями. Скажем вы учите слово: "delicious". И вам лезут всякие:
Guests will be delighted with your delicious dishes
А вам это "deligthed" и "dishes" пока не нужны, потому что вы, предположим, пока к ним не готовы. И конструкция "will be ...-ed with ..." тоже смущает. Ок. Карточкам лучше быть простыми, соответствовать вашему текущему уровню, иначе они плохо работают.
Что делать? Полистав context.reverso вы начинаете хорошо чувствовать смысл слова ("очень вкусный"), и просто строите на русском примитивное предложение. Например: "Еда из ресторана была очень вкусной". И просите AI сформировать его на английском, используя "delicious", оставив предложение простым. Можно уточнить - что предложение должно быть некосноязычным. Он вам построит что-то типа "The food from the restaurant was delicious".
Всё так. Беда. Тут нет простых рецептов. Обычно использую
context.reverso - чтобы прочувствовать слово, а если повезёт то и найти предложение донор
бывает предложение само валится из практики (увидел в книге, в метро в рекламе, в буклете, в ютьюб ролике, где угодно)
чаще всего его нужно упростить - выкидываю всё несущественное, меняю сложные части на упрощённые
если есть сомнения в том что мои упрощения не сломали грамматику или не сделали предложение косноязычным - спрашиваю GPT, она умеет хорошо в немецкий
размечаю в предложении те моменты ради которых создаю карточку (на моих скриншотах это зелёные буквы)
если предложения из reverso или других источников мне не понравились то уже мучаю chat GPT, и генерирую что-то через неё. Первое время боялся ибо все ж знают что GPT любит галлюцинировать. Но со временем понял что она очень хорошо владеет немецким, а галлюцинирует меньше чем многие преподаватели :D
на каждое новое слово в лексиконе подбираю от 2 до 5 предложений. Стараюсь чтобы были задействованы разные времена, склонения, спряжения и т.д.. Немецкий - не английский, там это важно.
в целом у меня 2 главные колоды - одна двустороняя. Каждое предложение я строю как ru-de так и de-ru. Два разных упражнения по сути. И два разных состояния для интервального запоминания. Но уже с A2-B1 появляется много слов и конструкций, которые мне не нужны в активном словарном запасе, но нужны в пассивном. Так что есть колода и для только de-ru.
Почему предложения, а не просто слова?
Многие слова теряют большую часть смысла без своих предлогов. Например есть слово kümmern - заботиться. Но используется как kümmern sich um [кто-нибудь]. И все эти три слова скачут по предложению в разных вариациях в зависимости от присутствия модальных глаголов, отрицания, времени, лица и т.д.. Плюс сами слова меняются (вместо sich может быть uns, mich, dich и т.д.). Всё это весьма нетривиально и единственный способ научиться это использовать - это практика. Вот такие вот карточки где я вынужден в рамках цельного предложения составить всё грамматически корректно и дают эту самую практику.
Мы не говорим отдельными словами. Мы говорим заготовками. Грамматическими и вокабулярными наборами слов, выражений и т.д..
Чем больше ассоциаций с новым словом - тем оно лучше запомнится. Слово в предложении сильно лучше запоминается, чем просто слово.
Самое глупое что можно сделать с карточками - это неглядя записывать пары слово-перевод. Например [delicious - восхитительный]. А потом их зубрить. Чтобы потом выяснить, что delicious это скорее "очень вкусный", и слово используется для описания еды.
Из той же оперы брать слово из "топ Х" частотных слов в языке не включая мозг. Например в топ100 часто попадает слово "bear". Звучит бредово, да? Зачем рядовому англичанину говорить о медведях каждый день по 10 раз? А разгадка простая - to bear, be born и пр. это тоже bear. Но в табличке будет медведь, хаха.
5 лет назад я окончательно разочаровался в существующих решениях и создал свой пет-проект. Где всё сделано именно так, как хочу я. По итогу уже больше 10к карточек. Из вашей таблицы у меня пропуск только в графе телеграм-бот. Для меня он бессмысленнен, т.к. с таким количеством карточек это будет настоящая спам-машина :)
Что меня не устраивало в существующих решениях:
Много где не было вменяемого интервального повторения. Зачем такие карточки вообще нужны?
Я быстро понял что карточки должны быть не с отдельными словами, а с предложениями и фразами. Иногда довольно длинными
Синхронизация между устройствами. То как это сделано в Anki меня не устраивало. Я взял классику - всё на сервере. Оффлайн режим мне оказался без надобности
Нормальные мобильный и десктопный клиенты
Поддержка изображений
Поддержка подсказок (скрытых и всегда видных)
Поддержка авто-транскрипции
Поддержка ручной побуквенной маркировки
Продвинутый режим ответа (не просто "да" и "нет").
Возможность пропустить карточку или отбросить её на 6 часов
Возможность отмены последнего ответа
Двунаправленные и однонаправленные колоды
И многое другое
Ближе всего к моим задачам была Anki. Но пользоваться ею я себя заставить не смог.
А как? Единственный способ сериализовать метод это fn.toString() + eval (либо new Function(rawFnStr)). В обоих случаях вы по сути работаете со строкой. Просто перевыполнить декларацию этой строки как код недостаточно чтобы зацепить scopes. А [[scopes]] как ниже указал nerd220 это просто удобная тула для дебага. Её нет в реальном runtime-е.
Не сочтите за грубость, но вас поразительно сложно понять. ВМ = Virtual Machine? Ok. А что за "комбайн"? И какую роль в этом комбайне играет ОС? Что хотел программист? и как правильно?
Разнесение серверов на разные машины увеличивает сетевые издержки. Да. Но в какой-то момент это может стать неизбежным. Горизонтальное масштабирование.
Вам не нужны типы в рантайме, чтобы сделать то, что вы хотите. Вам компилятор запретит передать другой тип
Вы сейчас явно не о том. Тип валидный. С чего бы компилятору мне запрещать что-то.
type-guards и условные операторы — это как раз про рантайм
И вот их можно избежать в языках без структурной типизации. Просто сравнив два указателя.
Но если вы сами ничего не испортите, компилятор всё выведет правильно и запретит вам отстреливать себе ногу
В TypeScript 1001 способ написать код без type guard-ов, без any, без type cast-ов и прочих инструментов таким образом, чтобы код был unsound. Таких компромиссов в языке много. Можно ли их избежать в рамках структурной типизации (гипотетически)? Ну Haskel вроде смог. Во всяком случае по словам моих бывших коллег, там есть подобное. Я не проверял. Но не наш случай.
Я понимаю, в чем проблема :)
В скорости? Одна математическая операция и переход по указателю vs работа со словарём. От языка со статической типизацией обычно такой тормознутости не ждут. Но у нас в реальности JS, а не TS.
Sorry, я прочитал как "не понимаю".
наименьшая в контексте производительности.
Ну если вспоминать как люди пишут на TS\JS (преимущественно ногами), то могу с вами согласиться. Но это уже разговор, про людей, а не про языки :D
Возможно мы тут говорим о разных вещах. Я имею ввиду осведомлённость о типах данных в runtime, и чёткое понимание того с каким типом данных я имел дело здесь и сейчас в runtime. Например чтобы не прибегать к type-guard-ам (лютый костыль) или сложным ветвистым if-ам с type narrow down (работает довольно плохо). Вне структурной типизации мы просто наверняка знаем с чем мы имеем дело.
что отсутствие оптимизации из-за плохих типов — не основная проблема с производительностью в TS.
Давайте я то перефразирую. Возьмём:
struct Animal {
AnimalKind kind;
std::string name;
int age;
};
Чего стоит в runtime обратиться к myAnimal.age? Да ничего: pointer to the variable + offset to the "age" field. В бинарнике уже так и зашито.
Что у нас в JS? Всё сложно, и в целом плохо. В лууучшем случае повезёт и будет hidden class. А так привет hash map и много implicit проверок.
Для JS это нормально. У нас динамически типизированный язык. Нам просто неоткуда взять эту информацию на этапе "компиляции", чтобы сразу всё просчитать по уму.
Для TS... внезапно тоже. Казалось бы - все возможности, крутейшая система типов. Можно такого наворотить. Но нет. Потому, что он совсем unsound. А unsound он потому что было решено, что для убийцы Javascript нужно быть настолько гибким, что других вариантов не оставалось. Я в целом доволен. Не поймите меня не правильно.
Собственно говоря о Typescript runtime или compliator-е я имею ввиду именно подобные вещи, привычные нам по статически типизированным компилируемым языкам. Такого в TS ждать не приходится. Оттого и смысла делать отдельный TS runtime нет, ибо он ничем не будет отличаться от JS runtime, которых уже много.
---
Надеюсь теперь понятнее, что именно я имею ввиду. А то нас явно в разные стороны заносит.
Мне нужна проверка типов в runtime. Очень. Но я видимо тот самый "никто". Но я понимаю, что её не будет, ввиду структурной типизации в TS. Её просто никак не реализовать, кроме как перебором полей, а такая проверка типов и правда не нужна.
Плюс вы затронули важную тему - типы в compile time это не только проверка. Это возможные оптимизации кода. Но ввиду тех компромиссов, которыми кишит Typescript (ввиду чего он unsound), почти все из них неприменимы.
В тоже время в языках сильно попроще (с точки зрения типов) можно всё очень сильно соптимизировать.
Нет, там внутри JavaScriptCore. И чтобы в нём запустить JS оно просто режет незнакомый синтаксис из TS.
В целом весь этот разговор бесмысленнен. Просто уже хотя бы потому, что для того чтобы иметь именно Typescript runtime (а не JS runtime игнорирующий TS-часть синтаксиса), надо чтобы в спеке языка это как-то подразумевалось. Т.к. язык представляет из себя всё тот же JS + типы, то нужна runtime проверка типов. А этого нет даже в спеке языка. Не совсем понятно куда её там даже цеплять, учитывая что типизация структурная.
Я пытался этим пользоваться. Но не смог. В моём случае оно очень плохо работало:
Отправляешь 3 таба - приходит 1 или 2
Или вообще не приходит
Оказалось что отправлять себе в телеграм-личку и открывать оттуда куда практичнее. Точно ничего не потеряется.
Отправил в личку.
Ещё я люблю сам строить предложения и спрашивать AI корявое оно или нет. Обычно AI вежливо отбрыкивает 70% моих стараний и указывает почему. Что полезно. Например:
В немецком полтора года назад получил B1 сертификат (279 баллов из 300). С тех пор недалеко ушёл, т.к. было много отвлекающих факторов, которые съедали почти всё время. Пора навёрстывать.
В английском сложно сказать, в разы лучше. Думаю где-то B2+. До C1 недотягиваю. Но возможно смогу сдать экзамен, если пару недель усердно буду готовиться. Английский у меня на работе, поэтому я его целенаправленно не учу, он сам учится. Просто периодически заношу интересные слова или выражения.
У меня иногда даже получается создавать комбинированные предложения, где разом по 2-3 слова из недавно-встреченных. Ну и простой рецепт составления карточек - это тюнить предложения под свои хотелки уточнениями. Скажем вы учите слово: "delicious". И вам лезут всякие:
А вам это "deligthed" и "dishes" пока не нужны, потому что вы, предположим, пока к ним не готовы. И конструкция "will be ...-ed with ..." тоже смущает. Ок. Карточкам лучше быть простыми, соответствовать вашему текущему уровню, иначе они плохо работают.
Что делать? Полистав context.reverso вы начинаете хорошо чувствовать смысл слова ("очень вкусный"), и просто строите на русском примитивное предложение. Например: "Еда из ресторана была очень вкусной". И просите AI сформировать его на английском, используя "delicious", оставив предложение простым. Можно уточнить - что предложение должно быть некосноязычным. Он вам построит что-то типа "The food from the restaurant was delicious".
Отправил.
Всё так. Беда. Тут нет простых рецептов. Обычно использую
context.reverso - чтобы прочувствовать слово, а если повезёт то и найти предложение донор
бывает предложение само валится из практики (увидел в книге, в метро в рекламе, в буклете, в ютьюб ролике, где угодно)
чаще всего его нужно упростить - выкидываю всё несущественное, меняю сложные части на упрощённые
если есть сомнения в том что мои упрощения не сломали грамматику или не сделали предложение косноязычным - спрашиваю GPT, она умеет хорошо в немецкий
размечаю в предложении те моменты ради которых создаю карточку (на моих скриншотах это зелёные буквы)
если предложения из reverso или других источников мне не понравились то уже мучаю chat GPT, и генерирую что-то через неё. Первое время боялся ибо все ж знают что GPT любит галлюцинировать. Но со временем понял что она очень хорошо владеет немецким, а галлюцинирует меньше чем многие преподаватели :D
на каждое новое слово в лексиконе подбираю от 2 до 5 предложений. Стараюсь чтобы были задействованы разные времена, склонения, спряжения и т.д.. Немецкий - не английский, там это важно.
в целом у меня 2 главные колоды - одна двустороняя. Каждое предложение я строю как ru-de так и de-ru. Два разных упражнения по сути. И два разных состояния для интервального запоминания. Но уже с A2-B1 появляется много слов и конструкций, которые мне не нужны в активном словарном запасе, но нужны в пассивном. Так что есть колода и для только de-ru.
Почему предложения, а не просто слова?
Многие слова теряют большую часть смысла без своих предлогов. Например есть слово kümmern - заботиться. Но используется как kümmern sich um [кто-нибудь]. И все эти три слова скачут по предложению в разных вариациях в зависимости от присутствия модальных глаголов, отрицания, времени, лица и т.д.. Плюс сами слова меняются (вместо sich может быть uns, mich, dich и т.д.). Всё это весьма нетривиально и единственный способ научиться это использовать - это практика. Вот такие вот карточки где я вынужден в рамках цельного предложения составить всё грамматически корректно и дают эту самую практику.
Мы не говорим отдельными словами. Мы говорим заготовками. Грамматическими и вокабулярными наборами слов, выражений и т.д..
Чем больше ассоциаций с новым словом - тем оно лучше запомнится. Слово в предложении сильно лучше запоминается, чем просто слово.
Самое глупое что можно сделать с карточками - это неглядя записывать пары слово-перевод. Например [delicious - восхитительный]. А потом их зубрить. Чтобы потом выяснить, что delicious это скорее "очень вкусный", и слово используется для описания еды.
Из той же оперы брать слово из "топ Х" частотных слов в языке не включая мозг. Например в топ100 часто попадает слово "bear". Звучит бредово, да? Зачем рядовому англичанину говорить о медведях каждый день по 10 раз? А разгадка простая - to bear, be born и пр. это тоже bear. Но в табличке будет медведь, хаха.
Зарегал аккаунт. Отправил в личку.
Да. Это PWA web-приложение. Просто разные стили для мобильника и десктопа.
В последствии добавил и тесты:
т.к. навалило много экзаменов и существущие решения мне не зашли :)
5 лет назад я окончательно разочаровался в существующих решениях и создал свой пет-проект. Где всё сделано именно так, как хочу я. По итогу уже больше 10к карточек. Из вашей таблицы у меня пропуск только в графе телеграм-бот. Для меня он бессмысленнен, т.к. с таким количеством карточек это будет настоящая спам-машина :)
Что меня не устраивало в существующих решениях:
Много где не было вменяемого интервального повторения. Зачем такие карточки вообще нужны?
Я быстро понял что карточки должны быть не с отдельными словами, а с предложениями и фразами. Иногда довольно длинными
Синхронизация между устройствами. То как это сделано в Anki меня не устраивало. Я взял классику - всё на сервере. Оффлайн режим мне оказался без надобности
Нормальные мобильный и десктопный клиенты
Поддержка изображений
Поддержка подсказок (скрытых и всегда видных)
Поддержка авто-транскрипции
Поддержка ручной побуквенной маркировки
Продвинутый режим ответа (не просто "да" и "нет").
Возможность пропустить карточку или отбросить её на 6 часов
Возможность отмены последнего ответа
Двунаправленные и однонаправленные колоды
И многое другое
Ближе всего к моим задачам была Anki. Но пользоваться ею я себя заставить не смог.
А как? Единственный способ сериализовать метод это
fn.toString()+eval(либо new Function(rawFnStr)). В обоих случаях вы по сути работаете со строкой. Просто перевыполнить декларацию этой строки как код недостаточно чтобы зацепить scopes. А[[scopes]]как ниже указал nerd220 это просто удобная тула для дебага. Её нет в реальном runtime-е.С WeakMap всё это делается линейно (никакого переобхода) и никакие внутренние ID не нужны
Хранить методы имеет мало смысла, т.к. замыкания сохранить всё равно не удастся
Не сочтите за грубость, но вас поразительно сложно понять. ВМ = Virtual Machine? Ok. А что за "комбайн"? И какую роль в этом комбайне играет ОС? Что хотел программист? и как правильно?
Разнесение серверов на разные машины увеличивает сетевые издержки. Да. Но в какой-то момент это может стать неизбежным. Горизонтальное масштабирование.
Статья из каменного века? :)
Вы сейчас явно не о том. Тип валидный. С чего бы компилятору мне запрещать что-то.
И вот их можно избежать в языках без структурной типизации. Просто сравнив два указателя.
В TypeScript 1001 способ написать код без type guard-ов, без any, без type cast-ов и прочих инструментов таким образом, чтобы код был unsound. Таких компромиссов в языке много. Можно ли их избежать в рамках структурной типизации (гипотетически)? Ну Haskel вроде смог. Во всяком случае по словам моих бывших коллег, там есть подобное. Я не проверял. Но не наш случай.
В скорости? Одна математическая операция и переход по указателю vs работа со словарём. От языка со статической типизацией обычно такой тормознутости не ждут. Но у нас в реальности JS, а не TS.Sorry, я прочитал как "не понимаю".
Ну если вспоминать как люди пишут на TS\JS (преимущественно ногами), то могу с вами согласиться. Но это уже разговор, про людей, а не про языки :D
Возможно мы тут говорим о разных вещах. Я имею ввиду осведомлённость о типах данных в runtime, и чёткое понимание того с каким типом данных я имел дело здесь и сейчас в runtime. Например чтобы не прибегать к type-guard-ам (лютый костыль) или сложным ветвистым if-ам с type narrow down (работает довольно плохо). Вне структурной типизации мы просто наверняка знаем с чем мы имеем дело.
Давайте я то перефразирую. Возьмём:
Чего стоит в runtime обратиться к
myAnimal.age? Да ничего: pointer to the variable + offset to the "age" field. В бинарнике уже так и зашито.Что у нас в JS? Всё сложно, и в целом плохо. В лууучшем случае повезёт и будет hidden class. А так привет hash map и много implicit проверок.
Для JS это нормально. У нас динамически типизированный язык. Нам просто неоткуда взять эту информацию на этапе "компиляции", чтобы сразу всё просчитать по уму.
Для TS... внезапно тоже. Казалось бы - все возможности, крутейшая система типов. Можно такого наворотить. Но нет. Потому, что он совсем unsound. А unsound он потому что было решено, что для убийцы Javascript нужно быть настолько гибким, что других вариантов не оставалось. Я в целом доволен. Не поймите меня не правильно.
Собственно говоря о Typescript runtime или compliator-е я имею ввиду именно подобные вещи, привычные нам по статически типизированным компилируемым языкам. Такого в TS ждать не приходится. Оттого и смысла делать отдельный TS runtime нет, ибо он ничем не будет отличаться от JS runtime, которых уже много.
---
Надеюсь теперь понятнее, что именно я имею ввиду. А то нас явно в разные стороны заносит.
Мне нужна проверка типов в runtime. Очень. Но я видимо тот самый "никто". Но я понимаю, что её не будет, ввиду структурной типизации в TS. Её просто никак не реализовать, кроме как перебором полей, а такая проверка типов и правда не нужна.
Плюс вы затронули важную тему - типы в compile time это не только проверка. Это возможные оптимизации кода. Но ввиду тех компромиссов, которыми кишит Typescript (ввиду чего он unsound), почти все из них неприменимы.
В тоже время в языках сильно попроще (с точки зрения типов) можно всё очень сильно соптимизировать.
А как это относится к нашей теме? TS без типов это JS.
Нет, там внутри JavaScriptCore. И чтобы в нём запустить JS оно просто режет незнакомый синтаксис из TS.
В целом весь этот разговор бесмысленнен. Просто уже хотя бы потому, что для того чтобы иметь именно Typescript runtime (а не JS runtime игнорирующий TS-часть синтаксиса), надо чтобы в спеке языка это как-то подразумевалось. Т.к. язык представляет из себя всё тот же JS + типы, то нужна runtime проверка типов. А этого нет даже в спеке языка. Не совсем понятно куда её там даже цеплять, учитывая что типизация структурная.
Дык в ноде нет своего JS Runtime-а. Там V8Ааа, sorry. Я неправильно понял сообщение. Отсутствие глагола смутило.