Проектируем мета-язык для полных идиотов

Сегодня в мэйнстриме модно разрабатывать easy-easy-easy-языки программирования наподобие Go — для команд из тысяч идиотов, которые должны разрабатывать более-менее устойчиво работающий софт в более-менее предсказуемое время, когда сам язык накладывает множество ограничений на свободу разработки. Интересно, что такие языки также довольно хорошо подходят и для задач Artificial General Intelligence — автоматической генерации текстов программ программами по заданной спецификации.

Вот каких общих принципов желательно придерживаться при создании подобных языков для идиотов (а также соответствующих фреймворков):

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

— когда мы комбинируем несколько функций, семантика результата должна быть достаточно сильно близка к семантике каждой из функций;

— структура исходников программы не должна оказывать семантическое влияние на программу — при том, что мы должны иметь мощные механизмы манипуляциями элементами исходных текстов и их рекомбинирования (отмечу, что исследователи этой темы не рекомендуют поддержку схем схлопывания/расхлопывания кода, весьма популярных в современных IDE);

— независимо от того, сколь велик или мал объём всей программы, её код мы строим всегда весьма простыми и очевидными «шагами идиота» (плавный градиент усложнения);

— сколь бы «случайно» мы не писали код (в соответствующем фреймворке), абсолютно должны быть исключены любые ошибки компиляции или времени выполнения (редактор не позволит ввести и сохранить ошибочную конструкцию, а фреймворк всегда тестово интерпретирует код на лету);

— рядовой программист разрабатывает код всегда некими однозначно формализованными «кусочками», которые никак не связаны с общей семантикой программы, о которой ему знать и не обязательно;

— при этом при всём (контринтуитивное утверждение) синтаксическая чистота и интуитивность понимаемости языка для программиста совершенно не обязательны; скорее наоборот, сам язык может быть весьма сложным и удобным для «понимания» прежде всего компьютеру, а не человеку. Потому что от разработчика-идиота не требуется соображать, не требуется включать мозги — он должен выполнять пусть и очень сложную технически, но максимально механизированную работу; даже помнить на память синтаксис ему не требуется — фреймворк сам подскажет, как записать очередной оператор.

Отсюда мы делаем логический шаг — чем больше коллектив из программистов-идиотов, тем больше в нём должно быть сделано акцентов на метапрограммировании.

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

Какой стиль языка для идиотов и для нейросетей тут наиболее пригоден? Мне кажется, что очень хорошо под обе эти концепции подойдут стековые/конкатенативные языки (возможно даже, чистые), исконно поддерживающие соответствующий уровень метапрограммирования. В качестве стека данных на глобальном уровне выступит стек энвайрементов, в качестве стека кода — стек CPS-трансформаций, для примера.

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *