Comments

А поясните задачу подробнее, сжатое абстрактное описание не совсем объясняет зачем понадобился еще один новый узкоспецифичный язык, дублирующий уже имеющиеся.
Хотелось бы увидеть модель взаимодействия между человеком и программой, и объяснение, какие инструменты необходимы, но не доступны в языках общего назначения.

Да, конечно, современные языки c IDE вполне комфортны для профессиональной работы. Но мы решили не использовать один из наиболее симпатичных. Довольно много причин, поясню может быть самые существенные основания конструирования отдельной грамматики:
1) Во-первых, совершенно неправильно реализовать отдельный интерпретатор для узкого подмножества или модифицированного множества грамматики существующего языка и назвать его тем же именем. Нам не нужна полная мощь вариативность конструкций современного языка, особенно «мульти – парадигменного» со всей трудоемкостью поддержки стандарта в некоторой версии.
2) При эволюции существующих языков совместимость с прошлыми версиями может быть нарушена. Наше базовое требование – полная работоспособность исходного текста (не байт-кода) при неизбежном расширении языка. По этой причине мы зарезервировали под верхний регистр все служебные идентификаторы, чтобы исключить риски попадания пользовательских идентификаторов в будущие зарезервированные слова.
3) У нас своеобразная концепция связывания компонентов в крупные системы, которая пока прямо не воспроизводится в известных нам языках. Частично это можно решить вариантом с условной компиляцией и директивами (pragma) интепретатору, но в итоге получится не очень хорошо.
Чтобы сделать низким порог освоения мы используем хорошо знакомые всем синтаксические элементы, в нескольких следующих статьях расскажу о логике отбора. Здесь я вдохновлен циклом Robert Nystrom по Lox Language craftinginterpreters.com/the-lox-language.html Даже если вы не совсем согласны со всеми тезисами автора по его учебному языку Lox, но сама работа просто замечательная.
Очень хороший вопрос про модель взаимодействия между «человеком» и «программой», собственно с этого всё началось. Мы еще не завершили эту работу даже в концепте, чтобы представить готовый вариант, нам как раз нужен формальный язык для интерпретаций. Если совсем упрощенно, то программы, написанные человеком анализируются и на их основе формируются другие, которые, в свою очередь могут быть модифицированы человеком или другим алгоритмом. Технология не связана с «машинным обучением» в том виде, как его сейчас понимают, но тоже использует семплы в данном случае исходного кода для задач обучения.

Как я понимаю, ваша цель — создать систему, которая может корректировать сама себя, при этом начальное зерно задается программистом. Т.е. утрированно, вы создаете высокоуровневый аналог примитивной машины Тьюринга, которая идя по ленте, технически может перезаписывать части этой ленты для адаптации программы на лету.
Но мне все равно не совсем ясна задача, которая будет решаться такой системой. В статье как пример используется gcd. Мы хотим от системы, которой на вход подана gcd реализация, некоторой трансформации этой программы. Как будет проведена трансформация — на уровне исходного кода, байт кода или ассемблерных инструкций нам не принципиально. Но почему мы хотим трансформацию, почему конкретную трансформацию, и что мы получим как результат трансформации — вот на эти вопросы хотелось бы получить ответы.

Так как мы по определению обладаем интерпретатором, то для случая таких функций как gcd с детерминированным поведением вполне можно умозрительно продумать цель трансформации как получение результата функции с меньшими ресурсами и за меньшее время путем естественного отбора из многих доступных функций с изоморфным поведением. Получив лучшего кандидата, мы можем просто заменить или хотя бы предложить это сделать для менее удачных функций с аналогичным поведением. Уже для этого простого случая мы упираемся в главную проблему. Для выполнения любой адаптации, начиная с распознавания изоморфного поведения мы должны обладать более сложно организованной системой и нет никакой возможности здесь «самому переписать себя». Цели для любой адаптивной системы задаются внешним окружением по отношению к самой системе.

Есть гипотезы, как частным образом решить эту главную проблему для программ, близких к игровым. Здесь очень нужен язык, удобный для экспериментов. Именно поэтому важны те тезисы, которые описаны в статье, в том числе по абсолютной исполнимости однажды написанных программных компонентов при расширении языка.

Очередное испытание GPT-3 завершено успешно. Только один прокол: "Нет" — не слишком удачное название для языка.

Cемантика второго утверждения мне непонятна. Имеется в виду известный фреймворк от Microsoft?

Если уж речь зашла о взаимодействии программных агентов с исходным кодом и генерации кода то собственно диалект Lisp'a был бы отличным кандидатом, какие особенности вашего языка делают его лучшим выбором в вашей задаче?

Согласен, первоначально мы планировали использовать Lisp (Scheme) для механики AI и структурный диалект Basic (например, как в FUZE 4) для листингов программ от человека. Lisp почему-то не очень подходит для паттернов мышления большинства людей. Возможно, если бы дошкольники во всем мире изучали не 2 + 2 = 4, а обратную польскую запись и рекурсию, то всё было бы по другому…

Ну, положим для арифметики можно макрос наваять. Базовые циклы тоже есть, это не хаскел, можно жить без рекурсии, но зачем? Лисп ведь тем и хорош, что для людей можно сделать dsl, при этом сохраняя гомоиконность и полную мощь для машины.
А так не ясно чем это лучше обычного чтовыизучалившколе?

Лисп имеет свою органичную логику, вероятно, не самая красивая идея навешивать дополнения, чтобы его приблизить к «императивному» стилю мышления. На самом деле, если проект получит развитие в части ресурсов, то мы сделаем два комплементарных представления программ: Hi и Scheme c мета-идентификаторами для интеграции.

Вот тема «чтовыизучалившколе» мне кажется очень актуальна. Я видел недавно как школа предлагала архаично выглядещую среду с сомнительным названием «КУМИР». Полагаю, это лучшее средство отбить охоту программировать вообще. А есть ли сейчас такие приложения, которые позволяют быстро в игровой манере с удовольствием на алгоритмическом языке начать программировать игры и головоломки без изучения сложных сопутствующих фреймвороков и библиотек вида XCode (не важно на каком языке)?
Лисп имеет свою органичную логику, вероятно, не самая красивая идея навешивать дополнения, чтобы его приблизить к «императивному» стилю мышления.

ну что вы, лисп мультипарадигменный язык, имеющий в том числе и императивные возможности. Кроме того "лиспов" существует много и создать еще один вполне легко и логично.


А есть ли сейчас такие приложения, которые позволяют быстро в игровой манере с удовольствием на алгоритмическом языке начать программировать игры и головоломки без изучения сложных сопутствующих фреймвороков и библиотек вида XCode (не важно на каком языке)?

как насчет scratch?

Что-то похожее на Scratch по environment но с текстом кода без визуального выбора и настройки lego-подобных блоков?

Лисп использует нотацию "(операция агрументы)", соответственно польская запись является нативной, в современных лиспах что-то поменяли?

Угу, только обратная польская запись это не то же самое, что польская запись.

да, в комментарии этом неточность есть. Слово «обратную» лишнее здесь.
Only those users with full accounts are able to leave comments. Log in, please.