Вся серия книг прекрасная, в этом нет сомнений. Но проблема в том, что декларативное знание не переходит само собой в процедурный навык и никакая книга не способна решить эту проблему. Я писал об этом в предыдущей статье.
Сейчас использую https://www.speechace.com/ . Ещё есть https://www.speechsuper.com/, но их я не тестировал. ELSA - самый известный пользовательский продукт, у них есть API по специальной программе, но им нельзя просто так заплатить деньги и получить ключ.
Возьмём для примера игру на фортепьяно. Наверное есть очень талантливые люди, которые могут слушая и наблюдая за игрой мастеров тоже достигнуть высоких результатов. Наверное они есть, но их очень мало. Но даже для них опытный наставник сократит путь просто на порядки. И так в любой области.
Сейчас же все пользуются частотными словарями, где слова отсортированы по частоте использования. Для английского, например, такие данные (один из вариантов) можно найти здесь: https://norvig.com/ngrams/ . Списки типа Oxford3000 или Oxford5000 составлены с учётом именно этой частотности. Для свободного общения нужно взять эти 5000 слов, плюс слова из области ваших интересов. Если вам язык нужен для технического общения, в то вашем словаре будет много слов из одной области, но при этом вам не надо уметь обсуждать какие-то вещи со водопроводчиком или грузчиком в магазине.
Если надо жить в среде и активно общаться по самому широкому кругу вопросов, то, конечно, слов потребуется больше. Обычно говорят про word families и цифра 6000 часто фигурирует как нижняя граница для более-менее комфортного чтения без постоянного обращения к словарю. Если совсем свободно читать, то речь где-то о 10 000 word families. Но устное общение, обычно, не так богато лексикой. При этом сам термин fluency он не сколько про знание лексики или владение грамматическими формами, он про беглость и автоматизм.
В предыдущей статье я писал про важность обратной связи. Я всегда считал, что "мастерство не является функцией опыта". Практика важна, но только одной практики в большинстве областей не достаточно для достижения высокого уровня (см. например спорт или музыку). Собственно, отсюда и появляется понятие о deliberate practice. В случае языка для взрослого человека основной проблемой будет fossilization - большой объём практики сам по себе не ведёт к исправлению закрепившихся ошибок.
Тогда всё норм. Я использую автоматический анализ произношения, который даёт оценку для каждой фонемы. Но я пришел к этому потому, что не могу сам на слух оценить качество своего произношения.
Изучение языка принципиально не отличается от овладения любым другим сложным навыком. Да, механизмы нейропластичности с возрастом несколько меняются, но никуда не исчезают. Идея о том, что у взрослых “что-то рассасывается”, не кажется мне сколько-нибудь научно обоснованной.
LLM в ушной имплант не поместиться. А синхронный перевод в реальном времени через интернет - тут уже много вопросов. Заказать еду в ресторане или что-нибудь ещё такое - наверное да. Но, например, вести сложную техническую дискуссию... Я думаю, что учитывая сложность задачи, сейчас единственная практическая значимая цель изучения языка, это интенсивное живое общение. Всё остальное ИИ либо уже делаем лучше и быстрее, либо скоро будет. Ещё можно изучать язык для профилактики деменции, но для этого можно и много чего другого делать.
> И что внутри там появилось что-то, отличное от списокв.
Структуры, массивы, хэш-таблицы, FFI. Посмотрите ассембленый код, который генерирует SBCL. Списки используются для синтаксиса и являются часто используемым типом данных, но не более того.
> что расширял себя сам, «вводя новые ключевые слова» через
> задание новых операций над списками
> Мда, я думал интереснее будет, чего нового про лисп узнаю
> «да ти праграмиравать сам ни умииш и ничаво не знаиш!!!»
Я не знаю, чего у вас там за обычная аргументация, но говорить, что в лисп есть только списки списки, а всё остальное это операции над списками, это абсолютно полное невежество. Так было 50 лет назад. С тех пор лисп очень сильно изменился.
> Посмотрите ради интереса создание класса на plain c, на common lisp
> и на c++.
Где в этом коде вы увидели создание класса на plain C? Когда он создаёт объект?
> вы только что назвали 2000 незнакомых вам человек
> говном только за знание РНР
Вы что, читать не умеете?
Во-первых, я не называл никого говно, я говорил только о коде. Во-вторых, я специально подчеркнул, что некомпетентность большинства ищущих работу не связана с фактом использования PHP. Есть процент разработчиков, которым бы лучше было наверное заниматься чем-то другим. Это приводит к тому, что они постоянно ищут работу (либо не имеют работы в данный момент, либо имеют проблемы на текущей). в итоге, 95% кандидатов на рынке труда принадлежат именно к таким, хотя их общий процент на фоне всех разработчиков совсем не велик. И сделать правильный выбор небольшой не-IT компании очень трудно.
Очень идеализировано и бесконечно далеко от практики. Говорить о взаимозаменяемости программистов на PHP имеет смысл только для больших организаций, с развитым IT-подразделением, или даже только для IT-компаний.
На деле оказывается, что когда PHP-программист увольняется, то надо делать выбор из 2000 кандидатов, большинство из которых совершенно не компетентны (не потому что, PHP, а потому что ищут работу). Кого в итоге возьмут — вопрос удачи (ведь контора не софтверная, с небольшим IT-подразделением).
Новый разработчик обнаруживает, что проект это куча говна. И начинает это говно разребать, но обычно лучше не становится, просто одно говно заменяется на другое. Ну ему-то в своем говне сидеть приятней, чем в чужом. А потом он увольняется и на его место приходит другой, и всё по новой.
В итоге, с точки зрения бизнеса, риски связанные с выбором CL просто меркнут на фоне рисков, связанных с постоянной ротацией якобы взаимозаменяемы PHP-программистов. Да, они взаимозаменяемы, но только для перемешивания говна, а бизнесу то надо совсем другое.
Теперь насчёт уникальных решений. Да, интернет-магазин задача типовая и можно использовать типовое решение. Только это вопрос вообще не имеет отношения к разработке, а исключительно к бизнесу. Если бизнес не хочет типового решения, а имеет амбиции и хочет развиваться, то он не будет делать ставку на типовое решение. У него есть набор своих требований, которые плохо ложатся на типовые решения.
Касательно конкретно этого магазина. Насколько я понимаю, там и был php до прихода автора. И, очевидно, описанная выше ситуация «круговорота говна в природе» настолько достала владельцев, что они согласились с аргументацией и дали возможность использовать CL. Да, риски велики. Но это дало шансы на изменения развития в сторону реальных интересов бизнеса. Собственно, это и есть задача бизнеса — оценивать риски, а программисты пускай лучше пишут код.
Вся серия книг прекрасная, в этом нет сомнений. Но проблема в том, что декларативное знание не переходит само собой в процедурный навык и никакая книга не способна решить эту проблему. Я писал об этом в предыдущей статье.
С чем возникла проблема? Да, сервис за cloudflare, поэтому требуется VPN.
Сейчас использую https://www.speechace.com/ . Ещё есть https://www.speechsuper.com/, но их я не тестировал. ELSA - самый известный пользовательский продукт, у них есть API по специальной программе, но им нельзя просто так заплатить деньги и получить ключ.
Опыта в 20 лет, пожалуй, ни у кого ещё нет, но вот довольно нашумевшее видео про опыт в 2000 дней: https://www.youtube.com/watch?v=y8cE5skIvok
Разбор на русском: https://www.youtube.com/watch?v=FjpOIZ4nHZw
Извините за нескромность, для ответа на вопрос "какой и почему" оставлю ссылку страницу с научным обоснованием FluentGym: https://fluentgym.ai/guide/science-behind/
Возьмём для примера игру на фортепьяно. Наверное есть очень талантливые люди, которые могут слушая и наблюдая за игрой мастеров тоже достигнуть высоких результатов. Наверное они есть, но их очень мало. Но даже для них опытный наставник сократит путь просто на порядки. И так в любой области.
Кому и до какого уровня? Но я в любом случае не интересовался вопросом :)
Сейчас же все пользуются частотными словарями, где слова отсортированы по частоте использования. Для английского, например, такие данные (один из вариантов) можно найти здесь: https://norvig.com/ngrams/ . Списки типа Oxford3000 или Oxford5000 составлены с учётом именно этой частотности. Для свободного общения нужно взять эти 5000 слов, плюс слова из области ваших интересов. Если вам язык нужен для технического общения, в то вашем словаре будет много слов из одной области, но при этом вам не надо уметь обсуждать какие-то вещи со водопроводчиком или грузчиком в магазине.
Если надо жить в среде и активно общаться по самому широкому кругу вопросов, то, конечно, слов потребуется больше. Обычно говорят про word families и цифра 6000 часто фигурирует как нижняя граница для более-менее комфортного чтения без постоянного обращения к словарю. Если совсем свободно читать, то речь где-то о 10 000 word families. Но устное общение, обычно, не так богато лексикой. При этом сам термин fluency он не сколько про знание лексики или владение грамматическими формами, он про беглость и автоматизм.
В предыдущей статье я писал про важность обратной связи. Я всегда считал, что "мастерство не является функцией опыта". Практика важна, но только одной практики в большинстве областей не достаточно для достижения высокого уровня (см. например спорт или музыку). Собственно, отсюда и появляется понятие о deliberate practice. В случае языка для взрослого человека основной проблемой будет fossilization - большой объём практики сам по себе не ведёт к исправлению закрепившихся ошибок.
Тогда всё норм. Я использую автоматический анализ произношения, который даёт оценку для каждой фонемы. Но я пришел к этому потому, что не могу сам на слух оценить качество своего произношения.
Изучение языка принципиально не отличается от овладения любым другим сложным навыком. Да, механизмы нейропластичности с возрастом несколько меняются, но никуда не исчезают. Идея о том, что у взрослых “что-то рассасывается”, не кажется мне сколько-нибудь научно обоснованной.
LLM в ушной имплант не поместиться. А синхронный перевод в реальном времени через интернет - тут уже много вопросов. Заказать еду в ресторане или что-нибудь ещё такое - наверное да. Но, например, вести сложную техническую дискуссию... Я думаю, что учитывая сложность задачи, сейчас единственная практическая значимая цель изучения языка, это интенсивное живое общение. Всё остальное ИИ либо уже делаем лучше и быстрее, либо скоро будет. Ещё можно изучать язык для профилактики деменции, но для этого можно и много чего другого делать.
Смотреть фильмы в оригинале, в моем понимании, не стоит затраченных усилий. Тем более у нас уже скоро будет качественный ИИ-перевод для чего угодно.
Структуры, массивы, хэш-таблицы, FFI. Посмотрите ассембленый код, который генерирует SBCL. Списки используются для синтаксиса и являются часто используемым типом данных, но не более того.
> что расширял себя сам, «вводя новые ключевые слова» через
> задание новых операций над списками
У вас всё в голове перемешалось.
> «да ти праграмиравать сам ни умииш и ничаво не знаиш!!!»
Я не знаю, чего у вас там за обычная аргументация, но говорить, что в лисп есть только списки списки, а всё остальное это операции над списками, это абсолютно полное невежество. Так было 50 лет назад. С тех пор лисп очень сильно изменился.
> Посмотрите ради интереса создание класса на plain c, на common lisp
> и на c++.
Где в этом коде вы увидели создание класса на plain C? Когда он создаёт объект?
> Ничего не напоминает?
Определение класса? о_О
Ну что за невежество.
> говном только за знание РНР
Вы что, читать не умеете?
Во-первых, я не называл никого говно, я говорил только о коде. Во-вторых, я специально подчеркнул, что некомпетентность большинства ищущих работу не связана с фактом использования PHP. Есть процент разработчиков, которым бы лучше было наверное заниматься чем-то другим. Это приводит к тому, что они постоянно ищут работу (либо не имеют работы в данный момент, либо имеют проблемы на текущей). в итоге, 95% кандидатов на рынке труда принадлежат именно к таким, хотя их общий процент на фоне всех разработчиков совсем не велик. И сделать правильный выбор небольшой не-IT компании очень трудно.
На деле оказывается, что когда PHP-программист увольняется, то надо делать выбор из 2000 кандидатов, большинство из которых совершенно не компетентны (не потому что, PHP, а потому что ищут работу). Кого в итоге возьмут — вопрос удачи (ведь контора не софтверная, с небольшим IT-подразделением).
Новый разработчик обнаруживает, что проект это куча говна. И начинает это говно разребать, но обычно лучше не становится, просто одно говно заменяется на другое. Ну ему-то в своем говне сидеть приятней, чем в чужом. А потом он увольняется и на его место приходит другой, и всё по новой.
В итоге, с точки зрения бизнеса, риски связанные с выбором CL просто меркнут на фоне рисков, связанных с постоянной ротацией якобы взаимозаменяемы PHP-программистов. Да, они взаимозаменяемы, но только для перемешивания говна, а бизнесу то надо совсем другое.
Теперь насчёт уникальных решений. Да, интернет-магазин задача типовая и можно использовать типовое решение. Только это вопрос вообще не имеет отношения к разработке, а исключительно к бизнесу. Если бизнес не хочет типового решения, а имеет амбиции и хочет развиваться, то он не будет делать ставку на типовое решение. У него есть набор своих требований, которые плохо ложатся на типовые решения.
Касательно конкретно этого магазина. Насколько я понимаю, там и был php до прихода автора. И, очевидно, описанная выше ситуация «круговорота говна в природе» настолько достала владельцев, что они согласились с аргументацией и дали возможность использовать CL. Да, риски велики. Но это дало шансы на изменения развития в сторону реальных интересов бизнеса. Собственно, это и есть задача бизнеса — оценивать риски, а программисты пускай лучше пишут код.