Здравствуйте, Ikemefula, Вы писали:
I>Передергиваешь в очередной раз. С чего ты взял что текстовые заведомо лучше графических ?
Не важно. Важно, что ты таки принял точку зрения, что для решения сложных задач ДСЛ-и подходят куда лучше чем ЯОН-ы.
I>В некоторых областях текстовые будут лучше, до тех пор пока не появится качественная графическая информация.
Вот хорошая область — разговоры в форумах. Очень много времени на них уходит. Как жаль, что для этого не придумали качественных графических ДСЛ-е. Приходится по старинке использовать текст.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
AVK>>Бизнес-логику, разумеется. Ты же не думаешь что реальная бизнес логика это как в игрушечных примерах, простенький алгоритм с минимумом входных и выходных параметров? WH>И что же там проектировать то? WH>Ты надеюсь, сбор требований с проектированием не путаешь?
Например, создав ДСЛ для описания ЯП, ты не освобождаешься от проектирования самого ЯП. Затраты, особенно на реализацию, при этом снизятся. Но проектировать ЯП ты один фиг будешь. Наличие ДСЛ-я тебе тут, конечно поможет, так как ты намного быстрее сможешь опробовать проектные решения. Но тем не менее проектировать ты будешь и это станет основной твой задачей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexCab, Вы писали:
AC>Нет, паттерны проектирования не могут приводить к дублированию кода, потому что на этом этапе нет кода, есть модули, процессы, объекты, этапы etc.
Назови, пожалуйста, 5 паттернов проектирования которые ты используешь на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Давай рассмотрим реальный, хоть и упрощенный, пример, ОК? Предметная область — бухгалтерия. В ней есть некие документы разных типов. И у каждого документа есть специальный алгоритм, или даже более обще — специальная функция, преобразующая данные документа в набор специальных сущностей — хозопераций (ХО это атомарное перемещение денег со счета на счет, но не суть). Наконец, есть универсальная рукоятка, позволяющая по набору разнотипных документов вычислить для них хозоперации. AVK>На этапе проектирования бизнес-логики мы оформляем собтвенно функцию перехода от документа конкретного типа к набору ХО как специальную сущность, видимую пользователю (потому что у него должна быть возможность самостоятельно выбирать такую функцию для конкретного типа документов).
До суда все понятно. Ну, разве что ХО я бы проводкой назвал. Так привычнее.
AVK>Обрати внимание, я ни слова не сказал про языки программирования и какой либо код.
Ага.
AVK>Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией.
Мать моя женщина! Так вот как оно умно называется! Едрит Модрид!
А мужики бабы (из бухгалтерии) и не знают поди!
Ну, а если серьезно, то вот он момент когда ты наплевав на безнес-логику начинаешь натягивать презерватив на глобус предметную область на свой любимый C#. А ведь в предметной области есть только банальное отображение одного представления (в виде документа) на другое (в виде набора проводок). Какая на фиг стратегия?!
Скажу больше. Твои слова "документ" и "ХО" уже говорят о том, что ты оперируешь не предметной областью, аз знакомым тебе алгоритмом (подходом). В нем у тебя первичны документы, а ХО генерируются по ним. Но по жизни есть данные, и только данные. И документ, ХО и прочая мутатень ни что иное как их представление в твоем решении.
В моем решении документ и ХО могут быть единым целым, или могут быть только документы, или только ХО. От этого ничего не изменится. Главное чтобы исходные данные не пропали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не обязательно. И, главное, паттерн Стратегия ничего подобного не диктует. Ты сам обвешиваешь паттерны каким то лишним для них смыслом, и потом сам себя и опровергаешь. Тебе уже несколько человек по нескольку раз повторили — паттерн это не шаблонный код, это шаблонный элемент дизайна. Если возможности языка позволяют реализацию паттерна написать один раз — отлично. Но паттерна это никоим образом не отменяет. Например, от того что в шарпе есть ключевое слово event паттерн Publisher-Subscriber никуда не девается, его просто не надо описывать многословно.
Проблема в том, что ты под словом "паттерн" понимаешь не сам паттерн, а стоящее за ним поняитие. Человек, несомненно, оперирует понятиями. Но чтобы превратить понятия в исполняемый код и нужны паттерны. И вот тут настает реальная беда, так как большинство понятий нихрнена нельзя запихать в библиотеки.
Ты можешь за вечер напроектировать столько, сколько не сделаешь за целый год. Вот это проблема! Меж тем твой проект — это вполне себе готовое решение. В нем не хватает только реализации и контроля корректности.
Так вот беда паттернов в том, что их авторы предлагают материализовывать стоящие за ними идеи вручную. Именно это и называется программированием. И именно на это и тратится основное время разработки.
Так что если получить возможность оперировать паттернами не только как понятиями, но и как готовыми настраиваемыми строительными блоками, то мы получим серьезное ускорение разработки ПО.
Но есть и более радикальный шаг — начать мыслить терминами предметной области, создавать формальные языки описывающие ее задачи и средства материлаизации этих решений.
В общем-то это и есть то к чему мы стремимся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Конкретно стратегия это не банальное отображение D->T[], а возможность выбирать конкретный способ этого отображения в зависимости от каких то данных.
О! У меня есть офигительная стратегия! Вот она:
foo(x)
в зависимости от переданных в нее данных возвращает требуемое отображение.
А еще вот такое есть:
switch (x)
{
...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AVK>In computer programming, the strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby algorithms can be selected at runtime. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.
Очень подходящее описание для функции возвращающей функцию или даже для банальной хэш-таблицы. К анализу предметной области это отношения не имеет. В своем ДСЛ ты мог бы определить операцию "ГенерацияХоПоДокументу" и пойти дальше. А детали реализации оставить на потом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>И где там потенциальные паттерны, которые исчезли из-за наличия DSL? К примеру, есть паттерн описания языка в виде грамматики и построению по ней парсящего кода генератором. Он, как я понимаю, никуда не делся.
Ага. Вот это и можно назвать паттерном проектирования. А твои паттерны — это патерны ГОФ. Их цель натянуть дырявый презерватив ООЯ на глобус решаемой задачи. Тяжело, неудобно, но другой модели для натягивания нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexCab, Вы писали: AC>Мне чертовски сложно представить код которой не нужно тестировать после изменений в его компиляторе.
Вы делаете полный regression каждый раз, как MS шиппит апдейт к C#?
AC>По моему скромному мнению, беда DSL(реализованых при помощи МП, а не в принципе), по сравнению с библиотеками, в том что: AC>1)по макроссам сложно составить полное и ясное представление что за код будет сгенерирован, AC>2)генерированый код будет монолитным и не читабльным.
А зачем вам нужно это полное и ясное представление, а также читабельность этого кода? Вот, скажем, вы сходу сможете сказать, во что разворачивается linq-expression? Со всеми этими скрытыми объектами автосгенерённых классов?
AC>Из чего следует: AC>1)отладка/тестирование транслятора — занятие не для слабонервных,
Да, это вопрос к WH. Пока что высокая стоимость разработки и отладки DSL является основным барьером к их применению.
AC>2)проблеммы с взаимо-интеграцией DSL'ей(и по вертикали, и по горизонтали),
Вот тут я как раз проблем особо не вижу. AC>3)"разбухание" генерированного кода(в особо запущенных случаях можно 1-1000 достичь(о которых WolfHound пишет )).
Во первых, непонятно, почему вас беспокоит этот параметр. Вон, шаблоны С++ позволяют лёгким манием руки породить килобайты машинного кода. Ничо, вроде народ не боится. Во-вторых, отлично, если этот код — нужный. Мы сократили объём ручной работы и уменьшили шансы сделать ошибку. Если же код — ненужный, и "руками" можно написать компактнее, то, опять же, пилится DSL-компилятор и он оптимизирует код по размеру.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты лучше скажи, ты тоже считаешь, что DSL заменяет необходимость создания архитектуры прикладного решения?
Нет. Я считаю, что архитектура прикладного решения разбивается на 2 (или более) уровней: уровень "языка" и уровень "описания".
DSL у нас уходит в язык. А архитектура решения описывается уже в терминах языка.
SQL — типичный пример. Сначала мы придумали, что все данные будут упакованы в таблицы (почти реляции РА), придумали типы полей, и придумали несколько типов constraints. Ввели операторы DML.
Это был первый этап нашей архитектуры.
На втором мы пишем описание нашей конкретной архитектуры в терминах таблиц, констреинтов, и запросов к этим таблицам.
В простых случаях этого достаточно. В более сложных у нас навёртываются ещё слои архитектуры поверх чистого SQL, но их на уровне SQL не видно.
Ну, например — делаем очередь заданий, которые выгребают N читателей, причём с одного конца, а в другой конец заталкивает произвольное количество "писателей". Можно смоделировать всё это в терминах таблиц, констреинтов, и запросов по запихиванию и вытаскиванию.
А можно сделать как в MS SQL 2005 — ввести сущность "очередь" и "разгребатель" на уровне языка.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Например, для предложенных тобой случаев — слёту не продемонстрирую. А вот, например, в том случае, который описал WolfHound
с моей точки зрения, оперировать исходной реализацией IPropertyNotifyChanged гораздо легче, чем макросом — реализация "в лоб" попросту не вызывает никаких вопросов. А по отношению к макросу первый же вопрос: каково имя переменной-члена объекта, в котором сохранено значение свойства? Не упрятано ли оно куда? Выполняется ли синхронизация при вызове callback-а, и если да, то где?
Аналогичный вопрос: каково имя переменной-члена объекта, в котором сохранено значение авто-свойства в C#? Почему вас не смущает незнание этого?
Вопрос про синхронизацию — хороший, он должен быть освещён в документации по применяемой фиче.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Я рад что ты это понимаешь. Вот та же фигня с ДСЛ-ями. Если все назвать ДСЛ-ями, то использование этого термина так же теряет смысл.
Ох. Каждый язык имеет свой домен. Он не может не иметь домен. Просто всякие сишарпы имеют домены, полностью оторванные от реальности.
В случае же с паттернами все совсем иначе.
Если мы свели конструкцию к ровно одному элементу, то паттерн исчез.
Кончено это не мешает этому элементу быть частью паттерна более высокого уровня.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Причем это занятие (битье головой о стену не понимания и незнания) отнимает у него время которое он мог бы потратить на крайне полезное дело — на найтру. По сему я призываю его бросить это неблагодарное занятие и заняться делом. Нас ждут великие дела .
Ты категорически не прав. Я узнал много интересного о психологии людей.
Так что эта тема не напрасна.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали: AC>>Нет, паттерны проектирования не могут приводить к дублированию кода, потому что на этом этапе нет кода, есть модули, процессы, объекты, этапы etc. VD>Назови, пожалуйста, 5 паттернов проектирования которые ты используешь на практике.
То немногое что я пишу — пишу for fun and joy. Потому склонен к изобретению собственных паттернов велосипедов. Из описанных Алексадреску изобрёл как минимум 7
Но, если бы занимался промышленным проектированием, использовал бы очень многие. Например те-же ООП паттерны(фабрики, сингтоны), можно использовать и вне ООП.
Ну допусти вот пять из ООПаттернов(для краткости): Singleton, Factory, Adapter, Interface, Interpreter
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, VladD2, Вы писали:
VD>Например, создав ДСЛ для описания ЯП, ты не освобождаешься от проектирования самого ЯП.
Ты взял язык для описания архитектуры и говоришь, вот видишь тут нужно архитектурить... очень смешно.
Ты мне лучше скажи, что ты собрался архитектурить в бухгалтерии?
Ведь после создания ДСЛ остается тупо открыть закон и переводить его в код.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexCab, Вы писали:
WH>>Ну и заглядывай в сам ДСЛ. А не в тот код, который он генерирует. AC>Как пользователь, что я там пойму?
А что ты понимаешь глядя в библиотеку?
AC>Nemerle это один, хоть и расширяемый ЯП, для одной платформы, а представь их 100+(бывают же проекты с таким количеством библиотек) генерящих разный код.
И они всё равно будут генерировать код в один язык.
И на этом уровне прекрасно уживаться.
И никакой разницы с тем, что сейчас происходит в немерле нет.
AC>Время шло, библиотеки менялись на DSL'и, в конце-концов их осталось всего нечего, и в чью-то голову пришла мысль "а давайте выкинем C#, а DSL'и пусть компилятся сразу в CIL". AC>Насколько им это будет тяжело сделать?
Придется переписать кодогенерацию. Насколько это сложно зависит от того сколько нужно писать.
Но зачем? Профит где?
AC>Я побродил там, нашел сотни незнакомого мне кода и несколько не понятных комментариев, ничего не понял. Я так понимаю архитектурной документации(диаграмм особенно(особенно с паттернами),описаний) у вас нету?
Рука лицо.
Я тут уже сколько раз говорил, что архитектура == язык.
Вот язык, написанный на себе. https://github.com/rampelstinskin/ParserGenerator/blob/8d02b02b76ed08ab9f71a54ca62b5091538e6cf4/N2/N2.Grammar/GrammarParser2.n2
WH>>После чего подумай, чего тебе будет стоить переписать это на С. AC>Так что не могу оценить объём критического кода.
А там нет ни строчки критического кода.
Он весь генерируется.
Для того чтобы его увидеть нужно сделать то что я сказал, а не то что сделал ты.
Весь код парсинга лежит во вложенном классе GrammarImpl.
Но рядом там еще куча всего лежит.
Короче посмотри на эту не реальную гору кода и подумай, сколько времени ты это будешь писать.
Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше. Причем код там такой, что сокращать практически нечего.
А на С получится еще больше.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
AC>>Мне чертовски сложно представить код которой не нужно тестировать после изменений в его компиляторе. S>Вы делаете полный regression каждый раз, как MS шиппит апдейт к C#?
А вы не делаете? о_О
И во вторых, я уверен M$ тратит не мало усилий на тестирование компилятора. Вы готовы тратить столько-же(конечно DSL'и будут проще чем C#, но их будет больше)? S>Вот, скажем, вы сходу сможете сказать, во что разворачивается linq-expression?
Линг он один и хорошо документирован(наверно), а DSL'и будут как библиотеки — писаться кем попало и как попало. AC>>3)"разбухание" генерированного кода(в особо запущенных случаях можно 1-1000 достичь(о которых WolfHound пишет )). S>Во первых, непонятно, почему вас беспокоит этот параметр.
Я начинал, и много программировал на ассемблере S>Во-вторых, отлично, если этот код — нужный.
В том-то и беда, это не нужный код, потому как автоматическая оптимизация менее эффективна(если бы было иначе pure C давно бы стал историей). S>Мы сократили объём ручной работы и уменьшили шансы сделать ошибку.
И это замечательно, но было-бы ещё лучше если бы мы нашли решение позволяющее: и сократить объём работы, и получить хороший код на выходе.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, WolfHound, Вы писали: WH>Ведь после создания ДСЛ остается тупо открыть закон и переводить его в код.
Не, тут не всё так просто.
Там нужно уметь поддерживать штуки типа "до 01.01.2011 считаем так, а потом — вот эдак". И перерасчёт прошлых периодов должен сохранять инварианты.
Нужно уметь поддерживать пользовательский выбор там, где он нужен.
В общем, в бухгалтерии есть где развернуться архитектору.
То есть я верю, что там тоже найдётся место DSL, причём это будет DSL ориентированный на прикладного пользователя.
Но насчёт "перевода закона в код" у меня сомнения. Разве что это будет ещё один, промежуточный DSL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Там нужно уметь поддерживать штуки типа "до 01.01.2011 считаем так, а потом — вот эдак". И перерасчёт прошлых периодов должен сохранять инварианты.
Вот мы и делаем ДСЛ, который позволяет прямо так и писать.
И после того как мы его сделаем архитектурить больше нечего.
Остается только сесть и писать.
S>Но насчёт "перевода закона в код" у меня сомнения. Разве что это будет ещё один, промежуточный DSL.
Нет. Это будет именно тот язык, что мы создали строчкой выше.
Ибо если он потребует дополнительных наворотов, то это означает что мы не решили задачу.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
.
