Здравствуйте, WolfHound, Вы писали:
I>>Перечитай или попроси что бы тебе объяснили — в строчке повыше твоей речь не о "можно" а о "нужно". Нет хорошего имени — все твои абстракции окажутся мусором, даже если язык будет трижды простой. WH>Понятно. WH>Показать задачу не можешь. WH>Ищешь отмазки.
Представь себе воркфлоу который делает тож самое что и агент турфирмы — бронирует билеты, проверяет документы, оформляет визу, бронирует номера в гостинице и тд и тд и тд и тд.
Таких агентов несколько штук, занимаеются разными вещами.
Это все , как ты понимаешь, чисто эвристика. Все что можно сделать в конкретном языке — убрать лишний код, вроде лишних скобочек. Агенты отличаются минимально, одному надо резервировать до X, другому после X, третьем вообще не надо. Как только ты упаковываешь схожую логику хотя бы в функцию, наглядность резко пропадает.
Потому проще воркфлоу представлять графически, что бы инструмент сам менял уровень детализации.
I>>Хочешь оспорить — предложи хороший текстовый язык взаимодействия пользоваетля с комьютером WH>Графика хорошо работает на мааааленьких объемах.
Графика может качетсвенно менять требуемый уровень детализации, ни один текст этого не позволяет.
WH>Но совершенно не масштабируется.
Масштабирование это смена уровня детализации а не то что ты думаешь.
WH>На досуге подумай, почему провалились все графические средства разработки.
И потому автоматы, схемы БД, воркфлоу и тд, описываются графичиески ? А ты непростой
Здравствуйте, WolfHound, Вы писали:
WH>А ты тут со мной споришь. WH>И как только у нас появляется ДСЛ точно отражающий предметную область архитектура готова.
Предметную область чего ? Десктоп, веб, мобайл приложения которые предназачены для одного и того же, имеют совершенно разные архитектуры, как ты это ДСЛ собираешься добиваться ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Дизайн там, где мы для реализации этой возможнгости выбрали стартегию.
А что мы ещё могли выбрать? AVK>При чем тут другие варианты? Напоминаю определение паттерна — "formal way of documenting a solution to a design problem".
Ну вот та Стратегия, которую я знаю, она вполне конкретная. Это не паттерн "проектирования вообще", а паттерн, при котором три или более классов находятся в определённых взаимоотношениях.
С натяжкой я могу себе представить ситуацию, в которой мы обсуждаем паттерн Стратегия в бесклассовом языке с объектами (типа JS).
Ты же ведёшь речь явно не об этом — никаких классов ещё нет, да и объектов тоже. Тем не менее, Стратегия уже есть.
Ты не мог бы привести более полное описание, или хотя бы определение для неё?
Потому что пока что это звучит так, что любое ветвление в алгоритме, сформулировнном в самых общих терминах (виртуальной машины или частично-рекурсивных функций) подходит в качестве Стратегии.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали: AVK>Это я тебя не понимаю. От того что обеспечение calling conversion берет на себя компилятор, вызов метода никуда не девается, он остается вызовом метода.
При этом он перестаёт быть паттерном, и нам не надо его "узнавать" за частоколом push;push;push;jmp;pop.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В этом смысле "паттерн" исчезает. Остаётся семантика.
Я именно это и говорю.
Но иди, объясни это Ikemefula и компании.
Ничего у тебя не получится.
S>Для меня паттерн — это некий особенный способ собрать воедино несколько "штук" из набора моих кубиков.
Только тут есть один важный момент.
Ты сначала просто пишешь код. И замечаешь, что некоторые кубики часто собираются в определенный узор.
После чего ты понимаешь, что это паттерн.
Именно так возникли все паттерны.
S>Если у меня вместо этого способа есть готовый кубик, то никакого "паттерна" уже нет.
Совершенно согласен.
Нет повторяющегося узора.
Нет паттерна.
Но иди, объясни это тем, кто со мной спорит.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
AVK>>Дизайн там, где мы для реализации этой возможнгости выбрали стартегию. S>А что мы ещё могли выбрать?
Не знаю. А что?
AVK>>При чем тут другие варианты? Напоминаю определение паттерна — "formal way of documenting a solution to a design problem". S>Ну вот та Стратегия, которую я знаю, она вполне конкретная. Это не паттерн "проектирования вообще", а паттерн, при котором три или более классов находятся в определённых взаимоотношениях.
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.
В ООП мейнстриме да, она приводит к конкретным классам, что логично.
S>Ты же ведёшь речь явно не об этом — никаких классов ещё нет, да и объектов тоже. Тем не менее, Стратегия уже есть.
Верно. Полностью соответствующая приведенному определению.
S>Потому что пока что это звучит так, что любое ветвление в алгоритме, сформулировнном в самых общих терминах (виртуальной машины или частично-рекурсивных функций) подходит в качестве Стратегии.
Придумывание паттернов от конструкций в коде — паттерны так не работают (ну кроме паттернов, решаюших какие то проблемы языка, разумеется). Скажем, некоторые паттерны в реализации могут приводить к одному коду, и понять только по реализации, который из них, не всегда возможно, нужна дополнительная семантика — какую проблему архитектуры решали.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, Ikemefula, Вы писали:
I>Я спрашивал про то, откуда взялись цифры, на это ты ничего не ответил ни тогда, ни сейчас.
Я просто сравнивал размер кода на ДСЛ и того кода который из него получался.
Если делать без ДСЛ, то тебе этот код придется написать руками.
Ну и можешь сам прикинуть какая разница между проектом в 1000 и 1000000 строк.
I>Это мягко говоря неправда. Только пару продуктов стали лидирующими в своей нише.
Ни одна контора не может быть номер один везде.
Это просто не реально.
Разговор всегда идет про определенную нишу.
I>Я такое делал безо всякого немерле
Как? Руками засовывал логику отображения в бизнеслогику?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Паттерны проявляются при слабости языка.
Паттерны появляются вне зависимости от языка.
На примере итерации — это абстракция.
В поиске решения задачи на каком то шаге ты просто находишь, что итерация это и есть искомое. Теперь нужно записать решение в коде. И теперь, если устранить дублирование (= убить копипасту) у тебя в коде будет реализован паттерн — итератор, это будет или в виде классов, или в виде функций, или в обобщенном виде, или даже в любимых тобой макрах или ДСЛ — не важно — это будет ПАТТЕРН ИТЕРАТОР.
То есть, паттерн это не копипаста, паттерн это элемент решения, при чем тогда, когда кода еще нет ни строчки. А реализация паттерна — это решение задачи + убиение копипасты.
Здравствуйте, Sinclair, Вы писали:
AVK>>Это я тебя не понимаю. От того что обеспечение calling conversion берет на себя компилятор, вызов метода никуда не девается, он остается вызовом метода. S>При этом он перестаёт быть паттерном
О май гад. Код не становится и не перестает быть паттерном. Паттерн это способ описания архитектуры. Наличие или отсутствие паттерна — добрая воля архитектора, описывающего архитектуру, а не какая то особенность готового кода.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
WH>>Она уходит в язык. AVK>Продемонстрируй, как архитектура уходит в язык.
Так ты же сам написал.
К примеру, если нам интересен детальный механизм вызова метода (к примеру, описываем немакроассемблер, где готовой инструкции call и соглашений о параметрах нет), то да, мы можем сформулировать в описании архитектуры вызов метода как паттерн. Если же описание архитектуры более абстрактно, выделять вызов метода как спецпаттерн не нужно, описательности это не добавит.
Ты тут прямым текстом пишешь что:
1)Язык и архитектура связаны один к одному.
2)Если поднять уровень языка и архитектуры, то паттерны начинают исчезать.
AVK>Это я тебя не понимаю. От того что обеспечение calling conversion берет на себя компилятор, вызов метода никуда не девается, он остается вызовом метода.
Да.
Но исчезает паттерн, который складывает аргументы функции в стек и регистры в нужном порядке.
AVK>То есть с определением из вики ты не согласен?
Я согласен с исходным определением, а не тем которое дают адепты называния копипасты красивым словом.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Потому что пока что это звучит так, что любое ветвление в алгоритме, сформулировнном в самых общих терминах (виртуальной машины или частично-рекурсивных функций) подходит в качестве Стратегии.
Ты начинаешь понимать предмет спора.
Наши оппоненты уверены, что паттерны это что-то данное свыше.
Что-то абсолютное, что не может быть устранено ничем и никак.
Но то, что я понял, что люди так думают это само по себе очень ценное наблюдение из данной дискуссии.
Я буду учитывать данный паттерн мышления в будущем.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ikemefula, Вы писали:
I>>Я спрашивал про то, откуда взялись цифры, на это ты ничего не ответил ни тогда, ни сейчас. WH>Я просто сравнивал размер кода на ДСЛ и того кода который из него получался. WH>Если делать без ДСЛ, то тебе этот код придется написать руками.
И это по твоему продуктивность ? В 10 раз меньше строк == в 10 раз больше продуктивность.
Время решения задачи у тебя равно нулю ? Время согласования требований тоже равно нулю ? Время исследования проблемы у так же равно нулю ?
I>>Это мягко говоря неправда. Только пару продуктов стали лидирующими в своей нише. WH>Ни одна контора не может быть номер один везде. WH>Это просто не реально. WH>Разговор всегда идет про определенную нишу.
По любому качественным результатом должен быть выход на новй рынок или на новые позиции на старом рынке.
I>>Я такое делал безо всякого немерле WH>Как? Руками засовывал логику отображения в бизнеслогику?
Зачем ? Ты ж внятно прочитай. Там речь про исключения и свойство которое используется в UI и выставляется автоматом по месту возникновения.
Здравствуйте, WolfHound, Вы писали:
WH>Ты тут прямым текстом пишешь что: WH>1)Язык и архитектура связаны один к одному.
Связаны один к одному и являются одним и тем же это мягко говоря две большие разницы
WH>2)Если поднять уровень языка и архитектуры, то паттерны начинают исчезать.
Не уровень языка и архитектуры, а уровень решаемой задачи. Одни паттерны заменяются на другие.
AVK>>Это я тебя не понимаю. От того что обеспечение calling conversion берет на себя компилятор, вызов метода никуда не девается, он остается вызовом метода. WH>Да. WH>Но исчезает паттерн, который складывает аргументы функции в стек и регистры в нужном порядке.
Никуда он не исчезает, типовая задача более низкого уровня уже решена, все это находится в компиляторе или инфраструктуре.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю. А что?
Ну тогда у нас получается, что решение == задаче. Есть требование "нужно выбирать алгоритм в рантайме". Ок, начинаем проектировать: "давайте выбирать алгоритм в рантайме". А для чего нам тогда понятие "паттерн"?
AVK>>>При чем тут другие варианты? Напоминаю определение паттерна — "formal way of documenting a solution to a design problem". S>>Ну вот та Стратегия, которую я знаю, она вполне конкретная. Это не паттерн "проектирования вообще", а паттерн, при котором три или более классов находятся в определённых взаимоотношениях.
AVK>
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.
Обана. Прикольно. Осталось, чтобы я понял, какой design problem мы тут решаем, и в чём соль solution, который мы documenting.
В таком описании для проектирования достаточно трёх паттернов: Стратегия (она же Policy), Следование (она же Последовательность), и Ничто.
Емнип, это было убедительно продемонстрировано ещё в каменном веке.
AVK>В ООП мейнстриме да, она приводит к конкретным классам, что логично.
А в SQL оно к чему приведёт?
А в ФП? AVK>Верно. Полностью соответствующая приведенному определению.
Непонятно. AVK>Придумывание паттернов от конструкций в коде — паттерны так не работают (ну кроме паттернов, решаюших какие то проблемы языка, разумеется). Скажем, некоторые паттерны в реализации могут приводить к одному коду, и понять только по реализации, который из них, не всегда возможно, нужна дополнительная семантика — какую проблему архитектуры решали.
Ты отвечаешь не на тот вопрос. У нас не стоит требование однозначного восстановления паттерна по коду. Наоборот — нам достаточно умения писать код по паттерну.
Но отвлечёмся от приёмов конкретного программирования и вернёмся к проектированию.
По моему опыту, проектирование — оно всегда в терминах чего-то. Если я проектирую базу данных, то у меня есть ER-модель, и я проектирую в терминах "сущность-связь". И паттерны, которыми я буду пользоваться — это ровно типовые решения для типовых задач.
Скажем, для задачи "связать между собой сущности в многие-ко-многим" я имею паттерн "Link Table", в котором вводятся промежуточные сущности.
Для задачи "changes tracking" я имею всякие паттерны вроде value history и archive table. Заметь, никаких "стратегий", никаких "абстрактных фабрик" — всё потому, что язык, которым я говорю, не включает слов, из которых можно построить такие "фразы".
Поэтому я совершенно не понимаю, каким волшебным образом мы имеем паттерн, не опирающийся ни на какие "нижележащие" концепции. В чём решение? Решение — это "возьми ..., приделай к ..., и добавь штуку, которая порождается из ... и ... по таким-то правилам".
Есть задача — позавтракать, то есть обеспечить организм белками, жирами, и углеводами на первую половину дня.
Есть паттерн для неё — "континентальный завтрак", который описывает, какого типа продукты нужно подавать. При этом подробностей реализации в нём нету — всякий повар трактует континентальный завтрак по-своему. Но говорить, что определение "континентального завтрака" == "завтрак, обеспечивающий организм белками, жирами, и углеводами на первую половину дня" — это профанация. Именно это происходит в определении паттерна "стратегия", которое ты привёл.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: AVK>>Это я тебя не понимаю. От того что обеспечение calling conversion берет на себя компилятор, вызов метода никуда не девается, он остается вызовом метода. S>При этом он перестаёт быть паттерном, и нам не надо его "узнавать" за частоколом push;push;push;jmp;pop.
Как-бы ничего не мешает использовать этот паттерн передачи аргументов в высокоуровневом ЯП: определить глобальную коллекцию-стек, помещать туда аргументы, а функцию/процедуру вызывать без аргументов.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали: S>>При этом он перестаёт быть паттерном, и нам не надо его "узнавать" за частоколом push;push;push;jmp;pop. AC>Как-бы ничего не мешает использовать этот паттерн передачи аргументов в высокоуровневом ЯП: определить глобальную коллекцию-стек, помещать туда аргументы, а функцию/процедуру вызывать без аргументов.
Это будет другой паттерн, т.к. он построен из других примитивов. И решает, надо полагать, какую-то другую задачу (потому что для решения оригинальной задачи уже есть готовая реализация в языке).
Не стоит сходу объявлять паттерном любой шаблон порождения бессмысленного кода.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: AC>>И теперь внимание вопрос: Насколько дороже обойдётся рефакторинг такого DSL(особенно если по верх него ещё 10)по сравнению с спроектированным? По сравнению с библиотекой? S>Даже не будучи Волкодавом, могу ответить: конечно же рефакторинг такого DSL обойдётся в разы дешевле.
Я больше теоретик, но если на практике это будет так это будет замечательно. S>Вот смотри...
Это, я так понял измение в интерфейсе библиотеки. Да они дорого обходятся. Но тоже справедливо и для DSL, если нам прийдётся менять синтаксис(котороый интерфейс DSL) нужно будет править весь написаный на нём пользователями код. А если поверх первого есть второй DSL то ещё и править его транслятор(чтобы он генерил код с исправленым синтаксисам). S>А в DSL мы просто меняем 1 строчку в 1 месте макропроцессора и весь код, все его 100%, подвергаются изменению. Перетестировать их не надо — достаточно перетестировать макрос.
Мне чертовски сложно представить код которой не нужно тестировать после изменений в его компиляторе.
По моему скромному мнению, беда DSL(реализованых при помощи МП, а не в принципе), по сравнению с библиотеками, в том что:
1)по макроссам сложно составить полное и ясное представление что за код будет сгенерирован,
2)генерированый код будет монолитным и не читабльным.
Из чего следует:
1)отладка/тестирование транслятора — занятие не для слабонервных,
2)проблеммы с взаимо-интеграцией DSL'ей(и по вертикали, и по горизонтали),
3)"разбухание" генерированного кода(в особо запущенных случаях можно 1-1000 достичь(о которых WolfHound пишет )).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, WolfHound, Вы писали:
WH>Так ты же сам написал.
WH>
WH> К примеру, если нам интересен детальный механизм вызова метода (к примеру, описываем немакроассемблер, где готовой инструкции call и соглашений о параметрах нет), то да, мы можем сформулировать в описании архитектуры вызов метода как паттерн. Если же описание архитектуры более абстрактно, выделять вызов метода как спецпаттерн не нужно, описательности это не добавит.
WH>Ты тут прямым текстом пишешь что: WH>1)Язык и архитектура связаны один к одному.
Связаны, да. Но связаны не значит архитектура=паттерн. Кузов авто и мотор связаны один-к-одному, но мотор кузовом не является.
WH>2)Если поднять уровень языка и архитектуры, то паттерны начинают исчезать.
Да. Некоторые, в основном на очень низком уровне.
Только это никоим образом не означает, что архитектура куда то исчезает. Исчезают языково-ориентированные паттерны, это нормально и даже хорошо. Но проблемно-ориентированные паттерны никуда не деваются. И уж тем более я совершеннол не понимаю, что это за DSL такой, в котором исчезают прикладные сущности и связи между ними.
WH>Но исчезает паттерн, который складывает аргументы функции в стек и регистры в нужном порядке.
Из прикладного уровня да, исчезает. Я с самого начала писал — трактовать вызов метода как паттерн в подавляющем большинстве случаев не нужно.
AVK>>То есть с определением из вики ты не согласен? WH>Я согласен с исходным определением, а не тем которое дают адепты называния копипасты красивым словом.
Ответь на простой вопрос — согласен ли ты с конкретным определением паттерна проектирования в английской вики?
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, Sinclair, Вы писали:
AVK>>Не знаю. А что? S>Ну тогда у нас получается, что решение == задаче.
Нет, не получается. Задачу я не описывал, я описывал решение. Задача — дать возможность пользователям настраивать механику проводок. Я лично видел целую тучу реализаций подобного в разных системах. Например, пачка параметров по модификации захардкоженного алгоритма проводок. Или вообще единственный способ модификации — изменение 1С-конфигурации и написание кода. Сменяемый пользователем алгоритм формирования ХО как публично видимая сущность — это уже конкретное решение, а не входная задача.
S>В таком описании для проектирования достаточно трёх паттернов: Стратегия (она же Policy), Следование (она же Последовательность), и Ничто.
Поясни мысль.
AVK>>В ООП мейнстриме да, она приводит к конкретным классам, что логично. S>А в SQL оно к чему приведёт?
К таблицам и прочим сущностям sql.
S>А в ФП?
Функциям и различным структурам и классификаторам.
S>Поэтому я совершенно не понимаю, каким волшебным образом мы имеем паттерн, не опирающийся ни на какие "нижележащие" концепции.
Этот вопрос в топике уже был — на какие нижележащие концепции опирается паттерн Chain of Resposibility? MVC?
Но интереснее другое — как из того, что какой то паттерн опирается на нижележащие концепции следует, что при применении DSL не нужна архитектура? Может хоть ты пояснишь?
S>Есть паттерн для неё — "континентальный завтрак", который описывает, какого типа продукты нужно подавать. При этом подробностей реализации в нём нету — всякий повар трактует континентальный завтрак по-своему. Но говорить, что определение "континентального завтрака" == "завтрак, обеспечивающий организм белками, жирами, и углеводами на первую половину дня" — это профанация.
А никто тут ничего подобного и не говорит. Если соответствовать приведенному определению паттерна, то "континентальный завтрак" это термин, который нужен чтобы написать его в меню, и клиенты по нему сразу поймут, о чем речь, не вдаваясь в детальное изучение всех ингредиентов и способов их приготовления.
S> Именно это происходит в определении паттерна "стратегия", которое ты привёл.
Это определение я взял из википедии. Оно там давно и вполне устаканено. Так что если у тебя притензии к общепринятым определениями — это не ко мне.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
В 10 раз меньше строк == в 10 раз больше продуктивность.
