Sergey Dmitriev ([info]sergeydmitriev) wrote,
@ 2003-11-27 20:54:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Current mood:creative
Entry tags:language_oriented_programming

Новый подход к программированию - теперь можно скачать!
Для того чтобы все лучше понимали то о чем я писал ранее, я решил начать выкладывать программу на свой сайт.
Пока это, конечно, очень ранний прототип, поэтому в реальной работе его еще нельзя использовать (это впереди!).
Однако он вполне подходит для иллюстрации излагаемых здесь идей.
Надо заметить, что как и любая программа на свете эта программа является объектом интеллектуальной собственности, и права на нее принадлежат компании JetBrains, что и изложено в файле MPS_license.txt, лежащем в корневом каталоге. Ну а саму программу скачать можно здесь: http://www.jetbrains.com/mps
Вот, а теперь я готов ответить на любые вопросы и комментарии.

Продолжение следует...


(Post a new comment)

а скриншоты можно нашотить ?
[info]dr_klm
2003-12-01 11:30 am UTC (link)
то-ж у меня небось под Linux не пойдет...

К.Л.М.

(Reply to this)(Thread)
Re: а скриншоты можно нашотить ?
[info]sergeydmitriev
2003-12-01 04:22 pm UTC (link)
Под Linux я думаю пойдет, если зайти в каталог bin и запустить команду:
java -cp ../lib/jdom-1.0beta9-20030331.jar:../lib/mps.jar jetbrains.semanticIP000.ide.IdeMain
При условии, конечно, что java 1.4 установлена.

(Reply to this)(Parent)(Thread)
ява-то у меня установлена,
[info]dr_klm
2003-12-02 06:00 am UTC (link)
на лицензии непонятные соглашаться не охота... их-же читать нужно, разбираться... то-ж можно согласиться, что потом так... Программа тоже... Кто его знает ? может Вы вирус какой подсовываете, я-ж Вас не знаю... в лицензии Вашей написано, что никакой ответственности за последствия Вы не несете... А скриншоты ни к чему не обязывают, доступны к просмотру за 3 минуты и, надеюсь, сразу дадут понять о чем идет речь...

Сделайте ! Уверяю Вас, что тогда откликов будет гораздо больше... И желающих скачать тоже, если там есть что скачивать...

К.Л.М.

(Reply to this)(Parent)(Thread)
Cкриншот
(Anonymous)
2003-12-02 11:37 am UTC (link)
Один скриншот есть уже, если кто не видел:
http://www.sergeydmitriev.com/mps/mps_screenshot.gif

(Reply to this)(Parent)(Thread)
Во как...
[info]dr_klm
2003-12-02 11:50 am UTC (link)
Выглядит как какое-то IDE для Явы... А в чем "новый подход" ? Или может просто screenshot показывает какой-то не тот аспект... И что это за серые линии такие ? Это что разделители "ячеек", и для того, чтобы ввести название метода и переменной, теперь нужно не просто набирать, но еще и кликать мышкой постоянно ?

Что-то не пойму я фишки... ;-(

К.Л.М.

(Reply to this)(Parent)(Thread)
Re: Во как...
[info]sergeydmitriev
2003-12-03 02:23 pm UTC (link)
1. Мышкой кликать не обязательно - стрелочки на клавиатуре тоже работают.
2. Это действительно выглядит как IDE для Явы, но фишка в том что не только для Явы - она здесь просто как пример языка который можно смоделировать на этой системе. Кстати в выложенной программе есть и пример другого языка - языка для описания структуры языков.

(Reply to this)(Parent)(Thread)
тогда я не понимаю
[info]dr_klm
2003-12-04 08:18 am UTC (link)
смысл примера, который не иллюстрирует именно новых, уникальных возможностей этого "подхода" (новизну, суть и достоинства которого, я все еще надеюсь уловить). Ведь IDE для Явы написано миллион...

И компилятор Явы, стандартный, javac тоже представляет программу в виде графа... да и любой компилятор с Явы обязан строить такое внутреннее представление, без него невозможно обеспечить хотя-бы перезагрузку функций (методов)... а вот, например, компилятор с Паскаля может без него и обойтись... А уж сколько разных графов и представлений программы, удобных для разных аспектов оптимизации и генерации кода, поддерживает одновременно gcc... там вообще мама-рОдная... ;-)

Ява уже поддерживает массу языков, мыслимых и немыслимых... Можно написать еще сколько угодно, даже я когда-то давно написал... ;-)

К.Л.М.

(Reply to this)(Parent)(Thread)
А была ли попытка?
[info]sergeyzhulin
2003-12-04 11:07 pm UTC (link)
Суть подхода описана здесь, как мне кажется достаточно внятно. Можно еще почитать книжку, чтобы представить себе в каком направлении сейчас движется развитие идеологии программирования.

То что компилятор представляет программу в виде графа Вы здорово подметили. Но обратите внимание, что этот граф не доступен на этапе написания исходного текста программы, что в свою очередь затрудняет осуществление следующих задач: browse source code, aspect programming, context assisting, refactoring, etc. Именно по этой причине, например C++, не имеет более-менее полезного инструмента для рефакторинга исходного кода, именно поэтому существуют инструменты статического анализа исходного кода и т.д.

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

Сергей.

(Reply to this)(Parent)(Thread)
была, и не одна...
[info]dr_klm
2003-12-05 12:29 pm UTC (link)
В том, что там описано я не вижу ничего нового, абсолютно... Да, такие системы не очень популярны (для программирования в широком, не специализированном, смысле), и потому дилетанту может показаться, что их нет... Но могу уверить, что непопулярны они в силу реальных причин, и заново изобретенный велосипед с квадратными колесами так-же будет неудобен, как и изобретенные ранее...

Есть специализированные системы, основанные на передаче управления по данным (то самое, что так многословно описано в том посте), такие как LabView, VHDL, Verilog, SystemC и многие многие многие другие... Их ВПОЛНЕ можно использовать для программирования вообще, любых задач, хоть чисел Фибоначчи... Но этого широкая публика все равно НЕ делает, хоть существуют такие языки чуть-ли не напротяжении всей истории компьютеров вообще... Может, это, конечно, заговор, против господина Дмитриева... но я сомневаюсь...

Да, идею по изобретению еще одного, миллионного в своем роде, велосипеда с квадратными колесами, видимо, мне не дано понять ;-))

К.Л.М.

P.S. И, увы, кроме недоделанного явовского IDE на картинке я пока ничего не вижу... Нет, ну Вы покажите -- новизну, полезные уникальные особенности, цель (кроме почесывания эго господина Дмитриева).. я попробую понять... я понятливый... ;-)

(Reply to this)(Parent)(Thread)
Re: была, и не одна...
[info]kirillk
2003-12-08 08:26 am UTC (link)
Попробуйте отредактировать reference на myFirst в теле метода setValues. И заоодно представьте сколько нужна написать кода, что бы повторить эффект переименования традиционными методами, с построением парсера и с последеющим reference resolve. В общем, все более-менее достойные java ide, о которых вы упоминаете, этим и занимаются, а уж "на лету" никто ничего не переименовывает потому как тяжко это -- из текста строить дерево и его резолвить.

(Reply to this)(Parent)(Thread)
вообще-то я по-жизни
[info]dr_klm
2003-12-08 09:07 am UTC (link)
делал подобные переименования через замену по RegExp в Emacs, и проблем с этим всегда было ноль. Такие переименования довольно редко приходится делать, если дизайн продуман и названия методов стандартизованы... но приходится иногда...

В построении дерева из текста, тем более инкрементальном, на лету, я особенно никаких проблем не вижу...

Надеюсь этот "проэкт" не решает только лишь проблему переименования переменных ?

К.Л.М.

(Reply to this)(Parent)(Thread)
Re: вообще-то я по-жизни
(Anonymous)
2003-12-08 12:24 pm UTC (link)
"переименования через замену по RegExp в Emacs", "Такие переименования довольно редко приходится делать", "дизайн продуман", "названия методов стандартизованы"

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

так что после этого поста ваше кредибилити, и так далеко не высокое, сильно ушло в минус.

творческих вам успехов!

(Reply to this)(Parent)(Thread)
не знаю что там Вам
[info]dr_klm
2003-12-08 12:32 pm UTC (link)
чувствуется, но на интернете Вы могли-бы найти больше чем 1000 строк моего кода, написанного в далеком детстве.

;-)))

Но дело не в моей кредибилити, она не имеет отношения к вопросу -- что-же нового и полезного в этом "подходе"... Хорошо: нового и полезного для человека, для которого инкрементальный парсинг и построение дерева -- детский сад (на что Вы, между прочим, никак не отреагировали) ?

К.Л.М.

(Reply to this)(Parent)(Thread)
Re: не знаю что там Вам
(Anonymous)
2004-01-09 05:04 pm UTC (link)
Такому человеку только остается сидеть и постигать суть тростника.

(Reply to this)(Parent)
comment
[info]kouzdra
2004-01-21 03:29 pm UTC (link)
Я как-то тоже не очень понимаю рулезности именно rename (imho это один из самых бесполезных рефакторингов - среди имеющихся в той же IDEA).

Но пафос "редактирования на лету" мне все равно неясен - та же IDEA afaik поддерживает синхронное с исходным текстом дерево. Если его нагрузить перекрестными ссылками (или прямо в дереве, как это я так понимаю и сделано в этом прототипе, или сбоку ассоциативную табличку приляпать) - rename "на лету" делается с полпинка.

Вопрос только в цене хранения и поддержания этой таблички - но эту-то проблему "новый подход" никак не решает.

Зато, скажем, вот чего не делает ни IDEA ни этот тул - такой простой вещи - вот я захотел в числах Фиббоначи заменить тип LongPair на допустим IntPair (не переименовать, а именно - заменить - предположим оба класса существуют и их самих трогать не планируется).

Ну и есс-но чтобы позаменялось везде, где надо. Такое преобразование мне как-то куда чаще нужно, чем rename. И что тут дает новый подход?

PS: Я в принципе представляю, как эту задачу можно решить, хотя не всегда, конечно.

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

Другой пример (немножко искусственный, но обобщение, я думаю вполне понятно) - есть
int x;
int getX () {return x;}

и мы добавили новый параметр его на
int getX(int x) { return x; }

В принципе проследить можно (обнаружить конфликт имен, просканировать все использования поля x и в каждом из них сделать заново связывание). Но как-то оно уже не очень.

(Reply to this)(Parent)
comment
[info]kouzdra
2004-01-22 10:15 am UTC (link)
По поводу связывания имен - можно я немножко покидаюсь банановыми шкурками:

- во-первых, в той демке, если переименовать параметр конструктора LongPair в myFirst очень забавный результат получается (это более простой вариант проблемы из моего предыдущего письма).

- во-вторых - что уже серьезно - мелкие, но некрасивые глюки со связыванием - есть перманентная фирменная фича рефакторингов IDEA. Я когда ее с год назад взял поиграться, наковырял сразу несколько (я что-то засабмитил, что-то в личном общении передал).

Ну, натурально я сейчас решил проверить - как оно с вариантом этого примера.

Тест #1:
final static int nn = 10;
static int fact (int n)
{
if (n == 0)
return 1;
else
return (nn * fact (n-1));
}

Добавляем в fact параметр char nn = 'a'.
Бага - nn в умножении так и осталось. Программа, понятное дело даже не компилируется.

Поставил последний билд - исправлено. Заменяется на
main.nn

Хорошо - следующая проверка на вшивость - чуть усложняем пример:

static int nn () { return 10; }
static class C
{
static int nnn (int x) { return x+20; }
static int fact (int n)
{
if (n == 0)
return 1;
else
return (nn () * fact (n-1));
}
}

nnn -> rename -> nn.

static class C
{
static int nn (int x) { return x+20; }
static int fact (int n)
{
if (n == 0)
return 1;
else
return (nn () * fact (n-1));
}
}

Ну натурально - естественно это не только не работает, но и не компилируется. Я уже даже думаю - может мне сдельно подрядиться к вам потестировать IDEA - баксов по 100 за багу. Будет очень неплохой приработок :)

Если без шуток - такие ляпы в "умном" редакторе - некрасиво, но не более. 95% их поймаются при первой же компиляции, остальные с некоторым геммороем найдутся в отладчике (благо причину ошибки все-таки можно понять по тексту). Юзер поматерится и поправит руками.

А вот если делать среду, вроде этой демки - там уже все это будет гораздо серьезнее (особенно для коммерческого продукта) - страховки в виде отдельного компилятора нет, по тексту ничего понять в общем случае нельзя (выглядеть может все "как надо", да и возникнуть она может не при редактировании, а при исполнении - просто свяжется не с тем именем в runtime), и простого способа обойти такую ошибку уже нет.

(Reply to this)(Parent)(Thread)
Re: comment
(Anonymous)
2004-01-22 06:42 pm UTC (link)
да, это проблема (и imho первый раз наезд по существу :))

(Reply to this)(Parent)(Thread)
Re: comment
[info]kouzdra
2004-01-22 10:07 pm UTC (link)
Я как раз эти глюки серьезной проблемой не считаю. Точнее - они проблема, но только конкретно JetBrains. Точнее - их низкой культуры надежности и их политики, что надо делать доработки как можно быстрее и плевать на надежность - юзеры баги отловят. Производители компиляторов с этим давно живут и вполне успешно справляются.

Я помню - когда меня сильно удивило, что мои попытки слегка поломать IDEA сразу же оказались успешными. Сейчас - тоже самое. 15 минут - 3 ошибки (одна исправленная в свежем билде и вторая - нет, на самом деле там реально было две независимые баги - #27431 и #27408).

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

Я собственно это письмо к чему пишу - я надеюсь, что когда они версию таки зарелизят, г-н Дмитриев свой ЖЖ возиожно прочитает и может примет это к сведению.

(Reply to this)(Parent)(Thread)
Re: comment
(Anonymous)
2004-01-23 10:36 pm UTC (link)
отвлекусь немного от темы.

1. насчет "низкой культуры надежности" это довольно странно. редко можно найти софт (а тем более IDE) который был бы более отшлифован чем IDEA. а баги есть везде.

2. если очень хочется, то сломать можно все что угодно (разве что какой-нибудь NADA&company будет нелегко). только разве это что-то доказывает?

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

Дима Скавыш

(Reply to this)(Parent)(Thread)
Re: comment
(Anonymous)
2004-01-24 12:51 am UTC (link)
Наркотики раздают? Оргии устраивают?

(Reply to this)(Parent)
comment
[info]kouzdra
2004-01-26 11:04 am UTC (link)
Во-первых - я говорил не "телячьих восторгах" пользователей IDEA, а о восторженном настроении разработчиков.

IDEA - штука весьма удобная. Я бы с большим удовольствием имел бы что-то похожее для C/C++, причем в принцие согласился бы и с намного более высоким уровнем глючности - потому как на безрыбье и рак - рыба.

Но тем не менее в IDEA есть куча мелких неряшливостей (наподобие того, что по кнопочке Help IDEA под Linux довольно долго пыталась вызывать Internet Explorer, или тем, что hilighting там только по расширениям файлов - я обломился на естественном желании научить ее как-то узнавать Makefile) и как минимум с одной довольно крупной дырой (о которой и речь).

И как раз c восторженностью ее разработчиков это связано самым непосредственным образом поскольку свое изделие они воспринимают совершенно некритически.

Что до этих моих ляпов - дело не в том, что они есть. Дело в том что это на самом деле один (но крупный) баг - в IDEA, судя по всему, нет никакого универсального механизма отслеживания и коррекции конфликтов имен при рефакторингах (хотя ничего сложного в этом я не вижу - что-но правдоподбное я вполне могу предложить "с ходу").

Соотвественно - вместо этого есть куча заплаток на конкретные ситуации, на которые юзеры пожаловались.

Не нравятся мне не сами ляпы, а то, что:
1) Я готов на спор за 15 минут найти еще один такой же (и повторить фокус еще несколько раз)

2) разработчики уже минимум около года в курсе этого факта и не считают необходимым хоть что-то с ним делать (но при этом исправляют частные случаи)

3) Это факт довольно сильно и сразу снизил мое доверие в корректности IDEA - если после рефакторинга программа перестала работать - мысль, а не могла где-то IDEA облажаться маловероятной мне уже не кажется. Ну как с багами в компиляторе - попавши быстренько пару-тройку раз, верить в корректность кода перестаешь.

А кроме того - эта дырка имеет самое непосредственное отношение к обсуждаемому вопросу о новом подходе (то есть вопрос - как она в нем должна решаться).

(Reply to this)(Parent)
Re: comment
(Anonymous)
2004-01-24 12:27 am UTC (link)
На самом-то деле все проблемы, перечисленное Антоном, достаточно серьезны. И вся эта затея в своей глобальности очевидным образом не осуществима. Другое дело, что если начать затею осуществлять, то можно для проблем найти частное решение, вполне удовлетворительное для ограниченной области практического применения. В чем польза и состоит.

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

Опять же, если бы не было гордо написано про новый подход, разве стали бы мы его тут так активно обсуждать? :)

(Reply to this)(Parent)
Re: была, и не одна...
(Anonymous)
2004-01-09 05:37 pm UTC (link)
Нельзя ли предъявить этот самый правильный велосипед с круглыми колесами?

А то у меня рука все тянется к шестнадцетиричному редактору, в котором можно все, в том числе и его самого, написать, но, наверно, я ошибаюсь?

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

Никаких принципиально новых идей в программировании нет этак года с 1968. Будем же последовательными, бросим заниматься ерундой и пойдем копать канаву или торговать пирожками :)

(Reply to this)(Parent)
comment
[info]kouzdra
2004-01-19 07:11 am UTC (link)
Тут мне приятель подкинул ссылочку на Вас, поэтому прошу прощения, что несколько "после темы", но возможно будет полезно.

С моей точки зрения идея так себе. Гораздо перспективнее развивать языки традиционным образом. Почему?

Во-первых (но не в главных) - попытки в разных случаях уйти от текстового представления неоднократно предпринимались и ничего хорошего не вышло. _Читабельное_ (по этому критерию отваливается XML) текстовое представление имеет много достоинств - с ним можно работать не только "специаьлно обученными" утилитами. А это очень часто полезно.

Да даже простой пример - поместить оператор по if уже требует какой-то специальной функции.

Вот возьмем Маке - что будет если оставить от него иерархическую структуру и какой-то визуальный редактор - ничего хорошего, потому что основную гибкость ему обеспечивает именно его текстовая природа и довольно развитые макросредства. А Make - утилита очень нужная. У вас вероятно существует некоторая абберация из за длительной работы в Java, которая система замкнутая и которой хватает простого алгоритма билда. Но обычно это не так.

К тому же - еще характерный пример - в Java нет препроцессора и это весьма серьезный ее недостаток. В C# уже есть, хоть и куцый.

Короче говоря текст имеет очень много преимуществ перед деревом или еще каким-то хитрым представлением.

Что до удобства "визуального представления" - я немножко имел дело с Clarion - ничего особенно удобного я в нем не нашел.





Теперь второй пакет возражений - более серьезный:

Есть такой язык Objective Caml, это диалект ML. Я сейчас буду говорить про него очень много, не потому, что я от него в таком уж восторге, а потому, что просто
пример не вполне "траниционного" языка (не сильно другого - статически типизированный язык с вполне обычной схемой компиляции) и уже, как мне кажется, все начинает разваливаться.

В числе прочего интересен тем, что у него есть syntax-oriented препроцессор (Camlp4). Я это к тому, что оно довольно по многим пунктам пересекается с Вашими идеями.

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

Правило грамматики сопоставляется с конструкцией и выполняет связанный с ним код, который должен породить дерево для конструкции (обычно это делает специальными синтаксическми расширениями, но можно и совсем руками)

Вот простенький пример - вводится словечко THERE, которое используется как выражение и раскрывается
в структуру с указанем имени файла и позиции, где оно употреблено (для всяких assert's):

EXTEND
expr: LEVEL "simple" [[ "THERE" ->
let (l,u) = loc in
[Error: Irreparable invalid markup ('<:expr<>') in entry. Owner must fix manually. Raw contents below.]

Тут мне приятель подкинул ссылочку на Вас, поэтому прошу прощения, что несколько "после темы", но возможно будет полезно.

С моей точки зрения идея так себе. Гораздо перспективнее развивать языки традиционным образом. Почему?

Во-первых (но не в главных) - попытки в разных случаях уйти от текстового представления неоднократно предпринимались и ничего хорошего не вышло. _Читабельное_ (по этому критерию отваливается XML) текстовое представление имеет много достоинств - с ним можно работать не только "специаьлно обученными" утилитами. А это очень часто полезно.

Да даже простой пример - поместить оператор по if уже требует какой-то специальной функции.

Вот возьмем Маке - что будет если оставить от него иерархическую структуру и какой-то визуальный редактор - ничего хорошего, потому что основную гибкость ему обеспечивает именно его текстовая природа и довольно развитые макросредства. А Make - утилита очень нужная. У вас вероятно существует некоторая абберация из за длительной работы в Java, которая система замкнутая и которой хватает простого алгоритма билда. Но обычно это не так.

К тому же - еще характерный пример - в Java нет препроцессора и это весьма серьезный ее недостаток. В C# уже есть, хоть и куцый.

Короче говоря текст имеет очень много преимуществ перед деревом или еще каким-то хитрым представлением.

Что до удобства "визуального представления" - я немножко имел дело с Clarion - ничего особенно удобного я в нем не нашел.





Теперь второй пакет возражений - более серьезный:

Есть такой язык Objective Caml, это диалект ML. Я сейчас буду говорить про него очень много, не потому, что я от него в таком уж восторге, а потому, что просто
пример не вполне "траниционного" языка (не сильно другого - статически типизированный язык с вполне обычной схемой компиляции) и уже, как мне кажется, все начинает разваливаться.

В числе прочего интересен тем, что у него есть syntax-oriented препроцессор (Camlp4). Я это к тому, что оно довольно по многим пунктам пересекается с Вашими идеями.

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

Правило грамматики сопоставляется с конструкцией и выполняет связанный с ним код, который должен породить дерево для конструкции (обычно это делает специальными синтаксическми расширениями, но можно и совсем руками)

Вот простенький пример - вводится словечко THERE, которое используется как выражение и раскрывается
в структуру с указанем имени файла и позиции, где оно употреблено (для всяких assert's):

EXTEND
expr: LEVEL "simple" [[ "THERE" ->
let (l,u) = loc in <:expr<
Misc.Loc ($str:!input_file$, ($int:string_of_int l$, $int:string_of_int u$)) >>
]];
END;;

Что до синтаксических контекстов (нетерминалов, доступных пользователю) - их там действительно очень мало - 6 или 7 (выражение, образец, тип, модуль и кое-что еще по мелочи.

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

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

[конец первой части мерлезонского балета]

Антон Москаль msk at tepkom ru

(Reply to this)
comment
[info]kouzdra
2004-01-19 07:16 am UTC (link)
[Вторая часть мерлезонского балета]

Тогда как возможность описывать легко описывать передавать функциональные значения позволяет создавать новые управляющие конструкции просто средствами языка. Вот пример - полиморфное дерево и итератор по нему:

type 'a tree = Empty | Tree of 'a tree * 'a * 'a tree
let rec iter fn = function
| Empty -> ()
| Tree (l, x, r) -> iter l; fn x; iter r

и использование - суммирование узлов целочисленного дерева

let sum t =
let i = ref 0 in
iter (fun x -> i := !i + x) t;
!i

Вот взять Форт - другой крайне неудачный пример - там теоретически можно сделать все, практически же даже такие вот вполне элементарные расширения делаются там с изрядным трудом.



Теперь другая проблема - вообще говоря общепринятой ОО-модели нет и не одной ею живы. Импортировать ОО-модель O'Caml в Java/.NET imho практически невозможно (она тоже статически типизирована, просто основана на несколько других идеях). Да даже реализация SmallTalk видимо приведет к падению эффективности на пару порядков (причина проста - для ST жизненно важна эффективность динамического вызова метода, а reflection в сравнении с ST тормозит тут страшно).

Мое личное мнение - ОО-модель идейно уже мертва и вопрос только сколько она протянет (думаю, долго - вон даже Cobol помирать не собирается, но как-то под нее особенно подстраиваться и пытаться развивать я смысла не вижу - надо уметь ее поддерживать, но не более) - generic programming это фактически попытки импортировать некоторые идеи из современных функциональных языков. Результат выглядит очень коряво и неполноценно (generic's в Java - это Wadler, который один из создателей Haskell, в C# - это Don Syme (ML)).

ML в JVM эффективно транслировать невозможно (потери в разы, если не на порядки), в MS IL лучше но проблем все равно очень много. Впрочем что до JVM, то туда трудно адекватно оттранслировать даже PASCAL (передача параметров по ссылке и вложенные процедуры как параметры - делается, но вместо простой конструкции получается монстризм с активными использованием кучи и довольно изрядным интеллектом транслятора).

Одна из них - типизация и reflection. Насколько я понимаю reflection у Вас является неотьемлемой фичей концепции. reflection держится на предположении, что у каждого выражения есть в runtime тип. Вопрос - есть полиморфная функция:

let compose f g = fun x -> f (g x)

у нее тип compose: ('a -> 'b) -> ('c -> 'a) -> ('c -> 'b)

Или let id x = x (id: 'a -> 'a)

Мы можем ее снабдить указателем на этот тип (хотя это влечет проигрыш в эффективности - ML - язык полностью статически типизированный и информации о типах в runtime "типовые" реализации не содержат).

Более серьезная проблема - я могу создать список из функций:

let inc i = i + 1;
let func_list = [inc; id]

func_list имеет тип (int -> int) list и фукнкция id _как компонент этого списка_ тоже имеет тип int -> int (специализация 'a -> 'a). Важно, что физически это одна и таже фукнция с одним и тем же адресом.

Вопрос - и что тут делать с reflection?

Еще один момент - алгоритм вывода типов ML не является локальным - тип выражения зависит в принципе от сколь угодно большого числа мест в программе (лежащих как до так и после самого выражения). То есть без полного анализа единицы трансляции определить тип выражения невозможно. Что тоже создает трудности.


С другой стороны - пракитчески полное отсуствие необходимости явно указывать типы сильно снижает потребность в каких-то специальных тулах для облегчения этого процесса.

А ML - язык весьма консервативный в смысле типизации. Есть куда более продвинутые
(тот же Haskell).

К чему я это - если вести речь о прогрессе, imho лучше развивать языки, а тулы наподобие IDEA полезны, но в первую очередь как фиксы к неудачным дизайнерским решениям.

Второе - главная польза IDEA в том, что она работает именно со стандартным плоским текстом на Java "as is". Без всяких собственных форматов и прочая. Что позволяет в любой момент слезть с нее и продолжить работать "по старинке". В крупных проектах подвязываться на конкретный тул просто нельзя. Та же демка, которую я видел, вряд ли будет обладать этим свойством.

Вот.

Антон Москаль msk at tepkom ru

(Reply to this)
Резюме
[info]kouzdra
2004-01-19 07:47 am UTC (link)
Краткое резюме:

1) Текстовое представление при прочих равных лучше "бинарного" (или XML-ного)

2) ОО сейчас - плохой источник идей

3) Любой универсальный тул такого рода (равно как и универсальные IL) на самом деле жестко ограничен кругозором автора и языками, которые он имел в виду.

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

3.1) Разнообразие даже традиционных языков гораздо выше, чем кажется

4) Язык (или система программирования) должна в первую очередь структурировать мышление и предоставлять уже готовые средства программирования. Расширяемость будет использоваться весьма ограниченно

4.1) Расширение языка (или системы), сильно выходящее за рамки начальной концепции затруднено по двум причинам

- это задача соизмеримая с созданием компилятора
- гораздо более важно то, что она соизмерима и даже превосходит задачу конструирования языка "с нуля" (намного более сложная задача, нежели реализация уже описанного).

5) Наиболее правильным путем достижения расширяемости является не надстройка метауровня (что равносильно использованию очень неудобного макропроцессора), а упрощение языка и превращение возможно большего числа сущностей в объекты языка пользовательского уровня (first-class entities). Например управляющие конструкции и reflection вполне могут быть таким образом реализованы.

Антон Москаль

(Reply to this)(Thread)
Re: Резюме
(Anonymous)
2004-01-21 06:55 pm UTC (link)
1. Если этот структурный редактор попользовать не вместо, а в дополнение к библиотеке/препроцессору, может получиться не слишком плохо.

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

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

(Reply to this)(Parent)
Re: Резюме
(Anonymous)
2004-01-21 06:58 pm UTC (link)
4. Класс языков, к которым такой структурный редактор может быть с пользой и без страшного геморроя применен, может быть достаточно широк.

(Reply to this)(Parent)(Thread)
Re: Резюме
[info]kouzdra
2004-01-21 08:25 pm UTC (link)
Я никоим образом не хочу сказать, что Сергею следует бросить этим заниматься. Я просто хочу попробовать как-то сделать так, чтобы он не скакал по граблям. Скажем если ограничиться "умным" редактором - то оно точно весьма интересно. Я, например, попробовал приложить его идеи к O'Caml, который я люблю и хорошо знаю - получается довольно любопытно (особенно с учетом того, что там-то есть и бинарное внежнее представление синтаксического дерева и реальная расширяемость синтаксиса). Опять же - и какие-то новые по отношению к Java-образным языкам идеи и запросы появляются.

Я почти уверен, что если взять другие языки (List/SmallTalk/Cecil) и попробовать примерить эту идею на них - тоже получится довольно много и интересного и поучительного (вон тот же Cecil - мультиметоды ведь в Java вставляли). Причем полезного не только для этих языков.

Просто, вполне хорошо видно, что человек знает только Java - и Жаба у него и получается. Только в макияже. А это, как-то, грустно. Особенно если учесть, что прямо у него в фирме есть куча народа, которые вполне в теме.

Антон Москаль

(Reply to this)(Parent)(Thread)
Re: Резюме
(Anonymous)
2004-01-22 02:43 am UTC (link)
Не думаю, что Жаба получается именно таким способом. В самом начале был некий фортообразный стековый интерпретатор. Через Жабу раскручиваться удобнее.

(Reply to this)(Parent)

(Anonymous)
2004-01-19 02:00 pm UTC (link)
насколько я понимаю основная предполагаемая фича это не возможность _расширения_ каких-то языков, а возможность задизайнить новый язык и автоматически получить для него готовый IDE со всякими полезными фичами типа rename.

(Reply to this)(Thread)

[info]kouzdra
2004-01-20 05:43 am UTC (link)
Если бы это было так, у меня возражений не было бы, кроме чисто технических (например требуемая функциональность тоже зависит от языка - в том же ML возможность подсветки фрагментов кода, от которых зависит тип выражения, куда важнее rename).

Но насколько я понимаю, речь идет о мультиязыковой среде наподобие .NET но с "структурным" умным редактором. Я немножко поквочу исходный постинг:

----
В идеале хотелось бы чтобы для данного класса задач можно было бы легко задать язык программирования наиболее близко выражающий понятия соответствующей предметной области. Я здесь описываю возможный способ решения этой проблемы.

Опишем новый подход:

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

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

----
Чем хорош и интересен такой подход?

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

imho "вводить языки, специализированные для данной области" как правило не надо - удачный результат получить очень трудно, а скорее надо развивать универсальные и делать минимальные их специализации (на уровне библиотек и простейших синтаксических расширений).

В конце концов скриптовые языки появились как альтернатива С, который довольно неудобен для большинства приложений. Да и Java - тоже не подарок. Скажем тот же O'Caml у меня почти не вызывает желания прибегать к скриптовым языкам (за исключением ситуации, где не устраивает относительная тяжеловесность цикла compile-link-run). Скорее наоборот - в целом на нем писать получается быстрее и короче. И если выбирать (при прочих равных) что-то Java-образное с ну даже очень умным редактором супротив того же O'Caml без среды вообще - я выберу O'Caml. Преимущестаа удачного языкового дизайна перевешивают в таком сопоставлении практически всегда.

(кстати достоинства ML заключаются именно в исключительно удачном дизайне, а вовсе не в "функциональной парадигме")

-----
Любой язык можно задать набором определений семантических типов, что полностью определяет семантику языка. И наоборот, можно утверждать, что для определения семантики языка достаточно такого набора определений.
-----
Опять же - сильно сомневаюсь. Например, что делать с типизацией в тех же ML (и еще хуже - Haskell - там просто невозможно выполнить программу, не сделав типового анализа - от него зависит семантика)?

(Reply to this)(Parent)(Thread)

[info]kirillk
2004-01-21 06:15 am UTC (link)
Не совсем правда насчет "структурного" редактора. Точнее, это правда, но не всегда.

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

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

(Reply to this)(Parent)(Thread)
comment
[info]kouzdra
2004-01-21 09:46 am UTC (link)
Я как-то не могу вьехать в чем заключается оригинальность этой идеи.

Cамо представление как-то весьма напоминает не то SmallTalk, не то Self (только с continuations вместо более традиционной системы "вызов-возврат"). Я так думаю, что если автор ответит на несколько вопросов, которые сейчас открыты, то оно станет еще более узнаваемо:

1) что с рекурсией (скажем if содержит "ссылку на следующий узел" AKA "continuation", понятно что в случае рекурсии этот же самый узел может быть обработан еще до завершения предыдущей обработки). - Cейчас наверное запахнет SECD-машиной

2) Что такое в этой модели описание переменных (параметров и прочая).

3) Что такое типы данных (только не говорите, что они не нужны - раз они есть в большинстве языков, они должны как-то отражаться)

4) Что такое исполняемый код и замыкание - ну для конкретности - процедурный параметр в Pascal


Что же до "помощи программисту" - хотелось бы конкретики - какого именно рода "помощь" имееся в виду - конкретные примеры.

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


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

Для внутрикомпиляторного IL это нормально, а вот для представления программы - нет.

(Reply to this)(Parent)(Thread)
Re: comment
(Anonymous)
2004-01-21 07:08 pm UTC (link)
Насколько понимаю, автор на такие вопросы сознательно отвечать не желает, считая их деталями конкретного применения. Если детали удалить, ничего, кроме общего формата и, возможно, не слишком большой общей библиотеки для работы с ним не остается. Возможно, я ошибаюсь, но все остальное предполагается оформлять в виде конкретизации-расширения. В какой степени при разумных усилиях это возможно, я судить не берусь. Пусть адепты и энтузиасты пробуют :)

(Reply to this)(Parent)(Thread)
Re: comment
[info]kouzdra
2004-01-21 08:03 pm UTC (link)
Есть такой бородатый анекдот про рабочего с завода, который швейные машинки выпускал. Он все по частям выносил, как ни соберет - все пулемет получается.

Вот тут пулемет уже очень отчетливо вырисовывается. Вопрос только какой именно модели. И будет он хоть как-нибудь стрелять или нет. Дело в том, что тему эту топчут уже лет 40, если не больше (считая от McCarthy с его Лиспом - даже 45) и почти все грабли давно уже изучены и нанесены на карту. Собственно мои вопросы - они как раз из серии типовых граблей.

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

Опять же - я лет 15-20 назад таким баловался (немножко в другом разрезе - "универсальный язык" изобретал). Ну дурак был - надо было книжки почитать. У меня хоть смягчающее обстоятельство было - в СССР с этими книжками была напряженка. Тойсть я не хочу сказать, что сама идея плоха - но так, как дело ведется, точно ничего интересного не выйдет. В лучшем случае - еще один Форт. Да и то - второй по счету. А в принципе - могло бы. Особенно если учесть, что у автора, как я понимаю, есть довольно значительные материальные резервы для осуществления своих затей.

Тойсть - сейчас все-таки без знания тех же ML/Haskell, современных систем типов, лямбда-исчисления и более архаического background - Scheme/Lisp/Smalltalk/Self/Cecil, imho лучше в это не лезть - не потому, что "оно круто", а потому что потом будет очень обидно за "зря прожитые годы". Я по себе знаю.

Вот взять тот же if: вместо наворотов автора (которые, кстати, называются continuation passing style - изобретение, кажется, ван Вейнгардена от середины 60-х) в Smalltalk предлагается следующее решение - есть класс Bool. У него есть два метода - ifTrue и ifFalse, параметрами у них "блок" - фрагмент кода в среде, но без параметров. "Исполняемый узел" в терминологии автора.

Есть два наследника этого класса - True и False, у них есть по одному экземляру - у true метод ifTrue выполняет свой блок, а ifFalse - does nothing. У false - наоборот. if состоит в посылке условию сообщений ifTrue и ifFalse с кодом веток в качестве аргументов. Просто и изящно. Кстати - это не оригинальная придумка авторов ST, а ОО-калька с кодирования булевских значений в лямбда-исчислении (вариант от 30-х годов прошлого века - еще до компьютеров).

Собственно, один из выводов из моих опытов этого рода - не надо ставить глобальные задачи. Там дай-то бог хотя бы несколько частных проблем решить. Скажем сделать унивесальный "интеллектуальный" редактор. Это, хотя бы, реально.

(Reply to this)(Parent)(Thread)
Re: comment
(Anonymous)
2004-01-22 02:40 am UTC (link)
Это все очень понятно :) Но каждому хочется испытать грабли на собственном лбу. Отговаривать я не возьмусь. А вдруг и действительно от долгого употребления грабли не выдержат и сломаются? :)

(Reply to this)(Parent)(Thread)
comment
[info]kouzdra
2004-01-22 05:10 pm UTC (link)
Обидно мне было не потому что долбился об грабли, а потому что рядом с граблями было довольно много вполне удобных дорожек.

То есть что с одной стороны - довольно долго бился об уже решенные проблемы, c другой - что просто не те задачи ставил. Я сейчас очень хорошо понимаю, что даже если бы продолбился, оно бы мало кому было интересно.

Антон Москаль

(Reply to this)(Parent)
Re: Что дальше?
(Anonymous)
2004-06-13 01:28 pm UTC (link)
Всем привет. Я тут у вас новенький буду :)
Вот, обсуждал свои идеи со знакомым, и он дал сюда ссылку.
Я, как заядлый графоман, уже успел тиснуть свои мыслишки по разным местам. А тут, почитывая "Сумму технологий" Лема, задумался - куда идёт программирование, каковы тенденции и каковы движущие силы оново движения.

И стукнуло мне в голову, что мои мысли (например в таком изложении - http://www.fido-online.com/x/_-0?Msg?otv1HG&1009&71& ), которые как я вижу - очень похожи на идеи Сергея, ведут много дальше, чем просто отвязка синтаксиса языка программирования от семантики. Ведут они к концепции по своей мощности не уступающей ООП (вот в таком изложении, например - http://www.fido-online.com/x/_-0?Msg?otv1HG&1009&96& ).

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

Другой, принципиально другой, подход - это "усилить" сознание. Выполнить за него рутинную работу по отслеживанию большого числа взаимосвязей в программе, последствий изменения кода, выполнение формальных и неформальных (с точки зрения языка программирования) предположений и условий. И зачатком этого подхода являются современные IDE типа Idea или Eclipse. И дальнейшее их развитие позволит совершить революцию в программировании аналогично революции ООП. И работа Сергея - это один из первых, необходимых шагов в этом направлении.

(Reply to this)
Новости?
(Anonymous)
2005-05-30 09:34 am UTC (link)
Есть ли в проекте какие-нибудь подвижки с 2004 (или даже с 2003) года?

Хотя первоначальное моё отношение к этому было достаточно критическое, теперь прихожу к подобным же мыслям. Но подошёл немного с другой стороны - запись структурированных даных, так как XML не всем устраивает. Возможно, поучаствовал бы разработке. Есть интересные идеи, как кажется.

Roman Dawydkin, tanmatragmailcom

(Reply to this)