MetaPlatform 0.0.1

>(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)))))

И это язык для написания других языков !? Пистон просто...

Да это как раз понятно. Просто события масштаба SQL в истории IT индустрии не так часто встречаются. И SQL рожали ни один год. Это того стоило. Но изобретать какой-то костыль для решения частной задачи, на мой взгляд, не правильно. У программы, кроме написана, еще впереди долгая жизнь, которая называется сопровождение. И скорее всего разработчик в этом участвовать уже не будет. Он должен будет составить "учебник" по своему изобретению, или пришедший на его смену перепишет это все, потратив уйму времени. В обоих случаях затраты времени приличные. Может пойти более простым путем?

Ну не знаю. Может я слишком консервативен.

> В основном в примерах идет речь о сферических конях в вакууме.

Живой пример:

1. SELECT * FROM documents WHERE TRUE AND ddb_type='department' AND (ddb_body ~* '<[^\s]+ [^>]*>([^<]*havior[^<]*)') ORDER BY ddb_id DESC

2. select department where ( * ~ 'havior')

1 транслируется из 2. Это простой запрос. На что похож сложный - можешь живенько представить. Я негочу писать сложные запросы типа 1 где буду озабочен эскейпингами скобочками и кавычками. Я хочу писать простые запросы типа 2. Потому я за пол часа напишу транслятор. И не буду мозги ковырять не себе ни другим. Один раз применив голову - я освобожу ноги от большой работы.

Вот более сложный пример.

1. SELECT *, substring(ddb_body from '<[^\s]+ name="name"[^>]*>([^<]*)') AS name FROM documents WHERE TRUE AND ddb_type='person' AND (((ddb_body ~* '<[^\s]+ name="name"[^>]*>([^<]*Fox[^<]*)' AND ddb_body ~* '<[^\s]+ name="name"[^>]*>([^<]*ulder[^<]*)' AND ddb_body ~* '<[^\s]+ name="name"[^>]*>([^<]*uld[^<]*)') OR (ddb_body ~* '<[^\s]+ name="name"[^>]*>([^<]*Fox[^<]*)' AND ddb_body ~* '<[^\s]+ name="name"[^>]*>([^<]*ulder[^<]*)' AND ddb_body ~* '<[^\s]+ name="name"[^>]*>([^<]*uld[^<]*)')) OR (ddb_body ~* '<[^\s]+ name="name"[^>]*>([^<]*Dana[^<]*)')) ORDER BY name ASC

2. select person where (name ~ 'Fox' and name ~ 'ulder' and name ~ 'uld') or (name ~ 'Fox' and name ~ 'ulder' and name ~ 'uld') or (name ~ 'Dana') order by name ascending

Это из unit-testов. 1 транслируется из 2. Можешь сравнить сложность.

>Ссылку на http://en.wikipedia.org/wiki/Domain-specific_modelling ты проигнорировало, да?

Опять кони... там написано что такое в ПРИНЦИПЕ DSL.

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

Тут все просто (возможно для меня) А вот как такую фигню написать на функциональном языке???? (тут постоянно говорят о Лиспе вот я и пишу офункциональном языке)

> Родной, ты о чем? Мы про С или шел говорим?

Похоже, о языках программирования, вообще, их применимости и эффективности, в разных предметных областях.

:-)

> Просто события масштаба SQL в истории IT индустрии не так часто встречаются.

Сдаётся мне, что твои знания об истории IT предельно ограничены. Почти КАЖДАЯ софтина включает DSL, и часто - не один. У некоторых это полноценные языки, у некоторых - не сложнее INI-файлов, но всегда - DSL.

> И SQL рожали ни один год. Это того стоило

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

> Может пойти более простым путем?

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

2 r * (*) (23.08.2005 17:56:35) Ну так и я пишу методы asSQL которые берут и все свои кишки оббегают и вызывают для них asSQL и на основе этих строк строят свои строки....

НЕ ПОНЯТЕН ПРИНЦИП... Откуда плясать? Как я могу смоделировать документ не как сложную сущность с полями, а как простой тип????

Вот на самом деле о чем спор. Вы показываете ГОТОВЫЙ и достаточно сложный результат. Для меня например совершенно неочевидно как добиться этого результата (тем более с помощью неизвестного мне языка - Lisp).

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

> Как учат ООП

Ах, так тебе общих принципов недостаточно? Тебе нужен учебник "метапрограммирование за 21 день для полных чайников", а так же задачник, методичка и лабораторные работы? Фигли с таким уровнем интеллекта ты тогда вообще в программирование сунулся?

> (тут постоянно говорят о Лиспе вот я и пишу офункциональном языке)

Опять этот бред. Ну кто тебе сказал, что Лисп - это функциональный язык? Очень даже императивный, очень даже ООП (куда как более ООП, чем всякие дешевые Java). То, что в нём есть lambda, функциональным его ни разу не делает. В Питоне тоже есть лямбда, и в Perl6, и даже в C++, если постараться.

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

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

> Может я слишком консервативен.

Это называется другим словом. Слишком безграмотен - так честнее будет.

Ещё веселее - настоящий brainfuck:

(DEF-MACRO (LIST . MACRO) (**B ((**SS **C ((**CC **BS CONS QUOTE CONS) . CONS) (**C . CONS) QUOTE) (**S (**C ((**BS . IF) . NULL) . CDR) QUOTE (QUOTE)) (**B CONS QUOTE LIST) ((**CC . APPEND) . CDR) QUOTE) . CAR) . CDR)

> Ну так и я пишу методы asSQL которые берут и все свои кишки оббегают и вызывают для них asSQL и на основе этих строк строят свои строки....

Ха! Я еще в этом проекте и принципы Generative Programming применил - у меня структуры данных с которыми работает проект - тоже в его конфиге описаны. Это не один законченный продукт это метасистема которая работает с описанной структурой и пользователь на другом простом языке описывает данные и отношения между ними, а система уже занимается трансформацией этого метаописания (причем в рантаймев во время работы метаописание может менятся) с хранилищем и инструментами дял манимпулирования данными. Дальше что?

> Вы показываете ГОТОВЫЙ и достаточно сложный результат. Для меня например совершенно неочевидно как добиться этого результата (тем более с помощью неизвестного мне языка - Lisp).

LISP тут не при чем. Да - лисп хороший инструмент в плане метаописания - но не единственный. Я проиллюстрировал сам подход DSL. А транслятор тут написан на ANTLR.

> Но я не могу понять чем мой молоток менее применим чем ваша отвертка?

Я же показал. Без отвертки пришлось бы запросы писать в виде 1. С отверткой в виде 2. Создание отвертки у меня заняло 1 час времени. Разница между 2 и 1 по скорости, уменьшении количества ошибок, читаемости, и прочитм параметрам очевидна?

> у меня структуры данных с которыми работает проект - тоже в его конфиге описаны.

А бедные жабофилы на самом деле тоже метапрограммирование юзают по полной программе, причём даже в рантайме, через BCEL и рефлексию, как например в Hibernate. Только до них не доходит, что XML-конфиги в Hibernate - это тоже DSL. Только очень криво реализованный.

А уж Spring - и вовсе ужас, летящий на крыльях ночи. Хуже только Oracle BC4j.

> Фигли с таким уровнем интеллекта ты тогда вообще в программирование сунулся?

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

>Ах, так тебе общих принципов недостаточно? Тебе нужен учебник >"метапрограммирование за 21 день для полных чайников", а так же >задачник, методичка и лабораторные работы? Фигли с таким уровнем >интеллекта ты тогда вообще в программирование сунулся?

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

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

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

Если вы уважаемый ВНИМАТЕЛЬНО прочитаете мои посты, то вы обратите внимание на то что я заинтерисован Лиспом (будь он хоть ООП, хоть еще чем). Только вот меня не интерисует что на нем легче написать вычисление последовательности Фибоначи... Мне не платят за нахождение последовательности Фибоначи, это не востребовано....

А Лисп за 21 день это такая-же чушь как и Питон за 21 день.... тут понятно. Нужна информация как стартануть. А ее нет. Я спокойно перешел с паскаля на перл, с перла на питон. И каждый раз я убеждался что выбрал правильный инструмент для задачи. Я вам предложил задачу (можно похожую - всеравно класс задач схож). Есть примеры эффективного решения таких ЭЛЕМЕНТАРНЫХ задач? Нет? Или просто эффективность лиспа проявляется на больших задачах (как например использование STL в такой задаче без ее предварительного знания сильно замедлит и усложнит разработку).

А так я пока просто слышу - Лисп крут, а все кто этого не понимает бараноголовые.

> В наших вузах практически во всех идет серьезный задвиг "не туда"

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

> Нужна информация как стартануть. А ее нет.

Ложь. Зибель, Грэхем - мало разве?

> Есть примеры эффективного решения таких ЭЛЕМЕНТАРНЫХ задач?

Зибеля читай. Вся книга так построенна, на примерах практических задач.

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

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

>Нужна информация как стартануть. А ее нет.

Как это нет, вам же уже писали onlisp(как раз очень много про создание собственных языков) + какую-нибудь вводную книжку по лиспу + Practical Common Lisp.

>Но ты почему-то думаешь что подход примененный к этой задаче не подходит частным одиночным задачам.

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

>только так чтобы мои VB девелоперы смогли это поддерживать потом.

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

Когда-то давно я применял программу построения конечных автоматов. На паскале такая в свободном обращении ходила. Нечто похожее, помоему, в фри паскале и сейчас есть. Было несколько плоттеров, и каждый понимал свой язык, или его диалект. В акаде файл выведут, а на этот плоттер очередь на сутки. Надо для другого ковертнуть. Тож был "изобретен" :) язык описания векторной графики. Перегонялось все сначала в него, потом в язык конкретного плоттера. Это очень сократило объем моей работы, как программиста. Даже на матричный принтер можно было чертеж вывалить. Но не прижилось. Т.к. ни кто не понимал как это происходит :( Оказалось проще поменять парк плоттеров. :(

Так что мой опыт применения таких инструментов оказался неудачным. Больше и не лезу.

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

Неправда. Сопровождение то стоит, только вот крутость кривой сопровождения (развития, модификации) может быть переменной. Введение подобного DSL - я убрал определенный класс ошибок это раз. Удешевил разработку за счет упрощения языка запросов - это 2. Подход GP позволил применить эту систему с 0выми модификациями на никак не пересекающиеся задачи - хотя заказывали на одну. То есть Генерализация и Абстракция в купе с Параметризацией и Конфигурабельностью рулят не по децки - сейчас системка которая писалась побыстрому для локальных нужд - уже имеет 4 внутренние аппликации 1 внешнюю, и еще на несколько продаж готовиться. В итоге я не грызусь с заказчиком за сроки и каждый день-доллар потому что ему надо 2 поля добавить там и одно убрать тут в его модели данных, а написал мануал по языку описания модели данных в 2 страницы и мы радостно пьем пиво сэкономив гору времени. И система сейчас всунута в несколько мест где экономически неэффективно было разрабатывать специальзированную систему именно благодаря подобномоу подходу. Так что в этом графике важен не только рост расходов, но и характер этого роста...

В твоем случае это стопудово оправдано. Запросы просто ужасны. В таких по 10 ошибок в строке можно навалять :)

А как все это происходит в реалтайме? Ты пишешь запрос на "человеческом" языке, компилишь его, а потом в текст программы вставляешь? Или я туплю совсем?

> А как все это происходит в реалтайме? Ты пишешь запрос на "человеческом" языке, компилишь его, а потом в текст программы вставляешь?

В рантайме это обертка вокруг апи к постгресу. Если была скажема функция

sql_select("sql писать тут") то появилась функция myql_select("dsl писать тут"). Внутри она парсит запрос и транслирует его в sql и вызывает sql_select(...). Схема приблизительно такая.

Грубо говоря схематически выглядит так:

Пишу MyDSL ANTNR Grammar -->

При сборке проекта генерируеся Lexer/Parser/SQLGenerator (translate)->

Пишется API оберткаи -->

function myql_select(myql) { return sql_select(translate(mysql)); }

--> юзается как библиотека во внешнем коде (потому как язык не лисп или ocaml - AST не достроишь:).

Реально там результат - тоже не rowset, и обертка покруче.

Понятно.
Есть у меня одно место, где это помогло бы. А то запросы сложноваты получились и не читаются нефига. Только поздно уже. Написаны, отлажены, работают. :(

Имхо самый наглядный пример DSL для большинства нынешних кодеров - это файлы, описывающие гуй. Что Qt'шные .ui, что Glade - они же не зря есть. Можно конечно это дело описывать прямо в коде, но сильно неудобно. Вот и приходится сишникам городить препроцессоры всякие. А в более гибком языке - можно быстро нарисовать язык для удобного описания гуя (кстати именно S-выражения для этого подходят практически идеально, т.к. имеем простую древовидную структуру), и отпадает необходимость во внешних костылях.

>>В данном случае не вижу разницы между объектным подходом. Только там не операции а методы а в мето типов данных - классы. Смысл ЛОП ? Немного красивше записать ?

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

Всё верно Луговской пишет! Только немного не теми словами :)

Языки под бизнес-процессы нужны и это гуд.

Меня вот другой вопрос больше интересует. Лиговской всегда хаял Java VM говоря, что .NET VM на порядки её превосходит. Так почему же он не выбрал .NET VM????

http://www.livejournal.com/users/mauhuur/2323.html?thread=22803#t22803

2ed. Спасибо, почитал с интересом.

>Ты будешь вынужден опуститься до 10-го правила Гринспуна.

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

Спасибо

Чем MetaPlatform принципиально отличается от http://nekovm.org/ ?