Comments 11
Идея интересная, но ниша не вполне понятна. Если не-технарю понадобится написать скрипт, попросить ИИ в свободной форме написать это на любом популярном языке будет гораздо проще, чем разбираться со специализированным решением без тулинга\библиотек\сообщества.
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
Вау! Начинаешь читать с эпиграфа, а потом отправляешься в увлекательное приключение через lisp-like языки, Oz и DAG-графы к примерам использования ИИ профессионалом! Получил большое удовольствие и вдохновился прочитанным!
Проиндексируйте, плиз.
https://deepwiki.com/ehlyzov/branchline-public
Не могу капчу пройти. (
UPD. Получилось.
Интересно что у вас в целях языка нету autocomplete friendly мне кажется это очень важный пункт, позволяет стереть грань между использованием библиотеки и полноценным UI
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например.
Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
Иногда возможности автокомплита ограничены синтаксисом языка. Давайте попробую показать на примерах. Самый простой пример — SQL:
SELECT email, age FROM users;При таком синтаксисе редактор не может подсказать возможные значения колонок для таблицы users. Такой синтаксис был бы лучше:
SELECT FROM users email, age;Ещё один пример: допустим, у меня есть функция для поворота вектора на угол a. Я могу оформить её как функцию rotate(x, a), а могу — как метод x.rotate(a). Второй вариант лучше для автокомплита, потому что если я не помню название функции, редактор подскажет её после точки.
Кроме собственно синтаксиса хочется, чтобы создатель библиотеки на языке мог гибко настраивать возможные значения для следующего шага через типы или ещё как-то. Например, в этой статье рассказывается про преимущество Fluent-подхода по сравнению с вызовом функций с несколькими аргументами (интересен там самый последний пример).
Из более практичного: было бы круто, если бы ваш язык учитывал JSON Schema (если такая есть) для автокомплита.
понятно что это всё достигается симбиозом между языком и редактором
Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
FROM users
SELECT email, age ;Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь.
Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
FROM users SELECT email, age ;
Да так красивее выглядит согласен
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания.
Вот это очень интересное утверждение. Возможно зависит от задач. А точнее от того сколько раз написанный код будут читать. Если я пишу код чтобы поисследовать данные и я выполню его 1 раз мне очевидно важнее удобство написания (Условно формат Jupiter notebook). Наверное в вашем сценарии предполагается что читать код будут много раз и тогда ваш тезис верный.
Но тут возникает ещё одна мысль, а что если совместить удобство написания и удобство чтения. Что если объект будет в себе хранить и то как его отображать в виде кода. Например чтобы я мог написать выражение как a / b или a.divide(b) а оно при форматирование отобразилось как
(При этом сам код останется как был. Его всегда можно посмотреть и подредактировать в сыром виде) Идея взята из Wolfram mathematics, но уверен она и в других местах встречается.
P.S. я понимаю это имеет слабое отношение к вашему языку и его ниши, но в целом интересно ваше мнение по дизайну языков
Как я создавал язык для преобразования данных вместе с ChatGPT