Как я создавал язык для преобразования данных вместе с ChatGPT

[impwx]

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

[0ex0]

Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.

Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.

[elaiv]

Вау! Начинаешь читать с эпиграфа, а потом отправляешься в увлекательное приключение через lisp-like языки, Oz и DAG-графы к примерам использования ИИ профессионалом! Получил большое удовольствие и вдохновился прочитанным!

[0ex0]

Спасибо :-)

[tnsr]

Проиндексируйте, плиз.
https://deepwiki.com/ehlyzov/branchline-public

Не могу капчу пройти. (

UPD. Получилось.

[0ex0]

О, не знал о таком проекте, выглядит очень круто, спасибо за наводку!

[korbash1]

Интересно что у вас в целях языка нету autocomplete friendly мне кажется это очень важный пункт, позволяет стереть грань между использованием библиотеки и полноценным UI

[0ex0]

Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например.
Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.

[korbash1]

Иногда возможности автокомплита ограничены синтаксисом языка. Давайте попробую показать на примерах. Самый простой пример — SQL:

SELECT email, age FROM users;

При таком синтаксисе редактор не может подсказать возможные значения колонок для таблицы users. Такой синтаксис был бы лучше:

SELECT FROM users  email, age;

Ещё один пример: допустим, у меня есть функция для поворота вектора на угол a. Я могу оформить её как функцию rotate(x, a), а могу — как метод x.rotate(a). Второй вариант лучше для автокомплита, потому что если я не помню название функции, редактор подскажет её после точки.

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

Из более практичного: было бы круто, если бы ваш язык учитывал JSON Schema (если такая есть) для автокомплита.

понятно что это всё достигается симбиозом между языком и редактором

[0ex0]

Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.

Для описанного вами автокомплита я бы предпочел

FROM users
SELECT email, age ;

Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь.
Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.

Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )

[korbash1]

FROM users SELECT email, age ;

Да так красивее выглядит согласен

Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания.

Вот это очень интересное утверждение. Возможно зависит от задач. А точнее от того сколько раз написанный код будут читать. Если я пишу код чтобы поисследовать данные и я выполню его 1 раз мне очевидно важнее удобство написания (Условно формат Jupiter notebook). Наверное в вашем сценарии предполагается что читать код будут много раз и тогда ваш тезис верный.

Но тут возникает ещё одна мысль, а что если совместить удобство написания и удобство чтения. Что если объект будет в себе хранить и то как его отображать в виде кода. Например чтобы я мог написать выражение как a / b или a.divide(b) а оно при форматирование отобразилось как

(При этом сам код останется как был. Его всегда можно посмотреть и подредактировать в сыром виде) Идея взята из Wolfram mathematics, но уверен она и в других местах встречается.

P.S. я понимаю это имеет слабое отношение к вашему языку и его ниши, но в целом интересно ваше мнение по дизайну языков

[0ex0]

Прощу прощения за долгий ответ, но вот только дошли руки. Я думаю, что возможность иметь адаптированное отображения для кода — это прекрасно и мы точно к этому придём. Причём было бы прикольно иметь различные срезы — для SRE, DBA, инженеров по безопасности, продактов и бизнес и системных аналитиков. Это чуть более высокий уровень чем тот, про который вы пишите, но кажется такие представления могли бы решить много проблем. Довольно часто из кода можно восстановить изначальную постановку задачи и то, каким именно образом она была решения. А имея всё это, можно записать решение в более подходящем для восприятия виде. Я уверен, что так и будет.

Но ведь тоже касается и написания. Если мне нужно решить задачу и у меня есть алгоритм, которым я хочу решить эту задачу, то кажется самое простое что я могу сделать — это описать ограничения задачи и сам алгоритм. На русском/английском используя математические термины или термины предметной области — это не важно. Если есть модель, которая хорошо воспринимает естественные и формальные языки, то так ли важно в какой именно код она преобразует написанное мной? Важно чтобы она смогла передать мне все условия и ограничения своего решения, но ведь для этого даже не обязательно показывать сгенерированный код. Достаточно описать это в лаконичной понятной форме, как это делает Wolfram M.

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

--

Не знаю, ответил ли я на исходный вопрос, но в любом случае, спасибо за него, навёл на мысли )