Спасибо за обзор. Может, где-то и язык пошёл бы хорошо, но я далёк от таких областей, поэтому останусь со старыми инструментами. APL выглядит довольно нишевым языком, поэтому и нет широкого применения. Вот скажем, как APL поможет в GameDev? Приложения для телефонов? Базы данных? и ещё куча других областей, где лаконичность написания математических формул погоды не делает.
Некоторые утверждения в статье мне не до конца понятны. Вот возьмём:
2. Edge Computing и IoT Проблема 2025: Устройства с ограниченными ресурсами (датчики, дроны) требуют лаконичного кода ... В 10 раз меньше кода, чем на С
Имеется в в виду, что исходный код в 10 раз меньше, чем сишный? Я думал, что IoT работают с бинарным кодом, и не используют интерпретаторы. В таком случае, сравнение размеров исходников некорректное и бессмысленное. Если это утверждение о том, что бинарник в 10 раз меньше, чем от С, то в это крайне сложно поверить без примеров.
Возможно пропустил, но повторное просматривание текста не помогло. Как в CJON кодируются массивы объектов? В примере видел только вариант "массив однотипных элементов примитивов". Скажем, из примера выше про такси куда/откуда/тариф считается, что тариф один. Но например, цена за километр может отличаться от того, что точка два идёт, к примеру, через платный участок дороги и там к тарифу будет ещё доплата. Как это всё кодировать в CJON? В том же JSON просто можно список объектов прикрутить с опциональными полями: "{ways: [ { from: 1, to: 2}, {from: 1, to: 3, extra_pay: 200}], tarif: 2 }". Или такое предлагается всегда вбивать массив extra, даже если оно надо только одному элементу, а отправитель и получатель должны корректно интерпретировать полученный набор? Правда, в этом случае уже не факт, что CJON всегда будет короче JSON
Edit: про вложенные массивы тоже интересно, как их описывать. Если таковые вообще используются. Хотя, вложенные массивы можно реализовать через одномерные при условии, что клиент и сервер знают об этом. Это опять же сводится тогда к указанию типа сообщения и некторому усложнению кода сервера и клиента.
Насколько помню из старых книжек (либо из журнала типа Квант), шаманы во время танца дождя дождя жгли в костре определённые растения. Исследование показало, что в тех растениях после сжигания образуется достаточно много аэрозольных веществ, например, азотистое серебро, которые могут служить катализатором для сбора воды в атмосфере в кучки дождевых облаков. Не знаю, правда, сколько надо сжечь таких растений, чтобы помогло :-)
Edit: не уверен, что именно азотистое серебро было упомянуто, но оно засело в мозгу, как связанное с эффектом "вызова дождя"
Спасибо за уточнение. Но, претензия была к подаче материала в статье.
Во-первых, в этой статье о LIMO вообще ни слова (Ctrl+F не находит ни одного включения, кроме вашего комментария). Во-вторых, если автор приводит сокращенные описания чего-то, то я ожидаю, что это будет самое важное, чтобы зацепить читателя пойти по ссылке и узнать больше. В данном случае, автор сделал упор на том, что только повысится скорость и меньше данных можно подсовывать для изучения. Это никак не подогревает интерес. Откуда простой читатель (я не слежу за всеми ИИ новостями) может почерпнуть о том, на что вы указали? Поэтому, если оценивать именно статью, то она со своей задачей не справляется и убедить меня в правильности своих предпосылок не может.
Насчёт того, что люди не замечают небольшой прогресс соглашусь. Те же генераторы картинок и видео понемногу продвинулись довольно далеко. Но вот с некоторыми позициями в статье вам меня убедить не удалось. Например раздел "Прорывы в обработке данных" заканчивается так:
Вывод прост: да, нехватка данных — это реальная проблема, но она решаема.
В самом разделе вы только упоминаете новые методы, которые всего лишь, цитата: " метод, позволяющий обучаться быстрее при меньшем количестве данных". То есть, проблема нехватки данных пока не решается вообще никак. Нет новых данных и хоть как ускоряй или урезай существующую выборку, новых достижений от ИИ не будет. Может, кто-то что-то когда-то и придумает, но сейчас, судя по всему, воз и ныне там.
Независимость кода от среды. Где бы код на Honey не запустился, результат всегда будет ожидаемый.
Имеете в виду, что исходники на вашем языке можно будет скомпилировать где угодно и получить в итоге от программы один и тот же результат везде?
А какие у вас будут заложены возможности для написания кроссплатформенного кода в таком случае? Макросов нет, значит будет что-то вроде атрибутов в Rust? Или как?
Года 2-3 назад они решили перевести TheBat со своего HTML движка на обычный Хром. Бат стал нормально отображать все письма(что очень хорошо), но сильно потяжелел и добавил багов из-за этого. Они баги чинят, молодцы. Но отсутствие некоторых простых вещей: например, я так и не уговорил их сделать что-то чтобы упростить восстановление случайно удалённого письма(в том же Thunderbird ты тут же жмёшь Ctrl+Z и письмо возвращается на место, а в TheBat мне предложили включить "показ удалённых" и попытаться глазами найти удалённое письмо, что при условии того, что можно не заметить, что это было за письмо и что курсор убегает в начало списка писем - и про "оставить курсор на месте после включения режима" я их тоже не уговорил, это делает задачу практически невозможной. В общем мало-помалу на Хром-версии Бата накопились критические для меня неудобства (что только стоит по умолчанию включающийся сейчас thread режим, который после *каждого" перезапуска программы переиндексирует всю базу - на моём HDD это минут 40 шуршания диском занятым на 100% при моей не такой уж большой базе писем примерно в 1.5GB. Да, это отключается в настойках, но настойка не очевидна), что я ушёл на BetterBird. BetterBird - это европейский форк Thunderbird, разве что более активно фиксящий баги и добавляющий фичи.
Лично мне хватило просто перейти на JSON5 (https://json5.org/). Полностью совместим с JSON, плюс: есть комментарии, запятая после последнего элемента массива не является ошибкой, если имя ключа map слово без пробелов, то кавычки можно не ставить, также есть шестнадцатеричные константы и многострочные сроки.
Хотя тут есть возможность иметь переменные и вычислять что-то на лету. Мне это нравится, но пока не было в этом необходимости.
Надеюсь, что автозакрытие настраивается отдельно. Сколько встречал автозакрытий в разных редакторах, они больше бесили, когда автоматом ставили скобки(а так же другие "скобки" типа кавычек) куда не требуется.
В Helix сначала выделяем, затем выбираем действие
Насколько я понял, это делает невозможным указание количества повторений. Скажем, не так уж редко я удаляю(точнее, заменяю) часть слова до второй точки или какое-то подобное действие. В Vim потом я это комплексное действие, включая и удаление старого текста и добавление нового вместо старого, могу повторить в другом место просто нажав ".". В Helix выходит, что мне первое действие надо будет это сделать за два приёма, а повторить это уже получится никак. Можно, конечно, поспорить и сказать, вот тут-то мультикурсор самое то, но по мне мультикурсор значительно менее удобен в этом случае. Второй минус такого подхода для меня(хотя это крайний случай): если терминал тормозит, то иногда проще выполнить команду типа "10j", чтобы сдвинуть курсор несколько ниже, чем пытаться попасть в нужную строчку двигая клавишами курсора.
Вопрос: а как у Helix в целом с повторением прошлой выполненной команды? У тех же Vim/Neovim есть замечательный плагин vim-repeat, который улучшает возможности встроенного повторителя ".".
Edit: ещё подумалось, что для описанного мной выше повтора замены до второй точки можно ещё попробовать поиск/замена с регулярками. (Кстати, а в Helix есть превью текста,чтобы видеть какам будет текст после наджатия на Enter и выполнения набранной команды? В NeoVim это очень удобная фича, особо если в регулярке не уверен :) ) Но, опять, писать регулярку ради замены текста в нескольких строках как-то тоже кажется перебором.
Инструкции, которые не планируете изменять, лучше ставить ниже остальных. Проще говоря, билдер проходится по командам сверху вниз. Следовательно, инструкции, которые мы планируем изменять редко, лучше держать выше других, чтобы они с большей вероятностью взялись из кеша.
Это самый простой язык, когда-либо придуманный. Так что потенциально это самая понятная энциклопедия.
Вот тут я бы поспорил :) Основа языка-то простая. Но, сомневаюсь, что это будет самая понятная энциклопедия. Ведь в Токипона количество слов очень мало и эти слова очень многозначны. В итоге либо ты используешь одно слово(тогда только контекст решает, а если его не достаточно, то приплыли), либо строишь нечто из кучи слов, чтобы передать смысл(а тут уже другие проблемы, такие как "каждый может придумать свой описательный перевод" или "вот вам словарь с тысячами словосочетаний и что они значат". Ни то, ни другое не добавляют языку точности и ясности). Чтобы не быть голословным, вот маленькая цитата из описания языка:
Почти все слова в токипоне имеют множество значений. Например pona — хороший, добро, добрый, простой, чинить (!). Из-за этого, например, предложение jan li pona можно перевести несколькими способами: человек — хороший, или человек — добрый, или, что совсем не похоже на предыдущие переводы, человек чинит. Поэтому часто перевод подбирается исходя из контекста или уточняется.
Из-за небольшого количества корней слова других языков часто переводятся на токипону с использованием нескольких корней, например «учить», «обучать» будет pana e sona, буквально «давать знание».[19] Хотя о токипоне часто говорят как о «языке из 120 слов», скептики считают, что это не совсем верно: в нём используется много словосочетаний и стандартных оборотов, которые необходимо заучивать как отдельные лексические единицы.
В Rust нет ограничений на тестирование приватных функций
Это ж пока пишешь тесты прям в тексте самого файла, который тестировать будешь? А если эти же тесты вынести за пределы файла, в папку tests? Там уже вроде ограничения уже есть. Это конечно возможно только для модулей, для бинарных пакетов такое сделать нельзя, там только писать тесты внутри самих исходников. Или я что-то путаю?
А так же нет сравнения с JSON5, который может парсить обычные JSON, плюс добавляет такие плюшки, как 1) комментарии 2) запятую можно ставить после последнего элемента 3) ключи, если они выглядят как идентификаторы, можно писать без кавычек
А то, и мне кажется, что оригинальный код может сбойнуть. Скажем a=0100-0000b и b=0000-0100: 1. 0100 xor 0000 = 0100 -> rdi 2. 0000 xor 0100 = 0100 -> rsi 3. 0100 xor 0100 = 0000 -> sete al = 1
Полностью с вами согласен. Современная глобализация стирает малые языки. Чтоб далеко не ходить, достаточно взглянуть на кельтские языки. Ещё в конце XIX века они были довольно в ходу. А сейчас, по моим ощущениям, разве что валлийский барахтается. А ирландский, шотландский и корнский (не забывая померший в районе 1970х мэнский), дышат на ладан под напором английского. Да, есть попытки возродить мэнский, но каков там успех не знаю, не слежу.
Как-то читал статью, в которой звучала мысль "уничтожение малых языков может ухудшить наше понимание окружающего мира". Ну или как-то так, точно уже не вспомню. Автор приводил пример, когда малые языки, даже те, что уж и не имеет носителей, могут дать дополнительную информацию, например о растениях. Пока племя долго живёт в какой-то области, оно находит лекарственные растения и часто даёт им описательные имена. Но тут приходит английский, и скажем "крово-стоп" становиться банальным "лютиком". Тем самым, человечество может упустить новые лекарственные препараты, которые могли бы из этого растения выделить, знай оно оригинальные названия. Звучит логично, хоть и немного натянуто.
Мой первый пост был больше не о том, что какие-то языки сложно выучить из-за недостатка информации. Так всегда было и будет, ибо языки не равны. Я сетовал больше о другом. Давно уж языками интересуюсь и периодически натыкаюсь на статьи и видео типа "Так учат языки профи" или "Вот помогло именно мне освоить языки". И почти каждая первая такая статья сводится к одному пункту: погрузитесь в языковую среду, общайтесь с нативами, смотрите фильмы и читайте книги на нужном языке. Спасибо, капитан Очевидность. А не скажете, где это всё взять не в случае вашего языка из топ 10?
Не говорю, что статья полностью бесполезная. Всё-таки приёмы про сосредоточтесь на конкретной теме, а так же освойте N самых используемых слов - универсальные советы, который иногда просто забываешь. Разве что, для редких языков вряд ли найдёшь списки "top N words", но тут можно сделать финт ушами и выбрать первые N слов русского и для них выучить слова из иностранного :-) Правда, тут можно упереться в то, что а обратных словарей-то и нет. Были случаи когда я находил словарь только в направлении "какой-то язык"-"англйиский или русский", но не в обратном.
Я всё ещё надеюсь где-нибудь прочесть какие-то интересные приёмы, о которых я не задумывался, но продолжаю попадаться на ту же удочку. И снова читаю статью об очередном прославлении погружения в языковую среду. Отсюда и мой изначальный комментарий про то, что методика вроде работающая и логичная, но далеко не универсальная и обсосанная уже тысячу раз.
так топ 50, считай, и есть "более или менее распространённые" :)
Вот, нашло на меня что-то, и стало интересно, что за язык у команчей. После фильмов с Гойко Митичем у меня до сих пор интерес к индейцам. А команчи - довольно известное племя. Но, что-то кроме страницы в википедии ничего толком и не нашёл.
Ладно, возьмём что-то покрупнее: самый "мощный" язык индейцев, на котором говорят миллионы (по разным оценкам от 2 до 10 миллионов носителей) - кечуа. Ведь это много, почти как говорящих на финском, а про финский книг завались. А не тут-то было. Подавляющее большинство литературы на испанском. Что не мудрено, ибо носители в Южной Америке живут. Правда, я даже на русском пару учебников нашёл. Ещё пару на английском. Даже что-то освоил и мог простые тексты понимать. А вот погружение в языковую среду - облом. Кечуа - язык сельской местности. Пытался найти кого-то онлайн и либо они на тех сайтах давно не появляются, либо это дети тех селян, что переехали в город, и поэтому кечуа у них хуже испанского, либо на кечуа почему-то ни слова не говорили. На этом кечуа у меня тоже заглох. Разве что книги на кечуа читать, если найдёшь - их понемногу каждый год выпускают. Но, кто мне поможет понять эти книги правильно? Точнее, подсказать как перевести верно. По моему предыдущему опыту, это будет крайне тяжко, ибо я и в простых учебных текстах ошибки делал.
Добавка:
Почти та же ситуация с языками русского крайнего севера. Был интерес почитать языки нивхов, чукчей и т.п. Нашлось по 1-2 книги 30х-50х годов прошлого века. Носителей, как полагаю, в интернете тож днём с огнём ищи :(
Спасибо за обзор. Может, где-то и язык пошёл бы хорошо, но я далёк от таких областей, поэтому останусь со старыми инструментами. APL выглядит довольно нишевым языком, поэтому и нет широкого применения. Вот скажем, как APL поможет в GameDev? Приложения для телефонов? Базы данных? и ещё куча других областей, где лаконичность написания математических формул погоды не делает.
Некоторые утверждения в статье мне не до конца понятны. Вот возьмём:
2. Edge Computing и IoTПроблема 2025:
Устройства с ограниченными ресурсами (датчики, дроны) требуют
лаконичного кода...
В 10 раз меньше кода, чем на С
Имеется в в виду, что исходный код в 10 раз меньше, чем сишный? Я думал, что IoT работают с бинарным кодом, и не используют интерпретаторы. В таком случае, сравнение размеров исходников некорректное и бессмысленное. Если это утверждение о том, что бинарник в 10 раз меньше, чем от С, то в это крайне сложно поверить без примеров.
Возможно пропустил, но повторное просматривание текста не помогло. Как в CJON кодируются массивы объектов? В примере видел только вариант "массив однотипных элементов примитивов". Скажем, из примера выше про такси куда/откуда/тариф считается, что тариф один. Но например, цена за километр может отличаться от того, что точка два идёт, к примеру, через платный участок дороги и там к тарифу будет ещё доплата. Как это всё кодировать в CJON? В том же JSON просто можно список объектов прикрутить с опциональными полями: "{ways: [ { from: 1, to: 2}, {from: 1, to: 3, extra_pay: 200}], tarif: 2 }". Или такое предлагается всегда вбивать массив extra, даже если оно надо только одному элементу, а отправитель и получатель должны корректно интерпретировать полученный набор? Правда, в этом случае уже не факт, что CJON всегда будет короче JSON
Edit: про вложенные массивы тоже интересно, как их описывать. Если таковые вообще используются. Хотя, вложенные массивы можно реализовать через одномерные при условии, что клиент и сервер знают об этом. Это опять же сводится тогда к указанию типа сообщения и некторому усложнению кода сервера и клиента.
Насколько помню из старых книжек (либо из журнала типа Квант), шаманы во время танца дождя дождя жгли в костре определённые растения. Исследование показало, что в тех растениях после сжигания образуется достаточно много аэрозольных веществ, например, азотистое серебро, которые могут служить катализатором для сбора воды в атмосфере в кучки дождевых облаков. Не знаю, правда, сколько надо сжечь таких растений, чтобы помогло :-)
Edit: не уверен, что именно азотистое серебро было упомянуто, но оно засело в мозгу, как связанное с эффектом "вызова дождя"
Спасибо за уточнение. Но, претензия была к подаче материала в статье.
Во-первых, в этой статье о LIMO вообще ни слова (Ctrl+F не находит ни одного включения, кроме вашего комментария). Во-вторых, если автор приводит сокращенные описания чего-то, то я ожидаю, что это будет самое важное, чтобы зацепить читателя пойти по ссылке и узнать больше. В данном случае, автор сделал упор на том, что только повысится скорость и меньше данных можно подсовывать для изучения. Это никак не подогревает интерес. Откуда простой читатель (я не слежу за всеми ИИ новостями) может почерпнуть о том, на что вы указали? Поэтому, если оценивать именно статью, то она со своей задачей не справляется и убедить меня в правильности своих предпосылок не может.
Насчёт того, что люди не замечают небольшой прогресс соглашусь. Те же генераторы картинок и видео понемногу продвинулись довольно далеко. Но вот с некоторыми позициями в статье вам меня убедить не удалось. Например раздел "Прорывы в обработке данных" заканчивается так:
В самом разделе вы только упоминаете новые методы, которые всего лишь, цитата: " метод, позволяющий обучаться быстрее при меньшем количестве данных". То есть, проблема нехватки данных пока не решается вообще никак. Нет новых данных и хоть как ускоряй или урезай существующую выборку, новых достижений от ИИ не будет. Может, кто-то что-то когда-то и придумает, но сейчас, судя по всему, воз и ныне там.
Имеете в виду, что исходники на вашем языке можно будет скомпилировать где угодно и получить в итоге от программы один и тот же результат везде?
А какие у вас будут заложены возможности для написания кроссплатформенного кода в таком случае? Макросов нет, значит будет что-то вроде атрибутов в Rust? Или как?
Года 2-3 назад они решили перевести TheBat со своего HTML движка на обычный Хром. Бат стал нормально отображать все письма(что очень хорошо), но сильно потяжелел и добавил багов из-за этого. Они баги чинят, молодцы. Но отсутствие некоторых простых вещей: например, я так и не уговорил их сделать что-то чтобы упростить восстановление случайно удалённого письма(в том же Thunderbird ты тут же жмёшь Ctrl+Z и письмо возвращается на место, а в TheBat мне предложили включить "показ удалённых" и попытаться глазами найти удалённое письмо, что при условии того, что можно не заметить, что это было за письмо и что курсор убегает в начало списка писем - и про "оставить курсор на месте после включения режима" я их тоже не уговорил, это делает задачу практически невозможной. В общем мало-помалу на Хром-версии Бата накопились критические для меня неудобства (что только стоит по умолчанию включающийся сейчас thread режим, который после *каждого" перезапуска программы переиндексирует всю базу - на моём HDD это минут 40 шуршания диском занятым на 100% при моей не такой уж большой базе писем примерно в 1.5GB. Да, это отключается в настойках, но настойка не очевидна), что я ушёл на BetterBird. BetterBird - это европейский форк Thunderbird, разве что более активно фиксящий баги и добавляющий фичи.
С чего бы это появилось в списке "Бесплатных нейросетей"? AI ошибся при написании статьи? :)
Лично мне хватило просто перейти на JSON5 (https://json5.org/). Полностью совместим с JSON, плюс: есть комментарии, запятая после последнего элемента массива не является ошибкой, если имя ключа map слово без пробелов, то кавычки можно не ставить, также есть шестнадцатеричные константы и многострочные сроки.
Хотя тут есть возможность иметь переменные и вычислять что-то на лету. Мне это нравится, но пока не было в этом необходимости.
Ещё такой вариант бесплатный есть (правда, застряла на бете, но играть можно): https://github.com/Harchvertelol/Dangerous-Dave-2-Modification-Edition
Надеюсь, что автозакрытие настраивается отдельно. Сколько встречал автозакрытий в разных редакторах, они больше бесили, когда автоматом ставили скобки(а так же другие "скобки" типа кавычек) куда не требуется.
Насколько я понял, это делает невозможным указание количества повторений. Скажем, не так уж редко я удаляю(точнее, заменяю) часть слова до второй точки или какое-то подобное действие. В Vim потом я это комплексное действие, включая и удаление старого текста и добавление нового вместо старого, могу повторить в другом место просто нажав ".". В Helix выходит, что мне первое действие надо будет это сделать за два приёма, а повторить это уже получится никак. Можно, конечно, поспорить и сказать, вот тут-то мультикурсор самое то, но по мне мультикурсор значительно менее удобен в этом случае. Второй минус такого подхода для меня(хотя это крайний случай): если терминал тормозит, то иногда проще выполнить команду типа "10j", чтобы сдвинуть курсор несколько ниже, чем пытаться попасть в нужную строчку двигая клавишами курсора.
Вопрос: а как у Helix в целом с повторением прошлой выполненной команды? У тех же Vim/Neovim есть замечательный плагин vim-repeat, который улучшает возможности встроенного повторителя ".".
Edit: ещё подумалось, что для описанного мной выше повтора замены до второй точки можно ещё попробовать поиск/замена с регулярками. (Кстати, а в Helix есть превью текста,чтобы видеть какам будет текст после наджатия на Enter и выполнения набранной команды? В NeoVim это очень удобная фича, особо если в регулярке не уверен :) ) Но, опять, писать регулярку ради замены текста в нескольких строках как-то тоже кажется перебором.
Так всё-таки выше других или ниже? :)
Вот тут я бы поспорил :) Основа языка-то простая. Но, сомневаюсь, что это будет самая понятная энциклопедия. Ведь в Токипона количество слов очень мало и эти слова очень многозначны. В итоге либо ты используешь одно слово(тогда только контекст решает, а если его не достаточно, то приплыли), либо строишь нечто из кучи слов, чтобы передать смысл(а тут уже другие проблемы, такие как "каждый может придумать свой описательный перевод" или "вот вам словарь с тысячами словосочетаний и что они значат". Ни то, ни другое не добавляют языку точности и ясности). Чтобы не быть голословным, вот маленькая цитата из описания языка:
Отсюда: https://ru.wikipedia.org/wiki/Токипона
Это ж пока пишешь тесты прям в тексте самого файла, который тестировать будешь? А если эти же тесты вынести за пределы файла, в папку
tests? Там уже вроде ограничения уже есть. Это конечно возможно только для модулей, для бинарных пакетов такое сделать нельзя, там только писать тесты внутри самих исходников. Или я что-то путаю?Есть занимательная статья о неочевидных подводных камнях фильтра Блума: https://blog.cloudflare.com/when-bloom-filters-dont-bloom
А так же нет сравнения с JSON5, который может парсить обычные JSON, плюс добавляет такие плюшки, как 1) комментарии 2) запятую можно ставить после последнего элемента 3) ключи, если они выглядят как идентификаторы, можно писать без кавычек
Так всё-таки, статья о "Увлекательный лексический анализ языка Rust" или о "Увлекательный лексический анализ с помощью языка Rust"?
Я ожидал разбор самого Rust, но с первых абзацев закрались смутные сомнения :)
Может там третья операция должна быть
or rdi,rsi?А то, и мне кажется, что оригинальный код может сбойнуть. Скажем a=0100-0000b и b=0000-0100:
1. 0100 xor 0000 = 0100 -> rdi
2. 0000 xor 0100 = 0100 -> rsi
3. 0100 xor 0100 = 0000 -> sete al = 1
Полностью с вами согласен. Современная глобализация стирает малые языки. Чтоб далеко не ходить, достаточно взглянуть на кельтские языки. Ещё в конце XIX века они были довольно в ходу. А сейчас, по моим ощущениям, разве что валлийский барахтается. А ирландский, шотландский и корнский (не забывая померший в районе 1970х мэнский), дышат на ладан под напором английского. Да, есть попытки возродить мэнский, но каков там успех не знаю, не слежу.
Как-то читал статью, в которой звучала мысль "уничтожение малых языков может ухудшить наше понимание окружающего мира". Ну или как-то так, точно уже не вспомню. Автор приводил пример, когда малые языки, даже те, что уж и не имеет носителей, могут дать дополнительную информацию, например о растениях. Пока племя долго живёт в какой-то области, оно находит лекарственные растения и часто даёт им описательные имена. Но тут приходит английский, и скажем "крово-стоп" становиться банальным "лютиком". Тем самым, человечество может упустить новые лекарственные препараты, которые могли бы из этого растения выделить, знай оно оригинальные названия. Звучит логично, хоть и немного натянуто.
Мой первый пост был больше не о том, что какие-то языки сложно выучить из-за недостатка информации. Так всегда было и будет, ибо языки не равны. Я сетовал больше о другом. Давно уж языками интересуюсь и периодически натыкаюсь на статьи и видео типа "Так учат языки профи" или "Вот помогло именно мне освоить языки". И почти каждая первая такая статья сводится к одному пункту: погрузитесь в языковую среду, общайтесь с нативами, смотрите фильмы и читайте книги на нужном языке. Спасибо, капитан Очевидность. А не скажете, где это всё взять не в случае вашего языка из топ 10?
Не говорю, что статья полностью бесполезная. Всё-таки приёмы про сосредоточтесь на конкретной теме, а так же освойте N самых используемых слов - универсальные советы, который иногда просто забываешь. Разве что, для редких языков вряд ли найдёшь списки "top N words", но тут можно сделать финт ушами и выбрать первые N слов русского и для них выучить слова из иностранного :-) Правда, тут можно упереться в то, что а обратных словарей-то и нет. Были случаи когда я находил словарь только в направлении "какой-то язык"-"англйиский или русский", но не в обратном.
Я всё ещё надеюсь где-нибудь прочесть какие-то интересные приёмы, о которых я не задумывался, но продолжаю попадаться на ту же удочку. И снова читаю статью об очередном прославлении погружения в языковую среду. Отсюда и мой изначальный комментарий про то, что методика вроде работающая и логичная, но далеко не универсальная и обсосанная уже тысячу раз.
так топ 50, считай, и есть "более или менее распространённые" :)
Вот, нашло на меня что-то, и стало интересно, что за язык у команчей. После фильмов с Гойко Митичем у меня до сих пор интерес к индейцам. А команчи - довольно известное племя. Но, что-то кроме страницы в википедии ничего толком и не нашёл.
Ладно, возьмём что-то покрупнее: самый "мощный" язык индейцев, на котором говорят миллионы (по разным оценкам от 2 до 10 миллионов носителей) - кечуа. Ведь это много, почти как говорящих на финском, а про финский книг завались. А не тут-то было. Подавляющее большинство литературы на испанском. Что не мудрено, ибо носители в Южной Америке живут. Правда, я даже на русском пару учебников нашёл. Ещё пару на английском. Даже что-то освоил и мог простые тексты понимать. А вот погружение в языковую среду - облом. Кечуа - язык сельской местности. Пытался найти кого-то онлайн и либо они на тех сайтах давно не появляются, либо это дети тех селян, что переехали в город, и поэтому кечуа у них хуже испанского, либо на кечуа почему-то ни слова не говорили. На этом кечуа у меня тоже заглох. Разве что книги на кечуа читать, если найдёшь - их понемногу каждый год выпускают. Но, кто мне поможет понять эти книги правильно? Точнее, подсказать как перевести верно. По моему предыдущему опыту, это будет крайне тяжко, ибо я и в простых учебных текстах ошибки делал.
Добавка:
Почти та же ситуация с языками русского крайнего севера. Был интерес почитать языки нивхов, чукчей и т.п. Нашлось по 1-2 книги 30х-50х годов прошлого века. Носителей, как полагаю, в интернете тож днём с огнём ищи :(