MetaPlatform 0.0.1

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

Да тут и методов никаких не надо. Формулировка задачи + формулировка предметной области - это уже само по себе язык. Всё проще, чем паренные грабли. Никаких тебе объектных декомпозиций, use cases и прочей параши.

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

Возьми листок бумаги.

Представь себе образ целевой системы.

Напиши на листочке слева-в-колонку ипользуемые понятия, объекты и лексемы, а справа их описание, свойства и взаимосвязи на естественном языке.

Ты получил СЛОВАРЬ транслятора.

Язык готов.

Задумываемся о реализации...

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

Слава творцам!

:-)

> Формулировка задачи + формулировка предметной области - это уже само по себе язык.

Bln, а я парился, расписывал...

:-)

> Да тут и методов никаких не надо. Формулировка задачи + формулировка предметной области - это уже само по себе язык. Всё проще, чем паренные грабли. Никаких тебе объектных декомпозиций, use cases и прочей параши.

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

Точняк. И получим объектную декомпозицию. Где язык то ?

Я не очень хорошо себе представляю предметную область, так что буду лажаться:

Есть сущности: документ, storage, права доступа, роль, физическое лицо, метаданные документа, транзакция, подпись.

Операции над сущностями:

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

Сущности при проектировании языка становятся типами данных, операции - конструкциями языка (не функциями, а операторами).

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

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

А какие свойства у объектов ? ИМХО объект = сущность, если не так то почему ?

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

http://en.wikipedia.org/wiki/Object-oriented_programming

http://en.wikipedia.org/wiki/Object_%28object-oriented_programming%29

Ещё немного:

http://en.wikipedia.org/wiki/Domain-specific_language

http://en.wikipedia.org/wiki/Domain-specific_modelling

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

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

Нет. не вижу. В чем разница? Математические сущности тоже подчиняются ограничениям, хотя бы налагаемыми их определениями. Функция это - ... Производная это ... и т.д.

Вообще человек ИМХО способен проводить два типа декомпозиции: по объектам и по действиям. Иногда объект может являтся действием. Математика не исключение. Там тоже все можно декомпозировать таким образом.

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

Пять балов!

> Новый язык запроектировать задача трудная и долгая.

Ты гонишь. Всякий, кто пишет на Common Lisp или на Forth, постоянно проектирует новые языки - и ничего, живут как-то.

> Запариваться на это ни кто не будет, ибо, как правило, задачу N еще вчера надо было решить. Если сегодня, тож не фигово, а вот завтра уже ни кому не надо будет.

Да кто ты такой, чтобы судить о работе индустрии?

> Математические сущности тоже подчиняются ограничениям, хотя бы налагаемыми их определениями. Функция это - ... Производная это ... и т.д.

Вот именно. Можешь ЛЮБОЕ определение дать, пользуясь ТОЛЬКО логикой. А в ООП ты ограничен идиотским определениям объекта.

> Вообще человек ИМХО способен проводить два типа декомпозиции: по объектам и по действиям.

Убогое у тебя ИМХО. Определи мне, раз уж заговорил об этом, понятие производной в терминах объектов и действий. Или, того лучше, реляционную алгебру переложи на ООП. Посмеёмся.

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

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

Я бы выделил:

{Документ, Метаданные, Папка/Тема/Задача/, Субъект, Роль, Права доступа, Подпись, Маршрут, Операция}

{Регистрация/в Папке/, Изменение, Назначение прав, Назначение маршрута, Делегирование, Отчёт, Контроль}

{Контроль ознакомления, Контроль исполнения, Контроль делегирования, Без контроля}

{...}

Есть "объекты", есть "субъекты", есть "операции", есть "свойства".

Т.е. есть "понятия" и их взаимодействие (между собой -- связи/свойства, с внешним миром -- метаданные).

Чем не язык?

:-)

> Иногда объект может являтся действием.

Не согласен.

Объект -- целостен, если имеет имя.

Действие -- взамодействие объектов.

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

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

> {Регистрация/в Папке/, Изменение, Назначение прав, Назначение маршрута, Делегирование, Отчёт, Контроль}

Sorry

Необходимо добавить сюда ещё и порождение одним документом нескольких, для отслеживания истории дерева порождений документов.

>Чем не язык?

Да не чем. :(

Опиши на нем стандартную ситуацию.

Пупкин составляет договор с контрагентом. Рыбу договолра берет из некоего хранилища рыб. Добывает реквизиты контрагента из другого хранилища. Если там нет, добывает их загадочным способом (телефон, факс, мыло, ...). Передает созданый договор в юротдел. Там вносят какие-то изменения. Вариант договора передает контрагенту. Тот вности свои изменения. Трем терки с контрагентом. Приходим к общему знаменателю. Пупкин правит договор. В юротдел его. Там правят. Опять терки. Опять юротдел. Директору на подпись. Опять терки... И так далее, пока обе стороны не подпишут. Через некое время с договором кто-то обгадился. Разбор палетов. В договоре обнаружилась лажа. Поднимаем цепочку изменений. Разбираемся с кем положенои наказываем кого попало....
Через год пришла налоговая проверка и отымела всех с этим договором. Накрутили штрафа. разобрались. Наказали. Уволили нафиг Пупкина. Он подал всуд. И выиграл...
И хотелось бы всю эту историю с документом как-то получить через года 3-4, когда Пупкин на пенсию пойдет.

>И хотелось бы всю эту историю с документом как-то получить через года 3-4, когда Пупкин на пенсию пойдет.

Прикрити к этому что-то типа CVS и добавь в язык средства для работы с ним - делов-то!:)

2vada (*) (23.08.2005 16:29:26)

vada, всё, что ты тут написал, называется маршрут, а всё, что ты хочешь, называется отчет по дереву порождения документов.

Посмотри, как оно всё прекрасно укладывается, даже, в эти в лексемы.

Теперь, твои желания не выглядят такими невозможными?

:-)

А вот скажи, русский язык, на котором ты всё это тут понаписал - он объектно-ориентированный?

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

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

Тот же самый документооборот - структура документа это структура объекта. Все. Где тут новая идеология ?

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

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

> А вот скажи, русский язык, на котором ты всё это тут понаписал - он объектно-ориентированный?

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

> В том числе и объектно-оринетированный.

Вот вот, что только "в том числе". Можешь себе представить разговорный язык, который был бы полностью ООПным? Нельзя! А вот, например, язык логики предикатов для устной речи вполне подходит. Что фундаментальнее и естественнее для человека получается, ась?

А где "/home/vsl/tsty.lsp"?

А может все это в cvs выкинуть?

>А вот скажи, русский язык, на котором ты всё это тут понаписал - он объектно-ориентированный?

Нет. Это безграмотный руский язык с множеством опечаток. Обычно я так пишу :(

>Так, собственно, очень многие делают.

В частности, я. Но не всегда. Когда просто, то и не делаю. Когда надо описать бизнес процесс, то так и пишу. Потом рисую. Потом согласовываю, что все правильно понял. Потом кодю. :)

И новый язык не изобретаю. Собственно, зачем?

>> А вот скажи, русский язык, на котором ты всё это тут понаписал - он объектно-ориентированный?

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

Всё ещё хуже:

если лексическая конструкция вызывает ассоциации в сознании и образы -- мы имеем дело с объектами.

:-)

> Реляционная алгебра формируется в терминах объектах и действий в полпинка.

Вперёд. Пинай. Начни с формилуровки декартового произведения.

> Тот же самый документооборот - структура документа это структура объекта.

Ты слово "декларативное" пропустил. Как в терминах ООП один объект изменит СТРУКТУРУ другому? Ты будешь вынужден опуститься до 10-го правила Гринспуна.

Так что, фанатик ты ООПный, ты обломался. Ну не удобно и не естественно это - мир в терминах дебильных объектов и ублюдочных сообщений представлять. В мире очень много декларативных сущностей, которые не являются последовательным действием - они являются УТВЕРЖДЕНИЕМ.

> И новый язык не изобретаю. Собственно, зачем?

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

Я уже предложил тут выкинуть SQL, bash, make, XML - и оставить только Java или C++. Посмотрим, как все завизжат.

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

Пример из жизни - в реляционной базе данных хранятся данные в некоем формате. Надо обеспечить некий поиск который на SQL не напишеш как СУБД юзается скорее как хранилище, в смысле реляциоонности там и близко нету. Поиск осуществляется путем применения регулярных выражений (postgres рулит). В результате конечные SQL запросы получаются весьмам мутантского вида особенно учитывая что нужно эскейпить sql в котором эскейпится регексп в котором эскепится xml. В общем если писать это руками - крышу оборвет просто мгновенно. Потому за часик ваяется псевдо-sql-образный язык и транслятор для него который траслирует этот псевдо-sql который выглядит вполне прилично и работает со структурами, которые дествительно хранятся, в сложные SQL выражения с regexpами и тремя видами эскейпинга.

Дальше все легко и просто.

> Новый язык запроектировать задача трудная и долгая.

Ты либо не знаешь о чем говоришь либо не понимаешь для чего оно надо. Я на последних 2х проектах штук 5 наваял и заняло это от 1 часа до пары дней.

> Так что, фанатик ты ООПный, ты обломался

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

>Теперь, твои желания не выглядят такими невозможными?

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

А стоит ли игра свеч? Созданием нового языка мы много выгодаем в стоимости программного продукта? Я не являюсь экономическим аналитиком, но опыт разработки сложных систем есть. И мое мнение, что эта метаплатформ является еще одним мертворожденным ребенком.

> Для того чтоб это написать, я не придумывал языка. :)

С удивлением узнал, что всю жизнь говорил прозой...

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

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

Изучить язык гораздо проще, чем изучить библиотеку. Вот скажи, что проще - libc или bash? Что проще - API imagemagick или интерфейс коммандной строки (тоже - язык!) его тулзовин?

> Созданием нового языка мы много выгодаем в стоимости программного продукта?

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

>> И новый язык не изобретаю. Собственно, зачем?

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

>Я уже предложил тут выкинуть SQL, bash, make, XML - и оставить только
>Java или C++. Посмотрим, как все завизжат.

Я ни чего не понял из того что ты написал. :( Видимо, я такой гений. :)

> Я ни чего не понял из того что ты написал.

Тупой, значит.

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

Тебе что проще - команды в bash набирать, или писать то же самое на Си? Согласился бы ты иметь Си своим единственным шеллом?

>Ты либо не знаешь о чем говоришь либо не понимаешь для чего оно надо.

Видимо, не понимаю. :(

> Тебе что проще - команды в bash набирать, или писать то же самое на Си? Согласился бы ты иметь Си своим единственным шеллом?

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

А ты попробуй. Для начала - попиши на Лиспе, пойми саму идеологию метапрограммирования. Убедись, как это просто - расширять язык, или создавать совсем новые микроязычки на основе полноценного метаязыка. Почитай "On Lisp" Пола Грехема.

Конечно, это жопа, создавать новые языки, если у тебя инструменты ограничиваются flex-ом, bison-ом и C. Даже простенький калькулятор, как в книге Кернигана и Пайка - и тот уже геморройно делать, а уж язычок типа SQL и вовсе заколебёшся реализовывать. Отсюда и такая убежденность среди программистов, что делать языки - сложно. Привыкли все к тупым и неудобным инструментам. По какой-то причине все очень старательно ингорировали Лисп - этот парадокс я объяснить никак не могу.

> Видимо, не понимаю. :(

Как общеприводимый пример SQL. Подумай что бы надо было делать, если бы его не было, в задачах управления данными, которые можно представить в реляционном виде. SQL и есть такой Domain Specific Language. А всякие оракелы представлят тебе транслятор, и набор библиотек которые предоставляют тебе возможность описывать критерии поиска не путем чтения структур из файла на набором for-ов и if-ов. Само метопрограммирование и наработки в нем направлены на то чтобы удешевить разработку DSLей для end-programmera и эти задачи не требовали задействования сотен человеко-месяце-баксов для разработки языков.

Ты точно тупой. Шелл - это DSL такой, для операций с файлами и процессами. Всё то же самое доступно из языка общего назначения - Си. Только вот DSL - на многие порядки удобнее, и только очень тупой и убогий на голову человек предпочтёт DSL-у язык общего назначения.

Не убеждает тебя такой простой и очевидный пример?

Самое интерестное что те кто защищают ЛОП так и не ответили ГДЕ можно хоть что-то почитать чтобы понять эту точку зрения. И это не в первый раз. Я например так и не нашел литературы с вменяемыми примерами. В основном в примерах идет речь о сферических конях в вакууме.

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

Нет DSL это действительно рулез. Хорошо об этом написано в вводных
 главах OnLisp. Самое простое это писать лиспобразные DSL на Lisp с
 помощью макросов. Вот маленький пример из того чем я  сейчас занимаюсь.
Система импорта информации о товарах из различных источников, в 90% это экселевские файлы. 
Вот как просто и понятно задаётся параметры импорта:

(defmodule-import photo "Фотопродукция"
  (:source "photo.txt" :main-category-id 19)
  (:category :if (and (non-free (row 1))
		      (non-free (row 2)))
	    :level-map ((:compute (parse-integer (row 1))))
	    :mapping ((:name 2)))
  (:goods :if (and (free (row 1))
		   (non-free (row 2))
		   (non-free (row 3)))
	  :mapping ((:code (make-p-counter)))
		    (:name 2)
		    (:in-cost 3 :transform #'rus-cost))))

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

2vada (*) (23.08.2005 17:20:12)

> Для того чтоб это написать, я не придумывал языка. :)

Таки, сочинил. :)

------------------------------------------------------------------

>"Пупкин составляет договор с контрагентом.

Кто такой "контрагент"?

> Рыбу договолра берет из некоего хранилища рыб.

"Что за рыба? Причем здесь рыба?!"

> Добывает реквизиты контрагента из другого хранилища.

"Что добываем?" "Что такое хранилище?"

> Трем терки с контрагентом.

"Чего делаем?!"

> Приходим к общему знаменателю.

"Куда приходим?"

...и т.д.

----------------------------------------------------------------

> Другое дело, что мое описани ни один копилятор не разбирет. :)

Это и есть предмет спора.

Нужно формализовать, классифицировать, сделать выводы, сохранить и иметь быстрый доступ, не исказив сути.

> Но описани понятно? Понятно. Причем, большинству.

Совершенно ошибочное мнение.

Тот, кто никогда не сталкивался с процессом "проталкивания" договоров, тебя, просто не поймёт...

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

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

> А стоит ли игра свеч? Созданием нового языка мы много выгодаем в стоимости программного продукта?

Можно существенно упростить проблемную логику программного продукта.

> ... мое мнение, что эта метаплатформ является еще одним мертворожденным ребенком.

Сейчас, речь не о MetaPlatform, а о теоретических аспектах такого рода продуктов и их сути.