Думаю, callbacks в JS были с самого его рождения. Это ж базовая фича. Потом просто новый синтаксис придумали для них. Так что, даже старый js до 2000 года уже не ясно, как нарисовать в Драконе.
Edit: Даже в вездесущем С можно передавать в функцию callbacks (ссылки на функцию) изначально. Так что, выходит некоторые программы С 70х-80х(к примеру, те же WinAPI приложения на чистом С) в Драконе не понятно как делать.
Не думаю, что в Вавилон-5 вдохновлялись Снеговым. Есть ещё книга Бестера "Человек без лица", вышедшая в 1952. Там главный герой для защиты от чтения мыслей просит придумать ему прилипчивую песню, чтобы у него в голове крутилась. Читал лет 20-30 назад, но всё ещё пару строк в голове осталось: "Ах ты, камбала, не вобла" (есть тут в цитатах: https://ru.wikiquote.org/wiki/Человек_без_лица_(Бестер) )
Спасибо за обзор. Может, где-то и язык пошёл бы хорошо, но я далёк от таких областей, поэтому останусь со старыми инструментами. 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
Думаю, callbacks в JS были с самого его рождения. Это ж базовая фича. Потом просто новый синтаксис придумали для них. Так что, даже старый js до 2000 года уже не ясно, как нарисовать в Драконе.
Edit: Даже в вездесущем С можно передавать в функцию callbacks (ссылки на функцию) изначально. Так что, выходит некоторые программы С 70х-80х(к примеру, те же WinAPI приложения на чистом С) в Драконе не понятно как делать.
Не думаю, что в Вавилон-5 вдохновлялись Снеговым. Есть ещё книга Бестера "Человек без лица", вышедшая в 1952. Там главный герой для защиты от чтения мыслей просит придумать ему прилипчивую песню, чтобы у него в голове крутилась. Читал лет 20-30 назад, но всё ещё пару строк в голове осталось: "Ах ты, камбала, не вобла" (есть тут в цитатах: https://ru.wikiquote.org/wiki/Человек_без_лица_(Бестер) )
Спасибо за обзор. Может, где-то и язык пошёл бы хорошо, но я далёк от таких областей, поэтому останусь со старыми инструментами. 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