MetaPlatform 0.0.1

седня я узнал, что быдлокодеры бывают латентными:))

>Все же никогда не понимал, почему бы не задействовать скобки разных типов. Хотя бы для того же (бэк)квотинга. Имхо уже бы глазу намного легче было цепляться за них и выделять в исходнике разные элементы.

Фигня все эти скобочки. Только глаза ломать.
begin
end;
надо писать!

>Основная фишка лиспа - его синтаксис, ибо не будь у него такого дурацкого синтаксиса все остальные плюсы "сошли на нет".

Дауж! Скобочки в лиспе это нечто! Пока сосчитаешь все открывающиеся и закрывающиеся, рехнешься. :) А если одной не хватит, или лишняя будет, рехнешься еще пару раз. :(

... все уже с ума свихнулись, даже кто безумен был... (С)

> На вкус и цвет. Не даром они expr сделали

Кто "они" и что такое expr?

> Дауж! Скобочки в лиспе это нечто! Пока сосчитаешь все открывающиеся и закрывающиеся, рехнешься. :) А если одной не хватит, или лишняя будет, рехнешься еще пару раз. :(

Ну, если самому считать - то таки да :)

Но кто Вас заставляет это делать? Утюг на пустую голову ставят? По рукам железной линейкой лупят, пока, возя пальцем по экрану, не пересчитаете их вслух? Кто же это Вас так?! :)

Ты, ламерок, очевидно, ни разу не пытался на Лиспе писать. Иначе бы не гнал такую пургу.

Табуляций хочешь? Да хто ж тебе мешает? В Common Lisp это делается тривиально, через set-macro-character. Там вообще над стандартным парсером можно очень зверски извратиться.

А ты посмотри, как там квадратные скобочки добавляются. Аналогично и с { } можно сделать.

> А вообще Форт - это наше всё. Лисп - overkill.

Не флейма ради. Интересно, а какие крупные (не в смысле размеров, а по функциональности) программы были написаны на Форте (см. для сравнения www.symbolics.com, если только он не залег в очередной раз)? То, что на нем успешно пишут для микроконтроллеров и встроенных систем, я в курсе.

--

SVK

> А вообще Форт - это наше всё. Лисп - overkill.

Да я с тобой полностью согласен: Форт - это ТВОЕ всё! И что дальше? :)

Давно на каком-то форуме (не здесь) был жуткий флейм, на котором vsl с кем-то спорил, что форт таки ограничен. Читал давно, флейм был еще более старый. Оппонент таки сдался... :) Хотя я тогда из того спора многого не понял. Найти что-ли и перечитать?

хм, есть масса вопросов по поводу этой работы, вот к примеру:

* я не против чего-то _принципиально_ нового, серьёзно облегчающего/углубляющего/етс, не мог бы кто-нибудь на реальных примерах показать это принципиально новое?

* а как быть с поддержкой библиотек от сторонних (и не очень) производителей? прозрачный биндинг будет обеспечен? ведь накопленный интеллектуальный багаж далеко не всегда переписывается "на раз",

* страус вроде по поводу "модификации языка" под задачу любит песни петь (перегрузка операторов, имён функций), я с ним согласен, язык должен легко затачиваться под задачу, быть легко модифицируемым в problem-oriented. Language-Oriented Programming имеет своей целью облегчить разработку и поддержку? не языка, а проекта в котором этот язык должен использоваться, или есть один "гений" и сотня кодеров пользующихся его гениальными идеями, правда при болезни/увольнении/етс "гения" вся работа кодеров встаёт раком сразу или постепенно?

> я не против чего-то _принципиально_ нового

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

> а как быть с поддержкой библиотек от сторонних (и не очень) производителей?

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

> Language-Oriented Programming имеет своей целью облегчить разработку и поддержку? не языка, а проекта в котором этот язык должен использоваться, или есть один "гений" и сотня кодеров пользующихся его гениальными идеями, правда при болезни/увольнении/етс "гения" вся работа кодеров встаёт раком сразу или постепенно?

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

Вообще, в очень многих софтинах есть свои встроенные языки. У кого-то когда либо были проблемы с их освоением? Ведь никто не хнычет, что надо бы всем софтинам один, общий язык использовать (мелкомягкие со своим идиотским VBA не считаются).

> Ведь никто не хнычет, что надо бы всем софтинам один, общий язык использовать

P.S. Таки Столлман хныкал, что надо бы везде воткнуть Guile, но он это хотя бы мотивировал тем, что там метапрограммирование доступно, и из Схемы можно любой другой язык сделать в случае надобности. Однако хорошо, что его не послушались. Мне болше нравится подход в том же Gimp, где уже три разных языка присобачили.

Так почему бы (GIMP'овцам) не послушаться впридачу дядьку Столлмана и не воткнуть ко всем этим языкам еще и Guile? И волки целы, и овцы сыты... А потом и MetaPlatform приколотить :)

Или новый язык прикрутить -- это костыли и шнурки из проволоки, которые обвязывают кед через подошву -- ввиду рваных дырок?

Меня в лоповской идеологии смущает одна особенность. Как я понимаю программы реализованные таким образом очень чувствительны к ошибкам допущенным на этапе проектирования / разработки DSL. Серьезная ошибка DSL повлечет необходимость переписать многое из написанного кода. Для того чтобы избежать или минимизировать такие ошибки требуется очень подробный анализ собственно проблемной области. Не получится ли так, что лоп как господствующая идеаология по сути откат назад по сравнению с идеологией ооп, которая гораздо более терпим к ошибкам проектировщиков.

> Так почему бы (GIMP'овцам) не послушаться впридачу дядьку Столлмана и не воткнуть ко всем этим языкам еще и Guile?

А на кой? У них там и так уже SIOD есть, зачем вторую Схему втыкать?

> Серьезная ошибка DSL повлечет необходимость переписать многое из написанного кода.

Почему? Когда ошибку в компиляторе Си находят - что, все гигатонны сишного кода переписываются?!?

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

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

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

В результате код рос как на дрожжах. Эффективности -- гулькин нос.

Блин, сорри -- забыл. :) Только популярности она почему-то не получила. Во всяком случае, слышно о ней мало.

> Почему? Когда ошибку в компиляторе Си находят - что, все гигатонны сишного кода переписываются?!?

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

>Не обязательно. Если в процессе разработки выясняется, что язык не совсем адекватен предметной области, то его можно расширить, оставив совместимость. Это ничем не хуже (а по многим параметрам и лучше) чем ООПный рефакторинг.

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

Это SIOD то не популярен? Мне вот кажется, что Схему для скриптования Гимпа используют куда как чаще, чем всякие питоны - по крайней мере туториалов про неё побольше будет.

При таком уровне неправильного проектирования и в ООП никакой рефакторинг не спасёт, всё переделывать придётся.

У меня есть вопросы, не флейма ради. Есть ли задачи, реализация которых не возможно без этого MetaPlatform или чего-то подобного? Зачем нужно быстрое прототипирование программого обеспечения (ну это ведь не демо-версия? и не сырая-пре-альфа-которую-все-равно-переписывать?)? Зачем затачивать язык под задачу (сразу скажу, что по-моему это не првильно, так как один человек не может быть хорошь во всем сразу, а если и хорошь, как потом проект поддерживать)? Если создавать язык под задачу, как доказать, что полученный язык для этой задачи подходит (то есть задача построения языка-под-задачу выполнена правильно)? Что делать, если условия задачи поменялись? Может ли возникнуть ситуация, когда при добавлении новых условий в задачу язык надо полностью переделывать, так как эти условия вносят противоречие в язык? Зачем это надо, когда уже есть много языков общего и неочень назначения ( :-D )

Откуда у меня в слове "хорош" взялся мягкий знак, интересно...

> Как быть в случае если расширение невозможно/слишком накладно (а это именно и есть самая дерьмовая ошибка), а тербуется именно изменение определенного набора языковых кострукций. Жопа ?

Пользуй Forth: и не Жопа, и не накладно, и возможно любое последующее изменение синтаксиса и семантики, оставив, с возможностью дальнейшего использования, предыдущие наработки "как есть".

>хочу чтобы при структурировании кода были не скобки а табуляции

Тогда Use Forth, Luc - там ТОЛЬКО пробел/таб/новая строка используются для структурирования разделения синтакчических единиц (изначально)... но можно это и изменить:)

> Зачем затачивать язык под задачу (сразу скажу, что по-моему это не првильно, так как один человек не может быть хорошь во всем сразу, а если и хорошь, как потом проект поддерживать)?

"Пришёл в церковь -- говори и думай о Боге"(с)

А что, по-твоему, представляет собой ПО, как не предметно-ориентированное средство обработки информации?

> Если создавать язык под задачу, как доказать, что полученный язык для этой задачи подходит (то есть задача построения языка-под-задачу выполнена правильно)?

use it!

> Что делать, если условия задачи поменялись?

modify it!

> Может ли возникнуть ситуация, когда при добавлении новых условий в задачу язык надо полностью переделывать, так как эти условия вносят противоречие в язык?

expand it!

>> Где стоит остановиться при разработке синтаксического сахара ?

>Там, где удобней, наверное.

Препрцессоры для этого существуют... или FORTH, который сам себе препроцессор:)

>а какие крупные (не в смысле размеров, а по функциональности) программы были написаны на Форте

PostScript/PDF подойдёт по "крупности"?:)

> Есть ли задачи, реализация которых не возможно без этого MetaPlatform или чего-то подобного?

Есть - быстрая реализация языков, исследования в области языков. Тут тулзы типа Mojave или языки типа Лиспа очень даже нужны.

> Зачем затачивать язык под задачу (сразу скажу, что по-моему это не првильно, так как один человек не может быть хорошь во всем сразу, а если и хорошь, как потом проект поддерживать)?

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

Так, чисто для справки: SQL - это DSL. Make - это DSL. Bash - это DSL. Попробуй их всех выкинуть, оставив только Java - посмотрим, как юзеры взвоют.

> Если создавать язык под задачу, как доказать, что полученный язык для этой задачи подходит

Есть такая наука - математика. Она, собственно, ТОЛЬКО этим и занимается.

> Может ли возникнуть ситуация, когда при добавлении новых условий в задачу язык надо полностью переделывать, так как эти условия вносят противоречие в язык?

Крайне маловероятно. Скорее язык расширится. Смотри на тот же SQL, как он менялся со временем при возникновении новых требований.

> Зачем это надо, когда уже есть много языков общего и неочень назначения

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

Это ясно. Просто при проектировании в ООП достаточно продумать базовые межкомпонентные интерфейсы, в соотвествии с четко заданными правилами ООП проектирования. Все остальное для проектирощика уже не на столько критично.

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

Ага, теперь понял. То есть эта штука позволяет написать, скажем Super-Duper-sh и потом упростит процесс его модификации?

> Это ясно. Просто при проектировании в ООП достаточно продумать базовые межкомпонентные интерфейсы, в соотвествии с четко заданными правилами ООП проектирования. Все остальное для проектирощика уже не на столько критично.

Так тут, по сути, ООП и является DSL для проектирования. И что делать, когда предметная область на эту модель не ложится (а она почти всегда не вписывается)?

> В ЛОП же приницп разработки языка не уточняется,

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

Так почему вся наука эту идеологию так легко и непринуждённо использует, а программисты - боятся до икоты?

> > Если создавать язык под задачу, как доказать, что полученный язык для этой задачи подходит

> Есть такая наука - математика. Она, собственно, ТОЛЬКО этим и занимается.

И что, есть методы вычисления "коэффициента подходящести" для задачи? Да ну.

А сказать, что мощность языка равна или меньше мощности машины Тьюринга - это неинтересно. Таки и Whitespace туда попадает, и Brainf*ck.

Да. Например, твои пользователи, такие все из себя специфичные, постоянно копаются в файлопомойках с mp3-шками, и если подсунуть им шелл, в котором и find про id3 знает, и комлишены по ним работают, и т.п., то они спасибу скажут.

>> Если создавать язык под задачу, как доказать, что полученный язык для этой задачи подходит > Есть такая наука - математика. Она, собственно, ТОЛЬКО этим и занимается.

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

> Крайне маловероятно. Скорее язык расширится. Смотри на тот же SQL, как он менялся со временем при возникновении новых требований.

И сколько надроду его развивало, анализировало и улучшало ?

> И что, есть методы вычисления "коэффициента подходящести" для задачи? Да ну.

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

> Нужен технологический подход, на раз-два-три.

Размечтался. Думаешь, для ООП есть методология разработки? Хрентам. Дзен сплошной.

> Так почему вся наука эту идеологию так легко и непринуждённо использует, а программисты - боятся до икоты?

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

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

> Так почему вся наука эту идеологию так легко и непринуждённо использует, а программисты - боятся до икоты?

Почему - боятся?

Есть разные классы задач - и есть разные языки. Надо данными ворочать - (PL/)SQL. Надо контроллером моторчики крутить - C/Forth. Надо данные от юзера в формочках получать - Java/Perl/PHP. Надо текст анализировать - Perl/awk. И т.д.

А еще даже бывают более специализированные языки/подъязыки, типа lex/yacc/perlRE/m4.

Причем все эти языки давно изучены и вылизаны, и понятно, как и зачем их использовать. Так же, как и в математике - подъязыки изобретают для больших разделов/задач. Никто же не будет создавать специальную нотацию для "задач про бассейны и трубы" ;)

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

Отчего нет ? Обощенные принципы построения ОО-модели вполне очевидны. Работаем с вложенными множествами различных, взамосвязанных объектов.

А в ЛОП-е какие приницпы ? Никаких.

> Обощенные принципы построения ОО-модели вполне очевидны.

Ну ну. Только у всех разные.

> А в ЛОП-е какие приницпы ? Никаких.

Да нет, очень даже чистые и понятные принципы, отточенные за столетия истории науки.

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

Инженерия - тоже наука.

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

Как это без гарантий? Методы то проверенные и отточенные.

$ make test2
java -dsa -client -XX:+AggressiveHeap -cp :./lazy.jar:. lazy/Test etc/bcel.l
java.io.FileNotFoundException: etc\bcel.l (═х єфрхЄё эрщЄш єърчрээ√щ Їрщы)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at lazy.Test.main(Test.java:26)

$ make bench3
java -dsa -client -XX:+AggressiveHeap -cp :./lazy.jar:. -agentlib:hprof=cpu=samples lazy/Test etc/s
omebench.l

------> 0
(A B C MYUNQUOTE D)
((MYBACKQUOTE (LETREC (((MYUNQUOTE TNM) (LET (MYUNQUOTE LM) (MYUNQUOTE TDEF)))))))
(CONS (QUOTE LETRC) (CONS (CONS (CONS TNM (CONS (CONS (QUOTE LET) (CONS LM (CONS TDEF (QUOTE)))) (QU
OTE))) (QUOTE)) (QUOTE)))
(CONS (QUOTE A) (CONS (QUOTE B) (CONS (CONS (QUOTE C) (FROMTO 1 2)) (APPEND (FROMTO 1 2) (QUOTE)))))

(Exception in thread "main" java.lang.StackOverflowError
at lazy.Evaluator.Reduce(Evaluator.java:65)
at lazy.Evaluator.Reduce(Evaluator.java:176)
at lazy.Evaluator.Reduce(Evaluator.java:194)
at lazy.Evaluator.Reduce(Evaluator.java:161)
at lazy.Evaluator.Reduce(Evaluator.java:176)
.....
at lazy.Evaluator.Reduce(Evaluator.java:176)
Dumping CPU usage by sampling running threads ... done.
make: *** [bench3] Error 1

$ make bench вываливается посередине с таким-же эффектом.

> Да нет, очень даже чистые и понятные принципы, отточенные за столетия истории науки.

Вот именно, что за столетия. За скольо дней/месяцев/лет формируется язык мат. теории ?

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

Издательство VSL Press выпустило новую книгу: "Спецификация HelloWorldLang, третье издание". В этом труде Аффтар пытается рассмотреть новые лексические конструкции расширенное спецификации этого перспективного языка, описывает построение основных функциональных блоков, и описывает свое видение дальнейшего развития и эволюционирования HelloWorldLang, которые планируется ввести в четвертую, пятую и шестую версии спецификации...

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

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

> Вот именно, что за столетия. За скольо дней/месяцев/лет формируется язык мат. теории ?

За минуты. Каждая задача - это уже новый язык.

>По рукам железной линейкой лупят, пока, возя пальцем по экрану, не пересчитаете их вслух? Кто же это Вас так?! :)

Свои все. Свои :))

> Как это без гарантий? Методы то проверенные и отточенные.

Ну назови методы разработки языка программирования под конкретную задачу за конечное время.

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