Language Oriented Programming и MPS
Jul. 11th, 2005 08:47 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
exceed_erСегодня было немного времени - скачал новую, самую последнюю версию (160ю) джет-брейновского MPS. Заодно уже поставил на бету 5й IDEA. Прошел туториал по созданию своего языка программирования. Особенно это было любопытно, потому что свои языки и интерпретаторы-трансляторы к ним я уже писал.
Ну, я всецело за и поддерживаю движение в сторону "умных" редакторов, которые не должны ограничивать себя рамками текста программы. Если я где-то в программе вставил цвет, то я бы ожидал возможности отредактировать его в редакторе цвета. А если я пишу SQL SELECT, то хорошо бы видеть в подсказке названия таблиц и колонок в БД, а также обьяснение пути выполнения набираемого селекта. То же самое с именами путей и файлами, ну и т.д. Естественно, хотелось бы иметь возможность такие редакторы и ситуации их вызова настраивать, скачивать и конфигурировать. Скажу больше, такое развитие IDE я вижу, как неизбежное.
Однако в MPS всё немного ушло в экстрим. Текст перестал быть сколько-нибудь текстом, а стал структурно-квадратным:
.
То есть вот там вот в функции никто не даст вам набрать текст просто так - только выбор из заранее известных выпадающих списков. В ячейках не обязательно будут слова - возможны картинки, иконки и даже 3D-модели. Две причины, почему я не буду именно таким пользоваться: (а) я часто пишу программу с конца - еще нет тех конструкций, которые когда-то появятся из моей головы, их не может быть для выбора. Не всегда, но иногда мне это нужно. Можно, конечно, попытаться придумать умную систему, которая догадывается о моих намерениях "наоборот", но в общем случае я не вижу, как это можно стройно включить в концепцию. (б) даже если от меня его далеко спрячут, все равно чуствуется громоздкость и древовидность XML-изации языка. Это удобно писателям IDE, но отнюдь не помогает мне ничего сделать быстрее. И потом, давно-давно это всё уже было - какой-то из экспериментальных редакторов Лиспа конца 80х выглядел именно так. И - "не пошёл". Во Флаше макромедиевском для активскрипта тоже та же система есть. Я ее выключаю немедленно.
Точно также, на первый взгляд, мне не понравилась семантика задания самих языков. Понятно, что они хотят использовать сами себя и писать свой собственный код на своей системе - совершенно верный подход. Но разбиение на модели и языки, которые в свою очередь имеют стрктуры и редакторы - неочевидно. Я не вижу, где тут выигрыш против "традиционного" юниксного подхода с BNF и flex-yacc, или какие там сейчас лексеры - парсеры? Меня всё это скорее запутало. В общем, концептуально продукт весьма сырой. Хотя с большим будущим, я думаю. Просто не в таком виде. Какой-никакой язык мне написать удалось, и он даже подключился куда надо, впрочем. Часа за 4. Но я никому его не покажу :)
Теперь как бы я себе это представлял в идеале. Во-первых, оговорюсь, что моя точка зрения на LOP - это часто полезно. Конечно, каждый хитрый микроскоп ждёт свой большой гвоздь, но кто-то где-то будет использовать это по назначению. Зачем нужен ЛОП?
У того, что мы пишем, обычно есть область применения. У этой области применения обычно своя, особая семантика. Мы же стараемся написать программу не для одного частного случая, а чтобы как можно проще было её подстроить под другие аналогичные. Приведу примеры.
Микшер mp3. Задача - накладывать друг на друга звуковые файлы, иногда уплотняя или растягивая звук, добавлять семплы и лупы. Такую систему можно начать писать с морды, но хороший программист напишет библиотеку с возможностями - фильтры, распознавание бита и т.д. и т.п. -- "движок". Дальше за элементами UI будт располгаться вызова в такую библиотеку. В зависимости от сложности параметров и логики последовательностей таких вызовов сам код может быть совершенно нечитабельный с точки зрения Ди-Джея, даже понимающего в принипах наложения звука. Решением был бы маленький компактный язык, который оперировал бы сэмплами, битами и mp3 как обьектами и позволял непосредственные конструкции типа "на каждый третий бит добавь сэмпл 'кряк' отсюда и до конца дорожки". "На каждый" = foreach, множество перебора - биты дорожки, инкремент 3, действие - "наложить" - всё знакомо... Опишите это же на С++ и, скорее всего, это займет целый экран.
Фотошоп. Фотографии, слои, выборки и маски, фильтры, цветовые пространства. Те, кто работал с графикой, знают как хочется иметь "умный" язык, который будет оперировать картинками с любой глубиной и видом описания точек, чтобы можно было сказать "найди область плавного перелива цветов вокруг текущей точки, создай из нее маску, вдоль внешнего контура расположи на равном расстоянии 72 аттрактора, запусти частицы на 5 сек из текущей точки..." или что-то в этом духе. Вообще-то Фотошоп уже дает макро-язык и SDK. Но они всё ещё далеки от идеала. Хотя проблема видна явно. GIMP справляется чуть лучше.
Нужно ли говорить, что торговля акциями имеет свои, совершенно другие правила, как имеет документооборот в правовой системе. Чем ближе будет язык описания процессов к области применения системы, тем эффективнее будут программы. Вопрос в том, как быстро можно написать язык. Плюс, в MPS правильно определили, что новый язык без "понимающего" редактора теряет как минимум половину своей привелкательности. То есть параллельно с созданием языка хорошо было бы научить какой-нибудь редактор понимать связи в нем. Желательно тот же самый, в котором люди работают обычно.
В общем, я хотел бы видеть следующее. Не надо никаких сверхновых концепций. Пусть будут старые добрые лекс-бизоновые описания базовых конструкций, но с разрешением использовать в будущем языке вместо ASCII-символов обьекты, умеющие себя визуализировать в строку или картинку внутри текста (для экстремалов). Типа "а тута вот имя файла: вот иконка, вот редактор, вот так писать текстом".
С ними надо будет определять ещё и связи для редактора - чтобы знал что и как подсвечивать-предлагать.
И метадату области применения (т.е. если пишем о документах, то типа "существуют папки, они содержат от 0 до * штучек, каждая штучка может быть документом или папкой, у штучки есть имя, у документа - содержимое и т.д.)
А также "входы" в ваш движок по событиям интерпретации кода нового языка - примерно как это делает SAX парсер. Всё.
Я думаю, написать такой плагин в ту же Эклипс займет макисмум полгода у пары хороших девелоперов - учитывая что лексеры-парсеры для джавы уже есть. Так что - ДжетБрейну стоит остановиться и подумать об acceptance и usability.
Что-то я, блин, расписался. Надеюсь, что за моей мыслью всё ещё хоть кому-то удалось уследить.
Upd: линки на тему
http://wesnerm.blogs.com/net_undocumented/2004/06/whidbey_may_mis.html
http://osl.iu.edu/~tveldhui/papers/dagstuhl1998/
http://en.wikipedia.org/wiki/Language_oriented_programming
http://www.onboard.jetbrains.com/articles/04/10/lop/
Upd2: отличные впечатления от новой IDEA5. Самое главное, ничего не испортили! :) Заработала и очень нравится интеграция в SVN. Однозначно лучше французской черепашки, в том числе функционально. Сильно помогают сокращенные пути в именах пакетов. Наконец-то можно дабл-кликом на шапке максимизировать окно с кодом. Стало быстрее. В интерфейсе, на мой взгляд, излишне много черных линий. Но это мелочи, жить можно.
Ну, я всецело за и поддерживаю движение в сторону "умных" редакторов, которые не должны ограничивать себя рамками текста программы. Если я где-то в программе вставил цвет, то я бы ожидал возможности отредактировать его в редакторе цвета. А если я пишу SQL SELECT, то хорошо бы видеть в подсказке названия таблиц и колонок в БД, а также обьяснение пути выполнения набираемого селекта. То же самое с именами путей и файлами, ну и т.д. Естественно, хотелось бы иметь возможность такие редакторы и ситуации их вызова настраивать, скачивать и конфигурировать. Скажу больше, такое развитие IDE я вижу, как неизбежное.
Однако в MPS всё немного ушло в экстрим. Текст перестал быть сколько-нибудь текстом, а стал структурно-квадратным:
.То есть вот там вот в функции никто не даст вам набрать текст просто так - только выбор из заранее известных выпадающих списков. В ячейках не обязательно будут слова - возможны картинки, иконки и даже 3D-модели. Две причины, почему я не буду именно таким пользоваться: (а) я часто пишу программу с конца - еще нет тех конструкций, которые когда-то появятся из моей головы, их не может быть для выбора. Не всегда, но иногда мне это нужно. Можно, конечно, попытаться придумать умную систему, которая догадывается о моих намерениях "наоборот", но в общем случае я не вижу, как это можно стройно включить в концепцию. (б) даже если от меня его далеко спрячут, все равно чуствуется громоздкость и древовидность XML-изации языка. Это удобно писателям IDE, но отнюдь не помогает мне ничего сделать быстрее. И потом, давно-давно это всё уже было - какой-то из экспериментальных редакторов Лиспа конца 80х выглядел именно так. И - "не пошёл". Во Флаше макромедиевском для активскрипта тоже та же система есть. Я ее выключаю немедленно.
Точно также, на первый взгляд, мне не понравилась семантика задания самих языков. Понятно, что они хотят использовать сами себя и писать свой собственный код на своей системе - совершенно верный подход. Но разбиение на модели и языки, которые в свою очередь имеют стрктуры и редакторы - неочевидно. Я не вижу, где тут выигрыш против "традиционного" юниксного подхода с BNF и flex-yacc, или какие там сейчас лексеры - парсеры? Меня всё это скорее запутало. В общем, концептуально продукт весьма сырой. Хотя с большим будущим, я думаю. Просто не в таком виде. Какой-никакой язык мне написать удалось, и он даже подключился куда надо, впрочем. Часа за 4. Но я никому его не покажу :)
Теперь как бы я себе это представлял в идеале. Во-первых, оговорюсь, что моя точка зрения на LOP - это часто полезно. Конечно, каждый хитрый микроскоп ждёт свой большой гвоздь, но кто-то где-то будет использовать это по назначению. Зачем нужен ЛОП?
У того, что мы пишем, обычно есть область применения. У этой области применения обычно своя, особая семантика. Мы же стараемся написать программу не для одного частного случая, а чтобы как можно проще было её подстроить под другие аналогичные. Приведу примеры.
Микшер mp3. Задача - накладывать друг на друга звуковые файлы, иногда уплотняя или растягивая звук, добавлять семплы и лупы. Такую систему можно начать писать с морды, но хороший программист напишет библиотеку с возможностями - фильтры, распознавание бита и т.д. и т.п. -- "движок". Дальше за элементами UI будт располгаться вызова в такую библиотеку. В зависимости от сложности параметров и логики последовательностей таких вызовов сам код может быть совершенно нечитабельный с точки зрения Ди-Джея, даже понимающего в принипах наложения звука. Решением был бы маленький компактный язык, который оперировал бы сэмплами, битами и mp3 как обьектами и позволял непосредственные конструкции типа "на каждый третий бит добавь сэмпл 'кряк' отсюда и до конца дорожки". "На каждый" = foreach, множество перебора - биты дорожки, инкремент 3, действие - "наложить" - всё знакомо... Опишите это же на С++ и, скорее всего, это займет целый экран.
Фотошоп. Фотографии, слои, выборки и маски, фильтры, цветовые пространства. Те, кто работал с графикой, знают как хочется иметь "умный" язык, который будет оперировать картинками с любой глубиной и видом описания точек, чтобы можно было сказать "найди область плавного перелива цветов вокруг текущей точки, создай из нее маску, вдоль внешнего контура расположи на равном расстоянии 72 аттрактора, запусти частицы на 5 сек из текущей точки..." или что-то в этом духе. Вообще-то Фотошоп уже дает макро-язык и SDK. Но они всё ещё далеки от идеала. Хотя проблема видна явно. GIMP справляется чуть лучше.
Нужно ли говорить, что торговля акциями имеет свои, совершенно другие правила, как имеет документооборот в правовой системе. Чем ближе будет язык описания процессов к области применения системы, тем эффективнее будут программы. Вопрос в том, как быстро можно написать язык. Плюс, в MPS правильно определили, что новый язык без "понимающего" редактора теряет как минимум половину своей привелкательности. То есть параллельно с созданием языка хорошо было бы научить какой-нибудь редактор понимать связи в нем. Желательно тот же самый, в котором люди работают обычно.
В общем, я хотел бы видеть следующее. Не надо никаких сверхновых концепций. Пусть будут старые добрые лекс-бизоновые описания базовых конструкций, но с разрешением использовать в будущем языке вместо ASCII-символов обьекты, умеющие себя визуализировать в строку или картинку внутри текста (для экстремалов). Типа "а тута вот имя файла: вот иконка, вот редактор, вот так писать текстом".
С ними надо будет определять ещё и связи для редактора - чтобы знал что и как подсвечивать-предлагать.
И метадату области применения (т.е. если пишем о документах, то типа "существуют папки, они содержат от 0 до * штучек, каждая штучка может быть документом или папкой, у штучки есть имя, у документа - содержимое и т.д.)
А также "входы" в ваш движок по событиям интерпретации кода нового языка - примерно как это делает SAX парсер. Всё.
Я думаю, написать такой плагин в ту же Эклипс займет макисмум полгода у пары хороших девелоперов - учитывая что лексеры-парсеры для джавы уже есть. Так что - ДжетБрейну стоит остановиться и подумать об acceptance и usability.
Что-то я, блин, расписался. Надеюсь, что за моей мыслью всё ещё хоть кому-то удалось уследить.
Upd: линки на тему
http://wesnerm.blogs.com/net_undocumented/2004/06/whidbey_may_mis.html
http://osl.iu.edu/~tveldhui/papers/dagstuhl1998/
http://en.wikipedia.org/wiki/Language_oriented_programming
http://www.onboard.jetbrains.com/articles/04/10/lop/
Upd2: отличные впечатления от новой IDEA5. Самое главное, ничего не испортили! :) Заработала и очень нравится интеграция в SVN. Однозначно лучше французской черепашки, в том числе функционально. Сильно помогают сокращенные пути в именах пакетов. Наконец-то можно дабл-кликом на шапке максимизировать окно с кодом. Стало быстрее. В интерфейсе, на мой взгляд, излишне много черных линий. Но это мелочи, жить можно.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2005-07-12 11:47 am (UTC)Для явы - antlr, javacc, sablecc, например.
сравнишь?
Date: 2005-07-12 12:04 pm (UTC)что проще/приятнее?
мне вот почему то всегда удобнее работать с клавиатуры, и проще тот же dsl на лиспе, например, нарисовать и потом с ним работать. в чем mps лучше?
Re: сравнишь?
Date: 2005-07-12 02:49 pm (UTC)Самое главное, моя самая большая проблема тут - это что после bnf получается язык, который конечный пользователь все же может использовать в notepad'e. С этим же подходом люди привязаны к IDEA (точнее, к MPS). Я не могу дать своим клиентам, даже как опцию, язык, который вынуждает их покупать продукт третьей парти, причем одной конкретной фирмы, без альтернатив. В этом месте BNF выигриывает сразу и сильно - с точки зрения бизнеса.
Кое где, конечно, проигрывает, но об этом позже.
Re: сравнишь?
Date: 2005-07-12 02:51 pm (UTC)no subject
Date: 2005-07-14 09:53 pm (UTC)Спасибо! :)
Date: 2005-07-14 10:49 pm (UTC)Надо бы что-нибудь запостить будет с утра ;-)
Re: Спасибо! :)
Date: 2005-07-15 12:03 am (UTC)no subject
Date: 2005-07-15 12:25 pm (UTC)