Метаязыки

форт, схема (с нормальным defmacro). Но чем CL не устраивает? Там своего сахару в качестве нескольких DSL в стандарте просто навалом.

А где же OCaml + camlp4 ? У них вроде с Nemerle одинаковый принцип реализации макрорасширений.

Форт - да, посмотрю еще раз, хотя тогда скорее Factor... CL - он конешно рулит ;) но хочется что-нибудь со статикой, менее тяжелое и изначально с сахаром ;)

2Burbaka На счет камла - можно немного по-подробнее? Вроде ж сам камль не поддерживает МП (по крайней мере в доках не нашел, хотя мож плохо искал)... Да, и желательно чтобы оно было в языке изначально, а не шло расширением... ;)

Всё, погуглил ;) camlp4 - интересная штука, правда всеж препроцессор... В принципе тоже вариант, хотя в лиспе оно элегантнее...

> но хочется что-нибудь со статикой, менее тяжелое и изначально с сахаром ;)

Статическая ML-подобная система типов все таки очень хороша. Сам сейчас балдею :) Возможности достаточно большие, а затрат на этапе рантайма почти нуль :) Ну разве только памяти жрет малость.

> На счет камла - можно немного по-подробнее? Вроде ж сам камль не поддерживает МП

Caml поддерживает метапрограммирование при помощи специального стандартного препроцессора camlp4. Описалово легко найдешь в инете.

Препроцессор работает на уровне синтаксического анализатора (как и в Nemerle). Т.e. ты пишешь программу на специальном метаязыке, которая расширяет стандартную грамматику caml-а, определяешь правила трансляции этого расширения в обычный caml. Таким образом ты расширяешь язык добавляя в него синтаксический сахар.

Далее все стандартно. Препроцессор пробигает исходник, находит в нем предложения, соответствующие расширенной грамматике и транслирует их в обычный нерасширенный caml. Оттранслированный код передается компилятору.

Такие дела

> Всё, погуглил ;) camlp4 - интересная штука, правда всеж препроцессор... В принципе тоже вариант, хотя в лиспе оно элегантнее...

На мой взгляд camlp4 это попытка пойти именно по лисповскому пути, но применительно к caml. Там очень четко прослеживаются аналогии. Но в силу сложной синтаксической структуры языка получился такой вот крякозяблик. На мой взгляд достаточно кривой :) Впрочем как и в Nemerle :)

Ну в принципе это неплохо (отделение макров от самого кода) ;) Была даже идея написать свой метаязык с т.н. "модулями", чтобы метапрограмминг был разрешен только в этих модулях; бОльшую часть языка определить через модули, сделать например модуль FP без побочных эффектов, еще модули для императивщины и ооп; если подключить все 3 - получится камль =) Это дело сходу решает проблему расширений языка - например в том же хаскелле есть стрелки как расширение, очень удобные для FRP и многих других вещей, но с другой стороны все уже сделано на монадах, поэтому в будующий стандарт стрелки не войдут; с одной стороны это хорошо - будет только идеология монад, но с другой не будет стандарта на стрелки, значит мало где они будут поддерживаться, ну и совместимость никто не гарантирует; и таких расширений много. А средствами метапрогания можно было бы просто сделать еще один модуль, но с другой стороны лепить макры везде где попало - не есть рулез. Ну и бывают места, где удобнее чистое фп или ооп... В общем очень хотелось бы иметь такой язычок ;))

Я сам плохо понимаю почему тут все так фанатеют от идеи метапрограммирования. Оно конечно дает в ряде случаев ощутимый выигрыш, сам убеждался, но применение его на практике весьма ограничено. Иногда удобно, но не более.

Я имею еще более малый опыт с этим делом, но понял что оно сразу решает многие проблемы:
1) Расширения языка (см пост про хаскель - имхо это очень важная тема)
2) Экспериментирование с языком благодаря вынесению в модули бОльшей части языка (в ядре (компиляторе) должен остаться вообще самый минимум)
3) Использование различных парадигм в _чистом_ виде и совместно - ФП и логическое прог-е например, а ведь из-за этого создавали новые языки - Curry, Mercury и т.д.

ЗЫ Кажется все идеи тривиальны однако я не знаю ни одного подобного языка...

На мой взгляд основное слабое место всех этих идей - сложность. Банальная сложность в человекочасах и днях.

Что выгоднее реализовать программу на чистом языке X или написать расширение MetaX к языку X и только потом реализовать программу на MetaX ?

А если расширение MetaX тоже нетривиально, его надо будет основательно продумать, реализовать и отладить. А если допустил фундаментальную ошибку и неточность при проектировании MetaX, такую что все ранее написанные на MetaX программы необходимо будет переписывать

И т.д.

У меня имеются некоторые сомнения в особой эффективности этого подхода.

Ну это так ... мысли в слух. Щас еще набегут, заклюют ... черти.

В любом случае спасибо что поделился соображениями :)

Вас не посещала мысль, что то время которое вы тут затратили на болтовню, можно было потратить на написание хорошего С кода?

Меня последнее время раздражают языки высокого уровня, прежде чем написать тривиальную программу, тебе сто раз надо подумать: а как сделать лучше, а не засунуть ли это в класс, а может это как-то по другому сделать, а какой класс лучше заfriend'ить, а стоит ли это вообще делать, может лучше его саб классом сделать?

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

Это даже согласуется с теорией - на языке высокого уровня нету "самого оптимального" решения, есть "вкус" писать так или иначе, а оптимально ли это будет решать компилятор/транслятор. Например, что быстрее ++i или i++? Первое? Ответ не верный. Верного ответа нету, пока вы не посмотрите в исходник каждого из этих операторов. Может ++i работает по очень медленному алгоритму, и вся оптимизация передачи аргумента ссылокой идет на смарку. Хорошо, тогда вы используете i++, а компилятор, по привычке, вдруг вам "оптимизирует" это до ++i. Вот спасибо. Таких примеров куча.

С другой стороны, машинный код - вот он *может* быть максимально оптимальным для данной архитектуры. У машинного кода нету ветвлений решения.

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

Кстати, я не одинок в своих суждениях. Дональд Эрвин Кнут (с его авторитетом спорить никто не будет?) не зря писал алгоритмы на MIX ассемблере. Ох не зря...

> но применение его на практике весьма ограничено

Если брать не метопрограммирование а languge-orientired-programming (который с помощью метапрограммирование осуществляеться проще всего), то имхо оно должно применяться постоянно в любом не тривиальном проекте.

> На мой взгляд основное слабое место всех этих идей - сложность. Банальная сложность в человекочасах и днях.

> Что выгоднее реализовать программу на чистом языке X или написать расширение MetaX к языку X и только потом реализовать программу на MetaX ?

(В продолжение предыдущего поста)

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

> Меня последнее время раздражают языки высокого уровня, прежде чем написать тривиальную программу, тебе сто раз надо подумать: а как сделать лучше, а не засунуть ли это в класс, а может это как-то по другому сделать, а какой класс лучше заfriend'ить, а стоит ли это вообще делать, может лучше его саб классом сделать?

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

> Я заметил такую вещь, на Си получается написать решение в разы быстрее, чем на самом "заточеном" для этой задачи языке. Количество ветвлений решения задачи, на языке низкого уровня, намного меньше (если писать более или менее оптимально).

Очень странно. Видимо просто у тебя привычка такая.

> Это даже согласуется с теорией - на языке высокого уровня нету "самого оптимального" решения, есть "вкус" писать так или иначе, а оптимально ли это будет решать компилятор/транслятор. Например, что быстрее ++i или i++? Первое? Ответ не верный. Верного ответа нету, пока вы не посмотрите в исходник каждого из этих операторов. Может ++i работает по очень медленному алгоритму, и вся оптимизация передачи аргумента ссылокой идет на смарку. Хорошо, тогда вы используете i++, а компилятор, по привычке, вдруг вам "оптимизирует" это до ++i. Вот спасибо. Таких примеров куча.

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

> С другой стороны, машинный код - вот он *может* быть максимально оптимальным для данной архитектуры. У машинного кода нету ветвлений решения.

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

> А еще бывает меня даже посещают жуткие мысли, что если основательно выучить ассемблер, набить руку, я имею ввиду - научиться *думать* на каком-либо ассемблере, то с помощью него можно будет решать поставленную задачу еще быстрее! Потому как самое оптимальное решение всего одно - осталось его только скопировать из головы, того и успевай жать кнопки.

Желаю успехов в этом по истине джедайском деле.

> Кстати, я не одинок в своих суждениях. Дональд Эрвин Кнут (с его авторитетом спорить никто не будет?) не зря писал алгоритмы на MIX 3ассемблере. Ох не зря...

Вот как то монописуально на чём писать алгоритмы на C или асме или языке того же уровня... А если это не алгоритм а сложная система?

> Например, что быстрее ++i или i++?

Какая нахер разница??? И то, и другое выполняется настолько быстро, что заметить не получится.

> Я заметил такую вещь, на Си получается написать решение в разы быстрее, чем на самом "заточеном" для этой задачи языке.

Э-э-э... неумение писать?

> Проще реализовать язык(и) отвечающий специфики данной прикаладной области (а это чаще гораздо проще сделать с помощью метаязыка) а потом реализовать логику на этом языке.

Вопрос насколько трудно спроектировать/реализовать/отладить проблемно-ориентированный язык? И кто это будет делать?

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

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

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

Особенный геморой возникнет когда выяснится что для дальнейшего развития программы имеющийся проблемно-ориентированный язык надо нафиг переделать. А ведь такое сплошь и рядом :)

> если основательно выучить ассемблер, набить руку, я имею ввиду - научиться *думать* на каком-либо ассемблере, то с помощью него можно будет решать поставленную задачу еще быстрее!

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

> Вопрос насколько трудно спроектировать/реализовать/отладить проблемно-ориентированный язык? И кто это будет делать?

Легче лёгкого. Правда сложно сделать это правильно. Но для этого и нужны программисты (а не быдлокодеры). Давай любой пример (но не сильно сложной области) попробую сходу чтонить придумать:)

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

У регулярных выражений есть чёткая математическая основа. И я бы не сказал что это простой DSL. Да и вообще если ты не заметил в Unix с давних времён повсеместно используються DSLи, но это называеться "миниязыки".

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

Ну для сложной области нужно сделать максимально гибкий и расширяемый язык.

> Особенный геморой возникнет когда выяснится что для дальнейшего развития программы имеющийся проблемно-ориентированный язык надо нафиг переделать. А ведь такое сплошь и рядом :)

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

> Кстати, я не одинок в своих суждениях. Дональд Эрвин Кнут (с его авторитетом спорить никто не будет?) не зря писал алгоритмы на MIX ассемблере. Ох не зря...

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

Грубо говоря - для описания _алгоритмов_ никакие языки, кроме императивных, не подходят by design. А ассемблер - самый простой императивный язык, и, к тому же, будучи описан для "искусственной" машины, он не подвержен устареванию.

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

Не понимаю, как можно *читать* *техническую* литературу? Я использую книги как справочник, не более.

Хотя, вроде, "Предисловие" я читал и цитаты "для описания _алгоритмов_ никакие языки, кроме императивных, не подходят" не встречал. Я почему-то уверен, что алгоритмы можно писать и в чисто функциональном языке. Хотя, покажите мне четкую границу, линию.

> Мнда, это тебя видимо раздражает ООП, дык кого оно не раздражает.

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

LISP был в авангарде в 80-ых, но потом он тихо подвинулся со сцены. Настала очередь С++, бум, и многие поддались. Все старательно учили С++. Далее пришла мода на Java, и все старательно начали учить Java. Потом концепция .Net с языком C#.

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

И ведь *по сути* эти все новые языки жизнь-то не облегчают! Никто и никогда не использует настоящие метаязыки в промышленности. Вспомните VHDL, Verilog -- это языки, которые, по сути, должны быть построены на основе метаязыка. Но ведь нет! Их писали с нуля, и никакие мета-концепции не применялись и не будут.

Такое ощущение, что новые языки создаются тогда, когда программисту становиться скучно. ;-)

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

А я и не задумываюсь. Когда в языке оптимальное решение только одно, задумываться не приходиться. ;-)

Даже если судить по этому форуму. Много раз тут поднималась темы, "как бы сделать этот код в более функциональном стиле". Или там "Что тут лучше использовать монады или <бла-бла>"

http://www.linux.org.ru/view-message.jsp?msgid=1491112
http://www.linux.org.ru/view-message.jsp?msgid=1288257
<дальше лень искать>

...Уделить *языку* и своему стилю столько внимания, вместо того, чтобы больше подумать об алгоритме... Пфф..


> Нефиг тратить своё драгоценное время на то чтобы оптимизировать то
> что существенно не повлияет на производительность

Встречный вопрос - нафиг тратить свое время на то, чтобы изобретать все новые языки, термины, оптимизировать стиль языка, что существенно не повлияет ни на производительности ни на читабельность/maintainable'ность кода? Чем больше всего придумаешь - тем быстрее сам в этом запутаешься.

> А если это не алгоритм а сложная система?

Например? Мне трудно представить что-либо не поддающееся законам логики. ;-)

> Меня последнее время раздражают языки высокого уровня, прежде чем написать тривиальную программу, тебе сто раз надо подумать: а как сделать лучше, а не засунуть ли это в класс, а может это как-то по другому сделать, а какой класс лучше заfriend'ить, а стоит ли это вообще делать, может лучше его саб классом сделать?

Аргументация офигенная. "Меня оно раздражает потому, что мне трудно принять правильное решение". Ну, а нетривиальные программы, с ними-то что делать? Назад к ассемблеру, "надо только руку набить"? Наверно, на самом деле необходимости не было от ассемблера уходить к высокоуровневым языкам, всё дело, оказывается, в том, что все двоешниками оказались. Так что ли?

> Я заметил такую вещь, на Си получается написать решение в разы быстрее, чем на самом "заточеном" для этой задачи языке.

Ну, "мужики-то и не знают". (c) Одного примера опровергающего утверждения будет достаточно? Возьми некую абстрактную простенькую задачку под веб. Да у тебя на начальном этапе, когда ты будешь выковыривать POST / GET параметры и делать урл-декодирование писанины будет в разы больше, чем на. Или возьми специально заточенный язык SQL. Уверен, что короче / проще выйдет в терминах си описать выборку с учётом всех отношений между задействованными множествами и указанием всех агрегатных функций?

Спорить не с чем, ибо кроме твоих ощущений и эмоций в твоих словах нет ничего :)

> Аргументация офигенная

Уж извините, какую нашел... ;-)

> Возьми некую абстрактную простенькую задачку под веб.
> Да у тебя на начальном этапе, когда ты будешь выковыривать POST / GET
> параметры и делать урл-декодирование писанины будет в разы больше, чем на.

Вот тут искреннее Спасибо. Я тоже об этом задумывался, и пришел к выводу, что все дело в библиотеках. Есть ведь fcgi:
http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch2c.htm

Но действительно нету распространенной библиотеки, которая бы позволяла делать рутину быстрее (так называемый "сахар" в С понимании). Я повторюсь - все дело в библиотеках, а язык ИМХО новый и для веба не нужен.

Но, тут меня надо правильно понять, я ведь не говорю, что язык должен быть всего один. Нет, не один. Можно 2. Можно 3. Да хоть 10. Но не сто и не двести. Тысячи уже есть сейчас, а с метаязыками изобретут миллион! И кто потом будет эту мешанину понимать?

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

> Я повторюсь - все дело в библиотеках, а язык ИМХО новый и для веба не нужен.

> Для кого вы пишете свой новый язык (основанный, конечно, на метаязыке)? Для себя? Тогда хорошо. Но если для других - будьте гуманней, не изобретайте новых сущностей.

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

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

То это зависит только от вас, и ни как от того языка, на котором вы писали.

Но, тут меня надо правильно понять, я ведь не говорю, что библиотека должна быть всего одна. Нет, не одна. Можно 2. Можно 3. Да хоть 10. Но не сто и не двести. Тысячи уже есть сейчас, а с языками высокого уровня изобретут миллион! И кто потом будет эту мешанину понимать?

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

> Спорить не с чем, ибо кроме твоих ощущений и эмоций в твоих словах
> нет ничего :)

Скорее всего крик души. ;-) Потому как языков много, а по сути все одно и то же. Везде. Устал уже рассчитывать на нечто революционное, а видеть лишь однообразие.

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

Так вот, смотрю на "реальные" проекты написанные на LISP'e (плагины Emacs'a) и думаю... ведь чистая императивщина!! Не впечатляет. Только синтаксис поменяли. Нету там ничего нового.

Смотрю на готовые проекты написанные на хаскелле (http://www.haskell.org/haskellwiki/Haskell_in_practice), и вижу тот же процедурный стиль! Ну задолбало! Если уж природа человека - процедурное мышление, то может не надо себя мучить?

И прошу заметить, я не о себе говорю. Я не мучаюсь. Мучаются те, кто "тужиться" писать в функциональном стиле, а выходит вся та же императивщина. Выглядит смешно.

> Встречный вопрос - нафиг тратить свое время на то, чтобы изобретать все новые языки, термины, оптимизировать стиль языка, что существенно не повлияет ни на производительности ни на читабельность/maintainable'ность кода?

А вот и повлияет. Есть такой закон один и тот же программист делатет примерно одно и тоже число ошибок на N строк в любом языке. Т.е. если DSL короче общего языка в 5 раз. То в коде реализующим один функционал на DSL будет в 5 раз меньше ошибок чем в коде на неспециализированном языке.

> Например? Мне трудно представить что-либо не поддающееся законам логики. ;-)

Хотя бы пример - компилятор. Что ты будешь юзать чистый C или всё же что-то типа yacc (вот пожалуйста страрый юникс dsl).

> Т.е. сонмы новых библиотек на все случаи жизни - это нормально (херня,
> что 80% из них повторяют 80% функциональности из остальных). А свой
> язык для спец. задачи - это новые сущности?

1. Кто просит писать повторяющиеся библиотеки? Не надо этого делать.

2. Библиотека и язык это совершенно разные вещи. Вменяемая библиотека не подменяет семантику всего остального, что есть в тексте программы! Метапрограммирование же *основано* на изменении семантики кода!

> То это зависит только от вас, и ни как от того языка, на котором вы писали.

Точно не зависит от языка? Brainfuck? Что и требовалось доказать - язык все же имеет значение.

> Скорее всего крик души. ;-) Потому как языков много, а по сути все одно и то же. Везде. Устал уже рассчитывать на нечто революционное, а видеть лишь однообразие.

Не так быстро... :)

Интерфейс между машиной и человеком медленно движется от 010101 к человеческому языку. Нравится тебе это или нет, но это так и так и будет продолжаться.

И по мере продвижения по этому пути задачи тоже будут меняться. Ну не будут на языке хрен знает какого уровня писать блокнот, нортон и 1С :)

А ты хочешь новый инструмент для решения старых задач :)

Хочешь чего-то хоть чуть-чуть революционного - можешь посмотреть на рефал. Но он не поможет тебе админить сервера и учитывать кадры :)

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

> Т.е. если DSL короче общего языка в 5 раз.

Где? Ну покажи мне настоящий, 1-в-1 (у проектов должна быть идентичная функциональность), проект на Си и на DSL, и сравним их вместе, по размеру, по наглядности... Только прошу, не надо мне показывать example'ы подсчета факториала или чисел Фибоначчи. ;-)


> То в коде реализующим один функционал на DSL будет в 5 раз меньше ошибок

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

> Что ты будешь юзать чистый C или всё же что-то типа yacc

Ох... неудачный пример ты выбрал. Если мне не изменяет память, разработчики GCC переписали парсер С++ в ручную на Си (это я точно знаю. А про С парсер не уверен, но ИМХО он всегда был рукописным).

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

> 1. Кто просит писать повторяющиеся библиотеки? Не надо этого делать.

Неа, ты "не догнал". Повторяются не библиотеки, а функции в них. И лекарство только одно (в пределе) - одна библиотека - одна функция. :) Жжжуть ...

> 2. Библиотека и язык это совершенно разные вещи.

И то и другое - информация. И её "пруд пруди" как не крути. И либо жёстко ограничивать число языков каким-либо неизменным критерием, либо их число всё равно будет расти по мере появления новых задач концептуального плана. Начнёшь с 2-х - 10-ти, закончишь теми же тысячами, а то и более :)

> Точно не зависит от языка? Brainfuck? Что и требовалось доказать - язык все же имеет значение.

Имеет конечно. Иначе бы их не писали. :) Но при написании _плохого_ кода первостепенен кодер. (ругаться можно на _любом_ языке - языки виноваты?)

> Где? Ну покажи мне настоящий, 1-в-1 (у проектов должна быть идентичная функциональность), проект на Си и на DSL, и сравним их вместе, по размеру, по наглядности... Только прошу, не надо мне показывать example'ы подсчета факториала или чисел Фибоначчи. ;-)

Так не с чем сравнивать! Тебе же уже говорили... Где сишные аналоги SQL, make-файлов и так далее? А языки разметки - языки?

> Легче лёгкого. Правда сложно сделать это правильно. Но для этого и нужны программисты (а не быдлокодеры). Давай любой пример (но не сильно сложной области) попробую сходу чтонить придумать:)

Давай попробуем :) Я тут на досуге продумываю маленький язычок для высокоуровневого описания графического интерфейса пользователя. Задача такая:

- Есть объектная модель данных описывающая определенную предметную область. Каждой сущности предметной области ставится в соответствие элемент модели с определенными характеристиками. Связи между сущностями отражаются в виде ссылок одного объекта на другой. Возможные виды связей "1 к 1", "1 к M" (в обе стороны), "M к M". Модель может динамически изменяться.

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

- Есть некий базовый императивный язык в котором есть примитивы для работы с моделью данных.

Задачка: Разработать высокоуровневый язык описания графического интерфейса просмотра и модификации ранее описанной модели данных. Язык должен легко интегрироваться с базовым императивным языком.

Это вполне реальная (всмысле полезная) задачка :) Кстати наверняка есть какие-то готовые решения.

> Ну для сложной области нужно сделать максимально гибкий и расширяемый язык.

Вот это и сложно на мой взгляд. Разработать "правильный" язык сложнее чем написать "правильную" библиотеку. А написать правильную библиотеку достаточно трудно :) Чего стоит, например, MFC от одной небезызвестной компании :)

> Где? Ну покажи мне настоящий, 1-в-1 (у проектов должна быть идентичная функциональность), проект на Си и на DSL, и сравним их вместе, по размеру, по наглядности... Только прошу, не надо мне показывать example'ы подсчета факториала или чисел Фибоначчи. ;-)

На сайте rubyonrails.com смотри скринкаст о блоге за 20 минут - и напиши тоже самое на C. RoR - в большей своей части набор DSL. Опятьже смотри DSL для создания парсеров. Далее весь SQL-код замени на прямой доступ к структуре БД через С. Потом скажем все расширения firefox перепиши на C, и емакс заодно. Ну это так на вскидку.

Вот это ещё почитай: http://www.faqs.org/docs/artu/minilanguageschapter.html

> То в коде реализующим один функционал на DSL будет в 5 раз меньше ошибок

>> Ой как спорно... Но мне лень это оспаривать, так как мы будем говорить о сферических конях в вакууме.

Ну это исследование такое было вообще-то смотри по вышеприведённой ссылке.

> Ох... неудачный пример ты выбрал. Если мне не изменяет память, разработчики GCC переписали парсер С++ в ручную на Си (это я точно знаю. А про С парсер не уверен, но ИМХО он всегда был рукописным).

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

ничего не могу скзать, об этом не знаю...

> Интерфейс между машиной и человеком медленно движется от 010101 к
> человеческому языку.

Если это движение и началось, то ИМХО это очень не правильно. С изобретением мозг-коннектора, я обещаю, мы все выучим RISC комманды. Этому будут учить в школе -- общаться со встроенным чипом. Нас будут обучать "складывать" придуманные функции и процедуры в специальный отдел мозга, а потом мы будем всю жизнь придумывать себе нужные функии, библиотеки и пользоваться ими. У каждого человека за его жизнь будет появляться своя "операционная система", которую он сам сотворил. Но это будет не завтра.

> Ну не будут на языке хрен знает какого уровня писать блокнот

Согласен. Но! На мета и функциональных языках сейчас пишут в том числе и блокнот (emacs ;-).

> чуть-чуть революционного - можешь посмотреть на рефал

Нет нет и нет. Это не революционное! Это чистая математика, которую я проходил в 5 классе. А какой там синтаксис этой математики меня слабо волнует. Хоть "формулы на листке бумаги" хоть Си, хоть хаскелль.

> Ты того, отдохни, отоспись, развейся.

Thanks, постараюсь. ;-)

> Если это движение и началось, то ИМХО это очень не правильно. С изобретением мозг-коннектора, я обещаю, мы все выучим RISC комманды.

Да нет, скорее этот коннектор по э.м. колебаниям в чайнике будет раньше тебя понимать, что ты сейчас захочешь, вспомнишь или подумаешь ;)

> У каждого человека за его жизнь будет появляться своя "операционная система", которую он сам сотворил. Но это будет не завтра.

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

> На мета и функциональных языках сейчас пишут в том числе и блокнот (emacs ;-)

Хмм, ты можешь представить себе формат конфигурационного файла и размер парсера для него _аналогичной_ функциональности? (мы сейчас не про её необходимость, да? :)

> Повторяются не библиотеки, а функции в них.

Ктож тебя просит писать повторяющиеся функции в новых библиотеках? Не делай этого. Решение проще некуда.

>> 2. Библиотека и язык это совершенно разные вещи.
> И то и другое - информация.

Ну знаешь... С такой точкой зрения просто нельзя спорить, и можно заканчивать разговор, потому как я согласен. ;-) Но если спуститься с небес то библиотеки и языки -- совершенно разные вещи. И оба есть информация. ;-)

> Но при написании _плохого_ кода первостепенен кодер.

Я не говорю о плохом коде. Код может быть замечательный, а вот язык отвратительный.

> С такой точкой зрения просто нельзя спорить, и можно заканчивать разговор, потому как я согласен. ;-)

"Что и требовалось доказать..." :)

> Код может быть замечательный, а вот язык отвратительный.

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

Т.е. тебе нужен язык для генерации визуального представления на основе данных. Т.е. View из MVC. Для html-а угадай куда я тебя пошлю, хотя это не критично. любой шаблонизатор подходит.

Для GUI. Берём руби, петон ил тикл раз.(этим решаем задачу лёгкой интегарации с базовым языком). Ну и делаем:

Layout.new { |l| add GUI::Tree.new(categories)

categories - ссылка массив данных .....

Но только я не очень представляю исходную предметную область.

> Т.е. инфу "арифмометр" должен от тебя получить, распознать,
> обработать, и вернуть тебе в понятном для тебя виде.

Bingo!! Именно ассемблер == "арифмометр"! add, sub, inc -- проще не придумаешь! Ты вторишь моим мыслям. Потом ты будешь вызывать чтото вроде

mov r0, #зарплата
mov r1, #жена_дети_налоги
swi хочу_машину

Функцию "хочу_машину" ты написал на уроке математики еще в школе, упражнение называлось "рассчитайте сколько вам потребуеться времени на приобретение автомобиля, если у вас есть жена, трое детей + налоги с зарплаты".

И прошу заметить у тебя перед глазами не будет виртуального редактора, команды ты будешь посылать мыслями, даже не задумываясь и не помня, что это называеться mov или add или sub.

> ты можешь представить себе формат конфигурационного файла и размер
> парсера для него _аналогичной_ функциональности

Нет, я не знаю как убить этого монстра. ;-) Но есть куча других редакторов, написанных на Си (vim!). А vim использует самый обычный императивный язык для плагинов. В емаксе же, ты пользуешься функциональным языком в процедурном стиле. Фу.

> В емаксе же, ты пользуешься функциональным языком в процедурном стиле. Фу.

То что лисп(тем более emacs лисп) это функциональный язык - это очень распространённой заблуждение. Это очень хороший ипмеративный язык.

> Bingo!! Именно ассемблер == "арифмометр"! add, sub, inc -- проще не придумаешь! Ты вторишь моим мыслям. Потом ты будешь вызывать чтото вроде...

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

> Функцию "хочу_машину" ты написал на уроке математики еще в школе, упражнение называлось "рассчитайте сколько вам потребуеться времени на приобретение автомобиля, если у вас есть жена, трое детей + налоги с зарплаты".

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

А люди меняются гораздо медленнее - посмотри на историю выч. техники и на историю человечества :)

> В емаксе же, ты пользуешься функциональным языком в процедурном стиле. Фу.

Ну кто та сволочь, которая тебя так обманула?!!! Не функциональный он. Перепрограммируйся, пожалуйста. А то я си начну называть "функциональным языком, на котором все пишут в процедурном стиле. Фу." :)

> блоге за 20 минут - и напиши тоже самое на C

"Дайте мне точку опоры, и я переверну мир" (с) Архимед

Дайте мне библиотеки и я напишу блог на С за 20 минут. Их просто нет, потому как авангард -- Perl, PHP, RoR, Java.

Web и эти языки развивались одновременно, друг друга подпирая. И не факт, что эти языки действительно необходимы -- это можно будет осмыслить чуть позже, когда все устаканится... и начнут переписывать блоги на Си, как это сделали gcc'шники со своими парсерами. ;-)

>>> То в коде реализующим один функционал на DSL будет в 5 раз меньше ошибок
>> Ой как спорно...
> Ну это исследование такое было вообще-то смотри по вышеприведённой
> ссылке.

Get the facts тоже своего рода исследование. Давай просто посмотрим Changelog emacs'a на предмет "fix", "bug", "bugfix"?

> И не факт, что эти языки действительно необходимы -- это можно будет осмыслить чуть позже, когда все устаканится... и начнут переписывать блоги на Си, как это сделали gcc'шники со своими парсерами. ;-)

Хех, на какие шиши ты это будешь переписывать? И каким калёным железом погонишь всех пионеров на "си с библиотеками"? :)

> Для GUI. Берём руби, петон ил тикл раз.(этим решаем задачу лёгкой интегарации с базовым языком). Ну и делаем:

Layout.new { |l| add GUI::Tree.new(categories)

А это по русски что означает ?

> Но только я не очень представляю исходную предметную область.

По сути требуется создать декларативный DSL который позволял бы описывать принцип функционаирования достаточно большого количества пользовательских интерфейсов для такой модели данных. Причем в большинстве случаев программист не должен опускаться на уровень обработчиков отдельных событий. Он должен описывать интерфейс в терминах зависимостей между визуализируемыми данными. Например, если в списке L был выбран объект A то в полях E1,E2,E3 должны отобразится свойства объекта A.p1, A.p2, A.p3. Ну и т.д.

>> В емаксе же, ты пользуешься функциональным языком в процедурном стиле. Фу.
> Ну кто та сволочь, которая тебя так обманула?!!! Не функциональный он.
> перепрограммируйся, пожалуйста. А то я си начну называть
> "функциональным языком, на котором все пишут в процедурном стиле.
> Фу." :)

Хаха. :-)

Товарищи, если это правда, то меня действительно ввели в заблуждение. Я даже знаю кто, тут был один проповедник функциональщины, Lisp'a и Emacs'а. nsav звали, если не ошибаюсь. ;-)

Ладно, про Emacs значит забудем, но это ничего не меняет, я смотрел и в другие lisp проекты (небольшие и не такие известные). И все было до боли похоже. Просто теперь, я не могу приводить в пример такой большой (и, к сожалению, успешный) проект как Emacs. А других проектов такого масштаба я и не припомню....

> Дайте мне библиотеки и я напишу блог на С за 20 минут. Их просто нет, потому как авангард -- Perl, PHP, RoR, Java. 

Почему же, есть. Только из-за своей низкоуровневой природы хрен ты на пишешь на C чтонить такое:



 class Category < ActiveRecord::Base
    acts_as_tree :order => "name"
  end

Без препроцессоров.

> Get the facts тоже своего рода исследование. Давай просто посмотрим Changelog emacs'a на предмет "fix", "bug", "bugfix"?

Ну и что? А предствь еслиб это еслиб всё что было написано на elispе было написано на C. Я думаю мой аццкий проект - неплохая такая IDE занял бы не 2,5Kстрок а все 50K. И ошибок там бы было намнооого больше.

> По сути требуется создать декларативный DSL который позволял бы описывать принцип функционаирования достаточно большого количества пользовательских интерфейсов для такой модели данных. Причем в большинстве случаев программист не должен опускаться на уровень обработчиков отдельных событий. Он должен описывать интерфейс в терминах зависимостей между визуализируемыми данными. Например, если в списке L был выбран объект A то в полях E1,E2,E3 должны отобразится свойства объекта A.p1, A.p2, A.p3. Ну и т.д.

Ну вот, ты уже на пол пути... Ты до конца "проговори" семантику. А потом будет видно, что и как с этим делать. А то ты сначала хочешь выбрать между тракторными колёсами и танковыми катками, а только потом делать гоночный болид ;)