Re[5]: Паттерны проектирования - копипаста! - Философия программирования

Здравствуйте, WolfHound, Вы писали:

WH>ДСЛ это когда
WH>assert a == b;
WH>а все остальное сделается само.

Ну где-то должен передаваться текст которым я хочу ругнуться, и список параметров, потому что я могу захотеть вывести не только a и b, а например какие-нибудь параметры при которых они получены, да и считаю упырством символ "==" если уж у нас DSL, так что что-то типа:

assert a equal b, "Хотели $a, а получилось $b"

И вот извините, но это очень мелкое преимущество над

Assert.AreEqual(a, b, "Хотели {0}, а получилось {1}", a, b);

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

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

Пробовал и без проблем. Из попсовых примеров могу вспомнить архитектуры всяких Mock, где ~ Assert.That(a.HasProperty("t").Equal(2).And.HasProperty("t", 1)); — чем плохо?

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

Нет, паттерны хороши также тем, что ты спрашиваешь у другого человека: "Хочу отлаживать приложение на заглушках, которые все делают в памяти, а собирать в релизе полноценную версию с подключениями к базе, интернету и энтерпрайзной шиной", а он говорит: посмотри в сторону IoC библиотек или Abstract Factory. Причем и ты можешь легко нагуглить о чем речь, и советующий человек не сильно напрягся, ибо просто подобрал для тебя возможно подходящие паттерны. И это важно.

WH>Если нет. То придётся писать язык.
WH>Ибо если это не хелло ворлд на сотню строк, то язык очень сильно сократит объем работы.

Если писать язык, то сократится суммарная работа? Увы, по моей практике — нет.
Хотя очевидно зависит от окружения. Если предстоит делать много проектов в одной области, поддерживать их и разрабатывать новые в той же сфере — то видимо иногда да, да собственно и создаются такие языки, это не секрет. Особенно основанные на xml в таких вопросах популярны.

Здравствуйте, Ikemefula, Вы писали:

I>Неправильно. Это решение типовой задачи.
Типовые задачи должен решать язык.
Если язык их решить не может и перекладывает на программиста копипасту то это плохой язык.

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

I>В предметной области уже есть паттерны...
Их там нет. Не выдумывай.

I>Монады, например, есть по сути те самые паттерны.
А где я хоть слово говорил про монады?
Я не вижу особой разницы между хаскелем и явой. Ибо он тоже язык общего назначения. И тоже не имеет в себе средств поднятия уровня языка до тех пор, пока в коде не исчезнут паттерны.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

WH>>ДСЛ это когда
WH>>assert a == b;
I>Внезапно — это уже паттерн, ага , только минимум копипасты

В каком месте?
Тут написано: утверждаю a равно b.
Это бизнес логика. И её никуда не убрать. По крайней мере, на данном уровне кода. Возможно, если обратиться к изначальной постановке задачи, то и assert a == b можно будет сгенерировать.
А паттерн это вот это говнокод

if (a != b)
{
  throw new Exception(string.Format("Хотели {0}, а получилось {1}",a,b));
}

Который еще и условие заставляет инвертировать.

I>А еще нужно что бы ты сам помнил. Помнить что реализован паттерн из некоторого семейства проще, чем запоминать все детали реализации.
А еще проще вообще его не реализовывать.

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

А теперь ДЗЕН вынесенный из этого проекта:
Ближе к концу мы уже не стремились лепить библиотечные навороты и расширять фреймворк, а скорее старались заменять макросами рукопашный код насовсем но локально. Т.е. гораздо проще разработать какую-то феньку нужную в 5 местах и без параметров, и какую-то очень похожую феньку (даже внешне точно такую-же) для 5 других мест, чем лепить универсальную, конфигурируемую через кучу параметров мега-фень, способную покрыть все эти 10 мест и ещё 20 гипотетических похожих.

(С)
Они тем и занимаются что, видя паттерн, убивают его макросом.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>От этого никуда не уйти, в принципе. можно только уменьшить размеры копипасты и заменить одну копипасту на другую.

То-то я уменьшаю копипасту до таких размеров, что она исчезает.

I>У тебя должно быть хорошее объяснение почему эти вещи не теряют популярности, а до кучи набирают популярность такие вещи как питон, джаваскрипт, руби или ПХП!!!
Кобол в свое время тоже набирал.

I>Зависит от данных которые нужно обрабатывать. Попробй на sql обрабатывать изображения или хотя бы задачи маршрутизации решать хотя бы в самом простейшем виде — охренеешь.
Я и не говорил, что на SQL можно все обрабатывать.
Но обработку тех данных, на которые заточен SQL сделать проще, чем на SQL очень не просто.

I>В каком смысле "порвут" ? По стоимости разработки ? По стоимости сопровождения ? Быстродействию ? Потреблению памяти ? По кривой вхождения ? По всем вместе взятым ? По любому подмножеству ? В любой временной перспективе ?
На задачах размером больше хелловролд по всем параметрам. И чем задача больше, тем сильнее отрыв.
Скажем, я сейчас занимаюсь оптимизацией, которую никогда бы не стал делать руками.
Ибо тот код, который будет генерироваться, просто невозможно написать руками без ошибок.
Тут даже не порядки. Тут возможно против невозможно.
При этом исходный ДСЛ не изменится. Совсем.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Nuseraro, Вы писали:

N>так что что-то типа:
N>assert a equal b, "Хотели $a, а получилось $b"
А теперь тебе понадобится это локализовать...

N>И вот извините, но это очень мелкое преимущество над
Это по тому, что ты задачу так выбрал.

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

Практика показывает, что отладка работает прекрасно.

N>Пробовал и без проблем. Из попсовых примеров могу вспомнить архитектуры всяких Mock, где ~ Assert.That(a.HasProperty("t").Equal(2).And.HasProperty("t", 1)); — чем плохо?
Ну, хотя бы тем, что я так и не понял что тут написано.

N>Нет, паттерны хороши также тем, что ты спрашиваешь у другого человека: "Хочу отлаживать приложение на заглушках, которые все делают в памяти, а собирать в релизе полноценную версию с подключениями к базе, интернету и энтерпрайзной шиной", а он говорит: посмотри в сторону IoC библиотек или Abstract Factory. Причем и ты можешь легко нагуглить о чем речь, и советующий человек не сильно напрягся, ибо просто подобрал для тебя возможно подходящие паттерны. И это важно.
Ты написал ровно то же самое что и я.
Но только общение развернул.

N>Если писать язык, то сократится суммарная работа?
Обычно на порядок. Если не больше.

N>Увы, по моей практике — нет.
Может проблема в том, что ты взял плохие инструменты?

N>Хотя очевидно зависит от окружения. Если предстоит делать много проектов в одной области, поддерживать их и разрабатывать новые в той же сфере — то видимо иногда да, да собственно и создаются такие языки, это не секрет. Особенно основанные на xml в таких вопросах популярны.
Во-во. Ты взял худший из возможных инструментов и удивляешься, почему все так плохо.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Неправильно. Это решение типовой задачи.
WH>Типовые задачи должен решать язык.

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

I>>В предметной области уже есть паттерны...
WH>Их там нет. Не выдумывай.

Есть. Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны. И какой язык тебе поможет избежать этого ?

Здравствуйте, WolfHound, Вы писали:

I>>Внезапно — это уже паттерн, ага , только минимум копипасты

WH>В каком месте?
WH>Тут написано: утверждаю a равно b.
WH>Это бизнес логика. И её никуда не убрать. По крайней мере, на данном уровне кода. Возможно, если обратиться к изначальной постановке задачи, то и assert a == b можно будет сгенерировать.

Это не бизнеслогика, а проверка инварианта.

WH>А паттерн это вот это говнокод
WH>

WH>if (a != b)
WH>{
WH>  throw new Exception(string.Format("Хотели {0}, а получилось {1}",a,b));
WH>}
WH>

WH>Который еще и условие заставляет инвертировать.

А вот это просто говнокод и никакой не паттерн.

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

WH>

WH>А теперь ДЗЕН вынесенный из этого проекта:
WH>Ближе к концу мы уже не стремились лепить библиотечные навороты и расширять фреймворк, а скорее старались заменять макросами рукопашный код насовсем но локально. Т.е. гораздо проще разработать какую-то феньку нужную в 5 местах и без параметров, и какую-то очень похожую феньку (даже внешне точно такую-же) для 5 других мест, чем лепить универсальную, конфигурируемую через кучу параметров мега-фень, способную покрыть все эти 10 мест и ещё 20 гипотетических похожих.

WH>(С)
WH>Они тем и занимаются что, видя паттерн, убивают его макросом.

Читай внимательно — меняют не все подряд, а "какую то феньку нужную в 5 местах" , то есть хорошо изолированую задачу, об чем я тебе и говорю.

Здравствуйте, WolfHound, Вы писали:

I>>От этого никуда не уйти, в принципе. можно только уменьшить размеры копипасты и заменить одну копипасту на другую.
WH>

То-то я уменьшаю копипасту до таких размеров, что она исчезает.

Главное что бы ктото кроме тебя мог легко её поднять.

I>>У тебя должно быть хорошее объяснение почему эти вещи не теряют популярности, а до кучи набирают популярность такие вещи как питон, джаваскрипт, руби или ПХП!!!
WH>Кобол в свое время тоже набирал.

То есть, объяснения нет

I>>В каком смысле "порвут" ? По стоимости разработки ? По стоимости сопровождения ? Быстродействию ? Потреблению памяти ? По кривой вхождения ? По всем вместе взятым ? По любому подмножеству ? В любой временной перспективе ?
WH>На задачах размером больше хелловролд по всем параметрам. И чем задача больше, тем сильнее отрыв.

Чушь.
По кривой вхождения очень трудно порвать питон или джаваскрипт для небольших сценариев или даже программ строчек в 100-1000.
По производительности очень трудно порвать С в тех местах где высокоуровневые оптимизации уже выюзаны.
В краткосрочной персктиве мне на C#, например, безо всяких ДСЛ для решения своих задач нужно день-два, а тебе только месяцы на чтение спек.
По стоимости сопровождения, например, многие проекты меняют тимы и живут десятками лет, сильно вряд ли твои мульки будут обладать преимуществом.

Здравствуйте, Ikemefula, Вы писали:

WH>>

То-то я уменьшаю копипасту до таких размеров, что она исчезает.
I>Главное что бы ктото кроме тебя мог легко её поднять.
Какого? Копипасту? Так у меня её нет. Так что и понимать нечего.

I>То есть, объяснения нет

То есть ровно по тем же самым причинам, почему использовали кобол.

I>Чушь.
Сказал человек, который никогда этим не пользовался.

I>По кривой вхождения очень трудно порвать питон или джаваскрипт для небольших сценариев или даже программ строчек в 100-1000.
Это хелловорлд.
Да и то это не правда.
Въезжать в калькулятор на питоне ты будешь гораздо дольше, чем в калькулятор на ДСЛ.

I>По производительности очень трудно порвать С в тех местах где высокоуровневые оптимизации уже выюзаны.
Ага. Конечно.
Ты просто представления не имеешь. На что способны оптимизаторы, которые оптимизируют конкретную предметную область.
Да тот код, что я генерирую, я на C никогда руками не напишу.
Ибо там всё в ошибках будет. Которые потом придется годами вылавливать.

I>В краткосрочной персктиве мне на C#, например, безо всяких ДСЛ для решения своих задач нужно день-два, а тебе только месяцы на чтение спек.
Каких еще спек?
На ДСЛ?
Так практика показывает что, зная предметную область ДСЛ понимается без чтения спек ваще.
А без знания ты и на C# опупеешь въезжать в предметную область.
Более того у тебя уйдет намного больше времени. Ибо в коде на C# предметной областью только пахнет. И тебе придется догадываться как все это нагромождение классов и методов ложится на решаемую задачу.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Это не бизнеслогика, а проверка инварианта.
Из этого куска кода это не ясно.

I>А вот это просто говнокод и никакой не паттерн.
Паттерн. Ибо очень часто повторяется.

I>Читай внимательно — меняют не все подряд, а "какую то феньку нужную в 5 местах" , то есть хорошо изолированую задачу, об чем я тебе и говорю.
А теперь прочитай про те самые "хорошо изолированные задачи"...

Или вот ещё ацкий трэш — у нас некоторые исключения имели помимо важности ещё свойство Color, которым (ааа111!!!) их надо было подсвечивать в GUI. Выставлялось это свойство автоматом, исходя из того в каком классе, в процессе работы над какой задачей, случился throw. Почему такое нарушение принципов вообще оказалось возможно — а потому что оно не выставлялось вручную вообще нигде. Т.е. GUI код просто использовал это свойство, и ему по-барабану как оно возникло, а программист который исключение кидал — даже не знал про какое-то там свойство, и его не выставлял. Соотвественно если бы мы решили эту хрень заменить, или вообще убрать — надо было бы менять только одно место, а значит принципы правильного разделения BL и GUI можно слать в конкретно этом случае лесом.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Это не бизнеслогика, а проверка инварианта.
WH>Из этого куска кода это не ясно.

Судя по тому, что в начале было Assert.AreEqual это более чем понятно откуда взялось

I>>Читай внимательно — меняют не все подряд, а "какую то феньку нужную в 5 местах" , то есть хорошо изолированую задачу, об чем я тебе и говорю.
WH>А теперь прочитай про те самые "хорошо изолированные задачи"...
WH>

WH>Или вот ещё ацкий трэш — у нас некоторые исключения имели помимо важности ещё свойство Color, которым (ааа111!!!) их надо было подсвечивать в GUI. Выставлялось это свойство автоматом, исходя из того в каком классе, в процессе работы над какой задачей, случился throw. Почему такое нарушение принципов вообще оказалось возможно — а потому что оно не выставлялось вручную вообще нигде. Т.е. GUI код просто использовал это свойство, и ему по-барабану как оно возникло, а программист который исключение кидал — даже не знал про какое-то там свойство, и его не выставлял. Соотвественно если бы мы решили эту хрень заменить, или вообще убрать — надо было бы менять только одно место, а значит принципы правильного разделения BL и GUI можно слать в конкретно этом случае лесом.

WH>Тут прямым текстом сказано, что они всю изоляцию нахрен разломали.

И здесь задача так же хорошо изолирована

А ты наверное "изоляция" понимаешь исключительно в контексте паттерна "слой"

Здравствуйте, Ikemefula, Вы писали:

WH>>Типовые задачи должен решать язык.
I>Задачи, даже типовые, решает человек и уже на этой стадии возникают паттерны. Паттерны в коде это просто следствие. Все что ты можешь это оформить поддержку паттернов в самом языке, например как это произошло с итератором.
О чем я и говорю.
Подкрутили язык и нет больше паттрна.

Поэтому я и пишу на языках, которые можно подкрутить.

А ты копипастишь паттрны на C# до тех пор пока макрософт не соизволит ввести в язык поддержку очередного паттрна общего назначения.
Которые, как известно бесполезны.
Читай что написано про паттерны общего назначения.

I>Есть. Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны. И какой язык тебе поможет избежать этого ?
Мне предметная область не знакома.
Но что-то мне подсказывает, что эти паттрны ни какого отношения к тем паттрнам, о которых мы говорим, не имеют.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>И здесь задача так же хорошо изолирована

А ты наверное "изоляция" понимаешь исключительно в контексте паттерна "слой"

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Задачи, даже типовые, решает человек и уже на этой стадии возникают паттерны. Паттерны в коде это просто следствие. Все что ты можешь это оформить поддержку паттернов в самом языке, например как это произошло с итератором.
WH>О чем я и говорю.
WH>Подкрутили язык и нет больше паттрна.

Паттерн никуда не делся.

I>>Есть. Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны. И какой язык тебе поможет избежать этого ?
WH>Мне предметная область не знакома.
WH>Но что-то мне подсказывает, что эти паттрны ни какого отношения к тем паттрнам, о которых мы говорим, не имеют.

Имеют. Исчезает конкретный код, а не паттерн. Паттерн это модель решения конкретной задачи.

Здравствуйте, WolfHound, Вы писали:

I>>И здесь задача так же хорошо изолирована

А ты наверное "изоляция" понимаешь исключительно в контексте паттерна "слой"

WH>Ну, так назови мне задачу, которая согласно твоим понятиям не изолирована.

ERP.

Здравствуйте, Ikemefula, Вы писали:

WH>>Ну, так назови мне задачу, которая согласно твоим понятиям не изолирована.
I>ERP.
42
Что сказать то хотел?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>>>Ну, так назови мне задачу, которая согласно твоим понятиям не изолирована.
I>>ERP.
WH>42
WH>Что сказать то хотел?

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

Здравствуйте, WolfHound, Вы писали:

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

Покажи мне как без итераций посчитать бегущую сумму. Вперёд.

Здравствуйте, Ikemefula, Вы писали:

I>Здесь много задач. Ни в одном приложении не встречается только одна из них, практически всегда идет целая пачка задач. Для сравнения если взять регулярные выражения, то приложении спокойно может быть одна две задачи. В первом случае изолировать не получится. Во втором — запросто.
Я опять ничего не понял.
Давай конкретно.
Что нельзя изолировать.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>>>Имеют. Исчезает конкретный код, а не паттерн. Паттерн это модель решения конкретной задачи.
WH>>Не путай модель предметной области и копипасту в конкретном языке которая нужна для того чтобы эту модель на этом языке реализовать.
I>Покажи мне как без итераций посчитать бегущую сумму. Вперёд.
И причем тут паттерны?
В любом случае можно сделать ФВП.
http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.html#v:scanl

Или сделать прямую поддержку пробежек по коллекциям в языке предметной области.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Здесь много задач. Ни в одном приложении не встречается только одна из них, практически всегда идет целая пачка задач. Для сравнения если взять регулярные выражения, то приложении спокойно может быть одна две задачи. В первом случае изолировать не получится. Во втором — запросто.
WH>Я опять ничего не понял.
WH>Давай конкретно.
WH>Что нельзя изолировать.

Задачи в такой области как ERP нельзя изолировать.

Здравствуйте, WolfHound, Вы писали:

WH>И причем тут паттерны?

Это и есть паттерн, а не то что ты думал.

WH>В любом случае можно сделать ФВП.
WH>http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.html#v:scanl

И здесь тож самое, только закорючек больше.

WH>Или сделать прямую поддержку пробежек по коллекциям в языке предметной области.

Вот-вот, а ты говорил паттрны не нужны.

Здравствуйте, Ikemefula, Вы писали:

I>Задачи в такой области как ERP нельзя изолировать.
Короче паттерны, которые нельзя убить языком ты так и не показал.
Засчитываю очередной слив с чистой совестью.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

WH>>И причем тут паттерны?
I>Это и есть паттерн, а не то что ты думал.
У тебя очень странное понимание паттернов.
Ибо в данном случае у нас стоит задача посчитать бегущую сумму.
Это задача предметной области.

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

А вызов одной функции это не паттерн. Иначе у нас всё состоит из паттернов, и разговор теряет всяческий смысл.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Задачи в такой области как ERP нельзя изолировать.
WH>Короче паттерны, которые нельзя убить языком ты так и не показал.

Аргумент про итерацию и блекджект ты проигнорировал ? Так держать !

Здравствуйте, WolfHound, Вы писали:

WH>>>И причем тут паттерны?
I>>Это и есть паттерн, а не то что ты думал.
WH>У тебя очень странное понимание паттернов.
WH>Ибо в данном случае у нас стоит задача посчитать бегущую сумму.
WH>Это задача предметной области.

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

WH>Но я не знаю ни одной осмысленной предметной области, где ставилась бы задача сделать визитер или абстрактную фабрику.
WH>Эти абсолютно бессмысленные с точки зрения предметной области сущности, которые кочуют из проекта в проект, и есть паттерны.

Это просто паттерны конкретной реализации. Они появляются там, где язык обладает хоть какими то свойствами. Нет свойств — нет паттернов. Правда и языка такого тоже нет.

В твоем случае паттерны вроде визиторов или фабрик перекочуют в реализацию ДСЛ, макросы и тд и тд и тд. Они никуда не деваются. Поскольку ты предлагаешь делать макры и дсл для каждой задачи по отдельности ("феньку нужную в 5 местах "), не желая рассматривать всю область, как ERP например, не совсем ясно чем же твой подход лучше.
Наверное тем, что паттерны "будут не в том месте"

Здравствуйте, Ikemefula, Вы писали:

I>Аргумент про итерацию и блекджект ты проигнорировал ? Так держать !
Про итерацию это никакой не аргумент. Ибо вызов функции не паттрен. Иначе все есть паттерн.
А про блекждек ты ничего не сказал.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Аргумент про итерацию и блекджект ты проигнорировал ? Так держать !
WH>Про итерацию это никакой не аргумент. Ибо вызов функции не паттрен. Иначе все есть паттерн.

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

WH>А про блекждек ты ничего не сказал.

Похоже ты просто заврался,цитирую себя:
"Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны."

Здравствуйте, Ikemefula, Вы писали:

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

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

Я думаю тебе еще рано говорить про остальных программистов, ты, как минимум, собираешься 99% вообще выбросить из индустрии

WH>И как следствие ты просто не понимаешь о чем вообще разговор.

Ты еще не понял, что бороться нужно с лишним кодом а не с паттернами.

Здравствуйте, Ikemefula, Вы писали:

I>Итерацию придется реализовывать одним из способов доступных в конкретном инструменте. Итерация это и есть паттерн. В конкретной реализации это может вылиться во что угодно.
Те любой вызов метода это паттерн.
Я тебя правильно понял?

WH>>А про блекждек ты ничего не сказал.
I>Похоже ты просто заврался,цитирую себя:
I>"Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны."
Где тут паттерны проектирования?

Ты вообще про паттерны почитай да.

Есть ООП паттерны типа визитера и абстрактной фабрики.
Есть функциональные паттерны типа zipper'а и scrap your boilerplate.

В любом случае мы говорим про паттерны в коде.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

__>>паттерны это естественные конструкции, которые возникают по мере разработки архитектуры
WH>Не правильно.
WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.

Упрощенчество. Скажем, паттерн "фасад" можно выделить даже тут:

class X {
  public void foo(); // Фасад
  public void zoo(); // Фасад
  protected void bar(); // Реализация
}

WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.

Или там, где нет необходимости вводить дополнительные конструкции в язык. Скажу крамольную вещь: подчас проще оперировать "паттернами", чем конструкциями языками, их реализующими. Связано это с тем, что "паттерн" является, в основном, мысленной конструкцией, и её можно легко адаптировать к реалиям того или иного языка. А вот языковая конструкция, реализующая паттерн — "чудище обло, огромно, стозевно и лаяй": по тем же причинам будет такой разнобой в реализациях, что мало не покажется.

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

Как водится, лучший способ доказать неправильную посылку — свернуть на обсуждение личности.

WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.

Лучший способ "бороться с паттернами" — употреблять их только в разговорной речи, а на языке программирования писать так, как он это позволяет.

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

Ну, как всегда — будем лечить ангину простудой, обвиняя пациента в том, что он не умеет болеть. Знакомо, знакомо...

P.S.: Чую, пора уже заводить новый мем: "Количество языков в проекте растёт до тех пор, пока оно не превысит возможности программиста".

Здравствуйте, Геннадий Васильев, Вы писали:

WH>>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
ГВ>Упрощенчество. Скажем, паттерн "фасад" можно выделить даже тут:
Как всегда. Написал, не поймешь что. И пытаешься строить далеко идущие выводы.
У тебя тут ни задачи. Без которой разговаривать не имеет смысла. Ни даже решения.

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

ГВ>Скажу крамольную вещь: подчас проще оперировать "паттернами", чем конструкциями языками, их реализующими.
А ты пробовал оперировать языковыми конструкциями, когда ты можешь их в любой момент создать и переделать как угодно?
Я пробовал.
Обратно на языки, которые это не могут, не хочу.

Шаблоны С++ по сравнению с этим детский сад. Ясельная группа.

ГВ>Связано это с тем, что "паттерн" является, в основном, мысленной конструкцией, и её можно легко адаптировать к реалиям того или иного языка.
Я предпочитаю языковые конструкции, которые могу легко адаптировать под себя.

ГВ>А вот языковая конструкция, реализующая паттерн — "чудище обло, огромно, стозевно и лаяй": по тем же причинам будет такой разнобой в реализациях, что мало не покажется.
Будет не больше чем разброд в библиотеках.
Ибо если язык позволяет вводить новые конструкции, то они автоматически становятся библиотеками.

WH>>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен.
ГВ>Как водится, лучший способ доказать неправильную посылку — свернуть на обсуждение личности.
А что у тебя есть другие варианты появления копипасты кроме слабости языка и некомпетентности?
Я других вариантов не знаю.

ГВ>Лучший способ "бороться с паттернами" — употреблять их только в разговорной речи, а на языке программирования писать так, как он это позволяет.
Ага.
И получить кучу одинаковых визитеров, абстрактных фабрик итп.
Ты пойми паттерны, они возникают в коде на языке недостаточно низкого уровня сами по себе.
Ни ты и ни кто другой не будет выдумать решение заново, если они уже решали практически такую же задачу.
И как только ты повторно используешь готовый подход к решению, ты получишь паттерн.

А я еще в первый раз расширю язык и во второй раз обойдусь без копипасты.

ГВ>Ну, как всегда — будем лечить ангину простудой, обвиняя пациента в том, что он не умеет болеть. Знакомо, знакомо...
Как всегда ты не понял о чем разговор и ставишь диагнозы.

ГВ>P.S.: Чую, пора уже заводить новый мем: "Количество языков в проекте растёт до тех пор, пока оно не превысит возможности программиста".
Ну, попробуй.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:

I>>Итерацию придется реализовывать одним из способов доступных в конкретном инструменте. Итерация это и есть паттерн. В конкретной реализации это может вылиться во что угодно.
WH>Те любой вызов метода это паттерн.
WH>Я тебя правильно понял?

Внимание !

 list.ForEach(x => Print(x))

Метод ForEach — итератор при чем это не ООП. Об этом, кстати говоря, и пишется в книгах про паттерны.

I>>Похоже ты просто заврался,цитирую себя:
I>>"Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны."
WH>Где тут паттерны проектирования?

А паттерны это только те что в ГОФ описаны ?

WH>Ты вообще про паттерны почитай да.

Паттерны проектирования или паттерны ооп это малая часть паттернов.

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

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

Здравствуйте, WolfHound, Вы писали:

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

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

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

А паттерн "слой", как с ним быть ? Это ж тоже лишний код по твоему

Здравствуйте, Ikemefula, Вы писали:

I>Внимание !
I>

I> list.ForEach(x => Print(x))
I>

I>Метод ForEach — итератор при чем это не ООП. Об этом, кстати говоря, и пишется в книгах про паттерны.
Вызов метода паттерн! (С)Ikemefula

I>>>Похоже ты просто заврался,цитирую себя:
I>>>"Берём блекджек и смотрим "мягкий дабл", "сплит тузов", "сплит десяток" — опаньки, паттерны."
WH>>Где тут паттерны проектирования?
I>А паттерны это только те что в ГОФ описаны ?

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

WH>>Ты вообще про паттерны почитай да.
I>Паттерны проектирования или паттерны ооп это малая часть паттернов.
Я говорю про паттерны в коде вообще.
А ты приплетаешь сюда совершенно левые паттерны типа распознавания ситуации в карточной игре.

I>Паттерны в коде никуда не денутся. Как только люди которые начнут писать на твоем ДСЛ, решат десяток другой однотипных задач, у них на ровном месте вырастут паттерны.
I>По этой причине не нужно бороться с паттернами, нужно бороться за то, что бы код было легко писать, легко майнтейнить и тд и тд и тд.
Вывод не правильный.
Если у людей появились паттерны, то нужно добавить в язык конструкции которые эти паттерны устранят.
Это единственный способ радикально упростить жизнь людям.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Нет, лишний код и паттерны проектирования вещи никак не связаные. В лишнем коде может быть как лишний паттерн так и например лишний ДСЛ, лишние макры и вообще все что угодно.
То, что лишним может быть, что угодно совершенно не противоречит утверждению о том, что паттерн проектирования всегда лишний код.

I>А паттерн "слой", как с ним быть ? Это ж тоже лишний код по твоему

И где там код?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Внимание !
I>>

I>> list.ForEach(x => Print(x))
I>>

I>>Метод ForEach — итератор при чем это не ООП. Об этом, кстати говоря, и пишется в книгах про паттерны.
WH>Вызов метода паттерн! (С)Ikemefula

Враньё, эту фразу сказал ты сам и уже дважды пытаешься приписать её мне.

I>>А паттерны это только те что в ГОФ описаны ?

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

Естественно. Это как пример что паттерны возникают не в коде, а в решении задачи.

I>>Паттерны проектирования или паттерны ооп это малая часть паттернов.
WH>Я говорю про паттерны в коде вообще.
WH>А ты приплетаешь сюда совершенно левые паттерны типа распознавания ситуации в карточной игре.

Паттерны появляются в решении задачи. Проявится ли это в коде — дело десятое.
Ну и ты игнорируешь паттерны вроде "слой" и тд.

I>>Паттерны в коде никуда не денутся. Как только люди которые начнут писать на твоем ДСЛ, решат десяток другой однотипных задач, у них на ровном месте вырастут паттерны.
I>>По этой причине не нужно бороться с паттернами, нужно бороться за то, что бы код было легко писать, легко майнтейнить и тд и тд и тд.
WH>Вывод не правильный.
WH>Если у людей появились паттерны, то нужно добавить в язык конструкции которые эти паттерны устранят.
WH>Это единственный способ радикально упростить жизнь людям.

Упрощать нужно только и только в том случае, если код сложно и трудно майнтейнить.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:

I>>Нет, лишний код и паттерны проектирования вещи никак не связаные. В лишнем коде может быть как лишний паттерн так и например лишний ДСЛ, лишние макры и вообще все что угодно.
WH>То, что лишним может быть, что угодно совершенно не противоречит утверждению о том, что паттерн проектирования всегда лишний код.

Паттерн проектирования как минимум понятен людям со стороны если у них есть определенный опыт. Мы то сейчас живем, а не через 1000 лет в другой вселенной, когда ты наконец то допилишь свой мега ДСЛ и он станет доминирующей парадигмой

I>>А паттерн "слой", как с ним быть ? Это ж тоже лишний код по твоему

WH>И где там код?

Везде

Здравствуйте, Ikemefula, Вы писали:

WH>>Вызов метода паттерн! (С)Ikemefula
I>Враньё, эту фразу сказал ты сам и уже дважды пытаешься приписать её мне.
Так ты уже второй раз показываешься на один вызов одной функции и говоришь что это паттерн.
Да ни в одном месте. Ибо если паттерны растянуть настолько широко, то это слово просто теряет смысл.

I>>>А паттерны это только те что в ГОФ описаны ?

WH>>Паттерны в коде. И паттерны в карточной игре это разные паттерны.
WH>>И общего межу ними как между синим и апельсином.
I>Естественно. Это как пример что паттерны возникают не в коде, а в решении задачи.
Еще раз.
Те паттерны, что в задаче не имею никакого отношения к паттернам в коде.

Ты просто путаешь разные сущности, которые называются одинаково.

Покажи мне задачу, в которой есть паттерн визитер или абстрактная фабрика или зиппер или scrap your boilerplate или любой другой.
Именно задачу. А не решение.

I>Упрощать нужно только и только в том случае, если код сложно и трудно майнтейнить.
Любой код усложняет поддержку.
Следствие если код можно убрать он должен быть убран.
Нельзя убрать только бизнес логику. Все остальное убрать можно.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Геннадий Васильев, Вы писали:

WH>>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.

ГВ>Лучший способ "бороться с паттернами" — употреблять их только в разговорной речи, а на языке программирования писать так, как он это позволяет.

Не надо с ними бороться. Решаешь несколько однотипных задач и паттерны появятся сами собой, от этого никуда не уйдешь.
Например многие вещи сворачивать в функции категорически противопоказано, например если описывается какой то воркфлоу. Всем таким функциям нужно дать качественное имя а это далеко не всегда возможно, особенно если логика имеет эвристическое происхождение, а не математическое.
Нет качественного имени — пусть лучше код будет побольше, чем иметь в качестве имен непойми что или, что еще хуже, закорючки вроде [||||] .!. 0|0

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

ГВ>P.S.: Чую, пора уже заводить новый мем: "Количество языков в проекте растёт до тех пор, пока оно не превысит возможности программиста".

Здравствуйте, Ikemefula, Вы писали:

I>Паттерн проектирования как минимум понятен людям со стороны если у них есть определенный опыт. Мы то сейчас живем, а не через 1000 лет в другой вселенной, когда ты наконец то допилишь свой мега ДСЛ и он станет доминирующей парадигмой

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

WH>>И где там код?
I>Везде

Понятно. Показать не можешь.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Не надо с ними бороться. Решаешь несколько однотипных задач и паттерны появятся сами собой, от этого никуда не уйдешь.
Я то ухожу. А ты не можешь по тому, что у тебя язык слабый.

I>Например многие вещи сворачивать в функции категорически противопоказано, например если описывается какой то воркфлоу. Всем таким функциям нужно дать качественное имя а это далеко не всегда возможно, особенно если логика имеет эвристическое происхождение, а не математическое.
Зато можно сворачивать в язык.
Давай потренируемся.
Просто напиши форкфлоу так как оно есть.
Только логику.
Без деталей реализации.

I>В сложных случаях лучше переходить на визуальные инструменты и в этом случае в принципе почти фиолетово, как будет выглядеть код.
Те графические ДСЛ для тебя приемлемы.
А текстовые, которые гораздо лучше нет. Интересная логика.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:

WH>>>Вызов метода паттерн! (С)Ikemefula
I>>Враньё, эту фразу сказал ты сам и уже дважды пытаешься приписать её мне.
WH>Так ты уже второй раз показываешься на один вызов одной функции и говоришь что это паттерн.

Снова враньё, я написал "Метод ForEach — итератор" а ты прочел это как "вызов метода". То ли ты врёшь, то ли читать не умеешь. Выбирай, мне всё равно.

I>>Естественно. Это как пример что паттерны возникают не в коде, а в решении задачи.
WH>Еще раз.
WH>Те паттерны, что в задаче не имею никакого отношения к паттернам в коде.

Это не важно, природа у них одна и та же.

WH>Покажи мне задачу, в которой есть паттерн визитер или абстрактная фабрика или зиппер или scrap your boilerplate или любой другой.
WH>Именно задачу. А не решение.

Цитирую себя:
"паттерны возникают ... в решении задачи." Ты точно умеешь чиатть ?

I>>Упрощать нужно только и только в том случае, если код сложно и трудно майнтейнить.
WH>Любой код усложняет поддержку.

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

WH>Следствие если код можно убрать он должен быть убран.

Это слишком категорично и безосновательно. Хорошо бы увидеть некоторые замеры, скажем "после тотального устранения лишнего кода производительность программистов увеличиалсть на А%, где А рассчитано по методика Б, проверено по методике В на программистах N проектов, увеличение производительности позволило увеличить продажина K%"

Здравствуйте, WolfHound, Вы писали:

I>>Паттерн проектирования как минимум понятен людям со стороны если у них есть определенный опыт. Мы то сейчас живем, а не через 1000 лет в другой вселенной, когда ты наконец то допилишь свой мега ДСЛ и он станет доминирующей парадигмой

WH>Так люди уже пользуются инструментами, которые это могут.
WH>И получают серьезные преимущества.

Эти сказки я уже слышу много лет. Еще в начале лета или весны ты рассказывал басни про увеличение продуктивности в 100-1000 раз, правда так и не рассказал, как же это ты вычислил и на чем это можно проверить.

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

Ожидаю, что джетбрейнс станет нумер1 в своей области. Если нет — немерле и дсл можно выкидывать в топку как академические бредни.

WH>То, что делаю я, будет позволять это делать еще проще.

Покажи свои методы на примере сайта РСДН. А то крутых специалистов хоть лопатой греби, а сайт работает все хуже и хуже. Уже дерево топика нельзя толком раскрыть, а поиск не то что по сайту, уже по треду стал проблемой.

WH>>>И где там код?
I>>Везде

WH>Понятно. Показать не можешь.

Тебе показать, как вычищаются обращения к UI из кода где выкачиваются данные из БД ?

Здравствуйте, WolfHound, Вы писали:

Такое впечатление, что ты взял за основу своих рассуждений неверную посылку и теперь пытаешься всех вокруг воспитывать, подгоняя реальность под эту самую посылку. Паттерны — они прежде всего в голове, а потом уже в коде. Отсюда, кстати, прямой как рельса вывод: "библиотека" паттернов в принципе возможна только на бумаге. Библиотека программных реализаций будет всегда именно библиотекой программных реализаций. Самое важное отличие настоящей библиотеки описаний паттернов от библиотеки реализаций — это то, что в описаниях паттернов можно смело опустить тонкие детали реализации, а в реализациях — нет.

Хотя я не спорю, что в мире полно наивных программистов, которые так же наивно "пихают паттерны" куда угодно, а потом ищут глубокий смысл в постановке вещей с ног на голову. Но не надо делать далеко идущих выводов из чужих глупостей, ага?

WH>>>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
ГВ>>Упрощенчество. Скажем, паттерн "фасад" можно выделить даже тут:
WH>Как всегда. Написал, не поймешь что. И пытаешься строить далеко идущие выводы.

Это называется "иллюстрация". Иллюстрирует она то, что было кратко написано в комментариях: публичная компонента интерфейса объекта вполне может интерпретироваться как одна из реализаций паттерна "фасад".

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

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

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

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

ГВ>>Скажу крамольную вещь: подчас проще оперировать "паттернами", чем конструкциями языками, их реализующими.
WH>А ты пробовал оперировать языковыми конструкциями, когда ты можешь их в любой момент создать и переделать как угодно?

Пробовал, впечатления равноценны тем, что возникают, когда бесконечно совершенствуешь библиотеку. Шило на мыло. Заметь, я не говорю, что видоизменять язык — заведомо плохая практика, так же, как и совершенствовать библиотеку.

(Гы-гы, сейчас начнут говорить, что у меня дзен неправильный и дао не туда)

WH>Я пробовал.
WH>Обратно на языки, которые это не могут, не хочу.

Вполне тебя понимаю, только что с того?

WH>Шаблоны С++ по сравнению с этим детский сад. Ясельная группа.

Ага, ну понятно, на сцене очередной "не-C++". Прикольно, C++ по-прежнему остаётся точкой отсчёта.

ГВ>>Связано это с тем, что "паттерн" является, в основном, мысленной конструкцией, и её можно легко адаптировать к реалиям того или иного языка.
WH>Я предпочитаю языковые конструкции, которые могу легко адаптировать под себя.

Да на здоровье! Высказанного мной это никак не опровергает.

ГВ>>А вот языковая конструкция, реализующая паттерн — "чудище обло, огромно, стозевно и лаяй": по тем же причинам будет такой разнобой в реализациях, что мало не покажется.
WH>Будет не больше чем разброд в библиотеках.

Угу, что и требовалось доказать.

WH>Ибо если язык позволяет вводить новые конструкции, то они автоматически становятся библиотеками.

Правильно. И так же автоматически перестают быть паттернами, становясь библиотеками. Забавная трансформация, правда?

WH>>>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен.
ГВ>>Как водится, лучший способ доказать неправильную посылку — свернуть на обсуждение личности.
WH>А что у тебя есть другие варианты появления копипасты кроме слабости языка и некомпетентности?
WH>Я других вариантов не знаю.

Во-первых, я знаю как минимум ещё один вариант появления копипасты — сознательное сохранение простоты кода.
Во-вторых, паттерны — это не всегда копипаста.

ГВ>>Лучший способ "бороться с паттернами" — употреблять их только в разговорной речи, а на языке программирования писать так, как он это позволяет.
WH>Ага.
WH>И получить кучу одинаковых визитеров, абстрактных фабрик итп.

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

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

Скажи, будь добр, новая языковая конструкция будет ориентирована на конкретные типы данных и другие подобные конструкции, пусть даже описательного характера? Или она зависнет на воздусех и "сама" будет привязываться ко всему, чему угодно?

ГВ>>Ну, как всегда — будем лечить ангину простудой, обвиняя пациента в том, что он не умеет болеть. Знакомо, знакомо...
WH>Как всегда ты не понял о чем разговор и ставишь диагнозы.

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

ГВ>>P.S.: Чую, пора уже заводить новый мем: "Количество языков в проекте растёт до тех пор, пока оно не превысит возможности программиста".
WH>Ну, попробуй.

Уже.

Здравствуйте, WolfHound, Вы писали:

I>>Например многие вещи сворачивать в функции категорически противопоказано, например если описывается какой то воркфлоу. Всем таким функциям нужно дать качественное имя а это далеко не всегда возможно, особенно если логика имеет эвристическое происхождение, а не математическое.
WH>Зато можно сворачивать в язык.

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

I>>В сложных случаях лучше переходить на визуальные инструменты и в этом случае в принципе почти фиолетово, как будет выглядеть код.
WH>Те графические ДСЛ для тебя приемлемы.
WH>А текстовые, которые гораздо лучше нет. Интересная логика.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хотя я не спорю, что в мире полно наивных программистов, которые так же наивно "пихают паттерны" куда угодно, а потом ищут глубокий смысл в постановке вещей с ног на голову. Но не надо делать далеко идущих выводов из чужих глупостей, ага?
Готов спорить, что в твоем коде полно паттернов.
Просто по тому, что ты пишешь на языке общего назначения.
А он про твою предметную область ничего не знает.

Вот, например берем вот такой интерфейс
http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx
Его реализация одинакова до безобразия.
И ни какими средствами C# ты ее не автоматизируешь.

Те у тебя в коде будет повторяющейся паттерн.

public class MyClass : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    private void OnPropertyChanged(string property)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(property));
    }

    private int _MyProp;
    public int MyProp
    {
        get { retunr _MyProp; }
        set
        {
            if (value != _MyProp)
            {
                _MyProp = value;
                OnPropertyChanged("MyProp");
            }
        }
    }
}

И это будет в каждом классе реализующем INotifyPropertyChanged
И ты будешь это копипастить руками.

А в немерле я могу реализовать макроаттрибут ImplementINotifyPropertyChanged
И писать так:

[ImplementINotifyPropertyChanged]
public class MyClass
{
    public MyProp : int { get; set; }
}

Вот это я называю паттернами и борьбой с ними.

ГВ>Правильно, только обрати внимание, ты сейчас соскальзываешь с паттернов на задачу реализации терминов предметной области. Я же тебе говорю, не уподобляйся идиотам — не смешивай разные по сути явления.
Паттерн возникает при реализации задачи предметной области на языке, который на эту предметную область не заточен.
См пример выше.

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

ГВ>(Гы-гы, сейчас начнут говорить, что у меня дзен неправильный и дао не туда)
Ну, так продемонстрируй свой дзен.
Только не говори что ты это на С++ных шаблонах делал.
Сразу засмею.

ГВ>Ага, ну понятно, на сцене очередной "не-C++". Прикольно, C++ по-прежнему остаётся точкой отсчёта.

Просто тут один орел заявляет что С++ это предел мечтаний.

WH>>Ибо если язык позволяет вводить новые конструкции, то они автоматически становятся библиотеками.
ГВ>Правильно. И так же автоматически перестают быть паттернами, становясь библиотеками. Забавная трансформация, правда?
Так они именно за тем и вводятся, чтобы убить паттерны.
См пример выше.
Просто обычные библиотеки не могут убить паттерн. А языковые расширения могут.
Причем если при их использовании снова возникает паттерн мы можем повторить итерацию еще раз.

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

ГВ>Куча одинаковых визитеров, фабрик и т.п. — это нюансы реализаций. И что самое весёлое, что ровно та же куча одинаковых реализаций схожих, но уже языковых конструкций будет появляться в разных фирмах (или вообще — у разных программистов). И всё это будет происходить только из-за того, что источники изменений будут разрознены, т.е. ровно из-за того, из-за чего появляется разнобой в библиотеках.
Разнобой вообще оффтопик.
Мы говорим про то, что паттерн это копипаста.
И про то, что с этим делать.
А то, что разные люди один и тот же паттерн убьют разными макрами к делу не относится.
Да и в любом случае особо распространённые паттерны будут убиваться стандартными макрами.
Так же как это сейчас происходит с библиотеками.

ГВ>Скажи, будь добр, новая языковая конструкция будет ориентирована на конкретные типы данных и другие подобные конструкции, пусть даже описательного характера? Или она зависнет на воздусех и "сама" будет привязываться ко всему, чему угодно?
А как реализуешь, так и будет.
Отчет практика.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Эти сказки я уже слышу много лет. Еще в начале лета или весны ты рассказывал басни про увеличение продуктивности в 100-1000 раз, правда так и не рассказал, как же это ты вычислил и на чем это можно проверить.
Рассказал. Но ты демонстративно проигнорировал.

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

Ожидаю, что джетбрейнс станет нумер1 в своей области. Если нет — немерле и дсл можно выкидывать в топку как академические бредни.
Он и так номер 1.

I>Покажи свои методы на примере сайта РСДН. А то крутых специалистов хоть лопатой греби, а сайт работает все хуже и хуже. Уже дерево топика нельзя толком раскрыть, а поиск не то что по сайту, уже по треду стал проблемой.
Я сайтом не занимаюсь.

I>Тебе показать, как вычищаются обращения к UI из кода где выкачиваются данные из БД ?

Или вот ещё ацкий трэш — у нас некоторые исключения имели помимо важности ещё свойство Color, которым (ааа111!!!) их надо было подсвечивать в GUI. Выставлялось это свойство автоматом, исходя из того в каком классе, в процессе работы над какой задачей, случился throw. Почему такое нарушение принципов вообще оказалось возможно — а потому что оно не выставлялось вручную вообще нигде. Т.е. GUI код просто использовал это свойство, и ему по-барабану как оно возникло, а программист который исключение кидал — даже не знал про какое-то там свойство, и его не выставлял. Соотвественно если бы мы решили эту хрень заменить, или вообще убрать — надо было бы менять только одно место, а значит принципы правильного разделения BL и GUI можно слать в конкретно этом случае лесом.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Перечитай или попроси что бы тебе объяснили — в строчке повыше твоей речь не о "можно" а о "нужно". Нет хорошего имени — все твои абстракции окажутся мусором, даже если язык будет трижды простой.
Понятно.
Показать задачу не можешь.
Ищешь отмазки.

I>Хочешь оспорить — предложи хороший текстовый язык взаимодействия пользоваетля с комьютером

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Снова враньё, я написал "Метод ForEach — итератор" а ты прочел это как "вызов метода". То ли ты врёшь, то ли читать не умеешь. Выбирай, мне всё равно.
Ты написал код, в котором вызвал метод.
Что ты там написал рядом текстом, не имеет значения.

WH>>Те паттерны, что в задаче не имею никакого отношения к паттернам в коде.
I>Это не важно, природа у них одна и та же.
Абсолютно ничего общего.
Ты знаешь, есть такое слово "ключ"?
А ты знаешь, что оно означает?

WH>>Покажи мне задачу, в которой есть паттерн визитер или абстрактная фабрика или зиппер или scrap your boilerplate или любой другой.
WH>>Именно задачу. А не решение.
I>Цитирую себя:
I>"паттерны возникают ... в решении задачи." Ты точно умеешь чиатть ?
Они в нем возникают, только если язык не адекватен задаче.

I>>>Упрощать нужно только и только в том случае, если код сложно и трудно майнтейнить.
WH>>Любой код усложняет поддержку.
I>Нет, не любой. Одна операция может запросто быть похожей на другую, но это вовсе не значит, что надо общую часть обязательно выделить в функцию или взять да обеспечить языковой поддержкой. Хорошего имени может просто и не быть, что обычное дело если логика суть эвристики.
Код в студию.
Без кода это все пустой треп.

I>Функционалисты вроде тебя заменяют такое на закорючки и прочую ересь которую мало кто станет изучать.
Я не функционалист.

I>Это слишком категорично и безосновательно. Хорошо бы увидеть некоторые замеры, скажем "после тотального устранения лишнего кода производительность программистов увеличиалсть на А%, где А рассчитано по методика Б, проверено по методике В на программистах N проектов, увеличение производительности позволило увеличить продажина K%"
Когда код сокращается раз в 10 это все исследования теряют смысл.
Re[4]: Паттерны проектирования — копипаста!

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Снова враньё, я написал "Метод ForEach — итератор" а ты прочел это как "вызов метода". То ли ты врёшь, то ли читать не умеешь. Выбирай, мне всё равно.
WH>Ты написал код, в котором вызвал метод.
WH>Что ты там написал рядом текстом, не имеет значения.

Имеет. Если нет, то я твой текст так же буду считать не имеющим значения. Идёт ?

WH>>>Те паттерны, что в задаче не имею никакого отношения к паттернам в коде.
I>>Это не важно, природа у них одна и та же.
WH>Абсолютно ничего общего.

Это и есть заблуждение. Паттерны есть следствие особенностей человеческого мышления. Неважно, какие ты задачи решаешь, после решения N схожих задач обязательно появляется паттерн. Какие именно задачи, бледжек или перевод в код модели игры в блекджек — абсолютно не важно.

WH>>>Покажи мне задачу, в которой есть паттерн визитер или абстрактная фабрика или зиппер или scrap your boilerplate или любой другой.
WH>>>Именно задачу. А не решение.
I>>Цитирую себя:
I>>"паттерны возникают ... в решении задачи." Ты точно умеешь чиатть ?
WH>Они в нем возникают, только если язык не адекватен задаче.

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

I>>Нет, не любой. Одна операция может запросто быть похожей на другую, но это вовсе не значит, что надо общую часть обязательно выделить в функцию или взять да обеспечить языковой поддержкой. Хорошего имени может просто и не быть, что обычное дело если логика суть эвристики.
WH>Код в студию.
WH>Без кода это все пустой треп.

Я уже знаю, что ты хочешь сказать про эвристики: "мне так хочется" -> "в лес". Ты забыл, что это уже было и даже несколько раз ?

I>>Функционалисты вроде тебя заменяют такое на закорючки и прочую ересь которую мало кто станет изучать.
WH>Я не функционалист.

Он самый

I>>Это слишком категорично и безосновательно. Хорошо бы увидеть некоторые замеры, скажем "после тотального устранения лишнего кода производительность программистов увеличиалсть на А%, где А рассчитано по методика Б, проверено по методике В на программистах N проектов, увеличение производительности позволило увеличить продажина K%"
WH>Когда код сокращается раз в 10 это все исследования теряют смысл.
WH>Re[4]: Паттерны проектирования — копипаста!

Очевидно, заблуждение. Нужно показать как это влияет на профит конторы. Например увеличение продаж, вытеснение конкурентов — то это круто. Если нет — ну и хрен с ним, с твоим коротким кодом.

Здравствуйте, WolfHound, Вы писали:
WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
Думаю ты перепутал паттерны проектирования(вроде ООП паттернов(фабрики, визиторы etc.)) применяемые на этапе проектирования(разработки архитектуры), с паттернами кодирования(вроде алгоритмов)применяемыми при кодировании(а точнее при разработке кода по архитектуре). Например на этапе проектирования решается будет ли в приложении фабрика объектов в принципе, а на этапе кодирования решается реализовать ли её например в виде класса, шаблона, встроена в транслятор предметного ЯП etc.
Паттерны кодирования как раз и приводят к дублированию кода(эта проблема традиционно решается вынесением дулирующегося кода например в функцию/макрос, разработкой DSL'а("вынесением в транслятор") etc.).
WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.
Не, паттерны это решения типичных проблем, соответственно возникают они там где есть такие проблемы.
WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
Разве программы на DSL не нужно проектировать?
WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
Не, это потому что, на сегодня:
1)Решить задачу(даже небольшой класс задач) в лоб сильно проще чем разработать ЯП для её решения.
2)Из первого следует, что для решения задачи в лоб можно нанять одного посредственного программиста, и сэкономить деньгу.

Здравствуйте, AlexCab, Вы писали:

AC>Думаю ты перепутал паттерны проектирования(вроде ООП паттернов(фабрики, визиторы etc.)) применяемые на этапе проектирования(разработки архитектуры), с паттернами кодирования(вроде алгоритмов)применяемыми при кодировании(а точнее при разработке кода по архитектуре). Например на этапе проектирования решается будет ли в приложении фабрика объектов в принципе, а на этапе кодирования решается реализовать ли её например в виде класса, шаблона, встроена в транслятор предметного ЯП etc.
Я ничего не перепутал.
Это одно и то же.
Ибо я не знаю ни одной модели предметной области, в которой была бы фабрика объектов. Или визитёр. Или зиппер.
Они всегда появляются на этапе превращения модели предметной области в код.
Причем в коде на яве ты не увидишь зиппер, а в коде на хаскеле абстрактную фабрику.
Ибо свойства языков очень разные и паттерны при реализации даже одной и той же задачи на разных языках получатся разными.

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

AC>Разве программы на DSL не нужно проектировать?
Проектирование == создание ДСЛ.
А дальше уже остается чистая бизнес логика.
Там нечего проектировать.
И нет никаких паттернов.

AC>1)Решить задачу(даже небольшой класс задач) в лоб сильно проще чем разработать ЯП для её решения.
Не правда.
Особенно если это не разработка, а расширение уже существующего.

AC>2)Из первого следует, что для решения задачи в лоб можно нанять одного посредственного программиста, и сэкономить деньгу.
И потом когда станет ясно, что это всё не работает нанять еще одного, но дорогого. Который сделает все в 10 раз быстрее и в 2 раза дешевле даже не смотря на то, что ему приходится платить в 5 раз больше. Ибо в 10 раз быстрее.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>Проектирование == создание ДСЛ.
WH>А дальше уже остается чистая бизнес логика.
WH>Там нечего проектировать.

Сильное заявление.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

WH>>Проектирование == создание ДСЛ.
WH>>А дальше уже остается чистая бизнес логика.
WH>>Там нечего проектировать.
AVK>Сильное заявление.
И что же нужно проектировать кода у тебя остается только код бизнес логики без намеков на детали реализации?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

WH>Я ничего не перепутал.
WH>Это одно и то же.
Нет, паттерны проектирования не могут приводить к дублированию кода, потому что на этом этапе нет кода, есть модули, процессы, объекты, этапы etc.
А уже на этапе разработки(когда архитектура уже готова и её можно воплотить в коде) появляются функции, потоки, классы etc. И тут как раз паттерны помогают избежать копипасты и избыточной сложности, так как позволяют использовать готовые решения(а не изобретать собственные велосипеды), в том числе и из готовых библиотек(а не переписывать всё заново).
WH>Ибо я не знаю ни одной модели предметной области, в которой была бы фабрика объектов. Или визитёр. Или зиппер.
ООП?

Паттрены проектирования есть везде где есть собственно проектирование(в любой п.области).
Но я думаю ты всё-таки имел ввиду предметно-прикладные области. Так вот там тоже есть паттерны. Откуда по твоему взялись ООП паттерны? Это типичные и удачные ПОО решение типичных проблем встречающихся в _разных_ предметных областях.
Я уверен, подобные паттерны существуют (будут) для тех-же типичных проблем, решаемых с помощью ИП, ФП, DSL etc.
WH>Они всегда появляются на этапе превращения модели предметной области в код.
Не согласен, паттерны проектирования(такие как например ООП паттерны) появляются на этапе проектирования модели предметной области, пригодной для превращения в код.
WH>Причем в коде на яве ты не увидишь зиппер, а в коде на хаскеле абстрактную фабрику.
Там вероятно есть свои паттерны, являющиеся решением те же проблемы.
WH>Ну да. Типичные проблемы при реализации кода на конкретном языке.
Есть среди них и такие.
AC>>Разве программы на DSL не нужно проектировать?
WH>Проектирование == создание ДСЛ.
При создании DSL не будут использоваться паттерны?
WH>А дальше уже остается чистая бизнес логика.
WH>Там нечего проектировать.
Подозреваю что ты представляеш себе разработку ПО как-то так: сделаем один DSL, поверх него ещё один, поверх второго третий,... последний DSL будет содержать единственный оператор "работай"?
WH>Особенно если это не разработка, а расширение уже существующего.
Возможно, но люди всегда ищут наиболее выгодный/короткий путь, потому если-бы разработка ЯП была выгодней думаю, всё бы так и делали.
WH>И потом когда станет ясно, что это всё не работает нанять еще одного, но дорогого. Который сделает все в 10 раз быстрее и в 2 раза дешевле даже не смотря на то, что ему приходится платить в 5 раз больше. Ибо в 10 раз быстрее.
Такое тоже бывает, но думаю не часто, иначе-бы некто не нанимал посредственных программистов, и они бы извелись как класс.

Здравствуйте, AlexCab, Вы писали:

AC>Нет, паттерны проектирования не могут приводить к дублированию кода, потому что на этом этапе нет кода, есть модули, процессы, объекты, этапы etc.
Они по тому и паттерны что их очень легко узнать.
А раз легко узнать значит, есть дублирование кода.
Просто по определению.

AC>А уже на этапе разработки(когда архитектура уже готова и её можно воплотить в коде) появляются функции, потоки, классы etc.
Архитекру делают под язык программирования, на котором будут писать код.
Ибо если ты попытаешься реализовать архитектуру, сделанную для явы на хаскеле или наоборот то у тебя получится такой кошмар что аж жуть.
Таким образом классы итп появляются еще до того как начинают писать код.

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

AC> так как позволяют использовать готовые решения(а не изобретать собственные велосипеды), в том числе и из готовых библиотек(а не переписывать всё заново).
Вызов метода не паттерн.
Ибо иначе у нас вообще все становится паттерном. И весь разговор теряет смысл.

AC>ООП?

ООП не предметная область.

AC>Паттрены проектирования есть везде где есть собственно проектирование(в любой п.области).
Они есть только там, где язык заставляет писать похожий код.
Само название паттерн указывает на то что-то повторяется много раз.

AC>Но я думаю ты всё-таки имел ввиду предметно-прикладные области. Так вот там тоже есть паттерны. Откуда по твоему взялись ООП паттерны? Это типичные и удачные ПОО решение типичных проблем встречающихся в _разных_ предметных областях.
Вот именно.
ООП решение
А если делать язык, который работает в терминах предметной области, то паттерны исчезают.

AC>Я уверен, подобные паттерны существуют (будут) для тех-же типичных проблем, решаемых с помощью ИП, ФП, DSL etc.
Для ИП и ФП будут. А для DSL не будут.
Просто по тому, что ДСЛ работает в терминах предметной области.

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

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

WH>>Причем в коде на яве ты не увидишь зиппер, а в коде на хаскеле абстрактную фабрику.
AC>Там вероятно есть свои паттерны, являющиеся решением те же проблемы.
Так, а я про что говорю?
Я и говорю, что паттерны типичны для конкретного языка. Ну, или группы очень похожих языков.
А если брать не похожий язык, то там и паттерны получаются совершенно другими.
А если язык заточен под конкретную задачу, то там паттерны не появляются вообще.
Ибо источник паттернов это несоответствие языка задаче.

WH>>Ну да. Типичные проблемы при реализации кода на конкретном языке.
AC>Есть среди них и такие.
Они все такие. 100%.

AC>>>Разве программы на DSL не нужно проектировать?
WH>>Проектирование == создание ДСЛ.
AC>При создании DSL не будут использоваться паттерны?
Зачем?
Когда ты генерируешь код из ДСЛ можно генерировать что угодно.
Главное чтобы работало. И работало быстро.

Вот, например я сейчас занимаюсь оптимизацией одного ДСЛ.
Генерирую такой говнокод что за ручное написание такого оторвал бы руки.
Но так как код генерируется то всем пофиг на, то, что его ни написать, ни прочитать.
За то все летать будет.

AC>Подозреваю что ты представляеш себе разработку ПО как-то так: сделаем один DSL, поверх него ещё один, поверх второго третий,... последний DSL будет содержать единственный оператор "работай"?
Сарказм не получился.
Ибо я так не только думаю. Но и делаю.

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>И что же нужно проектировать кода у тебя остается только код бизнес логики без намеков на детали реализации?

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

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>Они по тому и паттерны что их очень легко узнать.
WH>А раз легко узнать значит, есть дублирование кода.
WH>Просто по определению.

Давай рассмотрим реальный, хоть и упрощенный, пример, ОК? Предметная область — бухгалтерия. В ней есть некие документы разных типов. И у каждого документа есть специальный алгоритм, или даже более обще — специальная функция, преобразующая данные документа в набор специальных сущностей — хозопераций (ХО это атомарное перемещение денег со счета на счет, но не суть). Наконец, есть универсальная рукоятка, позволяющая по набору разнотипных документов вычислить для них хозоперации.
На этапе проектирования бизнес-логики мы оформляем собтвенно функцию перехода от документа конкретного типа к набору ХО как специальную сущность, видимую пользователю (потому что у него должна быть возможность самостоятельно выбирать такую функцию для конкретного типа документов).
Обрати внимание, я ни слова не сказал про языки программирования и какой либо код.
Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией. Т.е. мы использовали паттерн. Или, если не синтетически, а аналитически, мы можем назвать использованное решение паттерном.
Теперь вопрос — как в описанной цепочке DSL помогут куда то там деть паттерн? До DSL еще даже не дошло, пока только очень крупноблочный дизайн описан, а паттерны уже есть. И да, паттерны это не только совсем примитивные вещи типа фабрики или стратегии (эти паттерны ценны скорее как словарь для описания софтварных проектов), есть и более сложные вещи, типа MVC/MVVM, message bus и даже целые книжки навроде ITIL.

WH>Само название паттерн указывает на то что-то повторяется много раз.

Не что то, а дизайн. Не код, дизайн, понимаешь?

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>Вот, например берем вот такой интерфейс
WH>http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx
WH>Его реализация одинакова до безобразия.
WH>И ни какими средствами C# ты ее не автоматизируешь.
WH>Те у тебя в коде будет повторяющейся паттерн.
WH>

WH> skipped
WH>

Это не паттерн, а его реализация. Скажу больше, это одна из возможных реализаций Наблюдателя.

WH>И это будет в каждом классе реализующем INotifyPropertyChanged
WH>И ты будешь это копипастить руками.
WH>А в немерле я могу реализовать макроаттрибут ImplementINotifyPropertyChanged
WH>И писать так:
WH>

WH>[ImplementINotifyPropertyChanged]
WH>public class MyClass
WH>{
WH>    public MyProp : int { get; set; }
WH>}
WH>

А это реализация того же самого паттерна, но на другом языке.

WH>Вот это я называю паттернами и борьбой с ними.
Где борьба то? Паттерн как был, так и остался. Чем характеризуется паттерн? Задачей и ее решением. Причем, решение — это не конкретная реализация, а обобщенное описание решения. И что же поменялось? Да ничего, ты просто спрятал под капот небольшую часть ручной работы, даже интерфейс остался без изменений.

PS
Складывается ощущение, что ты тупо троллишь.

Здравствуйте, Игoрь, Вы писали:

И>Это не паттерн, а его реализация. Скажу больше, это одна из возможных реализаций Наблюдателя.
Ох. Что такое паттерн.
Паттерн это нечто повторяющееся.
Например, посмотри в гугле картинки по слову pattern.
Увидишь много картинок, на которых повторяется что-то.

И>А это реализация того же самого паттерна, но на другом языке.
Тут нет паттерна.
Вот эта хрень не повторяется.

    private int _MyProp;
    public int MyProp
    {
        get { retunr _MyProp; }
        set
        {
            if (value != _MyProp)
            {
                _MyProp = value;
                OnPropertyChanged("MyProp");
            }
        }
    }

И>Где борьба то? Паттерн как был, так и остался.
Как это остался?
Где повторение вон той хрени чуть выше по тексту?

И>Чем характеризуется паттерн? Задачей и ее решением.
Нет. Он характеризуется повторяющимся кодом.
Ты извращаешь понятие паттерн.
Паттерн это не решение. Это распознаватель решения.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AndrewVK, Вы писали:

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>И что же там проектировать то?

Да все как обычно — стурктура сущностей и связей между ними.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

AVK>>Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией. Т.е. мы использовали паттерн. Или, если не синтетически, а аналитически, мы можем назвать использованное решение паттерном.
WH>Еще один. Народ вам не надоело вызов одной функции назвать паттерном?

На вопрос ответ так и не получен. ЧТД.

WH>Такими темпами в паттерны можно записать буквально всё.

Можно. Но не нужно.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

WH>Они по тому и паттерны что их очень легко узнать.
WH>А раз легко узнать значит, есть дублирование кода.
Если ты можешь узнать паттерн в коде это говорит о том что ты знаешь этот паттерн, и возможно это даже дублировании кода, но паттерн в этом не виноват, тем более паттерн проектирования. В этом виноват тот кто это написал. И очень даже может быть что написал он это потому что не знал этот паттерн(если-б знал возможно использовал бы готовое решение).
WH>Архитекру делают под язык программирования, на котором будут писать код.
А если в проекте несколько языков?
И даже если и так, на этапе разработки архитектуры не известно каким будет код, даже в рамках одного языка(например будет ли он содержать классы или можно обойтись процедурами).
WH>Ибо если ты попытаешься реализовать архитектуру, сделанную для явы на хаскеле или наоборот то у тебя получится такой кошмар что аж жуть.
Не знаю, не пробовал.
WH>Таким образом классы итп появляются еще до того как начинают писать код.
Но после того как разработана архитектура, ибо это уже реализация.
WH>Так они и есть копипаста и избыточный код.
Паттерн != код.
WH>Вызов метода не паттерн.
WH>Ибо иначе у нас вообще все становится паттерном. И весь разговор теряет смысл.
Паттерн это то что позволило программисту:
1)Опознать типичную проблему.
2)Найти реализацию решения.
3)"вызвать метод".
WH>Ибо источник паттернов это несоответствие языка задаче.
От несоответствия ЯП задаче может появляется лишний код(адаптирующий), но уж всяко не паттерны проетирования.
AC>>При создании DSL не будут использоваться паттерны?
WH>Зачем?
WH>Когда ты генерируешь код из ДСЛ можно генерировать что угодно.
Не ты не понял, при дизайне/разработке самого DSL'я?
AC>>Подозреваю что ты представляеш себе разработку ПО как-то так: сделаем один DSL, поверх него ещё один, поверх второго третий,... последний DSL будет содержать единственный оператор "работай"?
WH>Сарказм не получился.
Не, это был вопрос.
WH>Ибо я так не только думаю. Но и делаю.
Чтобы использовать такой подход нужно уметь создавать DSL'и(а это сложно) что сводит на нет преимущество простоты их использования.
А если не использовать такой подход, а пользоваться готовыми языками то "привет "копипаста"!"

Здравствуйте, AndrewVK, Вы писали:

WH>>Еще один. Народ вам не надоело вызов одной функции назвать паттерном?
AVK>На вопрос ответ так и не получен. ЧТД.
На какой вопрос?

WH>>Такими темпами в паттерны можно записать буквально всё.
AVK>Можно. Но не нужно.
Вот и не занимайся натягиванием слова паттерн на вызов одного метода.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AlexCab, Вы писали:

AC>Если ты можешь узнать паттерн в коде это говорит о том что ты знаешь этот паттерн, и возможно это даже дублировании кода, но паттерн в этом не виноват, тем более паттерн проектирования. В этом виноват тот кто это написал. И очень даже может быть что написал он это потому что не знал этот паттерн(если-б знал возможно использовал бы готовое решение).
Вот тебе обычный такой паттерн.
Встречается в определённом классе задач при решении на C#

    private int _MyProp;
    public int MyProp
    {
        get { retunr _MyProp; }
        set
        {
            if (value != _MyProp)
            {
                _MyProp = value;
                OnPropertyChanged("MyProp");
            }
        }
    }

Узнается легко.
Встречается десятками и сотнями в одной программе.
Убрать дублирование средствами C# невозможно.

Средствами немерле сворачивается в одну строку.

public MyProp : int { get; set; }

Что фактически уничтожает паттерн.

Вот тебе еще примеры убирания лишнего кода.
http://nemerle.org/wiki/index.php?title=Design_patterns
Да их там много.

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

WH>>Ибо если ты попытаешься реализовать архитектуру, сделанную для явы на хаскеле или наоборот то у тебя получится такой кошмар что аж жуть.
AC>Не знаю, не пробовал.
Вот попробуй. Узнаешь много нового.

WH>>Таким образом классы итп появляются еще до того как начинают писать код.
AC>Но после того как разработана архитектура, ибо это уже реализация.
Так архитектура и задает реализацию.
Причем она всегда делается с учётом того на каком именно языке будет код.

AC>Паттерн это то что позволило программисту:
AC>1)Опознать типичную проблему.
AC>2)Найти реализацию решения.
AC>3)"вызвать метод".
Ага, конечно.
Посмотри на код выше и вызови метод.

WH>>Ибо источник паттернов это несоответствие языка задаче.
AC>От несоответствия ЯП задаче может появляется лишний код(адаптирующий), но уж всяко не паттерны проетирования.
Паттерны проектирования это и есть адаптация задачи к языку.
Ты, например, использовал зиппер и scrap your boilerplate?
А вот программисты на хаскеле не использовали визитер с абстрактными фабриками.

AC>Не ты не понял, при дизайне/разработке самого DSL'я?
Зачем?
У меня для этого ДСЛ есть.

AC>Чтобы использовать такой подход нужно уметь создавать DSL'и(а это сложно) что сводит на нет преимущество простоты их использования.
Это проще чем ООП дизайн делать.
И использовать их проще.

AC>А если не использовать такой подход, а пользоваться готовыми языками то "привет "копипаста"!"

О чем я и говорю.
Вы все копипастите на ровном месте.
И называете это красивым словом паттерн.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

AVK>>На вопрос ответ так и не получен. ЧТД.
WH>На какой вопрос?

Т.е. ты даже не читал то, на что ответил?

AVK>Теперь вопрос — как в описанной цепочке DSL помогут куда то там деть паттерн?

AVK>>Можно. Но не нужно.
WH>Вот и не занимайся натягиванием слова паттерн на вызов одного метода.

Попробуй найти в моем описании задачи фразу "вызов одного метода", или хотя бы слово "метод".

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

ГВ>>Хотя я не спорю, что в мире полно наивных программистов, которые так же наивно "пихают паттерны" куда угодно, а потом ищут глубокий смысл в постановке вещей с ног на голову. Но не надо делать далеко идущих выводов из чужих глупостей, ага?
WH>Готов спорить, что в твоем коде полно паттернов.
WH>Просто по тому, что ты пишешь на языке общего назначения.
WH>А он про твою предметную область ничего не знает.

Прикольно. Я тебе про Фому, ты мне — про Ерёму.

WH>Вот, например берем вот такой интерфейс
WH>http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx
WH>Его реализация одинакова до безобразия.
WH>И ни какими средствами C# ты ее не автоматизируешь.

WH>Те у тебя в коде будет повторяющейся паттерн.
[...]
WH>Вот это я называю паттернами и борьбой с ними.

Ясно, но, ИМХО, это довольно узкая интерпретация, по такой логике обычные библиотеки тоже можно назвать борцами с паттернами, хотя почему-то я таких названий не встречал. По сути, как это правильно сказал Игорь, ты никуда не деваешь сам паттерн, ты просто вносишь его частную реализацию в библиотеку. Так что, не обольщайся — например, для разбора того, что же делает твой макрос, будет снова использоваться описание паттерна.

Я называю паттернами более широкую группу явлений. Повторю свой пример:

class X {
  public void foo(); // Фасад
  public void zoo(); // Фасад
  protected void bar(); // Реализация
}

В данном случае нигде в коде, кроме комментариев и, возможно, сопроводительной документации не будет фигурировать термин "фасад". Просто появится соглашение, что foo и zoo — фасадные методы. Допустим, их не будут менять слишком бодро при очередном рефакторинге и т.п. И никакого лишнего кода. В конце концов, главное — это та информация, которая передана людям.

Я вполне согласен, что, может быть, имеет смысл сделать как-нибудь так:

[FacadeMethods(foo, zoo)]
class X {
  void foo();
  void zoo();
  void bar();
}

Правда, одно не понятно: а на фига?

ГВ>>Правильно, только обрати внимание, ты сейчас соскальзываешь с паттернов на задачу реализации терминов предметной области. Я же тебе говорю, не уподобляйся идиотам — не смешивай разные по сути явления.
WH>Паттерн возникает при реализации задачи предметной области на языке, который на эту предметную область не заточен.
WH>См пример выше.

O'K, примем это высказывание как пояснение к твоему определению паттерна.

ГВ>>Пробовал, впечатления равноценны тем, что возникают, когда бесконечно совершенствуешь библиотеку.
WH>Извини, не поверю.
WH>Просто все те, кто действительно этим занимался в реальных задачах, назад не хотят.

Ещё бы ты согласился! По сути ты сейчас рассуждаешь как фанатик — коверкаешь устоявшиеся термины и определения, бросаешься обобщениями ("все они такие"). А от фаната бессмысленно ждать согласия с чем-то таким, что противоречит его убеждениям.

ГВ>>(Гы-гы, сейчас начнут говорить, что у меня дзен неправильный и дао не туда)
WH>Ну, так продемонстрируй свой дзен.
WH>Только не говори что ты это на С++ных шаблонах делал.
WH>Сразу засмею.

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

Мне-то твой дзен понятен...

WH>>>Ибо если язык позволяет вводить новые конструкции, то они автоматически становятся библиотеками.
ГВ>>Правильно. И так же автоматически перестают быть паттернами, становясь библиотеками. Забавная трансформация, правда?
WH>Так они именно за тем и вводятся, чтобы убить паттерны.

Да не "убить паттерны", а забить в библиотеку их частные реализации. Всё, что здесь уничтожается — это дублирование кода. А паттерны, как обощённые структурные модели, остаются живёхоньки.

WH>См пример выше.
WH>Просто обычные библиотеки не могут убить паттерн. А языковые расширения могут.
WH>Причем если при их использовании снова возникает паттерн мы можем повторить итерацию еще раз.

Приходим к противоречию.

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

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

ГВ>>Во-первых, я знаю как минимум ещё один вариант появления копипасты — сознательное сохранение простоты кода.
ГВ>>Во-вторых, паттерны — это не всегда копипаста.
WH>Вот то, что выше это не копипаста да? И все паттерны они такие.

То, что ты ими называешь — да. Правда, почему-то, твоё мнение разделяют не все.

WH>Паттерн он на то и паттерн что глядя на два куска кода видишь насколько они одинаковые.
WH>Но сделать с этим ничего не можешь.
WH>Ибо язык не позволяет.

Ну почему же сразу "не позволяет"? Чаще дело сводится к тому, что нет нужды заниматься реализацией обобщённого решения, гораздо проще и легче сделать "копипасту" (ещё одна крамольность), чем выдумывать новые имена для того, что не нужно именовать. Я не всегда согласен с Ikemefula, но в данном случае наши мнения практически совпадают.

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

Хорошо, пусть так.

ГВ>>Скажи, будь добр, новая языковая конструкция будет ориентирована на конкретные типы данных и другие подобные конструкции, пусть даже описательного характера? Или она зависнет на воздусех и "сама" будет привязываться ко всему, чему угодно?
WH>А как реализуешь, так и будет.
WH>Отчет практика.

Да-да:

Кроме того у Nemerle есть свой match/биндинг по регекспам (называется кажется rx match или regex match), и мы по образу и подобию слепили себе такой же, но почему и чем он был лучше — уже не помню.

Извини, я не удержался.

P.S.: Кстати, а как по твоему методу можно изничтожить паттерн "Chain of responsibilities"?

P.P.S.: И с вот таким паттерном как быть: "Интерфейс"?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Прикольно. Я тебе про Фому, ты мне — про Ерёму.
Я тебе про сущность понятия паттерн.

ГВ>Ясно, но, ИМХО, это довольно узкая интерпретация, по такой логике обычные библиотеки тоже можно назвать борцами с паттернами,
Совершенно верно.
Они и есть борцы с паттернами также известными как копипаста.

ГВ>хотя почему-то я таких названий не встречал.
Это по тому, что те паттерны, с которыми успешно борются, исчезают из кода.
Нет паттерна. Нет обсуждения.

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

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

ГВ>В данном случае нигде в коде, кроме комментариев и, возможно, сопроводительной документации не будет фигурировать термин "фасад". Просто появится соглашение, что foo и zoo — фасадные методы. Допустим, их не будут менять слишком бодро при очередном рефакторинге и т.п. И никакого лишнего кода. В конце концов, главное — это та информация, которая передана людям.
Тут нет задачи.
Обсуждать борьбу с паттернами без исходной не замутненной реализацией задачи не имеет смысла.
Никакого.

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

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

Мне-то твой дзен понятен...
Ну да. Узнаю твой типичный паттерн поведения.
Слив -> демагогия.
Очень типично для тебя.

ГВ>Да не "убить паттерны", а забить в библиотеку их частные реализации. Всё, что здесь уничтожается — это дублирование кода. А паттерны, как обощённые структурные модели, остаются живёхоньки.
Не остаются.
Ибо они исчезают из кода.
И распознать их уже нельзя.
А во что их превращает компилятор уже не важно.

WH>>См пример выше.
WH>>Просто обычные библиотеки не могут убить паттерн. А языковые расширения могут.
WH>>Причем если при их использовании снова возникает паттерн мы можем повторить итерацию еще раз.
ГВ>Приходим к противоречию.
В каком месте?

ГВ>Если следовать твоей логике, что "паттерн — это повторяющаяся часть кода", то библиотеки — такое же средство "борьбы с паттернами", как и новый язык. Пусть не такое мощное, поскольку ограничено самим языком, но тем не менее.
Ну да. Библиотеки борются с некоторым очень примитивным классом паттернов.
Но их обсуждать не имеет смысла.
Ибо если программист грамотный, то их в коде и так не будет.

ГВ>А если опереться на общепринятое определение, что паттерн — это надъязыковая модель, то придётся констатировать, что ни библиотеки, ни новый язык не могут "убить паттерн", поскольку они его попросту реализуют, но никуда при этом не удаляют. Паттерн по-прежнему остаётся в описаниях и в языке общения разработчиков.
Начнем с того что паттерны прибиты гвоздями к группе похожих с семантической точки зрения языков.
На этом и закончим.
Ибо это делает всю твою цепочку рассуждений ложной.

ГВ>То, что ты ими называешь — да. Правда, почему-то, твоё мнение разделяют не все.
Просто не хотят признавать что нанимаются копипастой.

Но признание проблемы это первый шаг к ее исправлению.

ГВ>Ну почему же сразу "не позволяет"? Чаще дело сводится к тому, что нет нужды заниматься реализацией обобщённого решения, гораздо проще и легче сделать "копипасту"
Ну, реализуй мне на C# обобщенное решение для INotifyPropertyChanged.
Удачи.

А потребность есть.
Ибо народ даже переписыванием IL занимается, чтобы этот код не писать.

ГВ>(ещё одна крамольность), чем выдумывать новые имена для того, что не нужно именовать. Я не всегда согласен с Ikemefula, но в данном случае наши мнения практически совпадают.
Вот только ни ты, ни он не показали, что же не нужно именовать.
И чему при создании ДСЛ придется дать имя.

ГВ>

Кроме того у Nemerle есть свой match/биндинг по регекспам (называется кажется rx match или regex match), и мы по образу и подобию слепили себе такой же, но почему и чем он был лучше — уже не помню.

ГВ>Извини, я не удержался.

И что? У них была проблема. Они ее решили. Был бы C# они бы трахались неизмеримо сильнее.
Или ты хочешь сказать, что ни разу в жизни не выкидывал стандартную библиотеку по тому, что она тебя не устраивала?
Короче прекращай разводить двойные стандарты.

ГВ>P.S.: Кстати, а как по твоему методу можно изничтожить паттерн "Chain of responsibilities"?
Без исходной задачи не имею ни малейшего представления.

ГВ>P.P.S.: И с вот таким паттерном как быть: "Интерфейс"?
Ты еще вызов метода как это делают AVK и Ikemefula в паттерны запиши.
В любом случае, когда дело доходит до конкретной задачи оказывается что и это не нужно.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Т.е. ты даже не читал то, на что ответил?
AVK>

AVK>>Теперь вопрос — как в описанной цепочке DSL помогут куда то там деть паттерн?

Где паттерн то?
У тебя там вызов ровно одной функции который один документ превращает в коллекцию других.

AVK>Попробуй найти в моем описании задачи фразу "вызов одного метода", или хотя бы слово "метод".
Метод. Функция. Не важно.
Главное что у тебя только один вызов. А уже целый паттерн.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

WH>Вот тебе обычный такой паттерн.
WH>Встречается в определённом классе задач при решении на C#
WH>

WH>    private int _MyProp;
WH>    public int MyProp
WH>    {
WH>        get { retunr _MyProp; }
WH>        set
WH>        {
WH>            if (value != _MyProp)
WH>            {
WH>                _MyProp = value;
WH>                OnPropertyChanged("MyProp");
WH>            }
WH>        }
WH>    }
WH>

WH>Узнается легко.
WH>Встречается десятками и сотнями в одной программе.
1)Это не паттерн проектирования, ПП выглядит примерно так:

2)Это вообще не паттерн это частный случай реализации.
WH>Убрать дублирование средствами C# невозможно.
На C# я никогда не писал, но думаю это можно заменить классической парой методов get/set.
WH>Средствами немерле сворачивается в одну строку.
WH>

WH>public MyProp : int { get; set; }
WH>

Что фактически уничтожает паттерн.
А где тела get'а и set'а?
WH>Вот тебе еще примеры убирания лишнего кода.
WH>http://nemerle.org/wiki/index.php?title=Design_patterns
Я верю что ты можешь спрятать любую реализацию паттерна в макрос/DSL, ибо МП даёт полую власть над текстом программы(требуя в замен полной ответственности).
AC>>И даже если и так, на этапе разработки архитектуры не известно каким будет код, даже в рамках одного языка(например будет ли он содержать классы или можно обойтись процедурами).
WH>Это не правда.
Почему?
AC>>Но после того как разработана архитектура, ибо это уже реализация.
WH>Так архитектура и задает реализацию.
Но не является её.
WH>Причем она всегда делается с учётом того на каком именно языке будет код.
Но не более.
AC>>Паттерн это то что позволило программисту:
AC>>1)Опознать типичную проблему.
AC>>2)Найти реализацию решения.
AC>>3)"вызвать метод".
WH>Ага, конечно.
WH>Посмотри на код выше и вызови метод.
Элементарно:
1)берём Немерле, или какой ни будь препроцессор для C#, прячем реализацию в макрос, вызываем.
2)меняем все подобные вещи на пары get/set методов, вызываем.
AC>>От несоответствия ЯП задаче может появляется лишний код(адаптирующий), но уж всяко не паттерны проетирования.
WH>Паттерны проектирования это и есть адаптация задачи к языку.
Наверно всё-таки языка (общего н.) к задаче.

Но это всё гораздо менее интересно чем следующее:

AC>>Не ты не понял, при дизайне/разработке самого DSL'я?
WH>Зачем?
WH>У меня для этого ДСЛ есть.
DSL-дизайнер, DSL-архитектор — интригует

Если DSL'и не дизайнятся и не разрабатываются, откуда они берутся?

Здравствуйте, AlexCab, Вы писали:

AC>1)Это не паттерн проектирования, ПП выглядит примерно так:
AC>

AC>2)Это вообще не паттерн это частный случай реализации.

Это паттерн просто по определению паттерна. Значение слова паттерн посмотри.

WH>>Убрать дублирование средствами C# невозможно.
AC>На C# я никогда не писал, но думаю это можно заменить классической парой методов get/set.
Это и есть пара методов get/set.

Но даже если написать методы явно, то гора копипаста всё равно не пропадет. Её станет еще больше.

WH>>Средствами немерле сворачивается в одну строку.
WH>>

WH>>public MyProp : int { get; set; }
WH>>

Что фактически уничтожает паттерн.
AC>А где тела get'а и set'а?
Нету. Их макрос генерирует.
Вместе с полем и вызовом OnPropertyChanged("MyProp");

WH>>Вот тебе еще примеры убирания лишнего кода.
WH>>http://nemerle.org/wiki/index.php?title=Design_patterns
AC>Я верю что ты можешь спрятать любую реализацию паттерна в макрос/DSL, ибо МП даёт полую власть над текстом программы(требуя в замен полной ответственности).
Не спрятать. Уничтожить.
Ибо в коде повторения больше нет.

AC>>>И даже если и так, на этапе разработки архитектуры не известно каким будет код, даже в рамках одного языка(например будет ли он содержать классы или можно обойтись процедурами).
WH>>Это не правда.
AC>Почему?
Я уже раз 100 говорил, что архитектура делается под язык. Максимум под группу очень сильно похожих языков типа C# и Java. Но даже тут всё не просто ибо их инфраструктура очень разная.

WH>>Посмотри на код выше и вызови метод.
AC>1)берём Немерле, или какой ни будь препроцессор для C#, прячем реализацию в макрос, вызываем.
AC>2)меняем все подобные вещи на пары get/set методов, вызываем.
Это уже будет изменение языка.
А ты без изменения C# сделай.

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

AC>>>Не ты не понял, при дизайне/разработке самого DSL'я?
WH>>Зачем?
WH>>У меня для этого ДСЛ есть.
AC>DSL-дизайнер, DSL-архитектор — интригует

AC>Если DSL'и не дизайнятся и не разрабатываются, откуда они берутся?
И нахрена ДСЛю архитектура?
Для ДСЛ важны сущности и отношения между сущностями.
Всё остальное не важно.

Тот код, в который они превращаются, всё равно никто не читает. Так что и усилий к тому чтобы сделать его понятным человеку прилагать не нужно.
Можно генерировать говнокод как попало. Главное чтобы работал. Ну, максимум о чем можно побеспокоиться, чтобы он быстро работал и мало памяти кушал.
И что характерно эти требования входят в конфликт с требованием, чтобы код был понятен людям.
А в случае с ДСЛ такого конфликта нет. Ибо требования понятности людям генерируемого кода нет. Более того ДСЛ позволяет производить оптимизации на высоком уровне и добиваться такой эффективности что руками просто не сделать. В ошибках утонешь.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>У тебя там вызов ровно одной функции который один документ превращает в коллекцию других.

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

AVK>>Попробуй найти в моем описании задачи фразу "вызов одного метода", или хотя бы слово "метод".
WH>Метод. Функция. Не важно.

Важно. Потому что слово "функция" тут применено в математическом смысле, а не в программном.

WH>Главное что у тебя только один вызов.

Нет. Ты упорно не хочешь видеть разницу между проектом и кодом.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Игoрь, Вы писали:

И>>Это не паттерн, а его реализация. Скажу больше, это одна из возможных реализаций Наблюдателя.
WH>Ох. Что такое паттерн.
WH>Паттерн это нечто повторяющееся.
WH>Например, посмотри в гугле картинки по слову pattern.
WH>Увидишь много картинок, на которых повторяется что-то.
Я правильно тебя понимаю, что твое знакомство с паттернами ограничивается каринками в гугле? Причем искал ты не по software design patterns, а просто по patterns? Это объясняет...
Давай кроме картинок еще и боковки почитаем. Итак, первая ссылка на вики:

Software design pattern
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.

И>>А это реализация того же самого паттерна, но на другом языке.
WH>Тут нет паттерна.
WH>Вот эта хрень не повторяется.
И>>Где борьба то? Паттерн как был, так и остался.
WH>Как это остался?
WH>Где повторение вон той хрени чуть выше по тексту?
Повторение есть на уровне "задача-решение". То, что у тебя в коде могут встречаться похожие куски — это еще не делает эти куски кода паттерном. Повторение будет, когда у тебя возникнет похожая задача и ты реализуешь MyClass1, MyClass2.

И>>Чем характеризуется паттерн? Задачей и ее решением.
WH>Нет. Он характеризуется повторяющимся кодом.
WH>Ты извращаешь понятие паттерн.
WH>Паттерн это не решение. Это распознаватель решения.
Читай до просветления:

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

Здравствуйте, WolfHound, Вы писали:

WH>Для ДСЛ важны сущности и отношения между сущностями.

Это и есть архитектура. По определению.

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

(С) Википедия.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

WH>

Это паттерн просто по определению паттерна. Значение слова паттерн посмотри.
Ok, смотрим 1,2,3
Ни в одной, ни строчки кода.
WH>Это и есть пара методов get/set.
WH>Но даже если написать методы явно, то гора копипаста всё равно не пропадет. Её станет еще больше.
Да.
AC>>А где тела get'а и set'а?
WH>Нету. Их макрос генерирует.
WH>Вместе с полем и вызовом OnPropertyChanged("MyProp");
Т.е. ты их спрятал в макрос?
AC>>Я верю что ты можешь спрятать любую реализацию паттерна в макрос/DSL, ибо МП даёт полую власть над текстом программы(требуя в замен полной ответственности).
WH>Не спрятать. Уничтожить.
WH>Ибо в коде повторения больше нет.
Ok, ты уничтожишь повторения, но ведь не паттерн(см. выше определение слова "паттерн").
WH>Я уже раз 100 говорил, что архитектура делается под язык. Максимум под группу очень сильно похожих языков типа C# и Java. Но даже тут всё не просто ибо их инфраструктура очень разная.
А как насчёт проектов в которых например есть Python(для описания логики), C(для критических по производительности), Erlang(для распределения), Java(для сервисной части)?
WH>Это уже будет изменение языка.
WH>А ты без изменения C# сделай.
Я и не говорил что ограничений языков(заставляющих заниматься копипастой или избыточным кодированием) не существует, но причём здесь паттерны проектирования?
WH>>>Паттерны проектирования это и есть адаптация задачи к языку.
AC>>Наверно всё-таки языка (общего н.) к задаче.
WH>Нет. Именно задача натягивается на язык.
ИМХО, ты смотришь на проблему не стой стороны(со стороны ЯП, а не со стороны задачи), ну да тебе видней.
WH>Ибо языки, в коде которых обнаружились данные паттерны, просто не могут изменить себя под задачу.
Наверно всё-таки "языки, в коде которых обнаружилось дублирование кода"?

AC>>Если DSL'и не дизайнятся и не разрабатываются, откуда они берутся?
WH>И нахрена ДСЛю архитектура?
По моему скромному мнению DSL состоит как минимум из:
1)Синтаксиса, которой требует дизайна и разработки(чтобы быть эргономичным и логичным).
2)Транслятора(не важно как реализованного, на макросах или на Pythone'е), которой требует дизайна и разработки(чтобы быть быстрым и удобным).
3)Семантики(то что генерирует транслятор), которая требует дизайна и разработки(чтобы быть быстрой, безошибочной и интегрируемой).
WH>Для ДСЛ важны сущности и отношения между сущностями.
WH>Всё остальное не важно.
Подозреваю что ты конструируешь DSL'и методом добавления фичь по ходу работы?
WH>Можно генерировать говнокод как попало.
WH>Тот код, в который они превращаются, всё равно никто не читает.
Это до первой серьёзной ошибки в нижних DSL'ях (слоях абстракции).
Или до первого рефакторинга дерева DSL'ей.

Здравствуйте, AndrewVK, Вы писали:

AVK>Ты не оттуда пляшешь. Вызов функции это уже не паттерн, это его вопрощение в конкретный код. И в реальности это далеко не просто вызов одной функции, это целый объект, причем персистентный, с несколькими методами. Паттерн не диктует конкретный код, это не копипаста.
Ну, так это по тому, что ты всё видишь через призму C#.
А если посмотреть на чистую задачу, то от всего этого останется одна функция.

AVK>Важно. Потому что слово "функция" тут применено в математическом смысле, а не в программном.
А разве есть разница?
У нас в предметной области вполне себе математическая функция.
Значит и в коде должна быть математическая функция.
И ничего больше.
Всё остальное должен генерировать компилятор.

AVK>Нет. Ты упорно не хочешь видеть разницу между проектом и кодом.
Я упорно не хочу видеть тот код, который ты колбасишь ручками по паттернам.
Я хочу, чтобы этот код колбасил компилятор. Причем так чтобы этот код вообще ни кто не видел.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Игoрь, Вы писали:

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

И> Причем искал ты не по software design patterns, а просто по patterns? Это объясняет...
И>Давай кроме картинок еще и боковки почитаем. Итак, первая ссылка на вики:
Ох.
http://nemerle.org/wiki/index.php?title=Design_patterns
Там наглядна видна копипаста которую порождают паттерны.
И как она исчезает. При использовании макроса.

И>Повторение есть на уровне "задача-решение". То, что у тебя в коде могут встречаться похожие куски — это еще не делает эти куски кода паттерном.
Это именно что сделает это паттерном.
Просто по определению паттерна.
Просто те паттерны о которых ты говоришь встречаются так часто что их даже классифицировали.
А всё из-за слабости языков программирования.

WH>>Паттерн это не решение. Это распознаватель решения.
И>Читай до просветления:
Лучше ты сходи почитай определение слово паттерн.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AndrewVK, Вы писали:

WH>>Для ДСЛ важны сущности и отношения между сущностями.
AVK>Это и есть архитектура. По определению.
AVK>

AVK>The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

AVK>(С) Википедия.
Так я и говорю что ДСЛ и есть архитектура.
А ты тут со мной споришь.
И как только у нас появляется ДСЛ точно отражающий предметную область архитектура готова.
Можно спокойно сажать прикладников писать бизнеслогику. Они ничего не сломают. Им ДСЛ не позволит.
После чего можно спокойно заняться оптимизацией того кода который генерирует ДСЛ.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AlexCab, Вы писали:

AC>А как насчёт проектов в которых например есть Python(для описания логики), C(для критических по производительности), Erlang(для распределения), Java(для сервисной части)?
В том-то и дело, ни один из этих языков не подходит для решения всех классов задач. В том-то и дело, что применение языка с метапрограммированием, наподобие Nemerle, позволяет избавиться от кучи разных языков. На N пишутся DSL'и, которые будут идеальны для логики, для производительности. для распреледения и всего прочего.

AC>ИМХО, ты смотришь на проблему не стой стороны(со стороны ЯП, а не со стороны задачи), ну да тебе видней.
Хм, по-моему WolfHound постоянно твердит, что именно со стороны задачи нужно смотреть! И только DSL позволяют это делать. А применение ЯОН — это как раз взгляд со стороны ЯП.

AC>По моему скромному мнению DSL состоит как минимум из:
AC>1)Синтаксиса, которой требует дизайна и разработки(чтобы быть эргономичным и логичным).
Его не нужно изобретать: берём термины предметной области, и всё!

AC>2)Транслятора(не важно как реализованного, на макросах или на Pythone'е), которой требует дизайна и разработки(чтобы быть быстрым и удобным).
Nemerle — готовый транслятор. N2, по замыслам разрабов, будет ещё удобней.

AC>3)Семантики(то что генерирует транслятор), которая требует дизайна и разработки(чтобы быть быстрой, безошибочной и интегрируемой).
Ну, тут по моему разумению будет примерно то же, что и при написании обычных библиотек. Только потом можно будет пользоваться удобной терминологией предметной области, а не функции, натянутые на глобус, вызывать.

Здравствуйте, AlexCab, Вы писали:

WH>>

Это паттерн просто по определению паттерна. Значение слова паттерн посмотри.
AC>Ok, смотрим
Я говорю про значение слова паттерн вообще.
Поинтересуйся откуда это слово вообще взялось.

WH>>Нету. Их макрос генерирует.
WH>>Вместе с полем и вызовом OnPropertyChanged("MyProp");
AC>Т.е. ты их спрятал в макрос?
Я их убрал из кода.
Теперь в коде только то, что имеет значение.
И никакого мусора.

Паттерна больше нет.

AC>Ok, ты уничтожишь повторения, но ведь не паттерн(см. выше определение слова "паттерн").
Паттерн это и есть повторения. Просто по определению.

pattern

a particular way in which something is done, organized or happens
The pattern of family life has been changing over recent years.
A pattern is beginning to emerge from our analysis of the accident data.
In this type of mental illness, the usual pattern is bouts of depression alternating with elation.
Many behaviour(al) patterns have been identified in the chimp colony.

any regularly repeated arrangement, especially a design made from repeated lines, shapes or colours on a surface
Look, the frost has made a beautiful pattern on the window.
I've never really cared for floral patterns.

something which is used as an example, especially to copy
The design is so good it's sure to set the pattern for many others.

a drawing or shape used to show how to make something
a knitting pattern
a dress pattern
Cut out all of the pieces from the paper pattern and pin them on the cloth.

a small piece of cloth or paper taken from a usual-sized piece and used to show what it looks like; a sample
a pattern book

AC>А как насчёт проектов в которых например есть Python(для описания логики), C(для критических по производительности), Erlang(для распределения), Java(для сервисной части)?
И что? Ну, разделили проект на части.
И каждую часть отархитектурили под конкретный язык.

AC>Я и не говорил что ограничений языков(заставляющих заниматься копипастой или избыточным кодированием) не существует, но причём здесь паттерны проектирования?
При том, что они и есть формализованная копипаста.
Несмотря на все красивые слова, реализация паттернов повторяется практически 1 в 1 из проекта в проект.
Копипаста как она есть.

AC>ИМХО, ты смотришь на проблему не стой стороны(со стороны ЯП, а не со стороны задачи), ну да тебе видней.
Нет. Именно что со стороны задачи.
И мне больно видеть, как её бедную извращают, чтобы натянуть на язык.
Вместо того чтобы сделать по нее язык и не заниматься фигней.

WH>>Ибо языки, в коде которых обнаружились данные паттерны, просто не могут изменить себя под задачу.
AC>Наверно всё-таки "языки, в коде которых обнаружилось дублирование кода"?
Это и есть паттерн.
Все паттерны обнаружились, когда люди смотрели на код и видели что делают раз за разом одно и то же.

Те авторы Design Patterns: Elements of Reusable Object-Oriented Software сначала перелопатили кучу готового кода.
Нашли кучу повторяющихся кусков кода.
Классифицировали их и дали им имена.

WH>>Для ДСЛ важны сущности и отношения между сущностями.
WH>>Всё остальное не важно.
AC>Подозреваю что ты конструируешь DSL'и методом добавления фичь по ходу работы?
Ты так говоришь как будто это что-то плохое.

Видишь ли, в чем дело. Когда делаешь ДСЛ можно себе такое позволить.
Знаешь почему?
А по тому, что я могу поменять один раз генератор и перекомпилировать весь код.
Это дает мне возможность десятком строк безошибочно протащить что-то черед мегабайты генеренного кода.
А те, кто это код пишут руками, так не могут.
Вот и страдают с архитектурой.
И всё равно всегда не угадывают.
И архитектура сползает в говно под гнетом изменяющихся требований.

AC>Это до первой серьёзной ошибки в нижних DSL'ях (слоях абстракции).
AC>Или до первого рефакторинга дерева DSL'ей.
Раз в год. А код на ДСЛ, который в 10-100 раз меньше будет писаться, и читаться постоянно.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>Ну, так это по тому, что ты всё видишь через призму C#.

Ты, мне кажется, с какими то своими иллюзиями споришь. Где я хоть раз упомянул C#?

AVK>>Важно. Потому что слово "функция" тут применено в математическом смысле, а не в программном.
WH>А разве есть разница?

Есть.

WH>У нас в предметной области вполне себе математическая функция.
WH>Значит и в коде должна быть математическая функция.

Не обязательно. И, главное, паттерн Стратегия ничего подобного не диктует. Ты сам обвешиваешь паттерны каким то лишним для них смыслом, и потом сам себя и опровергаешь. Тебе уже несколько человек по нескольку раз повторили — паттерн это не шаблонный код, это шаблонный элемент дизайна. Если возможности языка позволяют реализацию паттерна написать один раз — отлично. Но паттерна это никоим образом не отменяет. Например, от того что в шарпе есть ключевое слово event паттерн Publisher-Subscriber никуда не девается, его просто не надо описывать многословно.

WH>Всё остальное должен генерировать компилятор.

Архитектуру решения пока что ни один компилятор генерировать не умеет. Даже компилятор Немерле.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>Так я и говорю что ДСЛ и есть архитектура.

Нет, DSL не есть архитектура. ДСЛ предоставляет удобные средства для описания сущностей и их связей, а не является ими. Иначе, в твоем понимании, ДСЛ вырождается в одну единственную конструкцию СделайЧтобыВсеБылоЗашибись() и превращается в абсурд.

WH>И как только у нас появляется ДСЛ точно отражающий предметную область архитектура готова.

Продемонстрируй на описанной мной задаче. Или на какой нибудь другой, более менее реальной.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, koodeer, Вы писали:
AC>>А как насчёт проектов в которых например есть Python(для описания логики), C(для критических по производительности), Erlang(для распределения), Java(для сервисной части)?
K>В том-то и дело, ни один из этих языков не подходит для решения всех классов задач. В том-то и дело, что применение языка с метапрограммированием, наподобие Nemerle, позволяет избавиться от кучи разных языков. На N пишутся DSL'и, которые будут идеальны для логики, для производительности. для распреледения и всего прочего.
Я только за! И даже собираюсь использовать N2 в своих меркантильных целях

K>Хм, по-моему WolfHound постоянно твердит, что именно со стороны задачи нужно смотреть!
Возможно я его и не правильно понял, но он утверждает что ЯП определяет решение(включая паттерны), а не задача.

K>Его не нужно изобретать: берём термины предметной области, и всё!
1)Синтаксис это не только термины, но ещё и конструкции из них.
2)Далеко не всегда можно просто взять и перенести термины в ЯП, так как они часто являются перегруженными и неформальными.

K>Nemerle — готовый транслятор. N2, по замыслам разрабов, будет ещё удобней.
Не, N и N2 это скорей инструменты для конструирования трансляторов.

K>Ну, тут по моему разумению будет примерно то же, что и при написании обычных библиотек. Только потом можно будет пользоваться удобной терминологией предметной области, а не функции, натянутые на глобус, вызывать.
Допилят, увидим.

Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, DSL не есть архитектура. ДСЛ предоставляет удобные средства для описания сущностей и их связей, а не является ими. Иначе, в твоем понимании, ДСЛ вырождается в одну единственную конструкцию СделайЧтобыВсеБылоЗашибись() и превращается в абсурд.
А что у тебя в архитектуре вся бизнеслогика прописана, которую лабают орлы из соседнего отдела?
Не ведь. У тебя там описано, в каких рамках эти орлы должны себя держать, и какими сущностями оперировать.
ДСЛ именно это и делает только несравнимо лучше.

AVK>Продемонстрируй на описанной мной задаче. Или на какой нибудь другой, более менее реальной.
Твою задачу я не знаю и узнавать не хочу.
Вот вполне реальная задача.
Написание парсеров.
Берем ДСЛ и пишем парсер.
https://github.com/rampelstinskin/ParserGenerator/blob/master/N2/N2.Grammar/GrammarParser2.n2

Там кстати пока еще есть паттерн, который давно хотим прибить. Но пока не знаем как именно. Общий случай довольно мутный.
"syntax"S
"is"S
"="s
итд...
Вот эти вот s/S за литералом это тоже паттерн. Его тоже надо прибить.

Внутри там генерируется куча кода.
При желании в генерируемом коде можно найти кучу GoF паттернов.
Но только на них всем пофиг.
Ибо сегодня там одно. А завтра будет всё совсем по другому (я как раз сейчас всё совсем по-другому и переделываю).
Но ДСЛ из-за этого не изменится ни на букву.
И если бы у меня сейчас был мегабайт кода на этом ДСЛ, его нужно было бы только перекомпилировать.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AlexCab, Вы писали:

AC>Возможно я его и не правильно понял, но он утверждает что ЯП определяет решение(включая паттерны), а не задача.
Решение определяет и ЯП и задача.
Причем ЯП ты менять не можешь.
По этому ты меняешь задачу натягивая ее на свой ЯП.
А паттерны появляются при натягивании задачи на конкретный язык. И при натягивании одной и той же задачи на разные языки у тебя будут разные паттерны.

В случае с ДСЛ тебе всё еще нужно формализовать задачу.
Но натягивать ее на язык не нужно.
Ибо задача сама определяет язык.
Тебе нужно только реализовать этот язык.
После чего задача ляжет на него без всяких паттернов и изменений.

K>>Его не нужно изобретать: берём термины предметной области, и всё!
AC>1)Синтаксис это не только термины, но ещё и конструкции из них.
AC>2)Далеко не всегда можно просто взять и перенести термины в ЯП, так как они часто являются перегруженными и неформальными.
Например?

AC>Не, N и N2 это скорей инструменты для конструирования трансляторов.
Немерле это конкретный, но расширяемый язык.
N2 это язык для написания компиляторов.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

WH>>>

Это паттерн просто по определению паттерна. Значение слова паттерн посмотри.
AC>>Ok, смотрим
WH>Я говорю про значение слова паттерн вообще.
Ааа.., стоит исправить название ветки.
AC>>Т.е. ты их спрятал в макрос?
WH>Я их убрал из кода.
А макрос это не код?

AC>>Подозреваю что ты конструируешь DSL'и методом добавления фичь по ходу работы?
WH>Ты так говоришь как будто это что-то плохое.
Да это что-то плохое, очень плохое, особенно в смеси с "сделаем один DSL, поверх него ещё один...", это time bomb

Потому что:
1)При таком подходе со временем DSL превращается в свалку фичь.
2)Поверх него наслаиваются новые DSL.
3)Наступает момент когда надо добавить новую фичу, а не получается(например конфликтует с ранее добавлеными), и возникает необходимость рефракторить DSL.
И теперь внимание вопрос: Насколько дороже обойдётся рефакторинг такого DSL(особенно если по верх него ещё 10)по сравнению с спроектированным? По сравнению с библиотекой?
WH>А по тому, что я могу поменять один раз генератор и перекомпилировать весь код.
Ok, у тебя большой проект, 100 генераторов на десяти абстрактных уровнях?
WH>Это дает мне возможность десятком строк безошибочно протащить что-то черед мегабайты генеренного кода.
Ты уверен что 95% программистов это смогут повторить?
WH>И архитектура сползает в говно под гнетом изменяющихся требований.
Ты говоришь: "DSL == архитектура".
Почему такого не может случится с DSL?

Здравствуйте, AlexCab, Вы писали:

AC>Ааа.., стоит исправить название ветки.
Нет. Стоит получше подумать про то откуда взялись паттерны проектирования.

AC>А макрос это не код?
Ну вызов функции тоже код.
Только это уже не паттерн.
А вот если заинлайнить функцию во все места, где мы её вызываем, то мы сразу обнаружим паттерн.

Причем при желании можно даже вызов макроса убрать. Вариантов много. Например, обрабатываем все классы, лежащие в пространствах имен *.ViewModel.

AC>>>Подозреваю что ты конструируешь DSL'и методом добавления фичь по ходу работы?
WH>>Ты так говоришь как будто это что-то плохое.
AC>Да это что-то плохое, очень плохое, особенно в смеси с "сделаем один DSL, поверх него ещё один...", это time bomb

Это обычная практика разработчиков ДСЛ.

AC>Потому что:
AC>1)При таком подходе со временем DSL превращается в свалку фичь.
AC>2)Поверх него наслаиваются новые DSL.
AC>3)Наступает момент когда надо добавить новую фичу, а не получается(например конфликтует с ранее добавлеными), и возникает необходимость рефракторить DSL.
Ты говоришь, так как будто это не происходит во всех других случаях.
Это все совершенно естественный процесс при изменении требований.
Ничего ты с ним не сделаешь.

AC>И теперь внимание вопрос: Насколько дороже обойдётся рефакторинг такого DSL(особенно если по верх него ещё 10)по сравнению с спроектированным?
Ты так говоришь, как будто можно изначально собрать все требования.
Нет, сынок. Такое только у разработчиков шатлов и АЭС бывает.

AC>По сравнению с библиотекой?
Намного дешевле. Ибо кода будет намного меньше.

WH>>А по тому, что я могу поменять один раз генератор и перекомпилировать весь код.
AC>Ok, у тебя большой проект, 100 генераторов на десяти абстрактных уровнях?
И?

WH>>Это дает мне возможность десятком строк безошибочно протащить что-то черед мегабайты генеренного кода.
AC>Ты уверен что 95% программистов это смогут повторить?
Я уверен, что эти 95% процентов можно посадить писать код на ДСЛ.
А остальные 5% займутся разработкой ДСЛ.
Создание ДСЛ это работа архитектора.
Ибо ДСЛ и есть архитектура.

AC>Ты говоришь: "DSL == архитектура".
AC>Почему такого не может случится с DSL?
По тому, что в ДСЛ только модель предметной области без намеков на детали реализации.
А код на C# чуть менее чем полностью состоит из деталей реализации.
В случае с ДСЛ детали реализации изменить очень дёшево.
В случае с классическим подходом тебе придется переписать всё.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

WH>По этому ты меняешь задачу натягивая ее на свой ЯП.
WH>А паттерны появляются при натягивании задачи на конкретный язык. И при натягивании одной и той же задачи на разные языки у тебя будут разные паттерны.
Может всё-таки я меняю решение задачи, чтоб оно удовлетворяло и задаче и ЯП. А паттерны(которое не паттерны проектирования) да, появляются там где язык слабый, либо там где я недостаточно хорошо знаю язык, чтобы избежать их появления.

K>>>Его не нужно изобретать: берём термины предметной области, и всё!
AC>>1)Синтаксис это не только термины, но ещё и конструкции из них.
AC>>2)Далеко не всегда можно просто взять и перенести термины в ЯП, так как они часто являются перегруженными и неформальными.
WH>Например?
Это то что ты выше назвал "формализация задачи", т.е. из естественного языка в DSL.

Здравствуйте, WolfHound, Вы писали:

ГВ>>Прикольно. Я тебе про Фому, ты мне — про Ерёму.
WH>Я тебе про сущность понятия паттерн.

Тише, тише. А то сейчас у тебя СПГС проявится.

ГВ>>Ясно, но, ИМХО, это довольно узкая интерпретация, по такой логике обычные библиотеки тоже можно назвать борцами с паттернами,
WH>Совершенно верно.
WH>Они и есть борцы с паттернами также известными как копипаста.

Не совсем так. Копипаста — это один из паттернов. Но паттерны вообще — это не только копипаста.

ГВ>>хотя почему-то я таких названий не встречал.
WH>Это по тому, что те паттерны, с которыми успешно борются, исчезают из кода.
WH>Нет паттерна. Нет обсуждения.

Да нет, обсуждений-то полно. Просто говорят: "вынеси это в функцию" или "вынеси это в класс", а не: "Уничтожь паттерн!".

WH>Но не все паттерны могут устранить библиотеки для обычных языков.
WH>Вот те паттерны, которые не могут быть устранены, начали изучаться и классифицироваться.
WH>Но это не отменяет то, что они копипаста.
WH>И более мощные языки это наглядно доказывают.

Более мощные языки доказывают только то, что можно трансформировать синтаксис языка под задачу (читай, сделать DSL). Бесспорно, это очень хорошее свойство новых языков, только при чём здесь уничтожение паттернов, как таковых?

ГВ>>По сути, как это правильно сказал Игорь, ты никуда не деваешь сам паттерн, ты просто вносишь его частную реализацию в библиотеку. Так что, не обольщайся — например, для разбора того, что же делает твой макрос, будет снова использоваться описание паттерна.
WH>А всегда говорил про код.
WH>И код исчез.
WH>А уж что там сгенерирует компилятор дело десятое.

Я тебя уже давно понял, не переживай. Вся проблема в том, что я не могу согласиться с твоей системой терминов. Соображаешь? По сути ты сейчас занимаешься подменой: ты подменяешь решение общей задачи частностью, а потом объявляешь это решением общей задачи. И кстати, да — такой приём порождает бесконечную цепочку восклицаний: "Ты не понимаешь!", "Ты понимаешь это неправильно!".

Спору нет, задача "избавиться от паттернов" выглядит sexy, только фокус в том, что sexy — это именно избавление от паттернов вообще, а не от реализации паттернов в коде. Первое — это было бы круто (средствами языка программирования), второе — не более, чем технологический приём, паттерну которого сто лет в обед. По сути вся техника с незапамятных времён развивается именно по такому принципу — повторяющиеся действия человека заменяют механизмом. Только это не избавляет человека от необходимости понимать внутреннее устройство механизма и паттерна, который им реализован.

ГВ>>В данном случае нигде в коде, кроме комментариев и, возможно, сопроводительной документации не будет фигурировать термин "фасад". Просто появится соглашение, что foo и zoo — фасадные методы. Допустим, их не будут менять слишком бодро при очередном рефакторинге и т.п. И никакого лишнего кода. В конце концов, главное — это та информация, которая передана людям.
WH>Тут нет задачи.
WH>Обсуждать борьбу с паттернами без исходной не замутненной реализацией задачи не имеет смысла.
WH>Никакого.

Странно. Тебе, почему-то, не помешало отсутствие задачи, чтобы вдребезги пополам разнести пример из MSDN. Хотя он ничуть не менее синтетический, чем мой.

WH>И что касается этого твоего фасада, то я вообще не помню, чтобы хоть раз применял что-то похожее.

А что, твой личный опыт — это альфа и омега индустрии? По-моему, это слишком самонадеянное высказывание.

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

Мне-то твой дзен понятен...
WH>Ну да. Узнаю твой типичный паттерн поведения.
WH>Слив -> демагогия.
WH>Очень типично для тебя.

Естественно. Я всегда сливаю, когда мне с пеной у рта доказывают, что 2x2=5. Так что — да, это мой типичный паттерн поведения.

ГВ>>Да не "убить паттерны", а забить в библиотеку их частные реализации. Всё, что здесь уничтожается — это дублирование кода. А паттерны, как обощённые структурные модели, остаются живёхоньки.
WH>Не остаются.
WH>Ибо они исчезают из кода.
WH>И распознать их уже нельзя.
WH>А во что их превращает компилятор уже не важно.

Странно. [ImplementINotifyPropertyChanged] — есть, а паттерна, который здесь реализован — нет. Прямо — "Ж... есть, а слова нет" или "Слово сказанное — суть ложь". С другой стороны, я понимаю, как именно ты ограничиваешь семантику слова "паттерн" и в рамках этого ограничения ты безусловно прав. Неприятность ровно одна — твоя правота построена на некорректной начальной посылке.

ГВ>>Если следовать твоей логике, что "паттерн — это повторяющаяся часть кода", то библиотеки — такое же средство "борьбы с паттернами", как и новый язык. Пусть не такое мощное, поскольку ограничено самим языком, но тем не менее.
WH>Ну да. Библиотеки борются с некоторым очень примитивным классом паттернов.
WH>Но их обсуждать не имеет смысла.
WH>Ибо если программист грамотный, то их в коде и так не будет.

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

ГВ>>А если опереться на общепринятое определение, что паттерн — это надъязыковая модель, то придётся констатировать, что ни библиотеки, ни новый язык не могут "убить паттерн", поскольку они его попросту реализуют, но никуда при этом не удаляют. Паттерн по-прежнему остаётся в описаниях и в языке общения разработчиков.
WH>Начнем с того что паттерны прибиты гвоздями к группе похожих с семантической точки зрения языков.
WH>На этом и закончим.
WH>Ибо это делает всю твою цепочку рассуждений ложной.

С чего бы это? Тот же AVK тебе привёл пример паттерна, обнаруженного в постановке задачи задолго до её решения на языке программирования.

ГВ>>То, что ты ими называешь — да. Правда, почему-то, твоё мнение разделяют не все.
WH>Просто не хотят признавать что нанимаются копипастой.

WH>Но признание проблемы это первый шаг к ее исправлению.

Смотри, ты снова повторяешь свой любимый съезд на личности: "не хотят признавать". Это ничто иное, как подмена обсуждения объекта обсуждением субъекта — классика демагогии, между прочим.

ГВ>>Ну почему же сразу "не позволяет"? Чаще дело сводится к тому, что нет нужды заниматься реализацией обобщённого решения, гораздо проще и легче сделать "копипасту"
WH>Ну, реализуй мне на C# обобщенное решение для INotifyPropertyChanged.
WH>Удачи.

ИМХО, можно что-то накрутить с Reflection и Emit (точнее на вскидку не скажу), только на фига козе баян?

WH>А потребность есть.
WH>Ибо народ даже переписыванием IL занимается, чтобы этот код не писать.

Ну так это проблемы самого C#.

ГВ>>(ещё одна крамольность), чем выдумывать новые имена для того, что не нужно именовать. Я не всегда согласен с Ikemefula, но в данном случае наши мнения практически совпадают.
WH>Вот только ни ты, ни он не показали, что же не нужно именовать.
WH>И чему при создании ДСЛ придется дать имя.

Зато ты это замечательно показал своим [ImplementINotifyPropertyChanged]. Вот как раз такие имена и бесят без меры — длинное имя ни о чём. Даже банальное [ObservableProperty] было бы короче и понятней, но (сюрприз!) здесь прямо фигурирует название паттерна.

ГВ>>

Кроме того у Nemerle есть свой match/биндинг по регекспам (называется кажется rx match или regex match), и мы по образу и подобию слепили себе такой же, но почему и чем он был лучше — уже не помню.

ГВ>>Извини, я не удержался.

WH>И что? У них была проблема. Они ее решили. Был бы C# они бы трахались неизмеримо сильнее.
WH>Или ты хочешь сказать, что ни разу в жизни не выкидывал стандартную библиотеку по тому, что она тебя не устраивала?
WH>Короче прекращай разводить двойные стандарты.

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

ГВ>>P.S.: Кстати, а как по твоему методу можно изничтожить паттерн "Chain of responsibilities"?
WH>Без исходной задачи не имею ни малейшего представления.

Один из ответственных подписывает документ — это может быть начальник, его заместитель или другое уполномоченное лицо. Если подписать документ некому — документ переводится в состояние "отложен". Чистый CoR и в очередной раз — без намёка на язык программирования.

ГВ>>P.P.S.: И с вот таким паттерном как быть: "Интерфейс"?
WH>Ты еще вызов метода как это делают AVK и Ikemefula в паттерны запиши.

Тем не менее — это паттерн. Фундаментальный. Что характерно, "воплощён" он даже в банальной электрической розетке.

WH>В любом случае, когда дело доходит до конкретной задачи оказывается что и это не нужно.

Что — не нужно?

AC>>Ааа.., стоит исправить название ветки.
WH>Нет. Стоит получше подумать про то откуда взялись паттерны проектирования.
Логика мне подсказывает что из проектирования(процесса). Твоя версия?

AC>>И теперь внимание вопрос: Насколько дороже обойдётся рефакторинг такого DSL(особенно если по верх него ещё 10)по сравнению с спроектированным?
WH>Ты так говоришь, как будто можно изначально собрать все требования.
Все конечно нет, но все что возможно стоит, а затем их систематизировать, и только тогда начинать работу над DSL, включающую: дизайн -> архитектуру -> реализацию.
WH>Нет, сынок. Такое только у разработчиков шатлов и АЭС бывает.
У них точно не бывает.
AC>>Ok, у тебя большой проект, 100 генераторов на десяти абстрактных уровнях?
WH>И?
И поменяв один из них тебе придётся менять N зависящих от него.
WH>В случае с ДСЛ детали реализации изменить очень дёшево.
Да, не считая случаев когда необходимо менять сам DSL.
WH>В случае с классическим подходом тебе придется переписать всё.
Не приведёт ли дешевизна изменения(в с. DSL) к ещё более быстрому скатыванию в говно, и как следствие необходимости переписывать всё с 0.

Здравствуйте, WolfHound, Вы писали:

WH>А что у тебя в архитектуре вся бизнеслогика прописана, которую лабают орлы из соседнего отдела?

Нет, конечно. У меня своя архитектура, у орлов своя.

WH>У тебя там описано, в каких рамках эти орлы должны себя держать

Да.

WH>, и какими сущностями оперировать.

Нет. Они свои собственные сущности определяют.

WH>Вот вполне реальная задача.
WH>Написание парсеров.
WH>Берем ДСЛ и пишем парсер.

И где там потенциальные паттерны, которые исчезли из-за наличия DSL? К примеру, есть паттерн описания языка в виде грамматики и построению по ней парсящего кода генератором. Он, как я понимаю, никуда не делся.

WH>Там кстати пока еще есть паттерн, который давно хотим прибить. Но пока не знаем как именно. Общий случай довольно мутный.
WH>"syntax"S
WH>"is"S
WH>"="s
WH>итд...
WH>Вот эти вот s/S за литералом это тоже паттерн.

Я пока что тут никакого паттерна не вижу. Вижу код.

WH>При желании в генерируемом коде можно найти кучу GoF паттернов.

Можно. Но не нужно.

WH>И если бы у меня сейчас был мегабайт кода на этом ДСЛ, его нужно было бы только перекомпилировать.

Это все здорово, но при чем тут архитектура и паттерны?

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, AlexCab, Вы писали:

AC>Логика мне подсказывает что из проектирования(процесса). Твоя версия?
Нет. Из кода.
Из много раз повторяющегося кода.

AC>Все конечно нет, но все что возможно стоит, а затем их систематизировать, и только тогда начинать работу над DSL, включающую: дизайн -> архитектуру -> реализацию.
Весь дизайн ДСЛ сводится к тому, чтобы найти сущности предметной области и то, как они взаимодействуют.
Это семантика ДСЛ.
Синтаксис чисто дело вкуса. Просто делаешь в стиле того языка который тебе нравится и все.
Реализацию ДСЛ можно менять как угодно в любой момент.
И так обычно и делается. Сначала пишется простейшая реализация.
Люди начинают работать.
И постепенно производятся оптимизации.

WH>>Нет, сынок. Такое только у разработчиков шатлов и АЭС бывает.
AC>У них точно не бывает.
Именно так они и работают.
Сначала несколько лет собирают требования.
Постом несколько лет пилят код обложенный тестами и формальными доказательствами.
А потом всё равно одна проскочившая ошибка роняет ракету.

AC>И поменяв один из них тебе придётся менять N зависящих от него.
Зачем?

WH>>В случае с ДСЛ детали реализации изменить очень дёшево.
AC>Да, не считая случаев когда необходимо менять сам DSL.
1)ДСЛ обычно расширяют.
2)Даже если будут ломающие изменения, то поменять код на ДСЛ будет гораздо проще. Ибо его на порядок меньше.

AC>Не приведёт ли дешевизна изменения(в с. DSL) к ещё более быстрому скатыванию в говно, и как следствие необходимости переписывать всё с 0.
Не приведет и даже написал почему.
Причем не один раз.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AndrewVK, Вы писали:

WH>>А что у тебя в архитектуре вся бизнеслогика прописана, которую лабают орлы из соседнего отдела?
AVK>Нет, конечно. У меня своя архитектура, у орлов своя.
И что же у них там за архитектура?

WH>>, и какими сущностями оперировать.
AVK>Нет. Они свои собственные сущности определяют.
Нет. Они заводят сущности тех кайдов (тип типа) которые ты им позволил заводить.
Ибо все остальное просто не будет работать в рамках твоей системы.

AVK>И где там потенциальные паттерны, которые исчезли из-за наличия DSL?
Если ты не найдешь в этом коде паттерны то дальнейший разговор не имеет смысла.

Скрытый текст

      mutable _ast_8;
      mutable _ast_7;
      mutable _ast_5;
      mutable _ast_4;
      mutable _ast_2;
      mutable isBest = false;
      def newPos = 
      {
        _  = "alias S Identifier = s Rule ; s";
        
        {
          (seqResult : 
          {
            def pos = 
            {
              _  = "alias";
              if (pos + 4 < text.Length && text[pos] == 'a' && text[pos + 1] == 'l' && text[pos + 2] == 'i' && text[pos + 3] == 'a' && text[pos + 4] == 's') 
              {
                _ast_2 = N2.NToken(pos, pos + 5);
                pos + 5
              }; else 
              {
                when (_grammar._parsingErrors._token_InnerAliasDeclaration_literal_"alias"_ < pos) _grammar._parsingErrors._token_InnerAliasDeclaration_literal_"alias"_ = pos;
                -1
              }
            };
            unless (pos >= 0 && isBest || 
                {
                  isBest = bestOffsets[0] < pos;
                  isBest || bestOffsets[0] == pos
                }) seqResult(-1);
            def ofs0 = pos;
            def pos = 
            {
              _  = "S";
              _grammar._#_S_(pos, text)
            };
            unless (pos >= 0 && isBest || 
                {
                  isBest = bestOffsets[1] < pos;
                  isBest || bestOffsets[1] == pos
                }) seqResult(-1);
            def ofs1 = pos;
            def pos = 
            {
              _  = "Identifier";
              _grammar._#_Identifier_(pos, text, ref _ast_4)
            };
            unless (pos >= 0 && isBest || 
                {
                  isBest = bestOffsets[2] < pos;
                  isBest || bestOffsets[2] == pos
                }) seqResult(-1);
            def ofs2 = pos;
            def pos = 
            {
              _  = "=";
              if (pos < text.Length && text[pos] == '=') 
              {
                _ast_5 = N2.NToken(pos, pos + 1);
                pos + 1
              }; else 
              {
                when (_grammar._parsingErrors._token_InnerAliasDeclaration_literal_"="_ < pos) _grammar._parsingErrors._token_InnerAliasDeclaration_literal_"="_ = pos;
                -1
              }
            };
            unless (pos >= 0 && isBest || 
                {
                  isBest = bestOffsets[3] < pos;
                  isBest || bestOffsets[3] == pos
                }) seqResult(-1);
            def ofs3 = pos;
            def pos = 
            {
              _  = "s";
              _grammar._#_s_(pos, text)
            };
            unless (pos >= 0 && isBest || 
                {
                  isBest = bestOffsets[4] < pos;
                  isBest || bestOffsets[4] == pos
                }) seqResult(-1);
            def ofs4 = pos;
            def pos = 
            {
              _  = "Rule";
              _grammar._#_Rule_(pos, text, 0, ref _ast_7)
            };
            unless (pos >= 0 && isBest || 
                {
                  isBest = bestOffsets[5] < pos;
                  isBest || bestOffsets[5] == pos
                }) seqResult(-1);
            def ofs5 = pos;
            def pos = 
            {
              _  = ";";
              if (pos < text.Length && text[pos] == ';') 
              {
                _ast_8 = N2.NToken(pos, pos + 1);
                pos + 1
              }; else 
              {
                when (_grammar._parsingErrors._token_InnerAliasDeclaration_literal_";"_ < pos) _grammar._parsingErrors._token_InnerAliasDeclaration_literal_";"_ = pos;
                -1
              }
            };
            unless (pos >= 0 && isBest || 
                {
                  isBest = bestOffsets[6] < pos;
                  isBest || bestOffsets[6] == pos
                }) seqResult(-1);
            def ofs6 = pos;
            def pos = 
            {
              _  = "s";
              _grammar._#_s_(pos, text)
            };
            unless (pos >= 0 && isBest || 
                {
                  isBest = bestOffsets[7] < pos;
                  isBest || bestOffsets[7] == pos
                }) seqResult(-1);
            def ofs7 = pos;
            if (isBest) 
            {
              
              {
                bestOffsets[0] = ofs0;
                bestOffsets[1] = ofs1;
                bestOffsets[2] = ofs2;
                bestOffsets[3] = ofs3;
                bestOffsets[4] = ofs4;
                bestOffsets[5] = ofs5;
                bestOffsets[6] = ofs6;
                bestOffsets[7] = ofs7
              };
              for (mutable i = 8;i < bestOffsets.Length && bestOffsets[i] >= 0;++i) bestOffsets[i] = -1;
              pos
            }; else -1
          })
        }
      };
      when (newPos >= 0) result = InnerAliasDeclaration.Ast(N2.Location(_grammar._parsingSource, N2.Internal.EvalLocationStart(_ast_2, pos), N2.Internal.EvalLocationEnd(_ast_8, newPos)), [], _ast_2, _ast_4, _ast_5, _ast_7, _ast_8);
      newPos
    }
  }

AVK>К примеру, есть паттерн описания языка в виде грамматики и построению по ней парсящего кода генератором. Он, как я понимаю, никуда не делся.
Я фшоке.
Сначала у тебя вызов функции это паттерн.
Теперь написание программы тоже стало паттерном.
Ахринеть.
Чем дальше, тем чудесатее.
Тебя послушать то везде одни паттерны.

WH>>Вот эти вот s/S за литералом это тоже паттерн.
AVK>Я пока что тут никакого паттерна не вижу. Вижу код.
А я вижу. За каждым литералом идет выжерание пробельных символов.
Это повторяющейся в каждой грамматике по многу раз код.
Самый натуральный паттерн.
А то, что он в GoF не описан так это по тому, что он специфичен для очень узкого класса языков.

WH>>При желании в генерируемом коде можно найти кучу GoF паттернов.
AVK>Можно. Но не нужно.
Те в вызове строго одной функции можно и нужно.
А в горе откровенно повторяющегося с небольшими изменениями кода не нужно.
Чем дальше, тем меньше логики.

WH>>И если бы у меня сейчас был мегабайт кода на этом ДСЛ, его нужно было бы только перекомпилировать.
AVK>Это все здорово, но при чем тут архитектура и паттерны?
При том, что ДСЛ это и есть архитектура.
А паттерны надежно закопаны в сгенерированном коде. На который всем наплевать.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

AVK>>Нет, конечно. У меня своя архитектура, у орлов своя.
WH>И что же у них там за архитектура?

Вопрос непонятен.

AVK>>Нет. Они свои собственные сущности определяют.
WH>Нет. Они заводят сущности тех кайдов (тип типа) которые ты им позволил заводить.

Все архитекторы заводят сущности, которые им позволяет инструмент. Архитектуры не существует?

AVK>>И где там потенциальные паттерны, которые исчезли из-за наличия DSL?
WH>Если ты не найдешь в этом коде паттерны то дальнейший разговор не имеет смысла.

Если вместо ответов на конкретные вопросы высылаются простыни кода, то действительно — не имеет.

AVK>>К примеру, есть паттерн описания языка в виде грамматики и построению по ней парсящего кода генератором. Он, как я понимаю, никуда не делся.
WH>Я фшоке.
WH>Сначала у тебя вызов функции это паттерн.

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

WH>Теперь написание программы тоже стало паттерном.

Такого я тоже не говорил.

WH>Ахринеть.
WH>Чем дальше, тем чудесатее.

Если ты мне будешь приписывать свои фантазии — тебя еще не то ждет.

WH>Тебя послушать то везде одни паттерны.

Меня ты, как раз, совершенно не слушаешь.

WH>>>И если бы у меня сейчас был мегабайт кода на этом ДСЛ, его нужно было бы только перекомпилировать.
AVK>>Это все здорово, но при чем тут архитектура и паттерны?
WH>При том, что ДСЛ это и есть архитектура.

Докажи. Продемонстрируй логическую цепочку. Определение архитектуры я уже привел. Осталось показать, почему в DSL не надо описывать сущности и связи между ними.

WH>А паттерны надежно закопаны в сгенерированном коде. На который всем наплевать.

Попробуй очень внимательно прочесть хотя бы раз: ПАТТЕРНЫ ЭТО НЕ КОД.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>Паттерн это и есть повторения. Просто по определению.
WH>

WH>pattern

Это не то определение. Термин design pattern имеет вполне конкретный смысл:
[q]
A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>К примеру, если нам интересен детальный механизм вызова метода (к примеру, описываем немакроассемблер, где готовой инструкции call и соглашений о параметрах нет), то да, мы можем сформулировать в описании архитектуры вызов метода как паттерн.
(*)

AVK>Если же описание архитектуры более абстрактно, выделять вызов метода как спецпаттерн не нужно, описательности это не добавит.
(**)

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

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

И про то, что архитектура == ДСЛ ты тоже написал в этом сообщении.

Я не понимаю, о чем ты тут споришь то?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

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

Это все, конечно верно и правильно, но ты не забывай что моя притензия была не к паттернам, а к фразе:

WH>Проектирование == создание ДСЛ.
WH>А дальше уже остается чистая бизнес логика.
WH>Там нечего проектировать.

Да, безусловно, в зависимости от целевого языка какие то паттерны теряют актуальность, какие то наоборот приобретают, но архитектура от этого никуда не девается.

WH>Причем если начинать проектировать сразу в терминах задачи то ты в коде на языке сделанном под эту задачу паттернов скорей всего никогда не найдешь. А если найдешь значит плохо проанализировал задачу.

Еще раз внимательно смотри на определение паттерна.

WH>И про то, что архитектура == ДСЛ ты тоже написал в этом сообщении.

Чего? Ссылочку на такое мое утверждение можно?

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

N>>И это по сути тот же DSL.
WH>ДСЛ это когда
WH>assert a == b;
WH>а все остальное сделается само.
Причём под "всё остальное" оптимисты типа меня подразумевают также оптимизации ниже по коду, которые опираются на эту эквивалентность.
Так что когда я пишу

assert a == b;
var x = 42 * (a-b);
if (x>0)
  CallA(x);

То код под иф-ом вместе с самим иф-ом устраняется компилятором.

Здравствуйте, WolfHound, Вы писали:

I>>Аргумент про итерацию и блекджект ты проигнорировал ? Так держать !
WH>Про итерацию это никакой не аргумент. Ибо вызов функции не паттрен. Иначе все есть паттерн.
Вызов функции — паттерн там, где нет встроенного средства по вызову функции.
Если у меня есть только pop, push, и команда jmp, то упражнение "вызвать функцию, положив параметры в стек" — вполне себе паттерн. Потому что повторяется постоянно, но при этом каждый раз немножко разный (в зависимости от сигнатуры функции).

Здравствуйте, WolfHound, Вы писали:

Вызов метода — паттерн там, где нету встроенного в язык понятия "вызов метода".
Я могу построить паттерн "вызов виртуального метода" вручную на С:

a->__vmt.Foo(a*, 10, 20);

Но удобнее, конечно, писать

a.Foo(10, 20);

Но это будет уже не паттерн.
Я могу на основе методов построить паттерн "свойство", определив пару методов T getSome() и void putSome(T).
А могу взять язык, в котором уже есть встроенная реализация паттерна "свойство", тогда это будет уже не паттерн.
Я могу на основе методов построить паттерн "событие", похожим на "свойство" способом.
А могу взять язык, в котором уже есть встроенная реализация паттерна "событие". Тогда это будет уже не паттерном.
Я могу построить паттерн "свойство с извещением об изменении" на основе языка, в котором есть паттерны "свойство" и "событие".
А могу поискать язык, в котором можно встроить такую конструкцию в сам язык, и писать

public notifyable int Foo { get; set;}

Вместо всего boilerplate, который пишется в соответствии с паттерном.

Здравствуйте, Nuseraro, Вы писали:

N>Пробовал и без проблем. Из попсовых примеров могу вспомнить архитектуры всяких Mock, где ~ Assert.That(a.HasProperty("t").Equal(2).And.HasProperty("t", 1)); — чем плохо?
1. Ужасный синтаксис. Лично я так и не смог сконвертировать это во что-то читаемое. Что-то вроде (a.t == 2) || (a.t==1) было бы куда понятнее. Почему-то никто не настаивает на обычной арифметике через вызовы методов.
2. Компилятор ничего не знает о семантике этого ассерта. В DSL у компилятора есть доступ к семантике; он может выводить из этого ассерта всякие полезные следствия — в частности, использовать его для оптимизации, а также для раздачи ворнингов типа "assert is never satisfied".

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Игoрь, Вы писали:

И>>Я правильно тебя понимаю, что твое знакомство с паттернами ограничивается каринками в гугле?
WH>Нет. Но тебе стоит почитать определение слова паттерн. И посмотреть на картинки.
Ты мне надоел. Вот определение по первой же ссылки из гугла:

Па́ттерн (англ. 'pattern — образец, шаблон, система) — заимствованное слово. Слово «pattern» используется как термин в нескольких западных дисциплинах и технологиях, откуда оно и проникло в русскоязычную среду. Смысл термина «паттерн» больше уже чем просто «образец», и варьируется в зависимости от области знаний, в которой используется.

Паттерн (информатика) — эффективный способ решения характерных задач проектирования, в частности проектирования компьютерных программ.

И далее ссылка на шаблоны проектирования.

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

Здравствуйте, Sinclair, Вы писали:

S>Вызов метода — паттерн там, где нету встроенного в язык понятия "вызов метода".
Я ровно про это тут уже сообщений 50 написал.
Был паттерн. Подняли уровень языка. Не стало паттерна.
А со мной тут куча народа спорит. Говорят, что паттерн всё равно остался.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Sinclair, Вы писали:

S>Причём под "всё остальное" оптимисты типа меня подразумевают также оптимизации ниже по коду, которые опираются на эту эквивалентность.
хъ
S>То код под иф-ом вместе с самим иф-ом устраняется компилятором.
Это тоже можно.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Игoрь, Вы писали:

И>И далее ссылка на шаблоны проектирования.
Вот только тебе стоило посмотреть в английские толковые словари.
Там про паттерны проектирования ни слова.
Я тут уже приводил цитату.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Да, безусловно, в зависимости от целевого языка какие то паттерны теряют актуальность, какие то наоборот приобретают, но архитектура от этого никуда не девается.
Она уходит в язык.

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

Ты тут сам говоришь об отображении архитектуры на язык.
Но сам же с этим споришь.
Я тебя совсем не понимаю.

AVK>Еще раз внимательно смотри на определение паттерна.
Паттерн это повторяющаяся хрень.
Вот и все его определение.

WH>>И про то, что архитектура == ДСЛ ты тоже написал в этом сообщении.
AVK>Чего? Ссылочку на такое мое утверждение можно?
Это напрямую следует из процитированного выше абзаца.
Где ты проводишь однозначное отображение архитектуры на язык.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Игoрь, Вы писали:

И>>И далее ссылка на шаблоны проектирования.
WH>Вот только тебе стоило посмотреть в английские толковые словари.
WH>Там про паттерны проектирования ни слова.
WH>Я тут уже приводил цитату.

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

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

Здравствуйте, Игoрь, Вы писали:

И>Во-первых, мы здесь на русском общаемся, а не английском. Во-вторых, если бы ты так же изъяснялся на английском, подозреваю, что были бы те же самые проблемы. В третьих, это не проблема, когда ты один размышляешь. Когда ты кому-то одному пытаешься донести мысль, то это уже ваша общая проблема. А если уж на форуме пишешь многим, то это только твоя проблема. Сколько ты уже времени на эту ветку потратил?
И>Удачи, продолжать дальше ветку "не о чем" желания нет.
Только тут нашлось немало людей, которые меня поняли.
Подумай об этом.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>А со мной тут куча народа спорит. Говорят, что паттерн всё равно остался.

Имхо, мискоммуникейшн. Потому как спорщики говорят ровно то же самое, что я, только другими словами.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Или там, где нет необходимости вводить дополнительные конструкции в язык. Скажу крамольную вещь: подчас проще оперировать "паттернами", чем конструкциями языками, их реализующими. Связано это с тем, что "паттерн" является, в основном, мысленной конструкцией, и её можно легко адаптировать к реалиям того или иного языка. А вот языковая конструкция, реализующая паттерн — "чудище обло, огромно, стозевно и лаяй": по тем же причинам будет такой разнобой в реализациях, что мало не покажется.
Давайте рассмотрим этот тезис на недавних примерах — паттернах C#. foreach, using, event, property — в других языках все они остаются мысленными конструкциями. Вы не могли бы убедительно продемонстрировать преимущества, которые такой подход даёт этим "другим языкам"?

Здравствуйте, Игoрь, Вы писали:
И>Это не паттерн, а его реализация. Скажу больше, это одна из возможных реализаций Наблюдателя.
Это значительно более специфичная реализация паттерна Наблюдатель. Наблюдатель нам дан в дотнете в готовом виде — механизмом событий, который реализован и в языке и в платформе.
А такой способ реализации INotifyPropertyChanged — это паттерн "свойство с оповещением об изменении".

WH>>И это будет в каждом классе реализующем INotifyPropertyChanged
WH>>И ты будешь это копипастить руками.
WH>>А в немерле я могу реализовать макроаттрибут ImplementINotifyPropertyChanged
WH>>И писать так:
WH>>

WH>>[ImplementINotifyPropertyChanged]
WH>>public class MyClass
WH>>{
WH>>    public MyProp : int { get; set; }
WH>>}
WH>>

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией. Т.е. мы использовали паттерн. Или, если не синтетически, а аналитически, мы можем назвать использованное решение паттерном.
Андрей, прости, но я совершенно не понимаю, почему ты называешь Стратегией банальное отображение D->T[]. Пока что ещё никакого паттерна нет.
Пока что мы говорим об анализе предметной области и видим, что
а) для каждого документа можно определить список хозопераций, которые необходимо провести в рамках "проведения" документа
б) список хозопераций для одного и того же документа может быть разным — в зависимости от желания пользователя.
Вот тут, по идее, надо копать дальше, и смотреть, чем эти желания пользователя ограничены — только ли его фантазией, или действующим законодательством, или списком возможных вариантов, специфицированных другим пользователем.

А паттерн Стратегия появится у нас (возможно) только в тот момент, когда мы начнём дизайнить классы. Если, конечно, мы работаем на традиционном современном ООЯ.

Здравствуйте, AlexCab, Вы писали:
AC>1)При таком подходе со временем DSL превращается в свалку фичь.
AC>2)Поверх него наслаиваются новые DSL.
AC>3)Наступает момент когда надо добавить новую фичу, а не получается(например конфликтует с ранее добавлеными), и возникает необходимость рефракторить DSL.
AC>И теперь внимание вопрос: Насколько дороже обойдётся рефакторинг такого DSL(особенно если по верх него ещё 10)по сравнению с спроектированным? По сравнению с библиотекой?
Даже не будучи Волкодавом, могу ответить: конечно же рефакторинг такого DSL обойдётся в разы дешевле.
Вот смотри: допустим, мы придумали библиотечное решение с INotifyPropertyChanged. У нас там был евент, в котором предполагалось передавать имя свойства.
Все сидели и педалили совершенно однообразный код методов set в пропертях. Спустя годы, у нас этого кода — мегабайты.
И вдруг мы поняли, что с именами свойств у нас дупа, т.к. бывают ситуации, когда класс реализует два интерфейса, где случайно есть одноимённые свойства. Есть желание заменить OnPropertyChanged(string) на OnPropertyChanged(PropertyInfo).
Даже если у нас вдруг есть волшебный инструмент рефакторинга с искусственным интеллектом, который автоматом сделает замену во всех мегабайтах кода, у нас прекрасный день — обновление, которое затрагивает 99% файлов в проекте. Велкам ту фулл регрешшн тестинг.
В принципе, я могу себе представить реализацию такого автомата (а опытные камрады, наверное, могут и навертеть его из имеющихся коробочных тулзов).
Но это ещё не всё.

Если мы вдруг выяснили, что нам по соображениям эффективности надо запретить репортить изменения, если устанавливается то же значение, что и было, то инструмента, позволяющего нам добавить в код if(value!= __innerField), в природе не существует. Как и инструмента, способного статически проверифицировать, что мы выполнили замену повсеместно.

А в DSL мы просто меняем 1 строчку в 1 месте макропроцессора и весь код, все его 100%, подвергаются изменению. Перетестировать их не надо — достаточно перетестировать макрос.

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

Поэтому ваш аргумент №3 — ровно в пользу DSL.

Здравствуйте, Sinclair, Вы писали:

WH>>А со мной тут куча народа спорит. Говорят, что паттерн всё равно остался.

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

WH>>public class MyClass
WH>>{
WH>> public MyProp : int { get; set; }
WH>>}
WH>>[/nemerle]
И>А это реализация того же самого паттерна, но на другом языке.

WH>>ДСЛ это когда
WH>>assert a == b;

I>Внезапно — это уже паттерн, ага , только минимум копипасты

WH>>Вот тебе обычный такой паттерн.
WH>>Встречается в определённом классе задач при решении на C#
WH>>
WH>>    private int _MyProp;
WH>>    public int MyProp
WH>>    {
WH>>        get { retunr _MyProp; }
WH>>        set
WH>>        {
WH>>            if (value != _MyProp)
WH>>            {
WH>>                _MyProp = value;
WH>>                OnPropertyChanged("MyProp");
WH>>            }
WH>>        }
WH>>    }
WH>>
WH>>Узнается легко.
WH>>Встречается десятками и сотнями в одной программе.
AC>1)Это не паттерн проектирования, ПП выглядит примерно так:
AC>
AC>2)Это вообще не паттерн это частный случай реализации.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:
WH>>>А со мной тут куча народа спорит. Говорят, что паттерн всё равно остался.

S>>Имхо, мискоммуникейшн. Потому как спорщики говорят ровно то же самое, что я, только другими словами.
WH>А мне почему-то кажется, что они постоянно утверждают, что паттерн никуда не девается, если его убрать макросом.
Ну, наверное это оттого, что сложно проследить всю мысль сразу.
Если посмотреть на современный "постмодернистский" ландшафт программирования, то мы увидим целую цепочку паттернов.
Скажем, тот же твой нотификатор об изменениях — это паттерн "событие" с паттерном "свойство". Событие у нас является реализацией паттерна Наблюдатель с определёнными доп. соглашениями. Наблюдатель и Свойство построены на паттерне "экземплярный метод", который в свою очередь построен на паттерне "вызов реентерабельного метода". Этот вызов, в свою очередь, построен на паттерне "стек", собранном из концепций "регистр" и "относительная адресация".

Каждый из этих элементов конструкции являлся бы паттерном в системе, где нет возможности компактно его записать.
Но с точки зрения пользователя конструкции промежуточные паттерны совершенно неинтересны. Вот у нас есть свойство, которое мы разметили [Notyfiable], и всё. Разработчику все эти внутренние поля, подписки/отписки совершенно неинтересны. Он скормил коллекцию размеченных объектов в визуальный компонент, и всё. Он знает, что для успеха надо правильно разметить свойства, и этого достаточно.
Мы завтра заменим реализацию, и не будет там внутри никаких "вызовов экземплярных методов", а будут прямые обращения к SQL и показ значений полей.
В этом смысле "паттерн" исчезает. Остаётся семантика.

Для меня паттерн — это некий особенный способ собрать воедино несколько "штук" из набора моих кубиков. Если у меня вместо этого способа есть готовый кубик, то никакого "паттерна" уже нет. То, что он был когда-то применён, не более интересно, чем информация о том, был ли отлит предмет интерьера, отштампован, или склеен из пяти других.
Нам уже не нужно отвлекать на это своё внимание. Можно просто писать код.

Здравствуйте, Sinclair, Вы писали:

S>Андрей, прости, но я совершенно не понимаю, почему ты называешь Стратегией банальное отображение D->T[].

Потому что могие паттерны отличаются не столько конкретной реализацией, сколько теми целями, которым они служат. Конкретно стратегия это не банальное отображение D->T[], а возможность выбирать конкретный способ этого отображения в зависимости от каких то данных.

S>Пока что мы говорим об анализе предметной области и видим, что

Мы говорим не об анализе, а о проектировании.

S>А паттерн Стратегия появится у нас (возможно) только в тот момент, когда мы начнём дизайнить классы.

В данном случае он появится на уровне выше дизайна классов, еще в крупноблочном дизайне. А на уровне классов появится сущность куда более сложная, чем просто D->T[], потому что процесс этого преобразования нужно подготовить и для этого нужны дополнительные данные и метаданные. Но принцип, положенный в основу стратегии, при этом никуда не девается. Другими словами, код реализации паттерна может быть каким угодно, не шаблонным, лишь бы основной принцип соблюдался.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>Она уходит в язык.

Продемонстрируй, как архитектура уходит в язык.

WH>Ты тут сам говоришь об отображении архитектуры на язык.
WH>Но сам же с этим споришь.
WH>Я тебя совсем не понимаю.

Это я тебя не понимаю. От того что обеспечение calling conversion берет на себя компилятор, вызов метода никуда не девается, он остается вызовом метода.

AVK>>Еще раз внимательно смотри на определение паттерна.
WH>Паттерн это повторяющаяся хрень.

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

WH>>>И про то, что архитектура == ДСЛ ты тоже написал в этом сообщении.
AVK>>Чего? Ссылочку на такое мое утверждение можно?
WH>Это напрямую следует из процитированного выше абзаца.

Нет, не следует.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>http://nemerle.org/wiki/index.php?title=Design_patterns
WH>Там наглядна видна копипаста которую порождают паттерны.
WH>И как она исчезает. При использовании макроса.

В итоге паттерн перекочевал в макры фремворка. В ООП он переходит в классы фремворка. В ФП он переходит в функции фремворка. Вероятно эта глубокая разница тебя и смущает ?

И>>Повторение есть на уровне "задача-решение". То, что у тебя в коде могут встречаться похожие куски — это еще не делает эти куски кода паттерном.
WH>Это именно что сделает это паттерном.

Ни в коем случае: " It is a description or template for how to solve a problem that can be used in many different situations."

WH>Просто по определению паттерна.

Паттерны это про решение, а не про реализацию решения в коде.

И>>Читай до просветления:
WH>Лучше ты сходи почитай определение слово паттерн.

Ты сам то прочти. В толковом словаре немного не то, что вкладывают в это определение авторы книг по паттернам

Здравствуйте, WolfHound, Вы писали:

WH>А в немерле я могу реализовать макроаттрибут ImplementINotifyPropertyChanged
WH>И писать так:
WH>

WH>[ImplementINotifyPropertyChanged]
WH>public class MyClass
WH>{
WH>    public MyProp : int { get; set; }
WH>}
WH>

WH>Вот это я называю паттернами и борьбой с ними.

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

Здравствуйте, AndrewVK, Вы писали:
AVK>Потому что могие паттерны отличаются не столько конкретной реализацией, сколько теми целями, которым они служат. Конкретно стратегия это не банальное отображение D->T[], а возможность выбирать конкретный способ этого отображения в зависимости от каких то данных.
Пока что я вижу только требование "возможность выбирать конкретный способ этого отображения в зависимости от каких то данных".
Где тут дизайн? Какие другие варианты могли бы быть у нас с этим дизайном?
Будет ли у нас применяться подобное же решение в других ситуациях? Или это просто "решение по месту"?

Здравствуйте, WolfHound, Вы писали:

I>>Эти сказки я уже слышу много лет. Еще в начале лета или весны ты рассказывал басни про увеличение продуктивности в 100-1000 раз, правда так и не рассказал, как же это ты вычислил и на чем это можно проверить.
WH>Рассказал. Но ты демонстративно проигнорировал.

Я спрашивал про то, откуда взялись цифры, на это ты ничего не ответил ни тогда, ни сейчас.

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

Ожидаю, что джетбрейнс станет нумер1 в своей области. Если нет — немерле и дсл можно выкидывать в топку как академические бредни.
WH>Он и так номер 1.

Это мягко говоря неправда. Только пару продуктов стали лидирующими в своей нише.

I>>Тебе показать, как вычищаются обращения к UI из кода где выкачиваются данные из БД ?
WH>

WH>Или вот ещё ацкий трэш — у нас некоторые исключения имели помимо важности ещё свойство Color, которым (ааа111!!!) их надо было подсвечивать в GUI. Выставлялось это свойство автоматом, исходя из того в каком классе, в процессе работы над какой задачей, случился throw. Почему такое нарушение принципов вообще оказалось возможно — а потому что оно не выставлялось вручную вообще нигде. Т.е. GUI код просто использовал это свойство, и ему по-барабану как оно возникло, а программист который исключение кидал — даже не знал про какое-то там свойство, и его не выставлял. Соотвественно если бы мы решили эту хрень заменить, или вообще убрать — надо было бы менять только одно место, а значит принципы правильного разделения BL и GUI можно слать в конкретно этом случае лесом.

Я такое делал безо всякого немерле

Здравствуйте, Sinclair, Вы писали:

S>Где тут дизайн?

Дизайн там, где мы для реализации этой возможнгости выбрали стартегию.

S> Какие другие варианты могли бы быть у нас с этим дизайном?

При чем тут другие варианты? Напоминаю определение паттерна — "formal way of documenting a solution to a design problem".

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, 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>>

Здравствуйте, 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>>

Здравствуйте, 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>>

Здравствуйте, Sinclair, Вы писали:

S>Потому что пока что это звучит так, что любое ветвление в алгоритме, сформулировнном в самых общих терминах (виртуальной машины или частично-рекурсивных функций) подходит в качестве Стратегии.
Ты начинаешь понимать предмет спора.

Наши оппоненты уверены, что паттерны это что-то данное свыше.
Что-то абсолютное, что не может быть устранено ничем и никак.

Но то, что я понял, что люди так думают это само по себе очень ценное наблюдение из данной дискуссии.
Я буду учитывать данный паттерн мышления в будущем.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, 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.
Как-бы ничего не мешает использовать этот паттерн передачи аргументов в высокоуровневом ЯП: определить глобальную коллекцию-стек, помещать туда аргументы, а функцию/процедуру вызывать без аргументов.

PS: Анти-паттерн

Здравствуйте, 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>>

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Продемонстрируй, как архитектура уходит в язык.
WH>>1)Язык и архитектура связаны один к одному.
AVK>Связаны, да. Но связаны не значит архитектура=паттерн.
Ты, похоже, вообще не читаешь, на что отвечаешь. И тебе совершенно всё равно, что ты отвечаешь.
Вот сейчас ты на ровном месте перескочил с языка на паттерны.

AVK>Кузов авто и мотор связаны один-к-одному, но мотор кузовом не является.
Это вообще фееричная демагогия на ровном месте. Особо доставляет то, что она просто не корректна сама по себе. Просто по тому, что кузов с двигателем один к одному не связаны.

WH>>2)Если поднять уровень языка и архитектуры, то паттерны начинают исчезать.
AVK>Да. Некоторые, в основном на очень низком уровне.
Если исчезли не все, значит нужно продолжать поднимать уровень языка, пока не исчезнут все.

AVK>Только это никоим образом не означает, что архитектура куда то исчезает.
Она не исчезает.
Она становится языком.
Сколько десятков раз нужно это повторить, чтобы ты перестал спрашивать, куда исчезла архитектура?
Ну, в самом деле. Попытайся ради разнообразия представить, что ты что-то не так понимаешь.
Я свои представления постоянно проверяю на прочность. И меняю их, если они не верны.
Раньше я тоже думал, что паттерны это что-то хорошее. Но теперь понял, что это просто красивое название для копипасты которую нельзя устранить из-за слабости языка.

AVK> Исчезают языково-ориентированные паттерны, это нормально и даже хорошо.
Все паттерны "языково-ориентированные" просто по тому, что их нашли глядя на то, как повторяется один и тот же код.
Ты никогда не найдешь зиппер в коде на яве и никогда не найдешь визитер в коде на хаскеле.

AVK>Но проблемно-ориентированные паттерны никуда не деваются.
А их вообще не существует.

AVK>И уж тем более я совершеннол не понимаю, что это за DSL такой, в котором исчезают прикладные сущности и связи между ними.
Где я такое говорил?
Я всегда говорил прямо противоположное.
Все сущности предметной области переезжают в ДСЛ и там прекрасно живут.

AVK>Из прикладного уровня да, исчезает. Я с самого начала писал — трактовать вызов метода как паттерн в подавляющем большинстве случаев не нужно.
Вызов метода является паттерном только в ассемблере. Где вызова метода нет. Есть только низкоуровневые конструкции, из которых собирают вызов метода.
И все паттерны такие.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AlexCab, Вы писали:

AC>Это, я так понял измение в интерфейсе библиотеки. Да они дорого обходятся. Но тоже справедливо и для DSL, если нам прийдётся менять синтаксис(котороый интерфейс DSL) нужно будет править весь написаный на нём пользователями код.
Это правда. Но!
1)Кода будет на порядок меньше.
2)Большинство изменений в интерфейсе библиотеки связаны с изменением реализации. В случае с ДСЛ таких изменений просто не будет. Ибо реализацию можно менять как, угодно не трогая синтаксис и семантику ДСЛ.

AC>А если поверх первого есть второй DSL то ещё и править его транслятор(чтобы он генерил код с исправленым синтаксисам).
Ну, это совсем дешево.
Ибо трансляторы очень маленькие.
И править там придется несколько строк.

AC>Мне чертовски сложно представить код которой не нужно тестировать после изменений в его компиляторе.
Тут немного не так.
Убедившись, что у тебя всё правильно работает в одном месте, ты можешь быть уверенным, что у тебя ничего не сломается в оставшихся 10000 местах.
Автотесты билдсервер всё равно прогонит. Но с вероятности 99.999% тебе ничего чинить не придется.

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

AC>2)генерированый код будет монолитным и не читабльным.
И что? Его всё равно никто не читает.
За то его можно сделать очень эффективным.

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

А пользователям моего ДСЛ на это вообще наплевать. Ибо они этот код никогда не увидят.
Если конечно декомпилятором сборку не откроют.

AC>Из чего следует:
AC>1)отладка/тестирование транслятора — занятие не для слабонервных,
Это намного проще, чем кажется. Уж поверь тому, кто эти трансляторы не первый год пишет.

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

AC>2)проблеммы с взаимо-интеграцией DSL'ей(и по вертикали, и по горизонтали),
Чего?

AC>3)"разбухание" генерированного кода(в особо запущенных случаях можно 1-1000 достичь(о которых WolfHound пишет

)).
Так на обычном языке ты этот разбухший код будешь писать руками. Только в 1000 раз дольше. И в 1000000 раз дольше баги вылавливать.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

AC>>1)по макроссам сложно составить полное и ясное представление что за код будет сгенерирован,
WH>Не нужно.
WH>Тебя же не напрягает то что современные оптимизирующие компиляторы переписывают код так что на оригинал он становится ну совсем не похож.
Это потому что я не занимаюсь их отладкой/тестированием.
AC>>2)генерированый код будет монолитным и не читабльным.
WH>И что? Его всё равно никто не читает.
WH>За то его можно сделать очень эффективным.
Не читая?
А если у пользователя DSL возникнет необходимость посмотреть как оно работает?
WH>А пользователям моего ДСЛ на это вообще наплевать. Ибо они этот код никогда не увидят.
WH>Если конечно декомпилятором сборку не откроют.
А если у пользователя возникнут проблемы со сборкой он будет должен обратится к тебе?
WH>Трудно придумать, как переписать код в язык уровнем ниже. Но после того как придумал тараканы вылавливаются на раз.
Ооо, так всё-таки дизайн и разработка нужны

AC>>2)проблеммы с взаимо-интеграцией DSL'ей(и по вертикали, и по горизонтали),
WH>Чего?
По вертикали это когда один DSL транслятор генерирует код для второго(более низкоуровневого), а тот для третьего и т.д.
По горизонтали это когда несколько DSL трансляторов одновременно генерируют код для одного(более низкоуровневого).
AC>>3)"разбухание" генерированного кода(в особо запущенных случаях можно 1-1000 достичь(о которых WolfHound пишет

)).
WH>Так на обычном языке ты этот разбухший код будешь писать руками. Только в 1000 раз дольше. И в 1000000 раз дольше баги вылавливать.
Не, я о том что если ручное решение, например занимает 100 строк, а DSL транслятор выдаёт 200(на одном и том же ЯП), то это уже очень плохо, не говоря уж о в разы.

Здравствуйте, AlexCab, Вы писали:

AC>Это потому что я не занимаюсь их отладкой/тестированием.
Поэтому ты и боишься.
Если бы занимался, то было бы не страшно.

AC>А если у пользователя DSL возникнет необходимость посмотреть как оно работает?
Зачем? Часто ты смотришь ассемблерный код, который получается из твоего кода?

AC>А если у пользователя возникнут проблемы со сборкой он будет должен обратится к тебе?
Это вроде обычная практика долбить того чей код не работает.
Или я чего не понимаю?

Ну а если таки приспичило, то пусть разбирается, что же там не работает.
Это проще чем ты думаешь.

WH>>Трудно придумать, как переписать код в язык уровнем ниже. Но после того как придумал тараканы вылавливаются на раз.
AC>Ооо, так всё-таки дизайн и разработка нужны

Я уже задолбался говорить, что ДСЛ == архитектура.
Ессно его нужно дизайнить и разрабатывать.

А вот код на ДСЛ уже дизайнить не нужно.
Весь дизайн уже сделан при разработке ДСЛ.
Нужно просто решать задачу.

AC>>>2)проблеммы с взаимо-интеграцией DSL'ей(и по вертикали, и по горизонтали),
WH>>Чего?
AC>По вертикали это когда один DSL транслятор генерирует код для второго(более низкоуровневого), а тот для третьего и т.д.
Это штатный режим работы. Никаких проблем тут нет.

AC>По горизонтали это когда несколько DSL трансляторов одновременно генерируют код для одного(более низкоуровневого).
И это тоже штатный режим работы. И тут тоже нет проблем.

AC>Не, я о том что если ручное решение, например занимает 100 строк, а DSL транслятор выдаёт 200(на одном и том же ЯП), то это уже очень плохо, не говоря уж о в разы.
А с чего оно будет выдавать больше?
ДСЛ генерирует то, что ты ему скажешь.
Если ты сделаешь генератор, который будет генерировать код, который ты пишешь руками он его и будет генерировать.
Более того первая версия генератора обычно так и пишется.
На этом ты можешь и остановиться.

Но дальше обычно результат работы генератора оптимизируют по скорости. И вот тут уже кода может быть больше.
Но если он намного быстрее то это не плохо, а хорошо.
Это одно из убойных преимуществ ДСЛ. Мы пишем красивый код. И получаем очень быстрый результат. Не только без всяких abstraction penalty. Но еще и с предметно ориентированными оптимизациями, которые обычный компилятор сделать никогда не сможет.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>Только тут нашлось немало людей, которые меня поняли.
WH>Подумай об этом.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Или там, где нет необходимости вводить дополнительные конструкции в язык. Скажу крамольную вещь: подчас проще оперировать "паттернами", чем конструкциями языками, их реализующими. Связано это с тем, что "паттерн" является, в основном, мысленной конструкцией, и её можно легко адаптировать к реалиям того или иного языка. А вот языковая конструкция, реализующая паттерн — "чудище обло, огромно, стозевно и лаяй": по тем же причинам будет такой разнобой в реализациях, что мало не покажется.
S>Давайте рассмотрим этот тезис на недавних примерах — паттернах C#. foreach, using, event, property — в других языках все они остаются мысленными конструкциями. Вы не могли бы убедительно продемонстрировать преимущества, которые такой подход даёт этим "другим языкам"?

Например, для предложенных тобой случаев — слёту не продемонстрирую. А вот, например, в том случае, который описал WolfHound с моей точки зрения, оперировать исходной реализацией IPropertyNotifyChanged гораздо легче, чем макросом — реализация "в лоб" попросту не вызывает никаких вопросов. А по отношению к макросу первый же вопрос: каково имя переменной-члена объекта, в котором сохранено значение свойства? Не упрятано ли оно куда? Выполняется ли синхронизация при вызове callback-а, и если да, то где?

AC>>Это потому что я не занимаюсь их отладкой/тестированием.
WH>Поэтому ты и боишься.
WH>Если бы занимался, то было бы не страшно.
Я занимался, потому и боюсь

Но, правда без DSL'ей и МП.
AC>>А если у пользователя DSL возникнет необходимость посмотреть как оно работает?
WH>Зачем? Часто ты смотришь ассемблерный код, который получается из твоего кода?
Я часто заглядываю в библиотеки, даже в свои.
AC>>По вертикали это когда один DSL транслятор генерирует код для второго(более низкоуровневого), а тот для третьего и т.д.
WH>Это штатный режим работы. Никаких проблем тут нет.
AC>>По горизонтали это когда несколько DSL трансляторов одновременно генерируют код для одного(более низкоуровневого).
WH>И это тоже штатный режим работы. И тут тоже нет проблем.
В смысле "штатный", разработчик DSL'я к этому усилий не прилогает?
WH>Это одно из убойных преимуществ ДСЛ. Мы пишем красивый код. И получаем очень быстрый результат. Не только без всяких abstraction penalty. Но еще и с предметно ориентированными оптимизациями, которые обычный компилятор сделать никогда не сможет.
Тут тоже не всё так просто:
1)Оптимизация по быстродействию упирается в быстродействие платформы под которую генерит код DSL(будь то .NET или другой DSL). Во первых, ты же не можешь, например просто взять и перенести приложение с .NET на натив или выкинуть слой DSL'ей, из-за зависимостей в верхних слоях кода. Во вторых, если DSL'и будут в несколько уровней, и каждый из них будет вносить свой вклад в замедление кода, то в итоге может получится что abstraction penalty более быстрое решение, а усилия на оптимизацию генерированного кода(на допиливание транслятора) были потрачены зря.
2)Для разработка/отладка/тестирование оптимизирующего транслятора нужны не слабые познания в дзене. То ли дело, переписать на Си несколько критических функций.

Здравствуйте, AlexCab, Вы писали:

WH>>Зачем? Часто ты смотришь ассемблерный код, который получается из твоего кода?
AC>Я часто заглядываю в библиотеки, даже в свои.
Ну и заглядывай в сам ДСЛ. А не в тот код, который он генерирует.

WH>>И это тоже штатный режим работы. И тут тоже нет проблем.
AC>В смысле "штатный", разработчик DSL'я к этому усилий не прилогает?
Посмотри на немерле.
Там куча макросов, которые друг о друге ничего не знают.
И прекрасно вместе работают.

AC>Тут тоже не всё так просто:
AC>1)Оптимизация по быстродействию упирается в быстродействие платформы под которую генерит код DSL(будь то .NET или другой DSL).
Но это не значит, что под одну и ту же платформу нельзя написать код, производительность которого различается на порядки.

AC>Во первых, ты же не можешь, например просто взять и перенести приложение с .NET на натив
Если код на ДСЛ который о .НЕТ ничего не знает то могу.
Более того это будет штатный режим работы Н2.

AC>или выкинуть слой DSL'ей, из-за зависимостей в верхних слоях кода.
Чего?

AC>Во вторых, если DSL'и будут в несколько уровней, и каждый из них будет вносить свой вклад в замедление кода, то в итоге может получится что abstraction penalty более быстрое решение, а усилия на оптимизацию генерированного кода(на допиливание транслятора) были потрачены зря.
Тут все с точностью до наоборот.
Каждый слой ДСЛ будет вносить свой вклад в разгон кода.
Это практика.

В любом случае если один из промежуточных ДСЛ мешает его всегда можно выкинуть и генерировать язык более низкого уровня. Это конечно сложнее но если оно того стоит то почему бы и нет?
При этом код на исходном ДСЛ не изменится ни на букву. Но результирующая программа будет работать быстрее.

AC>2)Для разработка/отладка/тестирование оптимизирующего транслятора нужны не слабые познания в дзене. То ли дело, переписать на Си несколько критических функций.
Никаких особых познаний не нужно.
Там всё просто.

А переписать пару критических функций на С не смешите мои тапочки.
Скомпилируй https://github.com/rampelstinskin/ParserGenerator/
И декомпилируй N2.Grammar.dll
После чего подумай, чего тебе будет стоить переписать это на С.
А я сейчас делаю еще более циничный кодогенератор. С которым ты и на С гоняться вспотеешь.
Но и это не последняя из запланированных оптимизаций. Дальше будет еще быстрее.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Sinclair, Вы писали:

WH>>А со мной тут куча народа спорит. Говорят, что паттерн всё равно остался.

S>Имхо, мискоммуникейшн. Потому как спорщики говорят ровно то же самое, что я, только другими словами.

Ты лучше скажи, ты тоже считаешь, что DSL заменяет необходимость создания архитектуры прикладного решения?

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Ты лучше скажи, ты тоже считаешь, что DSL заменяет необходимость создания архитектуры прикладного решения?
Пятисотый раз повторяю: Создание архитектуры и создание ДСЛ это один процесс.
Отличие лишь в том, что тебе не нужно насиловать модель предметной области так чтобы она натянулась на язык. Ибо язык создается одновременно с моделью предметной области так чтобы один к одному отображать все сущности и взаимодействия предметной области.

При этом при написании кода на ДСЛ архитектурить уже не нужно. Нужно просто описывать сущности и взаимодействия.
Если не веришь, попробуй найти тут архитектуру.
Тут просто решена задача, как она есть.
Вся архитектура осталась в коде, который реализует ДСЛ.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>При этом при написании кода на ДСЛ архитектурить уже не нужно. Нужно просто описывать сущности и взаимодействия.

Попробуй еще раз перечитать определение архитектуры программы.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

AVK>>Попробуй еще раз перечитать определение архитектуры программы.
WH>Дай ссылку на правильное с твоей точки зрения определение архитектуры.

http://en.wikipedia.org/wiki/Software_architecture

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

AC>>Я часто заглядываю в библиотеки, даже в свои.
WH>Ну и заглядывай в сам ДСЛ. А не в тот код, который он генерирует.
Как пользователь, что я там пойму?
WH>Посмотри на немерле.
WH>Там куча макросов, которые друг о друге ничего не знают.
WH>И прекрасно вместе работают.
Nemerle это один, хоть и расширяемый ЯП, для одной платформы, а представь их 100+(бывают же проекты с таким количеством библиотек) генерящих разный код.
AC>>или выкинуть слой DSL'ей, из-за зависимостей в верхних слоях кода.
WH>Чего?
Например, с помощью N2, некая компания реализовала транслятор C#(для совместимости с ранее написанным) генерящий CIL, поверх С# реализовали несколько DSL.
Время шло, библиотеки менялись на DSL'и, в конце-концов их осталось всего нечего, и в чью-то голову пришла мысль "а давайте выкинем C#, а DSL'и пусть компилятся сразу в CIL".
Насколько им это будет тяжело сделать?
WH>А переписать пару критических функций на С не смешите мои тапочки.
WH>Скомпилируй https://github.com/rampelstinskin/ParserGenerator/
Я побродил там, нашел сотни незнакомого мне кода и несколько не понятных комментариев, ничего не понял. Я так понимаю архитектурной документации(диаграмм особенно(особенно с паттернами),описаний) у вас нету?
WH>После чего подумай, чего тебе будет стоить переписать это на С.
Так что не могу оценить объём критического кода.

Здравствуйте, AlexCab, Вы писали:

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

На это и рассчитано.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, Nuseraro, Вы писали:

N>Надо где-нибудь похоливарить на эту тему, но лучше не тут

А что же не тут? Тема интересная!

Здравствуйте, Игoрь, Вы писали:

И>Где борьба то? Паттерн как был, так и остался. Чем характеризуется паттерн? Задачей и ее решением. Причем, решение — это не конкретная реализация, а обобщенное описание решения. И что же поменялось? Да ничего, ты просто спрятал под капот небольшую часть ручной работы, даже интерфейс остался без изменений.

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

Другими словами ты не в силах сократить ручной труд до минимум.

Тут возникает очень интересные вопросы. А каков он, этот минимум? Можно ли его вычислить? Да и существует ли он вообще?

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

ДСЛ-и и являются такими краткими решениями.

Вот оно счастье! Казалось бы золотой ключик у нас в кармане! Но не все так просто. Проблема в том, что современными средствами ДСЛ-и создавать очень трудно. Еще труднее обеспечить их гибкость, высокую эффективность и надежность функционирования.

Если сделать нечто позволяющее упростить материализацию ДСЛ-ей, то эффективность программирования удастся поднять во много раз.

И>PS
И>Складывается ощущение, что ты тупо троллишь.

Он просто любит постучаться лбом в бетонную стену непонимания.

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

Здравствуйте, Игoрь, Вы писали:

И>Я правильно тебя понимаю, что твое знакомство с паттернами ограничивается каринками в гугле? Причем искал ты не по software design patterns, а просто по patterns? Это объясняет...
И>Давай кроме картинок еще и боковки почитаем.

Обожаю когда люди таким надменным менторским тоном учат окружающих!

Пошел за попкорном...

Здравствуйте, Ikemefula, Вы писали:

I>В итоге паттерн перекочевал в макры фремворка.

Можно и так сказать. А можно сказать, что реализация паттерннов автоматизированна макросами.

I>В ООП он переходит в классы фремворка. В ФП он переходит в функции фремворка. Вероятно эта глубокая разница тебя и смущает ?

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

Интересно, что иногда то что является паттерном на одном языке просто веселит пользователей другого языка. Например, паттерн "Команад" очень веселит тех кто программирует на языках поддерживающих ФП (в частности ФВП и лямбды в частности).

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

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

Здравствуйте, Ikemefula, Вы писали:

I>В итоге ты устранил дублирование кода а реализация паттерна перекочевала в макры. Вероятно, все что ты хочешь сказать это "паттерны должны лежать не в том месте..."

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

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

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

Здравствуйте, Ikemefula, Вы писали:

I>Передергиваешь в очередной раз. С чего ты взял что текстовые заведомо лучше графических ?

Не важно. Важно, что ты таки принял точку зрения, что для решения сложных задач ДСЛ-и подходят куда лучше чем ЯОН-ы.

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

Вот хорошая область — разговоры в форумах. Очень много времени на них уходит. Как жаль, что для этого не придумали качественных графических ДСЛ-е. Приходится по старинке использовать текст.

Здравствуйте, WolfHound, Вы писали:

AVK>>Бизнес-логику, разумеется. Ты же не думаешь что реальная бизнес логика это как в игрушечных примерах, простенький алгоритм с минимумом входных и выходных параметров?
WH>И что же там проектировать то?
WH>Ты надеюсь, сбор требований с проектированием не путаешь?

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

Здравствуйте, WolfHound, Вы писали:

WH>Вызов метода не паттерн.
WH>Ибо иначе у нас вообще все становится паттерном. И весь разговор теряет смысл.

Я рад что ты это понимаешь. Вот та же фигня с ДСЛ-ями. Если все назвать ДСЛ-ями, то использование этого термина так же теряет смысл.

Здравствуйте, AndrewVK, Вы писали:

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

До суда все понятно. Ну, разве что ХО я бы проводкой назвал. Так привычнее.

AVK>Обрати внимание, я ни слова не сказал про языки программирования и какой либо код.

Ага.

AVK>Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией.

Мать моя женщина! Так вот как оно умно называется! Едрит Модрид!

А ~~мужики~~ бабы (из бухгалтерии) и не знают поди!

Ну, а если серьезно, то вот он момент когда ты наплевав на безнес-логику начинаешь натягивать ~~презерватив на глобус~~ предметную область на свой любимый C#. А ведь в предметной области есть только банальное отображение одного представления (в виде документа) на другое (в виде набора проводок). Какая на фиг стратегия?!

Скажу больше. Твои слова "документ" и "ХО" уже говорят о том, что ты оперируешь не предметной областью, аз знакомым тебе алгоритмом (подходом). В нем у тебя первичны документы, а ХО генерируются по ним. Но по жизни есть данные, и только данные. И документ, ХО и прочая мутатень ни что иное как их представление в твоем решении.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Не обязательно. И, главное, паттерн Стратегия ничего подобного не диктует. Ты сам обвешиваешь паттерны каким то лишним для них смыслом, и потом сам себя и опровергаешь. Тебе уже несколько человек по нескольку раз повторили — паттерн это не шаблонный код, это шаблонный элемент дизайна. Если возможности языка позволяют реализацию паттерна написать один раз — отлично. Но паттерна это никоим образом не отменяет. Например, от того что в шарпе есть ключевое слово event паттерн Publisher-Subscriber никуда не девается, его просто не надо описывать многословно.

Проблема в том, что ты под словом "паттерн" понимаешь не сам паттерн, а стоящее за ним поняитие. Человек, несомненно, оперирует понятиями. Но чтобы превратить понятия в исполняемый код и нужны паттерны. И вот тут настает реальная беда, так как большинство понятий нихрнена нельзя запихать в библиотеки.

Ты можешь за вечер напроектировать столько, сколько не сделаешь за целый год. Вот это проблема! Меж тем твой проект — это вполне себе готовое решение. В нем не хватает только реализации и контроля корректности.

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

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

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

В общем-то это и есть то к чему мы стремимся.

Здравствуйте, AndrewVK, Вы писали:

AVK>Конкретно стратегия это не банальное отображение D->T[], а возможность выбирать конкретный способ этого отображения в зависимости от каких то данных.

О! У меня есть офигительная стратегия! Вот она:

foo(x)

в зависимости от переданных в нее данных возвращает требуемое отображение.

А еще вот такое есть:

switch (x)
{
  ...

Здравствуйте, AndrewVK, Вы писали:

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.

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

Здравствуйте, 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>>

Здравствуйте, VladD2, Вы писали:

VD>Причем это занятие (битье головой о стену не понимания и незнания) отнимает у него время которое он мог бы потратить на крайне полезное дело — на найтру. По сему я призываю его бросить это неблагодарное занятие и заняться делом. Нас ждут великие дела

.
Ты категорически не прав. Я узнал много интересного о психологии людей.
Так что эта тема не напрасна.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, 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>>

Здравствуйте, 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>>

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, __kot2, Вы писали:

__>>неправильно пишется
WH>Знаешь, почему на РСДН запрещено придираться к орфографии?
WH>Правильно. По тому, что слившим товарищам не остается ничего другого.

Мне кажится, все были бы счастлевы, если бы было заприщено орфографию нарушать. Не к чему было бы придераться. Некаторым всё равно, а некоторым вопеющая неграмотность глаз мозолит. Это бональное неуважение к собеседникам, чего же ожедать в ответ?

WH>А что ты понимаешь глядя в библиотеку?
1)Там тот-же ЯП на котором я пишу, а не другой DSL.
2)Там готовые функции/классы, а не генерирующие макросы.

WH>Придется переписать кодогенерацию. Насколько это сложно зависит от того сколько нужно писать.
WH>Но зачем? Профит где?
Например: упрощение архитектуры, быстродействие, сокращение количества строк кода, меньший объём тестирования etc.

AC>>Я побродил там, нашел сотни незнакомого мне кода и несколько не понятных комментариев, ничего не понял. Я так понимаю архитектурной документации(диаграмм особенно(особенно с паттернами),описаний) у вас нету?
WH>Рука лицо.
WH>Я тут уже сколько раз говорил, что архитектура == язык.
Т.е. чтобы понять как это работает, мне нужно: 1)изучить все/основные используемые там DSL'и(это ведь они?), 2)перечитать сотни кода, по ходу делая кучу заметок(потому что в моей голове столько кода не поместится). Вместо того чтобы бегло просмотреть несколько диаграмм?

WH>Вот язык, написанный на себе.
WH>https://github.com/rampelstinskin/ParserGenerator/blob/8d02b02b76ed08ab9f71a54ca62b5091538e6cf4/N2/N2.Grammar/GrammarParser2.n2
Ещё десятки незнакомого кода. Каким образом написанное там превращается в исполняемый файл?

WH>>>После чего подумай, чего тебе будет стоить переписать это на С.
AC>>Так что не могу оценить объём критического кода.
WH>А там нет ни строчки критического кода.
Зачем мне строчки кода? Мне нужно знать как это работает, из каких частей состоит. Тогда я смогу оценить какие из частей критические, как это можно изменить чтобы эти части было возможно переписать на Си etc.

WH>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
Это ооооочень плохой результат. Подозреваю там сотни спагетти-кода, которые можно относительно(разработки DSL'а это генерирующего) легко заменить алгоритмами. И получатся те-же 190 строк например на питоне + плюс быстрая библиотека на Си.

Здравствуйте, AlexCab, Вы писали:

WH>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>Это ооооочень плохой результат. Подозреваю там сотни спагетти-кода

Естественно там спагетти код. А в чем проблема? Тя ж не коробит, что оптимизирующий компилятор С++ генерит спагетти-код, там почему тебя волнует какой код генерит DSL ??

Здравствуйте, AlexCab, Вы писали:
AC>А вы не делаете? о_О
Нет конечно. Зачем тестировать компилятор?
А UB мы не пользуемся.

AC>И во вторых, я уверен M$ тратит не мало усилий на тестирование компилятора. Вы готовы тратить столько-же(конечно DSL'и будут проще чем C#, но их будет больше)?
Вы поймите, если у вас код размера X, то надо тестировать весь X. Если у вас код размера X порождается компилятором из кода размера x, так что X = R * x, то вам надо тестировать x пользовательского кода плюс код компилятора, размером в Y.
Отсюда получаем неравенство — условие оправданности DSL:
x + Y < X
или
Y < x*(R-1)
Вся идея в том, чтобы заменить произведение суммой.

AC>Линг он один и хорошо документирован(наверно), а DSL'и будут как библиотеки — писаться кем попало и как попало.

AC>Я начинал, и много программировал на ассемблере

Это не объясняет беспокойства по поводу размера кода.
AC>В том-то и беда, это не нужный код, потому как автоматическая оптимизация менее эффективна(если бы было иначе pure C давно бы стал историей).
Сказки. Я неоднократно общался с распальцованными ассемблерщиками.
В реальной жизни они не могут порвать современный компилятор ЯВУ даже в простых сценариях.
В чуть более сложных сценариях всё заканчивается ещё в начале забега. К моменту, когда ассемблерщик вручную закончил рассчитывать constant propagation и loop unfolding, компилятор уже две недели тому назад наколбасил speculative virtual method inlining.

Это мы, конечно, говорим про "взрослые" компиляторы.
Тем не менее, идея остаётся — лучше вложить две недели в отладку алгоритма оптимизации, чем их же в ручную оптимизацию. Которую, к тому же, придётся переписывать, как только поменяются условия задачи.

S>>Мы сократили объём ручной работы и уменьшили шансы сделать ошибку.
AC>И это замечательно, но было-бы ещё лучше если бы мы нашли решение позволяющее: и сократить объём работы, и получить хороший код на выходе.
Какие бы критерии "хорошести" кода вы ни приводили, научить генератор кода им следовать можно. Обычно хотят быстродействие, а во вторую очередь — компактность. "Красоту", которая "понятность", все игнорируют. Посмотрите, во что превращается iterator pattern в C# — там же ужас с goto и switch.
Вручную так никто никогда не пишет. Тем не менее, это подкапотные неинтересные подробности. Интересует красота прикладного кода, где я написал yield return — и оно сйилдило мне ретёрн.

Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, не получается. Задачу я не описывал, я описывал решение. Задача — дать возможность пользователям настраивать механику проводок. Я лично видел целую тучу реализаций подобного в разных системах. Например, пачка параметров по модификации захардкоженного алгоритма проводок. Или вообще единственный способ модификации — изменение 1С-конфигурации и написание кода. Сменяемый пользователем алгоритм формирования ХО как публично видимая сущность — это уже конкретное решение, а не входная задача.
Непонятно. В приведённых трёх случаях разные требования.
В одном случае вообще нет требования выбора разных способов генерации проводок в рантайме.
В другом случае есть один алгоритм с дополнительными параметрами.
В твоём случае есть семейство разных алгоритмов с ручным выбором конкретного.

S>>В таком описании для проектирования достаточно трёх паттернов: Стратегия (она же Policy), Следование (она же Последовательность), и Ничто.
AVK>Поясни мысль.
Поясняю: это базис, из которого можно построить всё остальное. операторы if, приращения, и 0.

S>>А в SQL оно к чему приведёт?
AVK>К таблицам и прочим сущностям sql.
А можно продемонстрировать как-то способ применения паттерна Стратегия в терминах таблиц и прочих сущностей SQL?

AVK>Этот вопрос в топике уже был — на какие нижележащие концепции опирается паттерн Chain of Resposibility? MVC?
На ООП, очевидно. Везде фигурируют объекты, связанные между собой определённым образом, и которым раздаются определённые обязанности.
AVK>Но интереснее другое — как из того, что какой то паттерн опирается на нижележащие концепции следует, что при применении DSL не нужна архитектура? Может хоть ты пояснишь?
При применении DSL код программы совпадает с её архитектурой. Вся идея DSL — избежать разрыва между архитектурой (выраженной в "мысленных конструкциях") и кодом (написанным на далёком от архитектуры языке).
Вот в простых случаях старорежимных консольных С программ нам не нужна была никакая архитектура — придумали функциям имена, параметры, и вызываем их друг из друга. Вся архитектура и есть эти функции.
Если мы начинаем строить какие-то сложные штуки (например, недо-ООП на указателях на функции и структурах указателей) и описывать архитектуру в их терминах, то лучше перейти на язык, где такие штуки есть из коробки.

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

AVK>Это определение я взял из википедии. Оно там давно и вполне устаканено. Так что если у тебя притензии к общепринятым определениями — это не ко мне.

Да, у меня к нему претензии. Пойду писать в претензионный отдел википедии.

Здравствуйте, AlexCab, Вы писали:

WH>>А что ты понимаешь глядя в библиотеку?
AC>1)Там тот-же ЯП на котором я пишу, а не другой DSL.
AC>2)Там готовые функции/классы, а не генерирующие макросы.
И?

WH>>Придется переписать кодогенерацию. Насколько это сложно зависит от того сколько нужно писать.
WH>>Но зачем? Профит где?
AC>Например: упрощение архитектуры, быстродействие, сокращение количества строк кода, меньший объём тестирования etc.
Всё с точностью до наоборот.
Чем больше расстояние между языками, тем сложнее переписывать.

AC>Т.е. чтобы понять как это работает, мне нужно: 1)изучить все/основные используемые там DSL'и(это ведь они?), 2)перечитать сотни кода, по ходу делая кучу заметок(потому что в моей голове столько кода не поместится). Вместо того чтобы бегло просмотреть несколько диаграмм?
Нет. Тебе нужно только изучить ДСЛи.
Это будет быстрее, чем бегло посмотреть несколько диаграмм, ибо объем информации в диаграммах описывающие низкоуровневое решение будет на порядки больше.
Так что ты устанешь диаграммы пролистывать.

AC>Ещё десятки незнакомого кода. Каким образом написанное там превращается в исполняемый файл?
А зачем тебе это знать? Это не нужные знания.
Тебе нужно знать, что код делает. А не в какой машинный код преобразуется.

AC>Зачем мне строчки кода? Мне нужно знать как это работает, из каких частей состоит. Тогда я смогу оценить какие из частей критические, как это можно изменить чтобы эти части было возможно переписать на Си etc.
Там нет ни строчки кода которая будучи переписанной на С разогнала бы результирующую программу.
Я гарантирую это.

WH>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>Это ооооочень плохой результат.
Нет. Это очень хороший результат. Я сократил объем работы на два порядка.

AC>Подозреваю там сотни спагетти-кода, которые можно относительно(разработки DSL'а это генерирующего) легко заменить алгоритмами. И получатся те-же 190 строк например на питоне + плюс быстрая библиотека на Си.
Нельзя. Такой подход приведет к 10-100 кратным тормозам.
А учитывая, что я собираюсь делать оптимизации, которые асимптотику улучшают...

Но ты можешь попробовать. Будешь 100500тым, который потерпит неудачу, встав на этот заведомо тупиковый путь.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, VladD2, Вы писали:

I>>В итоге паттерн перекочевал в макры фремворка.

VD>Можно и так сказать. А можно сказать, что реализация паттерннов автоматизированна макросами.

Паттерн != реализация паттерна.

I>>В ООП он переходит в классы фремворка. В ФП он переходит в функции фремворка. Вероятно эта глубокая разница тебя и смущает ?

VD>Вот это огромное заблуждение. Паттерн на то и паттерн, что он не может перекочевать в библиотеку.

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

VD>Интересно, что иногда то что является паттерном на одном языке просто веселит пользователей другого языка. Например, паттерн "Команад" очень веселит тех кто программирует на языках поддерживающих ФП (в частности ФВП и лямбды в частности).

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

VD>Но это как раз и показывает, что паттерн может быть отлично встроен в язык. Встраивание позволяет забыть о паттерне и оперировать самаим понятием, которое эмулируется паттерном.

Это понятие и есть паттер, а в коде только его реализация.

VD>Например в одном языке есть оператор foreach, а в другом его приходится эмулировать паттерном. Мало кто будет спорить, что языковая конструкция foreach лучше такой эмуляции. Если ты с этим согласен, то подумай почему же в иных случаях ты готов жрать кактус и эмулировать простые понятия сложным нагромождением кода который ты называешь паттерном.

Не я а Wolfhound. Я уже говорил что такое паттерн и почему он появляется еще когда кода нет ни строчки.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Ikemefula, Вы писали:

I>>В итоге ты устранил дублирование кода а реализация паттерна перекочевала в макры. Вероятно, все что ты хочешь сказать это "паттерны должны лежать не в том месте..."

VD>Ага — в библиотеках. Жалко только, что большинство современных языков не способны их туда положить. По сему появляется попипаста и много красивых слов об архитектуре и дизайне.

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

Здравствуйте, VladD2, Вы писали:

I>>Передергиваешь в очередной раз. С чего ты взял что текстовые заведомо лучше графических ?

VD>Не важно. Важно, что ты таки принял точку зрения, что для решения сложных задач ДСЛ-и подходят куда лучше чем ЯОН-ы.

Важно что я этого и не отрицал, вообще говоря, т.к. сам спокойно использую ДСЛ и меня это нисколько не смущает.

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

VD>Вот хорошая область — разговоры в форумах. Очень много времени на них уходит. Как жаль, что для этого не придумали качественных графических ДСЛ-е. Приходится по старинке использовать текст.

Зато давно придумали общение с помощью естетсвнной речи, которая,внезапно!, так же не требует текст.

Здравствуйте, Ikemefula, Вы писали:

I>Ты как то сокрушался на счет качества кода и монолитности компилера Немерле. Продолжай, очень интересно послушать, почему же вам макры не помогли.
По тому что Н1 изначально был написано на языке общего назначения, а не на ДСЛ.
Те там просто не была использована вся мощь макросов.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Зато давно придумали общение с помощью естетсвнной речи, которая,внезапно!, так же не требует текст.
Ну, да... только она один к одному в него переводится... вот в чем прикол.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

AC>>Т.е. чтобы понять как это работает, мне нужно: 1)изучить все/основные используемые там DSL'и(это ведь они?), 2)перечитать сотни кода, по ходу делая кучу заметок(потому что в моей голове столько кода не поместится). Вместо того чтобы бегло просмотреть несколько диаграмм?
WH>Нет. Тебе нужно только изучить ДСЛи.

Я чет смотрю, в 99% случав проще, быстрее, надежнее будет написать мульку заново, чем изучать ДСЛ. Это если не считать internal DSL. С этими просто — залез в метод а посмотрел, что к чему. Раз-два и все понятно.

WH>Это будет быстрее, чем бегло посмотреть несколько диаграмм, ибо объем информации в диаграммах описывающие низкоуровневое решение будет на порядки больше.
WH>Так что ты устанешь диаграммы пролистывать.

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

Здравствуйте, WolfHound, Вы писали:

I>>Зато давно придумали общение с помощью естетсвнной речи, которая,внезапно!, так же не требует текст.
WH>Ну, да... только она один к одному в него переводится... вот в чем прикол.

Не переводится. Текст не передаёт эмоции, интонацию, паузы и тд и тд. Если добавить позы, жесты и тд, то окажется, что 80% информанции передаётся невербально ? Похоже что ты просто не в курсе этого.

Здравствуйте, WolfHound, Вы писали:

I>>Ты как то сокрушался на счет качества кода и монолитности компилера Немерле. Продолжай, очень интересно послушать, почему же вам макры не помогли.
WH>По тому что Н1 изначально был написано на языке общего назначения, а не на ДСЛ.
WH>Те там просто не была использована вся мощь макросов.

Интересно, а почему же есть проекты в которых кода на порядки больше чем в компилере и с ними легко работать, при чем безо всяких макросов ?
Может дело просто в качественном проектировании а не в количестве макросов ?

Здравствуйте, Ikemefula, Вы писали:

I>Я чет смотрю, в 99% случав проще, быстрее, надежнее будет написать мульку заново, чем изучать ДСЛ. Это если не считать internal DSL. С этими просто — залез в метод а посмотрел, что к чему. Раз-два и все понятно.
И куда ты смотришь? В свое воображение?

I>Попробуй предложить хорошую модель поиска решения задачи. Без этого говорить про паттерны и ДСЛ смысла нет, то есть вообще.
Собираешь информацию о предметной области.
Выписываешь все сущности.
Выписываешь их взаимодействия.
Язык из этого получается автоматически.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Я чет смотрю, в 99% случав проще, быстрее, надежнее будет написать мульку заново, чем изучать ДСЛ. Это если не считать internal DSL. С этими просто - залез в метод а посмотрел, что к чему. Раз-два и все понятно.
WH>И куда ты смотришь? В свое воображение?

Я выделил.

I>>Попробуй предложить хорошую модель поиска решения задачи. Без этого говорить про паттерны и ДСЛ смысла нет, то есть вообще.
WH>Собираешь информацию о предметной области.
WH>Выписываешь все сущности.
WH>Выписываешь их взаимодействия.
WH>Язык из этого получается автоматически.

Я просил модель поиска решения задачи, а не построение языка.

Здравствуйте, Jack128, Вы писали:
WH>>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>>Это ооооочень плохой результат. Подозреваю там сотни спагетти-кода
J>Естественно там спагетти код. А в чем проблема? Тя ж не коробит, что оптимизирующий компилятор С++ генерит спагетти-код, там почему тебя волнует какой код генерит DSL ??
То ж ассемблер, а то C#, который развернётся ещё в ~X10 строк.

S>Вы поймите, если у вас код размера X, то надо тестировать весь X. Если у вас код размера X порождается компилятором из кода размера x, так что X = R * x, то вам надо тестировать x пользовательского кода плюс код компилятора, размером в Y.
1)Это утверрждение основано на предположении: Xавтогенерированного = Xручнного. Это предположение верно, по вашему мнению?
S>Отсюда получаем неравенство — условие оправданности DSL:
S>x + Y < X
2)Откуда уверенность что не будет так: x + Y > Xр (особенно если транслятор оптимизирующий)?
3)А теперь расширим условие: x -> x', Y -> Y' Xр -> Xр', производные это цена(дизайна + разработка + реализация + (тестирование + отладка) + сопровождение).
Введём ещё добавочную цену новизны языка Z, это когда: после того как новый язык был разработан отлажен и протестирован, во время работы на нём иногда всплывают разные мелкие жуки(которые приходится либо обходить, либо править ЯП), и когда после обновления версии компилятора (которая хорошо прошла тесты), на реальном коде всплываю разные мелкие(а может и крупные) несовместимости с предыдущей версией.
Итак: x' + Y' + Z [<,=,>] Xр' ?

S>Сказки. Я неоднократно общался с распальцованными ассемблерщиками.
S>В реальной жизни они не могут порвать современный компилятор ЯВУ даже в простых сценариях.
Какие-то у вас слабые ассемблерщики, наверно потому что распальцованые

S>Тем не менее, идея остаётся — лучше вложить две недели в отладку алгоритма оптимизации, чем их же в ручную оптимизацию. Которую, к тому же, придётся переписывать, как только поменяются условия задачи.
Не общались ли вы с разработчиками компиляторов ЯВУ, рвущих ассемблерщеков? Сколько сил и средств затрачивается на разработку таких компиляторов?

WH>>>А что ты понимаешь глядя в библиотеку?
AC>>1)Там тот-же ЯП на котором я пишу, а не другой DSL.
AC>>2)Там готовые функции/классы, а не генерирующие макросы.
WH>И?
И я там вряд ли что-то пойму.
WH>>>Придется переписать кодогенерацию. Насколько это сложно зависит от того сколько нужно писать.
WH>>>Но зачем? Профит где?
AC>>Например: упрощение архитектуры, быстродействие, сокращение количества строк кода, меньший объём тестирования etc.
WH>Всё с точностью до наоборот.
WH>Чем больше расстояние между языками, тем сложнее переписывать.
А не, я понял вопрос как "Но зачем переписать кодогенерацию?"
AC>>Т.е. чтобы понять как это работает, мне нужно: 1)изучить все/основные используемые там DSL'и(это ведь они?), 2)перечитать сотни кода, по ходу делая кучу заметок(потому что в моей голове столько кода не поместится). Вместо того чтобы бегло просмотреть несколько диаграмм?
WH>Нет. Тебе нужно только изучить ДСЛи.
Например, у нас есть DSL для предметной области "Написание сообщения"(для форума), включающий возможности управления кареткой, вставки-удаления текста, и собственно отправки. Как его знание поможет мне понять смысл сообщения написанного при помощи этого DSL?
WH>Это будет быстрее, чем бегло посмотреть несколько диаграмм, ибо объем информации в диаграммах описывающие низкоуровневое решение будет на порядки больше.
Обычно диаграммы не описывают низкоуровневые решения(ну разве-что диаграммы алгоритмов). С пол года назад я писал на Sacala'е небольшое приложение, ~600-700 строк, диаграмма для него сотояла из ~15 кубиков, и показвала что за объекты есть в программе и как они взаимодействуют, не более. А недавно я открыл для себя Визуал парадигм, и(как это было с Солид ворком) подумал "блин как я раньше работал без этого", сейчас переношу туда проект.
AC>>Ещё десятки незнакомого кода. Каким образом написанное там превращается в исполняемый файл?
WH>А зачем тебе это знать? Это не нужные знания.
WH>Тебе нужно знать, что код делает. А не в какой машинный код преобразуется.
Я так понял, этот код как раз делает то — что преобразует себя в машинный код(через посредство других DSL'ей)?
WH>>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>>Это ооооочень плохой результат.
WH>Нет. Это очень хороший результат. Я сократил объем работы на два порядка.
Т.е. ты утверждаешь что автогенерированые 25380 строк на C#, эквиваленты по возможностям/сложности 25380 строкам на C# написанным руками?

Здравствуйте, AlexCab, Вы писали:

AC>И я там вряд ли что-то пойму.
Но в библиотеке то понимаешь.

AC>Например, у нас есть DSL для предметной области "Написание сообщения"(для форума), включающий возможности управления кареткой, вставки-удаления текста, и собственно отправки. Как его знание поможет мне понять смысл сообщения написанного при помощи этого DSL?
У тебя есть язык С. Который может вызывать метода, складывать числа,...
Как это знание помогает тебе понимать что написано на языке С?

AC>Я так понял, этот код как раз делает то — что преобразует себя в машинный код(через посредство других DSL'ей)?
Этот ДСЛ описывает разбор текста.

AC>Т.е. ты утверждаешь что автогенерированые 25380 строк на C#, эквиваленты по возможностям/сложности 25380 строкам на C# написанным руками?
Ага. Ужать его можно только ценой серьезной потери производительности.

В любом случае я не понимаю, почему тебя так беспокоит объем генерируемого кода?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Sinclair, Вы писали:

ГВ>>А вот, например, в том случае, который описал WolfHound с моей точки зрения, оперировать исходной реализацией IPropertyNotifyChanged гораздо легче, чем макросом — реализация "в лоб" попросту не вызывает никаких вопросов. А по отношению к макросу первый же вопрос: каково имя переменной-члена объекта, в котором сохранено значение свойства? Не упрятано ли оно куда? Выполняется ли синхронизация при вызове callback-а, и если да, то где?
S>Аналогичный вопрос: каково имя переменной-члена объекта, в котором сохранено значение авто-свойства в C#? Почему вас не смущает незнание этого?
S>Вопрос про синхронизацию — хороший, он должен быть освещён в документации по применяемой фиче.

Погоди. Речь не о том, что именно и как именно. Я имею в виду, что в случае "тупого" кода из примера, приведённого Wolfhound-ом, никаких вопросов относительно его свойств не возникает, а когда то же самое реализовано отдельной фичей (макросом, функцией, классом — хоть груздём назови), вопросы уже появляются. В случае автосвойств они тоже появляются, но тут как бы играет некоторую роль априорное доверие к компилятору от Microsoft, поэтому их можно назвать некритичными.

Здравствуйте, AlexCab, Вы писали:

AC>Какие-то у вас слабые ассемблерщики, наверно потому что распальцованые

Как я понял мы с таким ассемблерщиком и имеем дело. Пальцы аж у меня из монитора торчат.
Давай погоняемся. Пишем парсер C# крайней версии. Чтобы все строго по стандарту. С восстановлением после ошибок. С построением АСТ.
Я на моем генераторе парсеров. Ты на ассемблере.
И сравним скорость.

Ну как? Вызов принят?
Лично я уверен, что ты его никогда не закончишь.

AC>Не общались ли вы с разработчиками компиляторов ЯВУ, рвущих ассемблерщеков? Сколько сил и средств затрачивается на разработку таких компиляторов?
На многие порядки меньше чем потребовалось бы на ту же оптимизацию прикладного кода руками.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Погоди. Речь не о том, что именно и как именно. Я имею в виду, что в случае "тупого" кода из примера, приведённого Wolfhound-ом, никаких вопросов относительно его свойств не возникает, а когда то же самое реализовано отдельной фичей (макросом, функцией, классом — хоть груздём назови), вопросы уже появляются. В случае автосвойств они тоже появляются, но тут как бы играет некоторую роль априорное доверие к компилятору от Microsoft, поэтому их можно назвать некритичными.
Двойные стандарты на марше. Какая прелесть.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

AC>>Какие-то у вас слабые ассемблерщики, наверно потому что распальцованые

WH>Как я понял мы с таким ассемблерщиком и имеем дело. Пальцы аж у меня из монитора торчат.
Не, не я не претендую

Но считаю что вручную _всегда_ можно сделать код лучше, чем автогенерированный, пусть это и займёт больше времени.
AC>>Не общались ли вы с разработчиками компиляторов ЯВУ, рвущих ассемблерщеков? Сколько сил и средств затрачивается на разработку таких компиляторов?
WH>На многие порядки меньше чем потребовалось бы на ту же оптимизацию прикладного кода руками.
Обдумывая это предложение я нашол ещё одну проблему DSL-подхода: "чрезмерная специализированность языка".
Это когда цена решения при помощи DSL(разработка DSL и написание кода на нём) привышают затраты на тоже решение на менее специализированом ЯП(вплоть до ЯОН).
Проще говоря: зачем делать DSL на котором будет написано всего 10 строк.

AC>>И я там вряд ли что-то пойму.
WH>Но в библиотеке то понимаешь.
По моему мы ходим по кругу

AC>>Например, у нас есть DSL для предметной области "Написание сообщения"(для форума), включающий возможности управления кареткой, вставки-удаления текста, и собственно отправки. Как его знание поможет мне понять смысл сообщения написанного при помощи этого DSL?
WH>У тебя есть язык С. Который может вызывать метода, складывать числа,...
WH>Как это знание помогает тебе понимать что написано на языке С?
Вот и я о том же, знания одного DSL не достаточно, нужно ещё и код на нём читать.
WH>В любом случае я не понимаю, почему тебя так беспокоит объем генерируемого кода?
Не беспокоит, но в целом это плохо:
1)Толстый дистрибутив будет дольше скачиватся например.
2)Толстое приложение требует больше места на диске, и больше нагружает JIT(если для виртуалки).
3)Толстое приложение требует больше виртуальной памяти, оставляя меньше места для данных приложения.
Понятно что у нас толстые каналы, большие диски и x64, но считаю что всётаки стоит искать некую залотую середину между произволительность и размером кода.

Твой генератор парсеров создаёт распараллеливаемые парсеры(для работы на нескольких процессорах)?

Здравствуйте, AlexCab, Вы писали:

AC>Не, не я не претендую

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

AC>Проще говоря: зачем делать DSL на котором будет написано всего 10 строк.
Оно конечно иногда проще написать руками. Когда задача очень маленькая.

Но, например, у меня был ДСЛ на котором было чуть больше 20 строк кода.
Размер генератора был примерно равен размеру генерируемого кода.

Но было пара но. Малейшие изменения модели приводили к огромным изменениям сгенерированного кода.
Я менял модель не один десяток раз.

Так что экономия написанного кода получилась примерно порядок.

Это не говоря о том, что генератор гонял такие оптимизации, что руками я бы их не осилил ни в жизнь.
И нет. Руками я бы не нашёл лучший вариант. Ибо оптимизатор гонял точный алгоритм, дающий оптимальное решение.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AlexCab, Вы писали:

WH>>Вот язык, написанный на себе.
WH>>https://github.com/rampelstinskin/ParserGenerator/blob/8d02b02b76ed08ab9f71a54ca62b5091538e6cf4/N2/N2.Grammar/GrammarParser2.n2
AC>Ещё десятки незнакомого кода. Каким образом написанное там превращается в исполняемый файл?

Таким же образом, как и любой код: в конечном итоге компилируется компилятором.
Вообще, странно слышать такие вопросы при частом упоминании языка Си. При виде #define в коде C такие же вопросы возникают?

WH>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>Это ооооочень плохой результат. Подозреваю там сотни спагетти-кода, которые можно относительно(разработки DSL'а это генерирующего) легко заменить алгоритмами.

Это оооочень хороший результат! Вручную пишется мало кода. Без DSL придётся писать много кода. А итог — одинаков.

AC>И получатся те-же 190 строк например на питоне + плюс быстрая библиотека на Си.
Опять же, я недоумеваю, как можно бояться нескольких простых предметно-ориентированных языков, и при этом как контрпример приводить несколько сложных языков, такик как питон и си. Выучить эти два ЯОН и предметную область сложнее, чем выучить два-три DSL и ту же предметную область (ибо эти DSL и будут отражением предметной области — по сути их учить вообще не надо).

Здравствуйте, AlexCab, Вы писали:

WH>>В любом случае я не понимаю, почему тебя так беспокоит объем генерируемого кода?
AC>Не беспокоит, но в целом это плохо:
AC>1)Толстый дистрибутив будет дольше скачиватся например.
AC>2)Толстое приложение требует больше места на диске, и больше нагружает JIT(если для виртуалки).
AC>3)Толстое приложение требует больше виртуальной памяти, оставляя меньше места для данных приложения.
AC>Понятно что у нас толстые каналы, большие диски и x64, но считаю что всётаки стоит искать некую залотую середину между произволительность и размером кода.

Да не будет дистрибутив толще, чем без DSL. Итогового кода столько же. Только без DSL он будет писаться вручную, а с DSL — генерироваться.
Причём, если понадобится уменьшить объём кода, пусть в ущерб быстродействию, то ручной код придётся переписывать весь. А в случае с DSL код останется прежним — переписать нужно будет лишь код генерации.

AC>Твой генератор парсеров создаёт распараллеливаемые парсеры(для работы на нескольких процессорах)?

А вообще есть такие парсеры? Вернее, есть генераторы распараллеливаемых парсеров?
Опять же: смело пишем парсер на существующем генераторе (DSL). Если понадобится распараллеленный парсер — грамматика парсера остаётся прежней — переписываем лишь генератор (DSL).

Здравствуйте, WolfHound, Вы писали:

ГВ>>Погоди. Речь не о том, что именно и как именно. Я имею в виду, что в случае "тупого" кода из примера, приведённого Wolfhound-ом, никаких вопросов относительно его свойств не возникает, а когда то же самое реализовано отдельной фичей (макросом, функцией, классом — хоть груздём назови), вопросы уже появляются. В случае автосвойств они тоже появляются, но тут как бы играет некоторую роль априорное доверие к компилятору от Microsoft, поэтому их можно назвать некритичными.
WH>Двойные стандарты на марше. Какая прелесть.

Ты не понял о чем речь. Предложи хорошую модель поиска решений и тебе станет ясно.

Здравствуйте, AlexCab, Вы писали:

AC>Обдумывая это предложение я нашол ещё одну проблему DSL-подхода: "чрезмерная специализированность языка".

Так это же хорошо! Специализированный — значит простой! И понятный не программисту, а тому, для кого делается решение задачи в данной области.

AC>Это когда цена решения при помощи DSL(разработка DSL и написание кода на нём) привышают затраты на тоже решение на менее специализированом ЯП(вплоть до ЯОН).

Оппоненты DSL на это и упирают. Больше по сути не на что. Но это на ЯОН написать DSL сложно, а на N2 — ... Ждём, надеемся, верим. :)

AC>Проще говоря: зачем делать DSL на котором будет написано всего 10 строк.

А если эти 10 строк разворачиваются в 10 тысяч?

Здравствуйте, AlexCab, Вы писали:

AC>В том-то и беда, это не нужный код, потому как автоматическая оптимизация менее эффективна(если бы было иначе pure C давно бы стал историей).

Ну бред же. Я тоже писал на ассемблере. До появления MMX ещё можно было вручную что-то оптимизировать. Сейчас, со всеми этими 3DNow, SSE/2/3/4, с GPU в тысячи конвейеров — писать для них вручную практически нереально. Оптимизирующий компилятор рулит. Неужто указать пару опций компилятора или прагм в коде на Си сложнее, чем писать тысячи строк кода для задействования чего-нибудь из упомянутого?

Здравствуйте, AlexCab, Вы писали:

AC>Не общались ли вы с разработчиками компиляторов ЯВУ, рвущих ассемблерщеков? Сколько сил и средств затрачивается на разработку таких компиляторов?

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

Здравствуйте, AlexCab, Вы писали:

AC>Но, если бы занимался промышленным проектированием, использовал бы очень многие. Например те-же ООП паттерны(фабрики, сингтоны), можно использовать и вне ООП.
AC>Ну допусти вот пять из ООПаттернов(для краткости): Singleton, Factory, Adapter, Interface, Interpreter

А теперь возьми какую-нибудь область человеческой деятельности (бухучёт, планирование, конструирование техники, что угодно), и подумай, используется ли там хоть один из этих паттернов?
Спроси бухгалтера, инженера, кого-угодно (кроме программиста) — знакомы ли им эти термины? Нужны ли эти термины хоть в одной области человеческой деятельности (кроме программирования)?

K>Оппоненты DSL на это и упирают.
Я не оппонент, я ищу слабые места и границы применяемости технологии.
K>DSL — один. Приложений на нём — много. Так выгода понятна?
В N2 (как я понял) хотят заменить DSL'ами библиотеки. Потому DSL'ов будет много, даже в одном приложении, даже больше чем предметных областей.

Здравствуйте, koodeer, Вы писали:

K>А вообще есть такие парсеры? Вернее, есть генераторы распараллеливаемых парсеров?
K>Опять же: смело пишем парсер на существующем генераторе (DSL). Если понадобится распараллеленный парсер — грамматика парсера остаётся прежней — переписываем лишь генератор (DSL).
Теоритически мой алгоритм можно распараллелить. Только на практике это скорее создаст тормоза из-за затрат на синхронизацию чем ускорит разбор.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Ты не понял о чем речь. Предложи хорошую модель поиска решений и тебе станет ясно.
Я так понял, ты ее знаешь? Ну, тогда не томи. Покажи.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Ты не понял о чем речь. Предложи хорошую модель поиска решений и тебе станет ясно.
WH>Я так понял, ты ее знаешь? Ну, тогда не томи. Покажи.

Конечно знаю, даже целых несколько. Можешь начать отсюда — http://kolesnik.ru/2006/pattern/

Здравствуйте, WolfHound, Вы писали:

WH>Двойные стандарты на марше. Какая прелесть.

Где ты их увидел?

Здравствуйте, Ikemefula, Вы писали:

I>Конечно знаю, даже целых несколько. Можешь начать отсюда — http://kolesnik.ru/2006/pattern/
И как это относится к тому, что микрософту можно заводить поля типов не явно, а мне нет?
Причинно-следственной связи не вижу. Совсем.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Геннадий Васильев, Вы писали:

WH>>Двойные стандарты на марше. Какая прелесть.
ГВ>Где ты их увидел?
Майкрософту можно. Мне нельзя.

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

Двойные стандарты.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Sinclair, Вы писали:

S>В одном случае вообще нет требования выбора разных способов генерации проводок в рантайме.
S>В другом случае есть один алгоритм с дополнительными параметрами.
S>В твоём случае есть семейство разных алгоритмов с ручным выбором конкретного.

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

S>>>В таком описании для проектирования достаточно трёх паттернов: Стратегия (она же Policy), Следование (она же Последовательность), и Ничто.
AVK>>Поясни мысль.
S>Поясняю: это базис, из которого можно построить всё остальное. операторы if, приращения, и 0.

И что? При чем тут операторы if? Я еще раз напомню определение паттерна — это слово в словаре для описания архитектуры.

S>А можно продемонстрировать как-то способ применения паттерна Стратегия в терминах таблиц и прочих сущностей SQL?

Можно.

declare @alg varchar;

select @alg=alg
  from algs
  where doctype = (select type from docs where id=@docid);

execute sp_executesql @alg, @docid;

AVK>>Этот вопрос в топике уже был — на какие нижележащие концепции опирается паттерн Chain of Resposibility? MVC?
S>На ООП, очевидно.

Т.е. уже не на концепции языка, а на концепции целого класса языков. И именно ООП — не обязательно. Достаточно наличия в языке понятия сущности. В ФП, к примеру, кортеж функций прекрасно справится с MVC.

S>При применении DSL код программы совпадает с её архитектурой.

В идеале. Но это означает прямо противоположное — программа на DSL целиком из архитектуры состоит, а вовсе не отменяет ее. И я это с самого начала говорил.

AVK>>А никто тут ничего подобного и не говорит. Если соответствовать приведенному определению паттерна, то "континентальный завтрак" это термин, который нужен чтобы написать его в меню, и клиенты по нему сразу поймут, о чем речь, не вдаваясь в детальное изучение всех ингредиентов и способов их приготовления.
S>Правильно. И тем не менее, это определённое решение определённой задачи.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, VladD2, Вы писали:

VD>Очень подходящее описание для функции возвращающей функцию

Шиворот навыворот. Это указатель на функцию это подходящая реализация для стратегии в том случае, когда стратегию можно описать одной функцией. Если нельзя — реализации будут либо объектами с несколькими методами, либо кортежом функций.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, VladD2, Вы писали:

VD>До суда все понятно.

А после суда паттерны уже не нужны, код писать надо.

VD>Скажу больше. Твои слова "документ" и "ХО" уже говорят о том, что ты оперируешь не предметной областью, аз знакомым тебе алгоритмом (подходом).

Я описываю конкретный дизайн. Не задачу, а дизайн, понимаешь? Готовый.

VD>В моем решении документ и ХО могут быть единым целым

И это другой дизайн.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>>>Двойные стандарты на марше. Какая прелесть.
ГВ>>Где ты их увидел?
WH>Майкрософту можно. Мне нельзя.

Почему это сразу "нельзя"? Можно, просто к "твоему" коду поменьше доверия, что всё будет работать "искаропки" без особых сюрпризов, чем к продуктам Miscrosoft. Ну а что ты хотел?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Почему это сразу "нельзя"? Можно, просто к "твоему" коду поменьше доверия, что всё будет работать "искаропки" без особых сюрпризов, чем к продуктам Miscrosoft. Ну а что ты хотел?
Вот я и говорю двойные стандарты.
А самое противное, что на их основе делаются далеко идущие выводы.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

ГВ>>Почему это сразу "нельзя"? Можно, просто к "твоему" коду поменьше доверия, что всё будет работать "искаропки" без особых сюрпризов, чем к продуктам Miscrosoft. Ну а что ты хотел?
WH>Вот я и говорю двойные стандарты.
WH>А самое противное, что на их основе делаются далеко идущие выводы.

Посмотрим объективно. Что нам известно про Microsoft? Известно, что она делает удобные вещи и называет явления своими именами. Новых языков человеческого общения не создаёт, сиречь своих словарей не выпускает и по этому поводу пользователей идиотами не называет. Может быть она их таковыми где-то и считает (на что у меня есть свои соображения), но то, что она это не афиширует, говорит только в пользу MS — значит, она семь раз отмерит, один раз отрежет. Такой подход успокаивает.

Что нам известно про "WolfHound" (совпадение имён случайное)? Известно, что он называет синее — частично фиолетовым, фиолетовое — полукрасным, окружающих регулярно уличает в неправильном мышлении и грозится что-то общепринятое уничтожить как класс явлений. Такой подход настораживает сразу.

Ну и где здесь двойные стандарты? Система критериев одна и та же (как люди обращаются со словами и с аудиторией), только в случае MS она даёт один результат, а в твоём случае — прямо противоположный. Я тебя уверяю, ровно такое же отношение будет и к какой-нибудь малоизвестной фирме, которая выйдет на рынок с продуктом, скажем, класса Visual Studio, если она, паче чаяния, сопроводит это заявлениями на новоизобретённом языке. Заметь, я не говорю, что это невозможно, т.е. — что невозможно малоизвестной компании выпустить Visual Studio 2, я говорю только об отношении пользователей. Вполне возможно, что продукт будет на самом деле великих свойств и других достоинств, но тем не менее, доверять сходу ему будут только весьма отдельные товарищи.

Отсюда мораль: следи за языком.

ГВ>Посмотрим объективно. Что нам известно про Microsoft? [...]
Известно также, что у неё есть огромная аудитория пользователей, которые, вроде бы, общаются.

ГВ>Что нам известно про "WolfHound"? [...]
Известно, что он представляет интересы очень узкой прослойки программистов-гиков, относительно которых известно, что на практике многие их творения "не стреляют", потому что "средние пользователи" — они, в общем, везде одинаковы, а гики — все очень сильно разные.

Здравствуйте, AlexCab, Вы писали:

AC>Ну допусти вот пять из ООПаттернов(для краткости): Singleton, Factory, Adapter, Interface, Interpreter

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

На мой взгляд эти решают только одну проблему — проблему адаптации модели прикладной области к выбранному языку программирования.

Доказать это очень просто. Если взять другой язык, то некоторые (или даже все) из перечисленных паттернов станут бессмысленными. Например, первые два паттерна (Singleton, Factory) не имеют смысла в функциональном языке. А последний (Interpreter) бессмысленнен в любом динамическом языке обладающем функций eval.

Несколько интереснее паттерны вроде MCV. Но они скорее определяют архитектуру решения нежели используются при ее построении.

Здравствуйте, WolfHound, Вы писали:

VD>>Например, создав ДСЛ для описания ЯП, ты не освобождаешься от проектирования самого ЯП.
WH>Ты взял язык для описания архитектуры и говоришь, вот видишь тут нужно архитектурить... очень смешно.

Если вывод не подтверждается хотя бы одним примером, то это ложный вывод.

WH>Ты мне лучше скажи, что ты собрался архитектурить в бухгалтерии?

Для этого тебя придется посвятить в ее нюансы. Поверь там есть чем заняться. В ней надо описывать взаимосвязь операций. Описывать правила формирования отчетов.

Если бухгалтерия является частью информационной системы предприятия, то все становится еще более кучеряво.

WH>Ведь после создания ДСЛ остается тупо открыть закон и переводить его в код.

Это примерно тоже самое, что сказать, что после прочтения Дракона нужно тупо взять любой ЯП и написать компилятор.

Здравствуйте, AndrewVK, Вы писали:

AVK>Шиворот навыворот.

Это потому что ты мыслишь понятиями ООП.

AVK>Это указатель на функцию это подходящая реализация для стратегии в том случае, когда стратегию можно описать одной функцией. Если нельзя — реализации будут либо объектами с несколькими методами, либо кортежом функций.

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

Здравствуйте, AndrewVK, Вы писали:

VD>>Скажу больше. Твои слова "документ" и "ХО" уже говорят о том, что ты оперируешь не предметной областью, аз знакомым тебе алгоритмом (подходом).

AVK>Я описываю конкретный дизайн. Не задачу, а дизайн, понимаешь? Готовый.

О, как? А ты же говорил о проектировании. Не уж то можно вот так сразу готовый дизайн в один присест спроектировать?

VD>>В моем решении документ и ХО могут быть единым целым

AVK>И это другой дизайн.

Ага. Так какова связь паттернов и дизайна? Давай признаемся самим себе, что паттерны не более чем средство натягивания дизайна на выбранный язык.

VD>На мой взгляд эти решают только одну проблему — проблему адаптации модели прикладной области к выбранному языку программирования.
Думаю всё-таки ПП решают задачу дизайна/разработки(т.е. собственно проектирования) решения(некоторой проблемы в прикладно области), с тем чтобы оно удовлетворяло, и модели прикладной области, и модели ЯП(как ЯОН так и ПОЯ).
VD>Доказать это очень просто. Если взять другой язык, то некоторые (или даже все) из перечисленных паттернов станут бессмысленными. Например, первые два паттерна (Singleton, Factory) не имеют смысла в функциональном языке.
Singleton — глобальная или размещённая в корне(в main'е) функция хранящая состояние.
Factory — функция-конструктор значений, инкапсулирует метод конструирования.
VD>А последний (Interpreter) бессмысленнен в любом динамическом языке обладающем функций eval.
А сама функция eval(), является чем? (кроме того что является функцией)
VD>Несколько интереснее паттерны вроде MCV. Но они скорее определяют архитектуру решения нежели используются при ее построении.
Какая по твоему разница между "определением" и "построением", в контексте проектирования ПО?

И пользуясь случаем хочу ~~передать привет~~ спросить: не потому ли WolfHound так люто-бешено разгоняет парсер, что нету компиляции кусочками, т.е. каждое изменение требует пересборки всей программы?

Здравствуйте, AlexCab, Вы писали:
AC>Например, у нас есть DSL для предметной области "Написание сообщения"(для форума), включающий возможности управления кареткой, вставки-удаления текста, и собственно отправки. Как его знание поможет мне понять смысл сообщения написанного при помощи этого DSL?
Никак. Это плохой язык. Он слишком общий — годится не только для "написания сообщения для форума", а вообще для любых текстов.

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

Здравствуйте, AlexCab, Вы писали:

AC>Не беспокоит, но в целом это плохо:
AC>1)Толстый дистрибутив будет дольше скачиватся например.
AC>2)Толстое приложение требует больше места на диске, и больше нагружает JIT(если для виртуалки).
AC>3)Толстое приложение требует больше виртуальной памяти, оставляя меньше места для данных приложения.
AC>Понятно что у нас толстые каналы, большие диски и x64, но считаю что всётаки стоит искать некую залотую середину между произволительность и размером кода.

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

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

Здравствуйте, WolfHound, Вы писали:

I>>Конечно знаю, даже целых несколько. Можешь начать отсюда — http://kolesnik.ru/2006/pattern/
WH>И как это относится к тому, что микрософту можно заводить поля типов не явно, а мне нет?
WH>Причинно-следственной связи не вижу. Совсем.

ГВ говорит про разницу в реализациях. В одной есть детали, в другой нет. А поля это только один из примеров.
"реализация "в лоб" попросту не вызывает никаких вопросов" и, я так понял, вопрос синхронизации тебе удобно игнорировать ? А как на счет перформанса ? Как быть с зависимыми пропертями, т.е. когда одно свойство изменяется при изменении нескольких других, что часто встречается.
Да и сам вопрос про поля нисколько не праздный. Например может оказаться, что нужно создавать наследников и переопределять некоторые свойства...

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

Здравствуйте, Геннадий Васильев, Вы писали:

Мы снова наблюдаем твой типичный паттерн поведения. Слив -> демагогия на совершенно не связанную с разговором тему.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>ГВ говорит про разницу в реализациях. В одной есть детали, в другой нет. А поля это только один из примеров.
Он как обычно разводит демагогию.

I>"реализация "в лоб" попросту не вызывает никаких вопросов" и, я так понял, вопрос синхронизации тебе удобно игнорировать ? А как на счет перформанса ? Как быть с зависимыми пропертями, т.е. когда одно свойство изменяется при изменении нескольких других, что часто встречается.
И о чем это все? Если у меня в руках макросы я могу всё переделать как мне нужно.

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

Ты, похоже, понятия предметной области называешь паттернами...

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, AlexCab, Вы писали:

AC>И пользуясь случаем хочу ~~передать привет~~ спросить: не потому ли WolfHound так люто-бешено разгоняет парсер, что нету компиляции кусочками, т.е. каждое изменение требует пересборки всей программы?
Нет. Я его разгоняю, чтобы ты мог в реальном времени править мегабайтный файл и ИДЕ не тормозило.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>ГВ говорит про разницу в реализациях. В одной есть детали, в другой нет. А поля это только один из примеров.
WH>Он как обычно разводит демагогию.

Ты прочет так как тебе удобно и проигнорировал вопрос например про синхронизацию. В этом сообщении ты проигнорировал аналогичные вопросы от меня.

I>>"реализация "в лоб" попросту не вызывает никаких вопросов" и, я так понял, вопрос синхронизации тебе удобно игнорировать ? А как на счет перформанса ? Как быть с зависимыми пропертями, т.е. когда одно свойство изменяется при изменении нескольких других, что часто встречается.
WH>И о чем это все? Если у меня в руках макросы я могу всё переделать как мне нужно.

1 И как глядя на декларацию класса узнать про эти детали ?
2 Каким дзеном нужно обладать, что бы догадаться какой атрибут использовать для конкретного решения ? С кодом как раз понятно, залез, посмотрел, глянул другие реализации и дело в шляпе. А как быть с макросами ? Наверное каждый программист должен написать свою реализацию
[ImpementsINotyfyPropertyChanged]
[ImpementsINotyfyPropertyChangedSynchronized]
[ImpementsINotyfyPropertyChangedNotSynchronizedButSupportSetterForOverload]
[ImpementsINotyfyPropertyChangedSynchronizedSupportDependentProperties]
[ImpementsINotyfyPropertyChangedSynchronizedSupportCtorInjection]

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

WH>Ты, похоже, понятия предметной области называешь паттернами...

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

Здравствуйте, VladD2, Вы писали:

AVK>>Шиворот навыворот.

VD>Это потому что ты мыслишь понятиями ООП.

Это потому что я в курсе определения, что такое паттерн.

VD>В исходной задачи их нет и быть не может.

Я нигде не говорил, что он есть в исходной задаче.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, VladD2, Вы писали:

VD>О, как? А ты же говорил о проектировании. Не уж то можно вот так сразу готовый дизайн в один присест спроектировать?

Я не говорил, что он спроектирован в один присест. Откуда такие странные предположения?

AVK>>И это другой дизайн.

VD>Ага. Так какова связь паттернов и дизайна?

A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise.

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, Ikemefula, Вы писали:

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

Но если тебе интересно, что именно происходит, то открываешь, исходники ДСЛ и там все будет написано.

I>Покажи в своем примере "понятия предметной области", спасибо. Не облажайся только, потому как с моей стороны паттерн там есть в обоих реализациях понятия предметной области там нет вообще.
Понятие предметной области в данном весьма низкоуровневом случае реализация одного из классов view model.
Те если доводить до конца, то это код должен быть таким

view model Introduction
{
    FirstName     : string;//Свойства которые можно читать/писать.
    LastName      : string;//Система автоматом отслеживает их изменения.
    FullName      : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
    //Обновляется автоматически при изменении любого из значений от которого зависит.

    CapitalizeLastName() : void
    {
        LastName = LastName.ToUpper();
    }
}

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Ты прочет так как тебе удобно и проигнорировал вопрос например про синхронизацию. В этом сообщении ты проигнорировал аналогичные вопросы от меня.
WH>Просто нужно ради разнообразия понять, о чем тебе говорят.
WH>Все эти детали не нужны.
WH>Просто по тому, что если мы работает в терминах предметной области, то это не более чем детали реализации.
WH>Нас это вообще не должно волновать, когда читаем код.

Наоборот, именно это и интересует в самых критичных сценариях.

WH>Но если тебе интересно, что именно происходит, то открываешь, исходники ДСЛ и там все будет написано

Мне нужно что бы в один клик.

I>>Покажи в своем примере "понятия предметной области", спасибо. Не облажайся только, потому как с моей стороны паттерн там есть в обоих реализациях понятия предметной области там нет вообще.
WH>Понятие предметной области в данном весьма низкоуровневом случае реализация одного из классов view model.

То есть, непосредтсвенно в том коде понятия предметной области нет, но почему то паттерн есть. Странно, да ?

Здравствуйте, VladD2, Вы писали:

AC>>Ну допусти вот пять из ООПаттернов(для краткости): Singleton, Factory, Adapter, Interface, Interpreter

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

Все эти вещи

VD>На мой взгляд эти решают только одну проблему — проблему адаптации модели прикладной области к выбранному языку программирования.

VD>Доказать это очень просто. Если взять другой язык, то некоторые (или даже все) из перечисленных паттернов станут бессмысленными. Например, первые два паттерна (Singleton, Factory) не имеют смысла в функциональном языке. А последний (Interpreter) бессмысленнен в любом динамическом языке обладающем функций eval.

Фабрика нужна для выделения кода инициализации в отдельную часть, это нужно независимо от языка, главное что бы нужно было чтото инициализировать. Синглтон заменяется на глобальную функцию которая всегда возвращает один и тот же результат

Aдаптер согласовывает интерфейсы. В ооп это класс, в ФП это кучка функций. Единственный паттерн который полностью уходит в язык это Interpreter, собственно здесь и нужны ДСЛ.
Вобщем что в лоб, что по лбу.

Здравствуйте, Ikemefula, Вы писали:

I>Наоборот, именно это и интересует в самых критичных сценариях.
И давно ты интересовался, во что yield return раскрывается?

I>Мне нужно что бы в один клик.
В ИДЕ можно будет перейти к коду макры.
Или сказать покажи, во что раскроется этот код.

I>То есть, непосредтсвенно в том коде понятия предметной области нет, но почему то паттерн есть. Странно, да ?
Как это нет, когда есть? Там описывается view model.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Наоборот, именно это и интересует в самых критичных сценариях.
WH>И давно ты интересовался, во что yield return раскрывается?

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

I>>То есть, непосредтсвенно в том коде понятия предметной области нет, но почему то паттерн есть. Странно, да ?
WH>Как это нет, когда есть? Там описывается view model.

Вообще то там просто INotifyPropertyChanged, он используется для чего угодно кроме ViewModel. не совсем ясно, почему ViewModel стала у тебя вдруг понятием предметной области. когда описываются требования к UI, никто в своем уме не оперирует этим понятием.

Здравствуйте, Ikemefula, Вы писали:

I>Вообще то там просто INotifyPropertyChanged, он используется для чего угодно кроме ViewModel.
И для чего же?

I>не совсем ясно, почему ViewModel стала у тебя вдруг понятием предметной области. когда описываются требования к UI, никто в своем уме не оперирует этим понятием.
Именно им и оперируют когда говорят что отображать в ГУИ.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Вообще то там просто INotifyPropertyChanged, он используется для чего угодно кроме ViewModel.
WH>И для чего же?

Для связывания компонентов, сущностей и тд. Он появился задолго до ViewModel, ажно во втором фремворке.

I>>не совсем ясно, почему ViewModel стала у тебя вдруг понятием предметной области. когда описываются требования к UI, никто в своем уме не оперирует этим понятием.
WH>Именно им и оперируют когда говорят что отображать в ГУИ.

Это уже конкретная реализация в конкретной архитектуре. Когда обсуждается сам UI с тз пользователя, ViewModel вообще лишний.

Здравствуйте, VladD2, Вы писали:

VD>Вот это огромное заблуждение. Паттерн на то и паттерн, что он не может перекочевать в библиотеку.

Паттерн, конечно, не может. А вот реализация паттерна — вполне.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>Мы снова наблюдаем твой типичный паттерн поведения. Слив -> демагогия на совершенно не связанную с разговором тему.

Где же здесь слив? Ты ведь, сам возмущался, дескать: "Почему Microsoft можно, а мне нельзя?" Вот я тебе и показал, как работает один и тот же набор почти интуитивных критериев в отношении разных программных продуктов. Сами эти критерии никак не меняются в зависимости от того, с кем именно мы имеем дело (т.е. — двойных стандартов здесь даже рядом нет). Как я понимаю, больше всего тебя возмущает то, что эти самые критерии построены не на коде и технических решениях, а на каких-то весьма отвлечённых материях. Ну так с этим ничего не поделаешь: "по одёжке встречают".

Ну а за несколько ядовитый тон извини, у всех свои недостатки.

AC>>И пользуясь случаем хочу ~~передать привет~~ спросить: не потому ли WolfHound так люто-бешено разгоняет парсер, что нету компиляции кусочками, т.е. каждое изменение требует пересборки всей программы?
WH>Нет. Я его разгоняю, чтобы ты мог в реальном времени править мегабайтный файл и ИДЕ не тормозило.
Т.е. всё-таки мегабайтный файл будет каждый раз пересобераться?

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

Здравствуйте, fmiracle, Вы писали:
F>Компактный читабельный код, написанный вручную, и длинный нечитаемый код, нагенеренный DSL-ем, могут создать примерно одинаковый по размеру байт-код.

Думается мне, что даже если такое возможно, вероятность этого пренебрежительно мала.
F>Ну и плюс для .NET размер сборок обычно проблемы не составляет, а расход памяти и процесорного времени на JIT с лихвой может окупиться уменьшением расхода памяти и процессора на собственно обработку данных.
Тут да, согласен.

Здравствуйте, AlexCab, Вы писали:

AC>Т.е. всё-таки мегабайтный файл будет каждый раз пересобераться?
Ты не понял. Ты открываешь один исходник размером в мегабайт. Ага, такие бывают. И спокойно его редактируешь. И он в реальном времени на каждое нажатие кнопки перепарсивается.
Вот для этого нужен быстрый парсер.

AC>И ещё проблема: "лёгкий DSL говно-код"
В очередной раз мои наблюдения прямо противоречат твоим фантазиям.

Хватит уже придумывать проблемы, которых нет.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

AC>>Например, у нас есть DSL для предметной области "Написание сообщения"(для форума), включающий возможности управления кареткой, вставки-удаления текста, и собственно отправки. Как его знание поможет мне понять смысл сообщения написанного при помощи этого DSL?
S>Никак. Это плохой язык. Он слишком общий — годится не только для "написания сообщения для форума", а вообще для любых текстов.
S>Для форума хорошим будет язык, который оперирует понятиями предметной области. Например "написать вброс", "перевести тему на личность собеседника", "процитировать классиков". С возможностью управлять стилем независимо от содержания и прочими плюшками.
Несомненно изучение DSL даст мне понимание о его возможностях(например в д.с. о том что я не могу "написать ИМХО"), но не о том какие из возможностей были использованы программистом(например в д.с. решил ли он набросить или сумничать).

WH>Вот для этого нужен быстрый парсер.
Понял, просто надеялся что вы нашли способ перепарсивать только ту часть мегабайтного файла которая был изменена(например одну функцию, макрос etc.).
AC>>И ещё проблема: "лёгкий DSL говно-код"
WH>В очередной раз мои наблюдения прямо противоречат твоим фантазиям.
Ну дык, поделись наблюдениями.
WH>Хватит уже придумывать проблемы, которых нет.
Я всегда так делаю когда нет возможности "наблюдать": делаю предположение — проверяю его.

Здравствуйте, AlexCab, Вы писали:

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

AC>Я всегда так делаю когда нет возможности "наблюдать": делаю предположение — проверяю его.

И на чем же ты его проверяешь? Вот я пишу ДСЛи и код на них. А ты что делаешь в этом направлении?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

AC>>Я всегда так делаю когда нет возможности "наблюдать": делаю предположение — проверяю его.

WH>И на чем же ты его проверяешь? Вот я пишу ДСЛи и код на них. А ты что делаешь в этом направлении?
Расспрашиваю тех кто пишет DSL'и и код на них

Ну а когда допилите фреймворк, будем щупат.

Здравствуйте, AlexCab, Вы писали:

AC>Как-бы ничего не мешает использовать этот паттерн передачи аргументов в высокоуровневом ЯП: определить глобальную коллекцию-стек, помещать туда аргументы, а функцию/процедуру вызывать без аргументов.

Ага можно. Еще можно писать на C# используя только оператор goto и if, но зачем?

Здравствуйте, AndrewVK, Вы писали:

VD>>Вот это огромное заблуждение. Паттерн на то и паттерн, что он не может перекочевать в библиотеку.

AVK>Паттерн, конечно, не может. А вот реализация паттерна — вполне.

Ты путаешь паттерн и идею за ним стоящую. От того и ваш спор с Волфхаундом.

Что до "вполне", то не мог ты показать свою библиотеку паттернов?

Здравствуйте, Ikemefula, Вы писали:

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

Фабрика имеет смысл там где есть объекты. Нет объектов, нет фабрик.

Инициализация же это общее понятие не имеющее отношение к фабриками. Таким образом выводим, что фабрика — это паттерн применяемый для решения задачи инициализации объектов в ООЯ.

I>Синглтон заменяется на глобальную функцию которая всегда возвращает один и тот же результат

В ФЯ большинство функций таких. Вывод — в фя не нежны синглтоны. Этого понятия в них просто не существует.

I>Aдаптер согласовывает интерфейсы.

А в Прологе нет того что ты называешь интерфейсами.

I> В ооп это класс, в ФП это кучка функций.

Вот только в ФП никому не нужны ОО-патерны. Не нужны и все.

I>Единственный паттерн который полностью уходит в язык это Interpreter, собственно здесь и нужны ДСЛ.
I>Вобщем что в лоб, что по лбу.

Да ни один ОО-паттерн не имеет смысла в ФЯ. Зато в ФЯ есть свои паттерны. А в ДСЛ-е и те и другие не будут иметь смыла. Какие на фиг синглтоны в SQL или регексах?

Здравствуйте, AlexCab, Вы писали:

VD>>На мой взгляд эти решают только одну проблему — проблему адаптации модели прикладной области к выбранному языку программирования.
AC>Думаю всё-таки ПП решают задачу дизайна/разработки(т.е. собственно проектирования)

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

Паттерны — это эдакий адаптер между неподходящим языком и задачей.

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

Так вот использование языков более высокого уровня (более близкого к задаче) позволяют приблизить разработку к процессу проектирования.

AC> решения(некоторой проблемы в прикладно области), с тем чтобы оно удовлетворяло, и модели прикладной области, и модели ЯП(как ЯОН так и ПОЯ).

Проблема в том, что модель языка программирования общего назначения — это модель машины тьюринга, т.е. очень универсальная, но низкоуровневая машина. И программист решает проблему преобразования модели задачи в эту низкоуровневую модель. Так как почти все задачи не тривиальны, программист очень быстро прекращает видеть общую картину и начинает путаться. В результате — баг, тормоза, замедление разработки и т.п.

VD>>Доказать это очень просто. Если взять другой язык, то некоторые (или даже все) из перечисленных паттернов станут бессмысленными. Например, первые два паттерна (Singleton, Factory) не имеют смысла в функциональном языке.
AC>Singleton — глобальная или размещённая в корне(в main'е) функция хранящая состояние.

В ФЯ все функции глобальны. А main просто нет.

Суть Singleton в наличии изменяемого состояния разделяемого между отдельными частями системы. В ФЯ же глобального состояния просто нет. Там все состояние протаскивается через параметры функций. Это приводит к полной бесполезности паттерна синглтонг.

Зато в ФЯ могут быть другие паттерны, например Монада. И они точно так же не имеют смысла в рамках ОО-иделогии. Люди проектирующие ПО под ФЯ оперируют именно этими паттернами/понятиями. Причем в более высокоуровневых ФЯ многие ФЯ-паттерны встроены в язык. Так в Хаскеле поддержка монад встроена в язык.

AC>Factory — функция-конструктор значений, инкапсулирует метод конструирования.

В ФЯ все типы/значения создаются функциями. Так что понятие фабрика не имеет смысла.

VD>>А последний (Interpreter) бессмысленнен в любом динамическом языке обладающем функций eval.
AC>А сама функция eval(), является чем?

Не поверишь — функцией.

AC>(кроме того что является функцией)

Ей не надо быть "кроме того". Это просто функция. Она умеет выполнять произвольный код. При этом интерпретатор есть, а паттрна нет. Да и проектровать становится нечего. Если нужно что-то инициализировать, то можно тупо описать процесс инициализировать в виде программы и выполнить ее. Точнее проектирование становится настолько просым, что сливается с процессом разработки.

VD>>Несколько интереснее паттерны вроде MCV. Но они скорее определяют архитектуру решения нежели используются при ее построении.
AC>Какая по твоему разница между "определением" и "построением", в контексте проектирования ПО?

Примерно такая же как между кирпичным домом и кирпичами.

AC>И пользуясь случаем хочу ~~передать привет~~ спросить: не потому ли WolfHound так люто-бешено разгоняет парсер, что нету компиляции кусочками, т.е. каждое изменение требует пересборки всей программы?

Кто тебе такое сказал? Вольфхаунд ничего не разгоняет. Современная версия далека от оптимальной. Разногять будем, но после того как все заработает. Он говорит о возможности этого.

Возможность разложить парсер на составные части тоже есть. Более того, можно собирать парсер из кусков динамически.

ЗЫ

На самом деле у языкового подхода есть не мало нюансов и проблем. Все далеко не так радужно как это описывает Вольфхаунд. Просто он идеалист.

Но у языкового подхода действительно есть огромный потенциал. А вот у ОО и ФП потеницал уже исчерпан. Поднять уровень программирования выше современного уровня, с их помощью, сильно не удастся. А вот хороший ДЛС позволяет это сделать. Проблема только в том, что пока что ДСЛ-и создавать очень не просто. Мы хотим упростить эту задачу и тем самым сделать ДЛС-подход более практичным.

Здравствуйте, AlexCab, Вы писали:

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

Вот мы и работаем над тем, чтобы это тебя не волновало.

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

Вот мы и работаем над тем, чтобы создавать ДСЛ-и было не сложнее нежели библиотеки.

Здравствуйте, AlexCab, Вы писали:

AC>То ж ассемблер, а то C#, который развернётся ещё в ~X10 строк.

Если развернуть код на шарпе в ассемблер, то 100 раз не выйдет. Выйдет где-то в 10-20 раз больше. Так что ты можешь оценить насколько C# является низкоуровневым для задачи парсинга.

В прочем, рукописный парсер не будет в 100 раз толще. Он будет толше все в те же 10-20 раз. Но при этом его производительность будет во много раз ниже, чем генерируемого кода, так как алгоритмы будут проще и будут использовать не бесплатные абстракции (делегаты, классы, виртуальные методы).

Здравствуйте, AlexCab, Вы писали:

F>>Компактный читабельный код, написанный вручную, и длинный нечитаемый код, нагенеренный DSL-ем, могут создать примерно одинаковый по размеру байт-код.

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

Ошибаешся. Код не компактный именно потому, что он очень низкоуровневый. Там практически плоский сишный код получается. Его получается больше, но вот работает он быстрее чем код использующий современные ОО- и ФП- абстракции. Ну, а память там вообще почти не выделяется (опять же в следствии "сишности"). Так что по памяти он будет сильно лучше рукописного аналога.

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

Главное, что мы абстрагированы от задачи моделью (описываемой языком) и кодогенератором. Так что нам не придется переписывать сам парсер.

Здравствуйте, AlexCab, Вы писали:

AC>Не, не я не претендую

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

При наличии соответствющих знаний — несомненно. Вот только объем работы бдует неподъемным. По сему приемлемых по скорости и качеству парсеров даже таких простых языков как C# крайне мало. А для С++ так и вообще почти нет.

Здравствуйте, AlexCab, Вы писали:

AC>Я не оппонент, я ищу слабые места и границы применяемости технологии.

Так так и спросил бы. Мы тебе их бы сам описали бы.

У ДСЛ подхода есть ряд проблем:

1. Нужно уметь придумать подходящий под задачу ДСЛ. Тут нужно кое что понимать. Например, то что любой язык — это лингвистическое метаописание некоторой моедели. Так что прежде чем создать язык нужно описать модель предметной области (ну, или сделать это одноврменно).

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

3. Чтобы эффективно писать на некотором языке для него должна быть доступно поддержка IDE. Сделать качественную поддержку IDE еше сложнее нежели компилятор или интерпретатор. О рефакторингах уже вообще разговаривать не приходится.

4. ДСЛ зачастую требуется интегрировать в другой язык (обычно общего назначения) и/или в ДСЛ нужно интегрировать другой язык (ДСЛ или ЯОН). Следовательно ДСЛ-и нужно строить из кирпичиков.

Поднять все эти задачи программисту-одиночке для конкретного ДСЛ практически нереально. Вот мы и хотим сделать решение упрощающее создание ДСЛ-ей и других языков.

VD>4. ДСЛ зачастую требуется интегрировать в другой язык (обычно общего назначения) и/или в ДСЛ нужно интегрировать другой язык (ДСЛ или ЯОН). Следовательно ДСЛ-и нужно строить из кирпичиков.
Что за кирпичики? Макросы?

Я правильно понял, преобразование DSL-кода в ген-код будет происходить так?:

AC>>Думаю всё-таки ПП решают задачу дизайна/разработки(т.е. собственно проектирования)
VD>Ага. Задачу проектирования на языке уровень которого очень сильно отличается от уровня решаемой задачи.
Не "на языке", а "для реализации на языке".
VD>Паттерны — это эдакий адаптер между неподходящим языком и задачей.
Вот и паттерн "адаптер"

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

VD>Так вот использование языков более высокого уровня (более близкого к задаче) позволяют приблизить разработку к процессу проектирования.
Даже при проектировании для ЯП с единственным оператором "ЗделатьПриложение(КЛАССНОЕ_И_ЧТОБ_РАБОТАЛО)" будет использован паттерн "фабрика приложений".

VD>Проблема в том, что модель языка программирования общего назначения — это модель машины тьюринга, т.е. очень универсальная, но низкоуровневая машина. И программист решает проблему преобразования модели задачи в эту низкоуровневую модель. Так как почти все задачи не тривиальны, программист очень быстро прекращает видеть общую картину и начинает путаться. В результате — баг, тормоза, замедление разработки и т.п.
С другой строны: модель DSL ограничена предметной областью и предусмотрительностью разработчика. Так как почти все задачи не тривиальны, программист очень быстро понимает что возможностей DSL'а не хватает и начинает писать "хитрый" код или править сам DSL. В результате — баг, тормоза, замедление разработки и т.п.
VD>Более того, можно собирать парсер из кусков динамически.
Т.е. рантайм?
VD>Но у языкового подхода действительно есть огромный потенциал.
Это, думаю, понимали ещё разработчики Lisp'а. Это тоже что говорить "у листка и карандаша есть огромный потенциал". Но сделать этот потенциал доступным "простым смертным", с тех пор никому не удалось.
Кто знает, может вам повезёт

Здравствуйте, VladD2, Вы писали:

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

VD>Фабрика имеет смысл там где есть объекты. Нет объектов, нет фабрик.

Hello world ?

VD>Инициализация же это общее понятие не имеющее отношение к фабриками. Таким образом выводим, что фабрика — это паттерн применяемый для решения задачи инициализации объектов в ООЯ.

ОО появляется само собой когда в проекте появляются компоненты, модули и тд и тд и тд.

I>>Синглтон заменяется на глобальную функцию которая всегда возвращает один и тот же результат

VD>В ФЯ большинство функций таких. Вывод — в фя не нежны синглтоны. Этого понятия в них просто не существует.

Здесь ничего не меняется, паттерн один и тот же.

I>>Aдаптер согласовывает интерфейсы.
VD>А в Прологе нет того что ты называешь интерфейсами.

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

I>> В ооп это класс, в ФП это кучка функций.

VD>Вот только в ФП никому не нужны ОО-патерны. Не нужны и все.

Там не нужны ОО-реализации паттернов.

I>>Вобщем что в лоб, что по лбу.

VD>Да ни один ОО-паттерн не имеет смысла в ФЯ. Зато в ФЯ есть свои паттерны. А в ДСЛ-е и те и другие не будут иметь смыла. Какие на фиг синглтоны в SQL или регексах?

Нужно отделять паттерн от его реализации и все будет в шоколаде. Как только ты начнешь на SQL решать те же самые задачи, что в С# дают синглтон, этот самый синглтон резко появится и в SQL.

Здравствуйте, VladD2, Вы писали:

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

VD>Паттерны — это эдакий адаптер между неподходящим языком и задачей.

Паттерны это просто решения типовых задач, практически абстракции. В коде паттернов нет, в коде только их реализации.

VD>По сути проектирование с использованием паттернов напоминает эдакое высокоуровневое программирование на вымышленном языке.

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

VD>В ФЯ все функции глобальны. А main просто нет.

VD>Суть Singleton в наличии изменяемого состояния разделяемого между отдельными частями системы. В ФЯ же глобального состояния просто нет.

Это заблуждение. Изменяемое состояние требует задача, а не ЯП.

AC>>Factory — функция-конструктор значений, инкапсулирует метод конструирования.

VD>В ФЯ все типы/значения создаются функциями. Так что понятие фабрика не имеет смысла.

То есть, в ФЯ не нужно выделять инциализацию в отдельный модуль ? Вот так чудеса !

Здравствуйте, AlexCab, Вы писали:

AC>Я правильно понял, преобразование DSL-кода в ген-код будет происходить так?:
AC>

Почти. Блок кодогенератор не монолитный. А состоит из цикла переписываний и типизаций (чтобы ловить ошибки разработчиков языков) да и переписывание без типизации сделать нельзя. Ибо информации не будет.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, VladD2, Вы писали:

VD>Ты путаешь паттерн и идею за ним стоящую.

Я — не путаю. Определение паттерна я уже раз 5 приводил.

VD>Что до "вполне", то не мог ты показать свою библиотеку паттернов?

Ты тоже не читаешь чужие сообщения полностью.

Паттерн, конечно, не может.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, AlexCab, Вы писали:
AC>Несомненно изучение DSL даст мне понимание о его возможностях(например в д.с. о том что я не могу "написать ИМХО"), но не о том какие из возможностей были использованы программистом(например в д.с. решил ли он набросить или сумничать).
Я вас не понимаю. Что вам помешает воспринять использованные возможности, когда вы глядите в исходный код?
Вы почему-то интересуетесь целевым кодом — тем, что порождается компилятором DSL. Оставьте эту навязчивую идею.

Здравствуйте, Sinclair, Вы писали:

AC>>Несомненно изучение DSL даст мне понимание о его возможностях(например в д.с. о том что я не могу "написать ИМХО"), но не о том какие из возможностей были использованы программистом(например в д.с. решил ли он набросить или сумничать).
S>Я вас не понимаю. Что вам помешает воспринять использованные возможности, когда вы глядите в исходный код?

Разница в мышлении и опыте между архитектором, автором кода и читателем кода.

S>Вы почему-то интересуетесь целевым кодом — тем, что порождается компилятором DSL. Оставьте эту навязчивую идею.

Очень немногие обладают таким дзеном, что бы эффективно строчить эффективный код и не знать подробностей. В SQL заглянуть нельзя, потому приделан костыль — план выполнения запроса а так же написаны всякие профайлеры.
ДСЛ в который нельзя заглянуть без профайлера в критических случаях(память, перформанс) просто утопия.

S>Вы почему-то интересуетесь целевым кодом — тем, что порождается компилятором DSL. Оставьте эту навязчивую идею.
Это ген-кодомания

Здравствуйте, Ikemefula, Вы писали:
I>Разница в мышлении и опыте между архитектором, автором кода и читателем кода.
Конкретнее.
Вот вы читаете C# код. Вы видите using statement. Что мешает понять намерения программиста?
Понятнее ли такой код, чем рукопашный код с Dispose() (и, возможно, ещё всякое) в finally?

I>Очень немногие обладают таким дзеном, что бы эффективно строчить эффективный код и не знать подробностей. В SQL заглянуть нельзя, потому приделан костыль — план выполнения запроса а так же написаны всякие профайлеры.
I> ДСЛ в который нельзя заглянуть без профайлера в критических случаях(память, перформанс) просто утопия.
Не очень понятен термин "заглянуть без профайлера".
Вот, скажем, аспнет генерирует кучу С# кода по aspx-страницам. Вы часто смотрите в этот код?

Здравствуйте, AlexCab, Вы писали:

VD>>4. ДСЛ зачастую требуется интегрировать в другой язык (обычно общего назначения) и/или в ДСЛ нужно интегрировать другой язык (ДСЛ или ЯОН). Следовательно ДСЛ-и нужно строить из кирпичиков.
AC>Что за кирпичики? Макросы?

Форма может быть любой. В том числе такие кирпичики можно называть и макросами. Тут главное идея — возможность собирать большие языки из меньших (расширять языки, смешивать языки). Скажем чтобы создать язык .cshtml (Разор для шарпа) нам потребуется части грамматики C# и грамматика Разора. Причем нам потребуется их смешать.

AC>Я правильно понял, преобразование DSL-кода в ген-код будет происходить так?:
AC>http://files.rsdn.ru/96088/PG.png[/img]

Примерно. Но, это очень упрощенная схема.

Здравствуйте, Sinclair, Вы писали:

I>>Разница в мышлении и опыте между архитектором, автором кода и читателем кода.
S>Конкретнее.
S>Вот вы читаете C# код. Вы видите using statement. Что мешает понять намерения программиста?

Разумеется указаная разница. using это слишком простой пример, в более сложных вещах приходится разбираться в обязательном порядке. Например сахар в C# имеет обыкновение захватывать лишние переменные, что приводит к непонятным утечкам памяти.

S>Понятнее ли такой код, чем рукопашный код с Dispose() (и, возможно, ещё всякое) в finally?

Немногие знают что using разворачивается в try-finally, отсюда неудивительно видеть косяки в чужом коде или эмуляцию using разными способами.

I>> ДСЛ в который нельзя заглянуть без профайлера в критических случаях(память, перформанс) просто утопия.
S>Не очень понятен термин "заглянуть без профайлера".

Правильно так:
"В критических случаях(память, перформанс) ДСЛ, в который нельзя заглянуть, без профайлера просто утопия."

S>Вот, скажем, аспнет генерирует кучу С# кода по aspx-страницам. Вы часто смотрите в этот код?

Смотрел что бы понять, как эта хрень работает тк иногда вылазят кое какие косяки. Все они,кстати говоря, довольно популярные.
Сейчас в аспнет не смотрю, но смотрю в генереный код всяких *.tt шаблонов, например интересно в каком порядке и при каких условиях генерятся эвенты и тд и тд. Например кое что пришлось фиксить после изучения этого файлика в BLT.

AC>>Что за кирпичики? Макросы?
VD>Форма может быть любой. В том числе такие кирпичики можно называть и макросами.
Понял, "кирпичики" не совсем точная аналогия, скорей кусочки пазла, потому что должны подходить друг к другу, и собраться в одну картинку(собственно DSL).
VD>Тут главное идея — возможность собирать большие языки из меньших (расширять языки, смешивать языки).
Не рекламируйте эту фичу, или найдите способ защитить синтаксический модуль(паролем например), т.к. меня не радует перспектива обнаружить сутра ядерную смесь Python'а, Java и Haskell'я в одном файле исходного текста, как результат ночных стараний жуниора.

И ещё маленький вопрос: можно ли при помощи N2 реализовать ЯОН с метапрограммированием(реализованным иначе чем в N2), такой как например C++ с шаблонами, или же нужен отдельный препроцессор?

Здравствуйте, AlexCab, Вы писали:

AC>Понял, "кирпичики" не совсем точная аналогия, скорей кусочки пазла, потому что должны подходить друг к другу, и собраться в одну картинку(собственно DSL).

Можно называть и так.

AC>Не рекламируйте эту фичу, или найдите способ защитить синтаксический модуль(паролем например), т.к. меня не радует перспектива обнаружить сутра ядерную смесь Python'а, Java и Haskell'я в одном файле исходного текста, как результат ночных стараний жуниора.

Это теоретические страхи. На практике такого не происходит, как не происходит подобного с библиотеками.

AC>И ещё маленький вопрос: можно ли при помощи N2 реализовать ЯОН с метапрограммированием(реализованным иначе чем в N2), такой как например C++ с шаблонами, или же нужен отдельный препроцессор?

Можно. В прочем для С++ все равно нужно будет делать препроцессор.

Здравствуйте, AndrewVK, Вы писали:

AVK>Ты тоже не читаешь чужие сообщения полностью.

AVK>

AVK>Паттерн, конечно, не может.

Моё понимание — в том, что эта невозможность — исключительно ограничение языка. Вот, например, паттерн "Factory". На C++ его надо пилить руками, и в библиотеку его особенно не запихаешь.
А в Delphi этого паттерна в виде паттерна нет, т.к. в него встроены виртуальные конструкторы и есть понятие "ссылка на класс". Все инструменты, нужные для решения задачи, есть в языке в виде готовых конструкций. Поэтому все ритуальные припрыгивания с "объектом, который умеет порождать по требованию другие объекты", попросту не нужны.
А в C# паттерн чудесным образом уехал в библиотеку — волшебный класс Activator спасет даже тех, кто никогда не читал книгу GoF.

Здравствуйте, Sinclair, Вы писали:

S>Моё понимание — в том, что эта невозможность — исключительно ограничение языка. Вот, например, паттерн "Factory". На C++ его надо пилить руками, и в библиотеку его особенно не запихаешь.

А сдаюсь. Упорное нежелание понять отличие между паттерном и его реализацией мне непонятно.

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

AVK>>

AVK>>Паттерн, конечно, не может.

S>Моё понимание — в том, что эта невозможность — исключительно ограничение языка. Вот, например, паттерн "Factory". На C++ его надо пилить руками, и в библиотеку его особенно не запихаешь.
S>А в Delphi этого паттерна в виде паттерна нет, т.к. в него встроены виртуальные конструкторы и есть понятие "ссылка на класс". Все инструменты, нужные для решения задачи, есть в языке в виде готовых конструкций. Поэтому все ритуальные припрыгивания с "объектом, который умеет порождать по требованию другие объекты", попросту не нужны.

Фабрика нужна не для порождения, а для выделения инциализации-связывания в отдельную часть. Соответсвенно не надо удивляться вещам вроде emballo, dframe2009 или Delphi Spring.

S>А в C# паттерн чудесным образом уехал в библиотеку — волшебный класс Activator спасет даже тех, кто никогда не читал книгу GoF.

Паттерн никуда уехать не может.

Здравствуйте, Ikemefula, Вы писали:

I>Фабрика нужна не для порождения, а для выделения инциализации-связывания в отдельную часть. Соответсвенно не надо удивляться вещам вроде emballo, dframe2009 или Delphi Spring.
По-моему кто-то путает фабрику с DI и IoC.
Вот это и вот это в Delphi есть из коробки безо всяких паттернов и библиотек.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Фабрика нужна не для порождения, а для выделения инциализации-связывания в отдельную часть. Соответсвенно не надо удивляться вещам вроде emballo, dframe2009 или Delphi Spring.
S>По-моему кто-то путает фабрику с DI и IoC.

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

S>Вот это и вот это в Delphi есть из коробки безо всяких паттернов и библиотек.

То есть, в дельфи из коробки есть оба паттерна но без паттернов ?

Реализация паттерна перекочевала в язык. Это нормально. Сам паттерн никуда не перемещался, ибо паттерн не код что бы перемещаться.

P.S. Пора вводить паттерн "паттерн без паттерна", т.к. его используют минимум три человека в данном топике

Здравствуйте, AndrewVK, Вы писали:

AVK>А сдаюсь. Упорное нежелание понять отличие между паттерном и его реализацией мне непонятно.
Это оттого, что я себе вовсе не представляю паттерн без реализации. Паттерн — это описание "как изготовить майонез из воды, масла, уксуса и яичного порошка". Он нужен только тогда, когда у тебя нет коробочного майонеза. Когда он есть — ты просто берёшь и заправляешь им салат. Или что-то другое. У тебя паттернами становятся более интересные вещи — "салат", "яйцо под майонезом", и так далее.
Майонез, конечно же, никуда не делся. Но он перестал быть паттерном.

Скажем, тот же самый навязший в зубах using. В Delphi он был паттерном — аккуратные пацаны везде писали руками try begin v:= MyClass.Create(); finally FreeAndNil(v) end;
Это был Паттерн, хотя никто его так не называл. В С# у нас вместо него есть using statement. Кто-то считает его паттерном?
Или, быть может, кто-то считает event в C# паттерном? Нет, его считают элементом языка. Несмотря на то, что он полностью соответствует топологии объектов из Observer Pattern.
Когда ты пишешь шарповое приложение, ты не думаешь и не пишешь "о, тут мы применим паттерн Observer". Ты просто говоришь "у меня есть событие OnDataTransferComplete, которое вызывается при завершении передачи данных". И этого достаточно.

Здравствуйте, Ikemefula, Вы писали:

I>То есть, в дельфи из коробки есть оба паттерна но без паттернов ?

Конечно. Паттерн — это "узор", некая комбинация средств, применённая согласованно. Элемент языка становится монолитом и теряет свою "паттерновость".

I>Реализация паттерна перекочевала в язык. Это нормально. Сам паттерн никуда не перемещался, ибо паттерн не код что бы перемещаться.
I>P.S. Пора вводить паттерн "паттерн без паттерна", т.к. его используют минимум три человека в данном топике

Его ежедневно используют миллионы людей во всём мире.

Попробуй рассказать произвольному программисту на С, С++, С#, Pascal, Delphi, Java, JavaScript, что когда он пишет Foo(42);, он пользуется паттерном "вызов функции", состоящим из размещения в стеке параметров и адреса возврата, а затем передачи управления по адресу, где расположен пролог функции.

Реализация паттерна — налицо, но самого паттерна нету.

Здравствуйте, AlexCab, Вы писали:

AC>>>Думаю всё-таки ПП решают задачу дизайна/разработки(т.е. собственно проектирования)
VD>>Ага. Задачу проектирования на языке уровень которого очень сильно отличается от уровня решаемой задачи.
AC>Не "на языке", а "для реализации на языке".

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

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

VD>>Паттерны — это эдакий адаптер между неподходящим языком и задачей.
AC>Вот и паттерн "адаптер"

В данном случае, это не паттерн проектирования. Это паттерн мышления.

VD>>По сути проектирование с использованием паттернов напоминает эдакое высокоуровневое программирование на вымышленном языке. Если бы все вопросы покрывались бы паттернами, и паттерны можно было поместить в библиотеки, то процесс разработки ПО можно было свети к проектированию.
AC>Мы как раз о паттернах проектирования и говорим.

Мы говорим о том, что паттерны не нужны (что это плохо и не нужно).

Здравствуйте, Sinclair, Вы писали:

I>>То есть, в дельфи из коробки есть оба паттерна но без паттернов ?

S>Конечно. Паттерн — это "узор", некая комбинация средств, применённая согласованно. Элемент языка становится монолитом и теряет свою "паттерновость".

Неправильно. Примерно 5 лет назад я объяснял это но на другом форуме. Паттерн никакой не узор, а просто эффективное решение некоторой типовой задачи в абстрактном виде, причем паттерн это нотъемлемая составляющая при поиске и принятии решения а так же в образовании понятий.

S>Попробуй рассказать произвольному программисту на С, С++, С#, Pascal, Delphi, Java, JavaScript, что когда он пишет Foo(42);, он пользуется паттерном "вызов функции", состоящим из размещения в стеке параметров и адреса возврата, а затем передачи управления по адресу, где расположен пролог функции.
S>Реализация паттерна — налицо, но самого паттерна нету.

Вероятно тебе покажется странным, что функция в детстве была паттерном "вызов подпрограммы"

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

push ax
push bx
call func
add sp, 4

proc func
push bp
mov bp, sp
...
pop bp
ret

В твоем случае очевидно задача другая и не ясно зачем вообще рассматривать эот паттерн.

Здравствуйте, VladD2, Вы писали:

VD>Мы говорим о том, что паттерны не нужны (что это плохо и не нужно).

Ну какие то паттерны Вы считаете полезными, как например WH про ViewModel залепил такое что неясно как вообще весь его текст в этом треде рассматривать : "Войны не объявлять, мира не подписывать, армию распустить"

Здравствуйте, Ikemefula, Вы писали:

I>Ну какие то паттерны Вы считаете полезными, как например WH про ViewModel залепил такое что неясно как вообще весь его текст в этом треде рассматривать : "Войны не объявлять, мира не подписывать, армию распустить"

Полезна базовая идея. Паттерн — всегда вреден. Мы предлагает создавать решения в которых ViewModel явяляется сущностью первого порядка, а не эмулируется паттерном.

Вот погляди на досуге это.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, VladD2, Вы писали:

I>>>Ну какие то паттерны Вы считаете полезными, как например WH про ViewModel залепил такое что неясно как вообще весь его текст в этом треде рассматривать : "Войны не объявлять, мира не подписывать, армию распустить"

VD>>Полезна базовая идея. Паттерн — всегда вреден.

I>Паттерн это есть нечто между идеей и понятием, т.е. абстракция.

Зачем для понятий "идея" и "абстракция" выдумывать еще один термин?

Тут вам Вольфхаунд уже неделю одно и тоже долдоинт. Загляните в обычный словарь. А потом подумайте почему именно слово "паттерн" использовано для обозначения паттерна.

Ответ ведь лежит на поверхности. Это не просто идея. Это идея за которой лежит реализация.

>>Мы предлагает создавать решения в которых ViewModel явяляется сущностью первого порядка, а не эмулируется паттерном.

I>В доменной модели нет ViewModel, эта доменная модель хорошо видна в требованиях по UI.

Это в которой? В модели пользовательского интерфейса — есть.

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

AC>>Не "на языке", а "для реализации на языке".
VD>Это твоя ошибка.
Не исключено, но:
VD>Язык это не какая-то второстепенная хрень.
Смотря с чем сравнивать.
VD>Это проекция мышления.
По отношению к мышлению, довольно таки второстепенная.
VD>Человек всегда думает на каком-то языке.
Ok.
VD>Когда ты обдумываешь решение некоторой программной задачи, то ты мыслишь на каком-то языке.
Я, на естественном(русский/английский) + графика.
VD>Паттерны превносятся в это мышление...
Они не просто привносятся, я их методично собираю и каталогизирую.
VD>... для того, чтобы твое мышление не было излишне детализированным. По сути ты оперируешь более крупными понятиями...
Паттерны это не про детализацию, паттерны это про типичность.
VD>..., но так как эти понятия не имеют прямого отображения в язык...
Все, известные мне ,понятия имеют прямое отображение в язык, на котором я обдумываю решение программных задач.
VD>..., то приходится помнить, что в дальнейшем придется преобразовать эти понятия в кучу кода реализующего эти понятия на выбранном языке.
Да.
VD>Если же понятия имеют отражение в языке, то ты продолжаешь обдумывать задачу прямо в терминах своего языка.
Нет, даже если понятия реализованы в ЯП/библиотеке, я по прежнему продолжаю обдумывать задачу в терминах задачи, но уже не задумываюсь об их реализации.
Вас, паттерн-хейтеров, вводят в заблуждение 3 вещи:
1)Непонимание роли паттернов в мышлении.
2)Мнение: паттерны == код/язык
3)С поднятием уровня ЯП некоторые паттерны из предыдущего уровня становятся не актуальными и в целом при решении задачи на более высокоуровневом ЯП нужно использовать меньше паттернов. От чего кажется что если поднять уровень языка достаточно высоко из него уйдут вообще все паттерны. Однако, образно говоря, паттерны выше чем язык, даже когда ЯП упрётся в максимально возможный уровень("ЗделайМнеКлёва()"), над ним ещё будут паттерны.
VD>В данном случае, это не паттерн проектирования. Это паттерн мышления.
Насколько мне известно, не обладающие мышлением проектировать не могут.
VD>Мыговорим о том, что паттерны не нужны (что это плохо и не нужно).
На здоровье, развлекайтесь

Здравствуйте, VladD2, Вы писали:

VD>Зачем для понятий "идея" и "абстракция" выдумывать еще один термин?

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

I>>В доменной модели нет ViewModel, эта доменная модель хорошо видна в требованиях по UI.

VD>Это в которой? В модели пользовательского интерфейса — есть.

Покажи мне требования по UI что бы там ViewModel был.

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

Значит в топку ваш подход к паттернам, просто как выясняется одни паттерны вам нравятся, другие — нет. ViewModel актуален только для конкретной архитектуры.

Здравствуйте, Sinclair, Вы писали:

AVK>>А сдаюсь. Упорное нежелание понять отличие между паттерном и его реализацией мне непонятно.
S>Это оттого, что я себе вовсе не представляю паттерн без реализации.

Все равно сдаюсь.

S> Паттерн — это описание "как изготовить майонез из воды, масла, уксуса и яичного порошка".

Нет. Паттерн, это само слово "майонез". Если майонез является частью салата, и у нас есть машин6а, которая сама приготовляет его из элементальных ингредиентов — конкретно этот паттерн, разумеется, исчезнет. Но паттерн "салат" останется. И так до самого верха. Единственный способ устранить возможность применения паттернов, как правильно заметил WH, это полностью уничтожить само понятие архитектуры в разрезе прикладного решения. Так ты согласен с тем, что DSL устраняет необходимость разработки архитектуры?

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, WolfHound, Вы писали:

WH>Обратно на языки, которые это не могут, не хочу.

Поэтому, будешь писать исклюючительно под дотнет.

WH>Шаблоны С++ по сравнению с этим детский сад. Ясельная группа.

Это смотря, что есть твоя цель — процесс или результат.

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

eDSL — зло само по себе. Никакого разграничения исходников на "системный" код и "прикладной". Происходящее принципиально от шаблонов С++ убежало недалеко. Тот же самый детсад, ясельная группа.
А внешние кодогенераторы (твои DSL) мы юзаем в полный рост, ес-но... А на чем сами эти кодогенераторы написаны — да на чем угодно.

Здравствуйте, WolfHound, Вы писали:

WH>А в немерле я могу реализовать макроаттрибут ImplementINotifyPropertyChanged
WH>И писать так:
...
WH>Вот это я называю паттернами и борьбой с ними.

Жесть как она есть. Здесь ты поменял незначительные ньюансы реализации того же самого паттерна. Но сам паттерн никуда из кода не делся...

Ты уверен, что хорошо понимаешь слово "паттерн"? ))

Здравствуйте, Sinclair, Вы писали:

AVK>>Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией. Т.е. мы использовали паттерн. Или, если не синтетически, а аналитически, мы можем назвать использованное решение паттерном.
S>Андрей, прости, но я совершенно не понимаю, почему ты называешь Стратегией банальное отображение D->T[]. Пока что ещё никакого паттерна нет.

Угу, в таком случае "абстрактная фабрика" — это банальная +1 косвенность при вызове ф-ии и т.д. до бесконечности.

Ес-но, механика каждого паттерна банальна, но его роль в дизайне — нет. Саму эту роль в отрыве от конкретного дизайна обсуждать не комильфо. Т.е. попытка дать оценку паттерну в стиле "банальное отображение" в отрыве от контекста — заведомо нелепа.

S>А паттерн Стратегия появится у нас (возможно) только в тот момент, когда мы начнём дизайнить классы.

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

Здравствуйте, Sinclair, Вы писали:

S>А в Delphi...
S>волшебный класс Activator спасет даже тех, кто никогда не читал книгу GoF.

0) и первое и второе бесполезно, т.к. активатор ищет конструктор в рантайме, а делфя так вообще позволяет инстанциировать абстрактные классы и все ошибки перемещаются на этап выполнения: забыл разработчик переопределить нужный конструктор и приехали — об этом может узнать конечный пользователь.

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

2) сами паттерны в связи предыдущим пунктом выполняют коммуникативную функцию, т.е. название паттерна в идеальном случае описывает решаемую задачу и способ её решение кратким ёмким термином, а потому языковые навороты (в ЯВУ) лишь упрощают их реализацию, но не отменяют необходимых знаний

в своё время я не понимал зачем в делфе нужен TClass и писал в функции класса что попало (говнокодил), даже близко не подойдя к задаче для которой этот самый TClass был придуман.

Здравствуйте, Философ, Вы писали:

Ф>0) и первое и второе бесполезно, т.к. активатор ищет конструктор в рантайме, а делфя так вообще позволяет инстанциировать абстрактные классы и все ошибки перемещаются на этап выполнения: забыл разработчик переопределить нужный конструктор и приехали — об этом может узнать конечный пользователь.
Это мелкие недостатки конкретной реализации. Более того, "ручная" реализация в соответствии с книгой Банды ничуть не лучше: нет ни одного языка, который бы обязывал разработчика TDerivedFactory перекрывать метод TBaseFactory::Create. (вырожденный случай прямого наследования от абстрактного класса рассматривать смысла нет).
И про абстрактные методы в Delphi вы вряд ли сможете рассказать мне что-то новое

Ф>1) паттерны рождаются в процессе решения задачи, а не живут сами по себе, т.о. чтобы их использовать нужно понимать какую задачу они решают, и с ней столкнуться хотя-бы один раз, чтобы быть готовым выдвинуть такое решение.
Не очень понятно, к чему этот аргумент. Ну да, они решают конкретную задачу. Но паттерн — это паллиатив: способ сконструировать решение задачи по месту, если у вас нет готового решения. Если есть готовое решение, то надо изучать его, а не паттерн.
И точно так же — готовые инструменты сами по себе вас не спасут, если вы не понимаете, зачем они нужны.
Ф>2) сами паттерны в связи предыдущим пунктом выполняют коммуникативную функцию, т.е. название паттерна в идеальном случае описывает решаемую задачу и способ её решение кратким ёмким термином, а потому языковые навороты (в ЯВУ) лишь упрощают их реализацию, но не отменяют необходимых знаний

Омг, омг. То есть вы считаете, что необходимо ознакомиться с паттерном Observer, чтобы пользоваться event-ами в дотнете?
Меня мучают смутные сомнения.

Ф>

Ф>в своё время я не понимал зачем в делфе нужен TClass и писал в функции класса что попало (говнокодил), даже близко не подойдя к задаче для которой этот самый TClass был придуман.
Я вот, признаюсь честно, пользовался турбопаскалем с 1991 года. И только в 1994 году узнал, зачем нужны виртуальные методы. По той же причине — не сталкивался с задачами, где они были нужны. Но это никак не говорит ни в пользу паттернов, ни против них. Это говорит только о том, что программированию нужно учиться. А рассчитывать на то, что новичку можно просто дать современный прикладной язык без инструкции по применению, а дальше он сам разберётся — неумно.

Здравствуйте, Ikemefula, Вы писали:

I>Неправильно. Примерно 5 лет назад я объяснял это но на другом форуме. Паттерн никакой не узор, а просто эффективное решение некоторой типовой задачи в абстрактном виде, причем паттерн это нотъемлемая составляющая при поиске и принятии решения а так же в образовании понятий.
Невозможно описать решение некоей типовой задачи в абстрактном виде.
Решение всегда опирается на некоторые концепции. Можно постараться отказаться от специфики конкретного языка. Тогда получатся бессмысленные "паттерны" вроде той же Стратегии из Википедии, которая вообще ни о чём.
Это как если бы я описывал рецепт коктейля Bloody Mary, избегая упоминания о джине и томатном соке, а также о способе наливания слоями. "берём один напиток (обычно алкогольный), и другой напиток (обычно безалкогольный), и подаём (как правило, в одной таре)".
Все настоящие "паттерны" подразумевают использование некоторого инструментального набора.
Будем честными — авторы GoF имели в виду C++ и Java, хотя безуспешно старались это скрыть.
В итоге получается, что если требуемых инструментов нет, то применение паттерна становится мучительным (попытка напрямую применить большинство "решений" из GoF на, скажем, JavaScript, будет в лучшем случае разочаровывающей).
А если в языке есть готовые решения, то следование паттерну — это ненужное велосипедостроение.

I>Вероятно тебе покажется странным, что функция в детстве была паттерном "вызов подпрограммы"

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

I>

I>push ax
I>push bx
I>call func
I>add sp, 4

I>proc func
I>push bp
I>mov bp, sp
I>...
I>pop bp
I>ret
I>

Зачем вы мне пересказываете мой же аргумент?
I>В твоем случае очевидно задача другая и не ясно зачем вообще рассматривать эот паттерн.
Ну как зачем? Вы же мне пытаетесь рассказать, что наличие паттерна не зависит от языка. Задачи "низкоуровневого перехода по адресу с возможностью возврата", естественно не стоит. Стоит задача "реализовать частично рекурсивный алгоритм". И вот в одном языке для такой банальности, как "вызов подпрограммы" нужен полезнейший паттерн "использование стека", а в другом языке есть просто "вызов подпрограммы".
Более того, оказывается, что отказ от этого паттерна в пользу готового решения — штука очень хорошая. Так как позволяет среде выбирать другие способы реализации, чем этот красивый паттерн — например, передавать часть аргументов в регистрах, а не в стеке. И всё это без потери семантики вызова.
Вам понятны мои аргументы?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Неправильно. Примерно 5 лет назад я объяснял это но на другом форуме. Паттерн никакой не узор, а просто эффективное решение некоторой типовой задачи в абстрактном виде, причем паттерн это нотъемлемая составляющая при поиске и принятии решения а так же в образовании понятий.
S>Невозможно описать решение некоей типовой задачи в абстрактном виде.

Паттерн не обязательно есть решение самой прикладной задачи. Например может быть тот же ViewModel, который так нравится борцам с паттернами. До тех пор пока будут существовать обязанности и зависимости от паттернов никуда не деться. C внедрением DSL все что изменится, так это появятся другие паттерны, например паттерны реализации DSL, паттерны использования DSL, паттерны моделей DSL и тд и тд и тд. Ну и в каждом DSL так же будут паттерны — ибо в своем уме никто не будет дергать архитектора из за того, что в прикладном коде есть 5 задач и там 5 похожих решений.

S>Решение всегда опирается на некоторые концепции. Можно постараться отказаться от специфики конкретного языка. Тогда получатся бессмысленные "паттерны" вроде той же Стратегии из Википедии, которая вообще ни о чём.
S>Это как если бы я описывал рецепт коктейля Bloody Mary, избегая упоминания о джине и томатном соке, а также о способе наливания слоями. "берём один напиток (обычно алкогольный), и другой напиток (обычно безалкогольный), и подаём (как правило, в одной таре)".

Паттерн "Слоистый коктейль" + конкретная реализация из джина и томатного сока

S>Все настоящие "паттерны" подразумевают использование некоторого инструментального набора.

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

S>А если в языке есть готовые решения, то следование паттерну — это ненужное велосипедостроение.

Это собственно никто не пытается отрицать.

S>Зачем вы мне пересказываете мой же аргумент?
I>>В твоем случае очевидно задача другая и не ясно зачем вообще рассматривать эот паттерн.
S>Ну как зачем? Вы же мне пытаетесь рассказать, что наличие паттерна не зависит от языка. Задачи "низкоуровневого перехода по адресу с возможностью возврата", естественно не стоит. Стоит задача "реализовать частично рекурсивный алгоритм". И вот в одном языке для такой банальности, как "вызов подпрограммы" нужен полезнейший паттерн "использование стека", а в другом языке есть просто "вызов подпрограммы".

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

S>Более того, оказывается, что отказ от этого паттерна в пользу готового решения — штука очень хорошая. Так как позволяет среде выбирать другие способы реализации, чем этот красивый паттерн — например, передавать часть аргументов в регистрах, а не в стеке. И всё это без потери семантики вызова.
S>Вам понятны мои аргументы?

Понятно. Непонятно что же для тебя означает "паттерн"

Здравствуйте, Sinclair, Вы писали:

Ф>>в своё время я не понимал зачем в делфе нужен TClass и писал в функции класса что попало (говнокодил), даже близко не подойдя к задаче для которой этот самый TClass был придуман.
S>Я вот, признаюсь честно, пользовался турбопаскалем с 1991 года. И только в 1994 году узнал, зачем нужны виртуальные методы. По той же причине — не сталкивался с задачами, где они были нужны. Но это никак не говорит ни в пользу паттернов, ни против них.

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

Здравствуйте, Ikemefula, Вы писали:

I>Паттерн не обязательно есть решение самой прикладной задачи.
Зачем вы спорите с тем, чего я не говорил?
I>До тех пор пока будут существовать обязанности и зависимости от паттернов никуда не деться.

Смелое утверждение. Если бы я был злым, я бы попросил вас его обосновать и хохотал бы в тиши кабинета.
Потому что вы резко перешли от средств, задач, и решений, к обязанностям и зависимостям.
Но, поскольку я не злой, то сразу напишу: паттерны не имеют никакого отношения к обязанностям и зависимостям.
Паттерн — это всего лишь описание семейства решений некоторого семейства задач, выраженное на естественном языке в терминах некоторых средств.
Паттерны пишут на естественном языке не потому, что это хорошо, а потому, что не могут описать этот паттерн на языке формальном.
Как только паттерн описан на формальном языке, он становится средством, а его внутреннее устройство — уделом узкой касты гиков.
Да, иногда программисту внезапно приходится узнать, как устроено внутри то средство, которым он до этого пользовался, не задумываясь. (Как правило — в процессе отладки. Иногда — в процессе вылизывания перформанса).
Но это — исключение. Весь смысл языка программирования — в том, чтобы скрыть от разработчика лишние подробности.
Паттерн — строгая этому противоположность. Он сосредотачивается на устройстве, а не только на эффекте.

I>C внедрением DSL все что изменится, так это появятся другие паттерны, например паттерны реализации DSL, паттерны использования DSL, паттерны моделей DSL и тд и тд и тд.
Нет. Другие паттерны появятся — но они будут не про реализацию и использование DSL, а паттерны, построенные из доступных в DSL инструментов. Потому что можно будет не тратить мозг на незначительные детали, а проектировать в терминах паттернов, гораздо более близких к исходной задаче.

Почему вы не можете увидеть тенденцию? Вот полсотни лет назад кто-то придумал идею реализации вызова частично рекурсивных подпрограмм при помощи стека, теперь она реализована во всех мейнстримных языках. С шестидесятых годов почти никто не проектирует в терминах указателей на вершину стека. Проектируют сразу в терминах "подпрограмм".
Придумали паттерн "вызов метода объекта с диспетчеризацией на стороне получателя" — и никто не проектирует в терминах "давайте заведём в MyStruct указатель на myVMT, в котором будет поле fooBar — ссылка на функцию, принимающую ссылку на MyStruct в качестве одного из аргументов.
Проектируют сразу в терминах "давайте у MyClass заведём виртуальный метод fooBar".

I>Паттерн "Слоистый коктейль" + конкретная реализация из джина и томатного сока

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

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

I>Это собственно никто не пытается отрицать.
Да? А мне кажется, что пытаются.
I>Это просто другой уровень абстракции. Есть инструмент в который встроена поддержка паттерна — хорошо. Нет — паттер будет реализован в прикладном коде или инфраструктуре.
Если есть инструмент, то про паттерн можно вовсе забыть. Его изучение — опционально.

I>Понятно. Непонятно что же для тебя означает "паттерн"
Паттерн — это описание семейства решений некоторого семейства задач, выраженное на естественном языке в терминах некоторых средств.

Здравствуйте, Ikemefula, Вы писали:

I>Это говорит о том, что паттерны без задач смысла не имеют. Более того, языки без задач тоже смысла не имеют.

Ну, как вам уже справедливо заметил коллега Klapaucius, связь между языками и задачами обычно комплексная.
В теории всё хорошо и красиво — телега едет за лошадью, появление задач стимулирует языки, спрос рождает предложение.
Тем не менее на практике имеем баржи, едущие впереди толкача, планы Эпла выйти на рынок телефонов вызывают здоровый смех всех участников рынка (т.к. нет никакого неудовлетворённого спроса, который бы удовлетворялся этим забавным будущим гаджетом), а большинство задач в программировании решаются на совершенно неподходящих для них языках.

Это потому, что наивные модели работают в предположении бесконечной скорости распространения информации и нулевой стоимости принятия решения.
АСУ ТП Байкальского тоннеля была написана на Turbo Pascal 7.0, потому что её автор не смог заставить другие известные ему платформы корректно работать с ком-портами под Windows 95, а с полуфабрикатами типа LabVIEW он знаком не был.

Системы управления производством КАМАЗ в 80х годах писались на Фортране, потому что в НИИ Систем был ровно один отдел, умевший писать на чём-то, кроме фортрана, и он оказался занят.

Я почти не знаю историй, когда язык бы реально выбирался под задачу. Ну вот Форт, емнип, был разработан для решения задачи управления телескопом.
Языки пишут одни люди, владея ограниченной информацией. А решают с помощью них задачи — другие люди, тоже владея ограниченной информацией.
Поэтому к любому, самому бредовому утверждению мы найдём в дикой природе экспериментальное подтверждение.

Здравствуйте, Sinclair, Вы писали:

S>В Delphi он был паттерном — аккуратные пацаны везде писали руками try begin v:= MyClass.Create(); finally FreeAndNil(v) end;

Народ, откуда вы этот бред берёте то??? В любом книжке delphi for dummies написано, что создание объекта должно быть ДО блока try

obj := MyClass.Create;
try
..
finally
  obj.Free;
end;

Вон, и SergeyT на примерно ту же тему применительно к C# статью недавно написал, хотя обычно у него более интересная инфа проскакивает. Я не понимаю, детсадовская ошибка от вроде неглупых(??

) людей ?

Здравствуйте, Sinclair, Вы писали:

S>Но, поскольку я не злой, то сразу напишу: паттерны не имеют никакого отношения к обязанностям и зависимостям.

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

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

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

S>Почему вы не можете увидеть тенденцию? Вот полсотни лет назад кто-то придумал идею реализации вызова частично рекурсивных подпрограмм при помощи стека, теперь она реализована во всех мейнстримных языках. С шестидесятых годов почти никто не проектирует в терминах указателей на вершину стека. Проектируют сразу в терминах "подпрограмм".

С этой тендецией никто и не спорит, более того, эту же тенденцию я привел как пример бессмысленности борьбы с паттернами. Бороться нужно за эффективность и качество решений.

S>Придумали паттерн "вызов метода объекта с диспетчеризацией на стороне получателя" — и никто не проектирует в терминах "давайте заведём в MyStruct указатель на myVMT, в котором будет поле fooBar — ссылка на функцию, принимающую ссылку на MyStruct в качестве одного из аргументов.

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

I>>Паттерн "Слоистый коктейль" + конкретная реализация из джина и томатного сока

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

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

I>>Это собственно никто не пытается отрицать.
S>Да? А мне кажется, что пытаются.
I>>Это просто другой уровень абстракции. Есть инструмент в который встроена поддержка паттерна — хорошо. Нет — паттер будет реализован в прикладном коде или инфраструктуре.
S>Если есть инструмент, то про паттерн можно вовсе забыть. Его изучение — опционально.

Как минимум эти паттерны нужно знать для того, что бы понимать как работают инструменты, для инженера это очень важно, т.к. качество поиска решений очень сильно зависит от этого понимания. Если ты непонимаешь, как работают блочные итераторы, то сильно вряд ли тебе придется простое и эффективное решение основаное на этих итераторах.
Далее нужно знать эти паттерны что бы создавать новые инструменты. Ну и для работы со специфическими задачами так же надо знать паттерны.
Например, если ты вдруг проводишь отладку в windbg то сильно врядли он даст тебе C#, скорее всего тебе придется работать с теми паттернами, которые, как ты сказал, не нужны. Опаньки !!!

I>>Понятно. Непонятно что же для тебя означает "паттерн"
S>Паттерн — это описание семейства решений некоторого семейства задач, выраженное на естественном языке в терминах некоторых средств.

Ну вот, более менее годится

Здравствуйте, VladD2, Вы писали:

I>>Ну какие то паттерны Вы считаете полезными, как например WH про ViewModel залепил такое что неясно как вообще весь его текст в этом треде рассматривать : "Войны не объявлять, мира не подписывать, армию распустить"

VD>Полезна базовая идея. Паттерн — всегда вреден. Мы предлагает создавать решения в которых ViewModel явяляется сущностью первого порядка, а не эмулируется паттерном.

VD>Вот погляди на досуге это.

Теоретически — все очень хорошо. Но вот как практически заменить архитекторов(текущих), на создателей ДСЛ? Ведь индустрия есть, и ее надо подвинуть, для того что бы ваш подход стал частью main stream. Мало кодеров захочет знать какой-то один ДСЛ, потом сложно работу поменять. Мало архитекторов — захочет что-то менять. Мне немерле(как и подход в целом) нравится, но вот, если посмотреть с точки зрения практики, у него нет шансов стать популярным средством в лоб. Но, где не просто хорош такой подход, но и просто необходим? Научные расчеты(на верхнем леере), моделирование и т.д. Мне кажется в этом направлении и надо развивать язык и библиотеку макросов. ИМХО.

Здравствуйте, WolfHound, Вы писали:

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

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

WH>Все сущности предметной области переезжают в ДСЛ и там прекрасно живут.

В обычных прикладных проектах каждый из внутренних библиотечных "слоёв" ПО — тоже своего рода DSL для вышестоящих других слоёв. Это наблюдается в любом проекте, в котором присутствует явное разбиение на такие слои. Но описанного тобой эффекта, увы, не наблюдается. И тебе в первых же строчках сказали — почему. Потому что при таком раскладе на твой DSL будет претендовать лишь самый верхний слой ПО, в котором будет одна строчка кода: "сделать мне зашибись!". И от того, что ты всю "систему" вынесешь из одних исходников и фактически без изменений вложишь в другие исходники — в некий кодогенератор, ничего не изменится. Вообще ничего! Один и тот же код переедет из одного проекта в другой, но все примененные и реализованные паттерны как были, так и остануться. Потому что разбор синтаксиса DSL — это относительная фигня. И напротив, для наполнения семантики придется приложить усилия и задизайнить точно такой же дизайн и продумать сценарии применения тех самых известных паттернов (или изобрести пару неизвестных). В итоге, абсолютно все уровни внутреннего библиотечного кода (на которые ушло 90% трудоемкости) как были, так и останутся. А в DSL переедет самая несложная часть кода, которая в любом случае будет пользоваться всеми этими слоями, только из малость другого синтаксиса.

Здравствуйте, WolfHound, Вы писали:

WH>Ты мне лучше скажи, что ты собрался архитектурить в бухгалтерии?
WH>Ведь после создания ДСЛ остается тупо открыть закон и переводить его в код.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>

Здравствуйте, Ikemefula, Вы писали:

I>Я говорил про паттерны проектирования, т.к. в этом треде под паттернами понимаеют именно эти. Сильно вряд ли паттерны проектирования будут описываться в терминах отличных от обязанностей и зависимостей по той причине, что это и есть термины в которых описываются задачи.
Ок, наверное, я не в курсе того, что такое паттерны. Вот wolfhound, к примеру, совершенно точно имеет в виду под паттернами то, что описано в книге Банды, а также у Фаулера.
А вы что имеете в виду? Вот, скажем, Observer Pattern — это то, что вы понимаете под паттернами?

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

I>Разумеется. Но там где низкоуровневые задачи, именно так делается и по сей день.
Нет "низкоуровневых задач". Есть "низкоуровневые средства". Если вас выкинуть в ледяную пустыню, где всё надо программировать в машкодах, среди которых даже call нету, не то что enter/leave, то вы ровно те же задачи будете решать при помощи таких вот мега-паттернов.
А если дать вам для ровно тех же задач хотя бы язык С, то вам и в голову не придёт проектировать в терминах регистров и стека.

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

I>Опаньки — минимум деталей и максимум эффекта.
Никакого эффекта. Вас оставили наедине с задачей, которую по-прежнему надо решать. "слоистый коктейль" — это идея. Чтобы сделать из идеи решение, нужно добавить те самые детали.

I>Как минимум эти паттерны нужно знать для того, что бы понимать как работают инструменты, для инженера это очень важно, т.к. качество поиска решений очень сильно зависит от этого понимания. Если ты непонимаешь, как работают блочные итераторы, то сильно вряд ли тебе придется простое и эффективное решение основаное на этих итераторах.
Это совершенно ортогональная штука.
Во-первых, мне для понимания работы блочных итераторов совершенно не нужно знать, какой "паттерн" они реализуют. (Вот, кстати, какой? Где книжка, в которой можно про него прочитать?) Мне достаточно просто знать их устройство.
Во-вторых, для ежедневного использования блочных итераторов мне совершенно нет нужды знать их внутреннее устройство.
Ваши рассуждения про "простое и эффективное", простите, чушь. Простое решение — это то, которое легко читать. Чтобы его построить, не надо заглядывать внутрь. Надо понимать, что именно делает данный инструмент, вот и всё.
А важность априорное знание внутреннего устройства всего для построения эффективных решений сильно преувеличена. Скажем, Эрик Липперт, входящий в число авторов шарповых трюков, считает, что его догадки об эффективности тех или иных алгоритмов без запуска профайлера ничего не стоят.

I>Далее нужно знать эти паттерны что бы создавать новые инструменты. Ну и для работы со специфическими задачами так же надо знать паттерны.

Создание инструментов и использование инструментов — разные вещи.

I>Например, если ты вдруг проводишь отладку в windbg то сильно врядли он даст тебе C#, скорее всего тебе придется работать с теми паттернами, которые, как ты сказал, не нужны. Опаньки !!!
Эту фразу я, простите, не понял.
1. Скажите, в какой момент мне потребуются знания об Observer Pattern при отладке C#-кода под windbg?
2. Почему это вдруг windbg мне сильно вряд ли даст C#? Куда из него делась отладка исходников?
3. Скажите честно, вы сами сколько раз отлаживали своё приложение под windbg? Вы вправду думаете, что это настолько важный сценарий, что оправдывает изучение паттернов?

Здравствуйте, Jack128, Вы писали:

J>

J>obj := MyClass.Create;
J>try
J>..
J>finally
J>  obj.Free;
J>end;
J>

Ну, я на Delphi уже давно не программирую, мог и напутать. Разве там не было инициализации ссыллочных типов нулями?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Jack128, Вы писали:

J>>

J>>obj := MyClass.Create;
J>>try
J>>..
J>>finally
J>>  obj.Free;
J>>end;
J>>

S>Ну, я на Delphi уже давно не программирую, мог и напутать. Разве там не было инициализации ссыллочных типов нулями?
Инициализируются только те типы, время жизни которых контролируется компилятором. Строки/дин массивы, интерфейсы, варианты. Все остальное — не инициализируется.

Здравствуйте, Sinclair, Вы писали:

I>>Я говорил про паттерны проектирования, т.к. в этом треде под паттернами понимаеют именно эти. Сильно вряд ли паттерны проектирования будут описываться в терминах отличных от обязанностей и зависимостей по той причине, что это и есть термины в которых описываются задачи.
S>Ок, наверное, я не в курсе того, что такое паттерны. Вот wolfhound, к примеру, совершенно точно имеет в виду под паттернами то, что описано в книге Банды, а также у Фаулера.

WH совершенно точно имеет ввиду под паттернами чтото своё. Для него любая копипаста это и есть паттер, а паттерн(если это не ViewModel) и есть копипаста. Между тем в GoF есть четкое разделение, где копипаста а где паттерн.

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

S>А вы что имеете в виду? Вот, скажем, Observer Pattern — это то, что вы понимаете под паттернами?

Это конкретный паттерн. Что с ним не так ?

I>>Паттерн нужен для того, что бы искать и принимать решение не ковыряясь во всех деталях разом.
S>Паттерн нужен для того, чтобы обучить типовому решению, чтобы каждый "архитектор" не изобретал недореализации паттернов вроде Observer.

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

S>Нет "низкоуровневых задач". Есть "низкоуровневые средства". Если вас выкинуть в ледяную пустыню, где всё надо программировать в машкодах, среди которых даже call нету, не то что enter/leave, то вы ровно те же задачи будете решать при помощи таких вот мега-паттернов.
S>А если дать вам для ровно тех же задач хотя бы язык С, то вам и в голову не придёт проектировать в терминах регистров и стека.

Хорошо, задача это просто задача, какая есть. Но есть текущий набор ограничений. Задачу мы решаем именно в этих рамках, а не в идеальных условиях на идеальном ЯП.

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

I>>Опаньки — минимум деталей и максимум эффекта.
S>Никакого эффекта. Вас оставили наедине с задачей, которую по-прежнему надо решать. "слоистый коктейль" — это идея. Чтобы сделать из идеи решение, нужно добавить те самые детали.

Слоистый коктейль и есть паттерн. Он нужен для поиска и принятия решения и очевидно он не есть решение. Как получить решение с помощью этого паттерна, я уже показал. В чем польза — тоже показал.

I>>Как минимум эти паттерны нужно знать для того, что бы понимать как работают инструменты, для инженера это очень важно, т.к. качество поиска решений очень сильно зависит от этого понимания. Если ты непонимаешь, как работают блочные итераторы, то сильно вряд ли тебе придется простое и эффективное решение основаное на этих итераторах.
S>Это совершенно ортогональная штука.
S>Во-первых, мне для понимания работы блочных итераторов совершенно не нужно знать, какой "паттерн" они реализуют. (Вот, кстати, какой? Где книжка, в которой можно про него прочитать?) Мне достаточно просто знать их устройство.

А что значит "знать устройство" ? Это уже собственно конкретный паттерн.

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

Если не вдумываться, чисто по чужому рецепту, то да.

S>Ваши рассуждения про "простое и эффективное", простите, чушь. Простое решение — это то, которое легко читать. Чтобы его построить, не надо заглядывать внутрь. Надо понимать, что именно делает данный инструмент, вот и всё.

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

S>А важность априорное знание внутреннего устройства всего для построения эффективных решений сильно преувеличена. Скажем, Эрик Липперт, входящий в число авторов шарповых трюков, считает, что его догадки об эффективности тех или иных алгоритмов без запуска профайлера ничего не стоят.

Для доказательства твоей гипотезы нужно взять одного человека, который вообще не будет в курсе деталей реализации С# даже на интуитивном уровне и сможет эффективно решать задачи на этом самом C#.

I>>Далее нужно знать эти паттерны что бы создавать новые инструменты. Ну и для работы со специфическими задачами так же надо знать паттерны.
S>

Создание инструментов и использование инструментов — разные вещи.

Инженеру нужно как минимум и то и другое.

I>>Например, если ты вдруг проводишь отладку в windbg то сильно врядли он даст тебе C#, скорее всего тебе придется работать с теми паттернами, которые, как ты сказал, не нужны. Опаньки !!!
S>Эту фразу я, простите, не понял.
S>1. Скажите, в какой момент мне потребуются знания об Observer Pattern при отладке C#-кода под windbg?

Тут был паттерн "вызов функции". В windbg тебе придется иметь с этим дело.

S>2. Почему это вдруг windbg мне сильно вряд ли даст C#? Куда из него делась отладка исходников?

Когда доходит дело до windbg это почти всегда значит, что проблема тухлая, например косяки с вызовами нативных методов или даже косяки в самих нативных методах.

S>3. Скажите честно, вы сами сколько раз отлаживали своё приложение под windbg? Вы вправду думаете, что это настолько важный сценарий, что оправдывает изучение паттернов?

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

Здравствуйте, Ikemefula, Вы писали:

I>WH совершенно точно имеет ввиду под паттернами чтото своё. Для него любая копипаста это и есть паттер, а паттерн(если это не ViewModel) и есть копипаста.
В чём-то я с ним согласен. Паттерн, как решение, воплощённое в коде — это именно копипаста и есть. Когда у нас не хватает языковых средств для того, чтобы подготовить удобное решение для задачи оповещения об изменениях, мы садимся и пишем на естественном языке паттерн "Обзёрвер". И миллионы хомячков начинают копи-пейстить это решение, заменяя имена классов и сигнатуры методов.
Но я не вижу, где бы он утверждал, что любая копипаста — это сразу паттерн.
I>Между тем в GoF есть четкое разделение, где копипаста а где паттерн.
Можно мне процитировать это чёткое разделение?

I>Мне не нравится подход фаулера и гоф, нужно обязательно учитывать, что паттерны нужны для поиска и принятия решений, то есть, это некоторая модель наших представлений о некоторой области знаний.
Нет. Не нужны эти паттерны для поиска и принятия решений. Ещё раз: это всего лишь некоторые приёмы, типовые способы комбинировать низкоуровневые инструменты для решения задач чуть более высокого уровня. Они нужны только в том случае, когда вы ищете решение проблемы на некотором языке, лишённом встроенных средств нужного вам уровня.
Вот скажите, на какой хрен вам нужен паттерн "вызов подпрограммы" для поиска и принятия каких-то решений? Ну, если вы не в ледяной пустыне, наедине с RISC-процессором, у которого нет даже инструкции call и регистра ESP?
Волшебным образом оказывается, что 99.999% архитекторов прекрасно обходятся без этого паттерна ещё с пятидесятых годов. Эта наблюдаемая действительность полностью противоречит вашим утверждениям.

I>Это конкретный паттерн. Что с ним не так ?
То, что он вовсе не "паттерн архитектуры", который применим до того, как выбран язык программирования.
Он выражен в терминах конкретных инструментов — подразумевается наличие определённой модели ООП, и отсутствие более удобных инструментов вроде замыканий.

I>Паттернам нужно не обучать, паттерны нужно выращивать путем скармливания обучаемому N-задач определенной специфики. Если просто выдавать типовые решения, то это приводит к том, что люди строят домики-огородики из паттернов.
Давайте ещё раз посмотрим на C#. В него встроили множество "паттернов", которые программисты на более консервативных языках были вынуждены выпиливать вручную. Что, это привело к тому, что люди строят домики-огородики из using/iterator block/foreach/event/property?
Лично я такого не наблюдаю.

I>Хорошо, задача это просто задача, какая есть. Но есть текущий набор ограничений. Задачу мы решаем именно в этих рамках, а не в идеальных условиях на идеальном ЯП.
Вот мы и подобрались к сути. Именно это вам и объясняет Wolfhound — что можно не молиться на текущий набор ограничений, а решать задачу сразу в идеальных условиях на идеальном ЯП. В этом идеальном ЯП вместо того, чтобы устно описывать приёмы типа "возьмите класс, сделайте у него метод, отнаследуйтесь от бла-бла-бла", можно просто добавить элемент языка, который всё это делает сразу. И писать нелитературу, а руководство пользователя.

I>Слоистый коктейль и есть паттерн. Он нужен для поиска и принятия решения и очевидно он не есть решение. Как получить решение с помощью этого паттерна, я уже показал. В чем польза — тоже показал.
Неубедительно.

I>А что значит "знать устройство" ? Это уже собственно конкретный паттерн.
Это не паттерн. Иначе любой библиотечный код внезапно становится паттерном.
Устройство — это ровно то, о чём вы тут пишете: в какой именно конечный код разворачиваются все эти yield return.

I>Вот это самое понимание и даёт на выходе паттерны.
Паттерны получаются разными. Если вас оставить без yield return, то вы, возможно, когда-то и изобретёте паттерн "ручная реализация ленивого IEnumerator<T> на основе конечного автомата". А вот если у вас есть yield return в языке, вы имеете шанс изобрести паттерн типа "запись ленивого асинхронного алгоритма в виде энергичного синхронного", и применять его к задачам типа такой.
Обратите внимание: для изобретения этого паттерна совершенно ненужно знать, как именно внутри реализуется yield return. Это вообще мало кто знает досконально — так, в общих чертах. Делать такой же код вручную вообще никто не будет.

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

I>Для доказательства твоей гипотезы нужно взять одного человека, который вообще не будет в курсе деталей реализации С# даже на интуитивном уровне и сможет эффективно решать задачи на этом самом C#.
Вы под термином "эффективно" что имеете в виду? С приемлемой производительностью?
Я вас разочарую: 90% разработчиков С# имеют очень отдалённое представление о деталях реализации.

I>Тут был паттерн "вызов функции". В windbg тебе придется иметь с этим дело.
Ок, пусть будет "вызов функции". В какой момент в windbg мне придётся иметь дело с этим паттерном?

S>>2. Почему это вдруг windbg мне сильно вряд ли даст C#? Куда из него делась отладка исходников?
I>Когда доходит дело до windbg это почти всегда значит, что проблема тухлая, например косяки с вызовами нативных методов или даже косяки в самих нативных методах.
И? Неужели вы думаете, что windbg не покажет исходники нативных методов?
I>Много раз, правда это был немного другой отладчик. Например если дебуггер останавливается хрен знает где, мне нужно хотя бы приблизительно сказать, чего там происходит.
Отлично. То есть мы вернулись к моему же утверждению про то, что иногда, в процессе отладки особенно злостных багов, инженеры таки внезапно узнают значительно больше подробностей о том, как что работает, чем до этого.
К сожалению, это работает и в обратную сторону: до тех пор, пока у вас нет баги, которую нужно расследовать, заучивание деталей устройства используемого инструмента вам ничего не даст.
А вы как раз пытаетесь меня убедить, что ещё при разработке архитектуры (!) мне обязательно нужно знать паттерны, иначе я не смогу найти решение. Это находится на максимально противоположном конце спектра программистских обязанностей.

Здравствуйте, Sinclair, Вы писали:

I>>WH совершенно точно имеет ввиду под паттернами чтото своё. Для него любая копипаста это и есть паттер, а паттерн(если это не ViewModel) и есть копипаста.
S>В чём-то я с ним согласен. Паттерн, как решение, воплощённое в коде — это именно копипаста и есть. Когда у нас не хватает языковых средств для того, чтобы подготовить удобное решение для задачи оповещения об изменениях, мы садимся и пишем на естественном языке паттерн "Обзёрвер". И миллионы хомячков начинают копи-пейстить это решение, заменяя имена классов и сигнатуры методов.
S>Но я не вижу, где бы он утверждал, что любая копипаста — это сразу паттерн.

Например,

А паттерн это вот это говнокод
if (a != b)
{
throw new Exception(string.Format("Хотели {0}, а получилось {1}",a,b));
}
Который еще и условие заставляет инвертировать.

Где тут паттерн — мне не ясно. Зато ясно, что WH считает такой говнокод паттерном.

I>>Между тем в GoF есть четкое разделение, где копипаста а где паттерн.
S>Можно мне процитировать это чёткое разделение?

Буквально там нет такой фразы, но они везде упоминают например reusable, flexible design. Насколько я понимаю, копипаста не является ни reusable ни flexible.

I>>Мне не нравится подход фаулера и гоф, нужно обязательно учитывать, что паттерны нужны для поиска и принятия решений, то есть, это некоторая модель наших представлений о некоторой области знаний.
S>Нет. Не нужны эти паттерны для поиска и принятия решений. Ещё раз: это всего лишь некоторые приёмы, типовые способы комбинировать низкоуровневые инструменты для решения задач чуть более высокого уровня. Они нужны только в том случае, когда вы ищете решение проблемы на некотором языке, лишённом встроенных средств нужного вам уровня.

Описания у фаулера и гоф не нужны для поиска и принятия решений, а паттерны — нужны. http://kolesnik.ru/2006/pattern/

S>Вот скажите, на какой хрен вам нужен паттерн "вызов подпрограммы" для поиска и принятия каких-то решений? Ну, если вы не в ледяной пустыне, наедине с RISC-процессором, у которого нет даже инструкции call и регистра ESP?
S>Волшебным образом оказывается, что 99.999% архитекторов прекрасно обходятся без этого паттерна ещё с пятидесятых годов. Эта наблюдаемая действительность полностью противоречит вашим утверждениям.

Именно этот паттерн не нужен в большинстве насущных задач.

I>>Это конкретный паттерн. Что с ним не так ?
S>То, что он вовсе не "паттерн архитектуры", который применим до того, как выбран язык программирования.
S>Он выражен в терминах конкретных инструментов — подразумевается наличие определённой модели ООП, и отсутствие более удобных инструментов вроде замыканий.

"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."

I>>Паттернам нужно не обучать, паттерны нужно выращивать путем скармливания обучаемому N-задач определенной специфики. Если просто выдавать типовые решения, то это приводит к том, что люди строят домики-огородики из паттернов.
S>Давайте ещё раз посмотрим на C#. В него встроили множество "паттернов", которые программисты на более консервативных языках были вынуждены выпиливать вручную. Что, это привело к тому, что люди строят домики-огородики из using/iterator block/foreach/event/property?
S>Лично я такого не наблюдаю.

Я про обучение. Дать человеку C# это совсем не тоже что обучить паттернам и ждать что он не будет изобретать велосипед. Я видел около десятка реализаций Observer на C# все до одной уникальные и все из них я заменил на обычный эвент. Последний раз в прошлом месяце кстати говоря.
Для того, что бы человек прекратил изобретать велосипеды Observer, нужно обязательно прокачать этот паттерн и показать, как он реализован хотя бы в C#. Тогда в голове будет всего лишь нечто, чему соответсвует (с некоторой стпенью точности) "Observer:Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." и как только человек задетектил факт использования этого паттерна, результатом будет решение в подходящем виде в зависимости от контекста(ЯП и тд и тд).

I>>Хорошо, задача это просто задача, какая есть. Но есть текущий набор ограничений. Задачу мы решаем именно в этих рамках, а не в идеальных условиях на идеальном ЯП.
S>Вот мы и подобрались к сути. Именно это вам и объясняет Wolfhound — что можно не молиться на текущий набор ограничений, а решать задачу сразу в идеальных условиях на идеальном ЯП. В этом идеальном ЯП вместо того, чтобы устно описывать приёмы типа "возьмите класс, сделайте у него метод, отнаследуйтесь от бла-бла-бла", можно просто добавить элемент языка, который всё это делает сразу. И писать нелитературу, а руководство пользователя.

I>>Слоистый коктейль и есть паттерн. Он нужен для поиска и принятия решения и очевидно он не есть решение. Как получить решение с помощью этого паттерна, я уже показал. В чем польза — тоже показал.
S>Неубедительно.

А я тебя и не убеждаю вобще говоря

I>>А что значит "знать устройство" ? Это уже собственно конкретный паттерн.
S>Это не паттерн. Иначе любой библиотечный код внезапно становится паттерном.

Я уже говорил, паттерны позволяют искать решение не вдаваясь в детали.

S>Устройство — это ровно то, о чём вы тут пишете: в какой именно конечный код разворачиваются все эти yield return.

Сам код в деталях не важен.

I>>Вот это самое понимание и даёт на выходе паттерны.
S>Паттерны получаются разными. Если вас оставить без yield return, то вы, возможно, когда-то и изобретёте паттерн "ручная реализация ленивого IEnumerator<T> на основе конечного автомата". А вот если у вас есть yield return в языке, вы имеете шанс изобрести паттерн типа "запись ленивого асинхронного алгоритма в виде энергичного синхронного", и применять его к задачам типа такой.
S>Обратите внимание: для изобретения этого паттерна совершенно ненужно знать, как именно внутри реализуется yield return. Это вообще мало кто знает досконально — так, в общих чертах. Делать такой же код вручную вообще никто не будет.

Нету шансов если ты не знаешь что такое блочный итератор как ты говоришь "в общих чертах", все что тебе нужно — это название паттерна который реализует этот yield. Всё. Если ты не знаешь этого или с этим паттерном работал мало, никогда и ни при каких условиях тебе не видать эффективного решения.
Максимум — долгие годы изобретений велосипедов пока не прокачаешь нужную область.

I>>У человека мозг не умеет работать в жостко заданых рамках — сюда заглядывать, сюда не заглядывать. Для поиска и принятия решения может понадобиться вообще все что угодно.
S>Вы делаете странный переход. Из более-менее бесспорного утверждения "может понадобиться вообще все что угодно" вы делаете аргумент для "паттерны обязательно нужно изучать". Проиллюстрирую логический изъян: совершенно аналогичным образом для поиска и принятия решения может потребоваться умение закидывать ногу за голову. Неужели вы считаете, что этого достаточно для пропаганды гимнастического экстремизма среди архитекторов?

Это никакой не изъян

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

I>>Для доказательства твоей гипотезы нужно взять одного человека, который вообще не будет в курсе деталей реализации С# даже на интуитивном уровне и сможет эффективно решать задачи на этом самом C#.
S>Вы под термином "эффективно" что имеете в виду? С приемлемой производительностью?

Эффект с учетом затрат в условных единицах.

S>Я вас разочарую: 90% разработчиков С# имеют очень отдалённое представление о деталях реализации.

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

I>>Тут был паттерн "вызов функции". В windbg тебе придется иметь с этим дело.
S>Ок, пусть будет "вызов функции". В какой момент в windbg мне придётся иметь дело с этим паттерном?

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

S>>>2. Почему это вдруг windbg мне сильно вряд ли даст C#? Куда из него делась отладка исходников?
I>>Когда доходит дело до windbg это почти всегда значит, что проблема тухлая, например косяки с вызовами нативных методов или даже косяки в самих нативных методах.
S>И? Неужели вы думаете, что windbg не покажет исходники нативных методов?

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

I>>Много раз, правда это был немного другой отладчик. Например если дебуггер останавливается хрен знает где, мне нужно хотя бы приблизительно сказать, чего там происходит.
S>Отлично. То есть мы вернулись к моему же утверждению про то, что иногда, в процессе отладки особенно злостных багов, инженеры таки внезапно узнают значительно больше подробностей о том, как что работает, чем до этого.
S>К сожалению, это работает и в обратную сторону: до тех пор, пока у вас нет баги, которую нужно расследовать, заучивание деталей устройства используемого инструмента вам ничего не даст.

В обратную не работает. Инженеру очень важно понимаеть как что работает.

S>А вы как раз пытаетесь меня убедить, что ещё при разработке архитектуры (!) мне обязательно нужно знать паттерны, иначе я не смогу найти решение. Это находится на максимально противоположном конце спектра программистских обязанностей.

Вопрос не в том, сможешь или нет, а в том сколько времени и труда на это положишь и каким будет качество решения. Паттерны дают тебе возможность перебирать возможныерешения руководствуюясь минимумом деталей. Что очевидно — системы еще нет, детялями она полностью обрастет только по окончании реализации, зато решение можно искать .

Здравствуйте, Sinclair, Вы писали:

I>>Тут был паттерн "вызов функции". В windbg тебе придется иметь с этим дело.
S>Ок, пусть будет "вызов функции". В какой момент в windbg мне придётся иметь дело с этим паттерном?

Вот хороший пример — http://rsdn.ru/forum/philosophy/4871897.1.aspx

Здравствуйте, Sinclair, Вы писали:

Ф>>1) паттерны рождаются в процессе решения задачи, а не живут сами по себе...
Ф>>2) сами паттерны в связи предыдущим пунктом выполняют коммуникативную функцию, т.е. название паттерна в идеальном случае описывает решаемую задачу и способ её решение кратким ёмким термином, а потому языковые навороты (в ЯВУ) лишь упрощают их реализацию, но не отменяют необходимых знаний

S>Омг, омг. То есть вы считаете, что необходимо ознакомиться с паттерном Observer, чтобы пользоваться event-ами в дотнете?
S>Меня мучают смутные сомнения.

Нет, просто желательно знать название и назначение этого паттерна и реализацию этого паттерна в языке.
Во-первых для того, чтобы уметь объяснить своё решение другому разработчику, возможно пишущему на другом ЯП, своё решение.
Во-вторых, для того, чтобы не изобретать велосипед(ы) и не писать Publisher-Subscriber вручную (очень это плюсисты и явисты это любят при переходе на C#).

Здравствуйте, Sinclair, Вы писали:

S>Это мелкие недостатки конкретной реализации.

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

Здравствуйте, Ikemefula, Вы писали:

I>Где тут паттерн — мне не ясно. Зато ясно, что WH считает такой говнокод паттерном.
Странно. А как раз мне — всё ясно. Это же паттерн assert, который приходится лепить вот в таком виде при отсутствии в языке понятия assert. В С++ такой копипейст традиционно реализуется при помощи макросов.

I>Буквально там нет такой фразы, но они везде упоминают например reusable, flexible design. Насколько я понимаю, копипаста не является ни reusable ни flexible.
Мне непонятен ваш ход мысли. Копипаста является reusable по определению, и flexible по факту.

I>Описания у фаулера и гоф не нужны для поиска и принятия решений, а паттерны — нужны. http://kolesnik.ru/2006/pattern/
Вы жонглируете понятиями. Давайте я приведу ссылку на понятие "паттерн" из вышивальной практики, и буду ссылаться на него при обсуждении свойств паттернов софтостроения.

S>>Волшебным образом оказывается, что 99.999% архитекторов прекрасно обходятся без этого паттерна ещё с пятидесятых годов. Эта наблюдаемая действительность полностью противоречит вашим утверждениям.
I>Именно этот паттерн не нужен в большинстве насущных задач.
Вы шутите? В моём опыте в 99.999999999% систем понятие "вызов подпрограммы" используется в полный рост и играет значительную роль в архитектуре.

I>"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."
И? Вам что, непонятно, что здесь сразу делается предположение о наличии объектов с изменяемым состоянием? И это несмотря на то, что в процитированном виде паттерн совершенно бесполезен, как и приведённый AVK "паттерн" Стратегия. Вместо решения опять имеем задачу. Вот нам нужно сделать так, чтобы состояние N объектов менялось в зависимости от изменения состояния одного объекта. Что имеем? Офигенное решение: "давайте зададим зависимость так, чтобы состояние N объектов менялось в зависимости от изменения состояния одного объекта.
Знаете, любой так может решать любые задачи. "Как сверстать бюджет РФ без дефицита?" — "Определите размер каждой расходной статьи бюджета так, чтобы их сумма не превышала сумму размеров доходных статей".
К счастью, в настоящих паттернах всё же приводят решение, а не только формулировку задачи.

I>Я про обучение. Дать человеку C# это совсем не тоже что обучить паттернам и ждать что он не будет изобретать велосипед. Я видел около десятка реализаций Observer на C# все до одной уникальные и все из них я заменил на обычный эвент. Последний раз в прошлом месяце кстати говоря.
I>Для того, что бы человек прекратил изобретать велосипеды Observer, нужно обязательно прокачать этот паттерн и показать, как он реализован хотя бы в C#.
А может быть, просто надо рассказать человеку про event?

Тогда в голове будет всего лишь нечто, чему соответсвует (с некоторой стпенью точности) "Observer:Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." и как только человек задетектил факт использования этого паттерна, результатом будет решение в подходящем виде в зависимости от контекста(ЯП и тд и тд).
Что вы называете "фактом использования паттерна"? Постановку задачи, или готовое решение?

I>Я уже говорил, паттерны позволяют искать решение не вдаваясь в детали.
Нет, не позволяют.

I>Сам код в деталях не важен.
Вы только что писали мне ровно противоположное. А как же windbg?

I>Нету шансов если ты не знаешь что такое блочный итератор как ты говоришь "в общих чертах", все что тебе нужно — это название паттерна который реализует этот yield. Всё. Если ты не знаешь этого или с этим паттерном работал мало, никогда и ни при каких условиях тебе не видать эффективного решения.
Этот поток сознания я не понял, простите.

I>Это никакой не изъян

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

I>Эффект с учетом затрат в условных единицах.
Что вы считаете эффектом? Что вы считаете затратами?

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

I>Когда дебуггер выбросит тебя в нативный код и тебе нужно будет понять хотя бы приблизительно, что же там происходит, а может даже накидать пару строчек этого кода.
Какого кода? На ассемблере?
I>Есть некоторые сомнения, что исходники всех возможных нативных модулей входят в поставку windbg.
Ну то есть вы придумали изолированный пример, который встречается один-два раза в жизни, и то не всем.
И на основании этого вы вправду считаете, что нельзя допускать к разработке и проектированию людей, не владеющих ассемблером? Экстремальненько.

I>В обратную не работает. Инженеру очень важно понимаеть как что работает.
И какое отношение к этому имеют паттерны? Особенно в любимом вами виде "ни о чём"?

I>Вопрос не в том, сможешь или нет, а в том сколько времени и труда на это положишь и каким будет качество решения. Паттерны дают тебе возможность перебирать возможныерешения руководствуюясь минимумом деталей. Что очевидно — системы еще нет, детялями она полностью обрастет только по окончании реализации, зато решение можно искать .
Простите, я не понимаю. Можно какой-то пример того, как я перебираю решения при помощи "паттернов"?

Здравствуйте, Ikemefula, Вы писали:

I>Вот хороший пример — http://rsdn.ru/forum/philosophy/4871897.1.aspx
А, ну в том, что для форумных срачей надо знать вообще всё, я никогда не сомневался.
А в том, что средний программист на Паскале никак не смог бы жить без знаний вот этих нюансов реализации, я сомневаюсь и сейчас.
Я написал очень большое количество кода на Паскале и Дельфи, ни разу не задумавшись о том, как же именно работает рекурсивный вызов для локальных процедур.

Здравствуйте, Философ, Вы писали:

Ф>Нет, просто желательно знать название и назначение этого паттерна и реализацию этого паттерна в языке.

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

Ф>Во-вторых, для того, чтобы не изобретать велосипед(ы) и не писать Publisher-Subscriber вручную (очень это плюсисты и явисты это любят при переходе на C#).
Для этого важно знать не паттерн, а само наличие event. Конечно, плюсисты и явисты делают всё вручную. А ещё они не любят цикл foreach, просто потому, что у них for(int i=0; i< count; i++) набирается на одном дыхании вслепую за 0.6 секунды.

Здравствуйте, Sinclair, Вы писали:

S>А, ну в том, что для форумных срачей надо знать вообще всё, я никогда не сомневался.
S>А в том, что средний программист на Паскале никак не смог бы жить без знаний вот этих нюансов реализации, я сомневаюсь и сейчас.
S>Я написал очень большое количество кода на Паскале и Дельфи, ни разу не задумавшись о том, как же именно работает рекурсивный вызов для локальных процедур.

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

Здравствуйте, Ikemefula, Вы писали:

I>Вот представь, ты пишешь легальынй код, практически как в мануале на который ты дал ссылку, только внезапно функция у тебя локальная...
Ну, вот на практике у меня ни разу не возникло локальной функции.
Сейчас вот разгребаю код чужого проекта. Там локальных функций — горы. Но они нигде не передаются по ссылке. В принципе не используется этот приём.

Здравствуйте, Sinclair, Вы писали:

I>>Где тут паттерн — мне не ясно. Зато ясно, что WH считает такой говнокод паттерном.
S>Странно. А как раз мне — всё ясно. Это же паттерн assert, который приходится лепить вот в таком виде при отсутствии в языке понятия assert. В С++ такой копипейст традиционно реализуется при помощи макросов.

А что, Assert.IsTrue(a != b) уже рокет саенс и надо обяательно писать говнокод ?

I>>Буквально там нет такой фразы, но они везде упоминают например reusable, flexible design. Насколько я понимаю, копипаста не является ни reusable ни flexible.
S>Мне непонятен ваш ход мысли. Копипаста является reusable по определению, и flexible по факту.

на счет reusable я погорячился

flexible — возможность легко и быстро привести код в соответствие изменяющимся требованиям.
Проверяем твое высказывани — копипастим код под конкретный набор требований и меняем требования.
Если копипаста flexible, то не составит труда внести изменения.

I>>Описания у фаулера и гоф не нужны для поиска и принятия решений, а паттерны — нужны. http://kolesnik.ru/2006/pattern/
S>Вы жонглируете понятиями. Давайте я приведу ссылку на понятие "паттерн" из вышивальной практики, и буду ссылаться на него при обсуждении свойств паттернов софтостроения.

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

S>>>Волшебным образом оказывается, что 99.999% архитекторов прекрасно обходятся без этого паттерна ещё с пятидесятых годов. Эта наблюдаемая действительность полностью противоречит вашим утверждениям.
I>>Именно этот паттерн не нужен в большинстве насущных задач.
S>Вы шутите? В моём опыте в 99.999999999% систем понятие "вызов подпрограммы" используется в полный рост и играет значительную роль в архитектуре.

Цитирую себя: "функция в детстве была паттерном 'вызов подпрограммы'"

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

I>>"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."
S>И? Вам что, непонятно, что здесь сразу делается предположение о наличии объектов с изменяемым состоянием? И

Здесь нет ничего про ЯП. Например нельзя сказать, C# это, С++ или Java или F#.

>это несмотря на то, что в процитированном виде паттерн совершенно бесполезен, как и приведённый AVK "паттерн" Стратегия. Вместо решения опять имеем задачу. Вот нам нужно сделать так, чтобы состояние N объектов менялось в зависимости от изменения состояния одного объекта. Что имеем? Офигенное решение: "давайте зададим зависимость так, чтобы состояние N объектов менялось в зависимости от изменения состояния одного объекта.
S>Знаете, любой так может решать любые задачи. "Как сверстать бюджет РФ без дефицита?" — "Определите размер каждой расходной статьи бюджета так, чтобы их сумма не превышала сумму размеров доходных статей".
S>К счастью, в настоящих паттернах всё же приводят решение, а не только формулировку задачи.

Я привел основную часть и этого достаточно что бы найти решение, потому что паттерн сам по себе решением не является и являться не может.

I>>Я про обучение. Дать человеку C# это совсем не тоже что обучить паттернам и ждать что он не будет изобретать велосипед. Я видел около десятка реализаций Observer на C# все до одной уникальные и все из них я заменил на обычный эвент. Последний раз в прошлом месяце кстати говоря.
I>>Для того, что бы человек прекратил изобретать велосипеды Observer, нужно обязательно прокачать этот паттерн и показать, как он реализован хотя бы в C#.
S>А может быть, просто надо рассказать человеку про event?

Я выбросил слишком много обсерверов в проектах на C# что бы поверить в магию "рассказать человеку про event".
Рассказать это слишком мало, нужно что бы человек прочувствовал event своими руками, а потом прочувствовал этими же руками разницу между event и самопальным Observer. А далее ему надо дать несколько задач что бы он сам свел их к обсерверу.
Вот так — работает !

S>Тогда в голове будет всего лишь нечто, чему соответсвует (с некоторой стпенью точности) "Observer:Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." и как только человек задетектил факт использования этого паттерна, результатом будет решение в подходящем виде в зависимости от контекста(ЯП и тд и тд).
S>Что вы называете "фактом использования паттерна"? Постановку задачи, или готовое решение?

Проблема + некоторое решение.

I>>Я уже говорил, паттерны позволяют искать решение не вдаваясь в детали.
S>Нет, не позволяют.

Я привел описание, покажи что в нем не так для той задачи что я упомянул: Слоистый коктейль -> справочник по плотности напитков -> список рецептов -> план работ/закупок.

I>>Сам код в деталях не важен.
S>Вы только что писали мне ровно противоположное. А как же windbg?

Это про конкретный паттерн — вызов подпрограммы и пример реализации для x86. Пример реализации естественно конкретный, с деталями.

I>>Нету шансов если ты не знаешь что такое блочный итератор как ты говоришь "в общих чертах", все что тебе нужно — это название паттерна который реализует этот yield. Всё. Если ты не знаешь этого или с этим паттерном работал мало, никогда и ни при каких условиях тебе не видать эффективного решения.
S>Этот поток сознания я не понял, простите.

Бывает.

I>>Это никакой не изъян

Как минимум со времен Ньютона известно, что к решению может приводить даже падение яблока на голову. Очевидно, у нас нет такой фичи, которая могла бы сказать, в каких направлениях надо копать что бы найти решение.
S>Тем не менее, учёные не занимаются ронянием на головы яблок, пытаясь уподобиться Ньютону. Вас это не удивляет?

Яблоки может и не роняют, но активно используют самые разные приемы для решения своих задач. И я уже ответил, что нет функции которая выдаст направление поиска для любой задачи.
Факт что этот вырожденый случай вполне вписывается в мою теорию

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

I>>Эффект с учетом затрат в условных единицах.
S>Что вы считаете эффектом? Что вы считаете затратами?

Эффект — решение проблемы. Затраты — время на реализацию, майнтенанс и суппорт помножить на ЗП.
Пример из жизни:
Некто закомитал некоторую фичу потратив месяц и этот код до сих пор имеет одну ревизию, реюзается, при чем мигрировл в другие проекты практически без изменений
Другой некто на другом проекте закоммитал почти такой же функционал но за два часа, при этом за два года вышло более двух сотен коммитов.
Две сотни коммитов за два года это значит, что в среднем два раза в неделю в этом коде надо фиксить баги, то есть, это фактически throtling.
Добавить к этому время всех людей вовлеченных в рабочий цикл и получится вполне конкретная картина.

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

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

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

Вопрос в том, как разработчик не имея твоего багажа выдать точно такое же решение. У тебя есть ответ ?

I>>Когда дебуггер выбросит тебя в нативный код и тебе нужно будет понять хотя бы приблизительно, что же там происходит, а может даже накидать пару строчек этого кода.
S>Какого кода? На ассемблере?

Да.

I>>Есть некоторые сомнения, что исходники всех возможных нативных модулей входят в поставку windbg.
S>Ну то есть вы придумали изолированный пример, который встречается один-два раза в жизни, и то не всем.
S>И на основании этого вы вправду считаете, что нельзя допускать к разработке и проектированию людей, не владеющих ассемблером? Экстремальненько.

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

I>>В обратную не работает. Инженеру очень важно понимаеть как что работает.
S>И какое отношение к этому имеют паттерны? Особенно в любимом вами виде "ни о чём"?

I>>Вопрос не в том, сможешь или нет, а в том сколько времени и труда на это положишь и каким будет качество решения. Паттерны дают тебе возможность перебирать возможныерешения руководствуюясь минимумом деталей. Что очевидно — системы еще нет, детялями она полностью обрастет только по окончании реализации, зато решение можно искать .
S>Простите, я не понимаю. Можно какой-то пример того, как я перебираю решения при помощи "паттернов"?

см про слоистый коктейль и блочные итераторы.

Здравствуйте, Sinclair, Вы писали:

I>>Вот представь, ты пишешь легальынй код, практически как в мануале на который ты дал ссылку, только внезапно функция у тебя локальная...
S>Ну, вот на практике у меня ни разу не возникло локальной функции.
S>Сейчас вот разгребаю код чужого проекта. Там локальных функций — горы. Но они нигде не передаются по ссылке. В принципе не используется этот приём.

Значит код старый. Как выяснилось, даже вниз передавать эти локальные функции было сильно сложно

Здравствуйте, Sinclair, Вы писали:

Ф>>Во-вторых, для того, чтобы не изобретать велосипед(ы) и не писать Publisher-Subscriber вручную (очень это плюсисты и явисты это любят при переходе на C#).
S>Для этого важно знать не паттерн, а само наличие event. Конечно, плюсисты и явисты делают всё вручную. А ещё они не любят цикл foreach, просто потому, что у них for(int i=0; i< count; i++) набирается на одном дыхании вслепую за 0.6 секунды.

Это четко доказывает что само знание о наличии event как минимум недостаточно.

Здравствуйте, Ikemefula, Вы писали:

I>Цитирую себя: "функция в детстве была паттерном 'вызов подпрограммы'"

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Цитирую себя: "функция в детстве была паттерном 'вызов подпрограммы'"

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

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

Здравствуйте, Ikemefula, Вы писали:

I>А что, Assert.IsTrue(a != b) уже рокет саенс и надо обяательно писать говнокод ?
Нет, не обязательно. Но когда мы видим многократно повторённый код, приведённый WH, мы прозреваем наличие паттерна, даже если его никто заранее не описал.

I>на счет reusable я погорячился

I>flexible — возможность легко и быстро привести код в соответствие изменяющимся требованиям.
Это вы, имхо, только что сами придумали. У банды про вот это как раз ничего нет. Потому что их паттерны никак не позволяют "легко и быстро привести код в соответствие изменяющимся требованиям". Там скорее про то, что можно "согнуть под конкретное место использования".

I>Проверяем твое высказывани — копипастим код под конкретный набор требований и меняем требования.
I>Если копипаста flexible, то не составит труда внести изменения.
Ну, давайте пример изменения требований. И посмотрим, каков труд в случае "копипасты", и каков — в случае "ГоФ".

I>Я с самого начала говорю о том, откуда берутся паттерны и почему они актуальны. Практически все что сказано в этой статье при паттерны, применимо к паттернам из GoF. Вероятно ты понимаешь паттерн именно как фиксированое описание

Я уже привёл своё определение паттерна. Вы внезапно присылаете ссылку на "паттерны мышления", которая про совершенно другие вещи с похожим названием. Понимаете? Из того, что баран и овца похожи, никак не следует похожесть баранки и овчарки. Такое жонглирование терминами вас никуда не приведёт.
I>Реализация паттерна перекочевала в язык и с этого момента стала абстракцией, это естественный процесс, я повторяю это уже раз наверное пяццот.
Вы это не повторяете, а пытаетесь спорить ровно с этим утверждением. Это мы с WH утверждаем, что паттерны должны перекочевать в язык и стать абстракцией, и с этого момента сами паттерны нафиг не нужны в 99.99999% случаев. А вы притягиваете за уши любые аргументы, лишь бы с этим поспорить.

I>Здесь нет ничего про ЯП. Например нельзя сказать, C# это, С++ или Java или F#.
Здесь очень много про ЯП. Можно сказать, что это точно не дотнет (т.к. этот паттерн в дотнете нахрен не упал, при наличии готовой абстракции), и точно не SQL (потому что там нет объектов), и точно не чистый функциональный язык, т.к. там нет изменяемого состояния.
Итого, остаётся С++ либо Джава — что интуитивно было понятно с самого начала, т.к. именно под них и затачивала свои паттерны Банда. И стыдливые попытки спрятать этот факт за туманностью формулировок не помогают.

I>Я привел основную часть и этого достаточно что бы найти решение, потому что паттерн сам по себе решением не является и являться не может.
Да ладно. Может вы всё же посмотрите определение термина Паттерн — хотя бы в wiki?

I>Я выбросил слишком много обсерверов в проектах на C# что бы поверить в магию "рассказать человеку про event".
I>Рассказать это слишком мало, нужно что бы человек прочувствовал event своими руками, а потом прочувствовал этими же руками разницу между event и самопальным Observer. А далее ему надо дать несколько задач что бы он сам свел их к обсерверу.
Судя по вашему описанию, эти люди не знали про event, зато знали паттерн Observer. Что служит аргументом в пользу меня — то есть того, что учить паттернам вреднее, чем учить языку.
Точно так же я могу ожидать того, что дельфист-новичок, начитавшись ГоФ, может броситься писать классы фабрик, вместо того, чтобы изучить TClass и виртуальные конструкторы.

S>>Тогда в голове будет всего лишь нечто, чему соответсвует (с некоторой стпенью точности) "Observer:Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." и как только человек задетектил факт использования этого паттерна, результатом будет решение в подходящем виде в зависимости от контекста(ЯП и тд и тд).
S>>Что вы называете "фактом использования паттерна"? Постановку задачи, или готовое решение?
I>Проблема + некоторое решение.
Ок. Вы предлагаете переходить к решению от "Проблема + некоторое решение"? Зачем, если решение уже есть?

I>Я привел описание, покажи что в нем не так для той задачи что я упомянул: Слоистый коктейль -> справочник по плотности напитков -> список рецептов -> план работ/закупок.
То, что вы решили задачу крайне неэффективно. Для сформулированной вами задачи достаточно нагуглить рецепт коктейля Б-52, или мохито, или ещё чего-то конкретного. А ваше "решение" (в котором решения-то и нету — где коктейль??? У вас пока что только план по построению плана) запросто может привести к коктейлю из растительного масла и кока-колы, которым можно удивить только в неприятном смысле.

I>Яблоки может и не роняют, но активно используют самые разные приемы для решения своих задач. И я уже ответил, что нет функции которая выдаст направление поиска для любой задачи.
Совершенно верно. Нет такой функции.

I>Факт что этот вырожденый случай вполне вписывается в мою теорию

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

I>Эффект — решение проблемы. Затраты — время на реализацию, майнтенанс и суппорт помножить на ЗП.
А, то есть вас интересуют затраты на стороне программиста. Уже хорошо (странно, что вы так долго сопротивлялись попыткам это выяснить), а то в этом форуме некоторые считают "затратами" косвенность вызовов.
Отлично. Для этих затрат есть вполне приличные эмпирические метрики. Эффекты первого порядка — это просто размер кода.
Поэтому подпрограмма всегда лучше, чем копи-пейст.
Эффекты второго порядка — контроль компилятора. Поэтому нативно поддержанная абстракция всегда лучше, чем подпрограмма с неизвестной компилятору семантикой.
Скажем, в случае "говнокода" про ассерт, компилятор может нас предупредить про unreachable code, если мы заведомо нарушаем условие ассерта. То же самое можно сделать в случае нативной абстракции assert. В случае Assert.IsTrue() компилятор нам ничем не поможет — он понятия не имеет о том, что в случае вычисления аргумента в false будет брошено исключение и весь следующий код пойдёт лесом.

I>Ну вобще не ясно, как проверить какой набор знаний об этих итератора у тебя уже был заранее.
Придётся поверить мне на слово.

I>Вообще, зачем знать эти детали ? Паттерн избавляет тебя от этого. Если ты задетектил паттерн как ДКА, то и решение будет искаться именно с учетом ДКА. А если вдруг тебе пришло в голову короутина, то и решение будет искаться именно таким образом.
Я не понимаю этот набор слов. Я ничего не задетектил. Я просто заметил, что yield return превращает "энергичный" императивный код в "ленивый", позволяя вернуться к исполнению нашего императивного кода тогда, когда мы будем к этому готовы. Мне всё равно — ДКА там или демон Максвелла.
Просто есть удобная абстракция, с известными (из документации) наблюдаемыми свойствами.

I>Можно обойтись и без заглядывания непосредтсвенно в код, например если есть лет десять опыта и ты уже в курсе короутин, автоматов и прочих вещей, то из одного описания в мсдн + пару собственных попыток можно построить адекватную модель.
Мне не надо строить адекватную модель. Мне надо хорошо понимать, что за поведение у yield return. Многократные перечитывания GoF и Фаулера этому никак не помогут.

I>Вопрос в том, как разработчик не имея твоего багажа выдать точно такое же решение. У тебя есть ответ ?
Есть — учите матчасть. Под матчастью я понимаю знание того, как и для чего надо применять используемые инструменты.

I>Нельзя допускать к разработке людей, которые не понимают как работает виртуальная машина — так будет правильно. Для этого в университетах, что характерно даже в Мит и Стенфорде, студентов обучают довольно низкоуровневым вещам.
Какая виртуальная машина? Windbg не показывает виртуальных машин. Он показывает конкретный целевой код.
Нет, я не против того, чтобы это знать. Я вообще обоими руками за профайлеры и отладчики — но я не верю, что нужно всю жизнь готовиться к такому случаю.

S>>Простите, я не понимаю. Можно какой-то пример того, как я перебираю решения при помощи "паттернов"?
I>см про слоистый коктейль и блочные итераторы.
Оба примера говорят в мою пользу. См. выше.

Здравствуйте, Ikemefula, Вы писали:

I>Это четко доказывает что само знание о наличии event как минимум недостаточно.
Это понятно. Но это также доказывает, что самого знания о наличии Observer Pattern тоже недостаточно.
И из очевидных соображений мы понимаем, что знания о наличии event как минимум необходимо для того, чтобы им пользоваться.
Знания Observer Pattern необходимыми тут никак не являются.

Здравствуйте, Sinclair, Вы писали:

I>>Это четко доказывает что само знание о наличии event как минимум недостаточно.
S>Это понятно. Но это также доказывает, что самого знания о наличии Observer Pattern тоже недостаточно.
S>И из очевидных соображений мы понимаем, что знания о наличии event как минимум необходимо для того, чтобы им пользоваться.
S>Знания Observer Pattern необходимыми тут никак не являются.

Как минимум event включает в себя observer

Вот пример:

public void Update(OperationArgs args)
{
  foreach(var c in clients)
  {
    c.ProcessOperation(new Operation(args));
  }
}

На этом этапе можно задетектить и проверить сам обсервер, и далее предложить конкретную реализацию, например с помощью event

event OperationStatusHandler ProgressChanged;
...
ProgressChanged(this, new OperationStatusArgs());
...
publisher.ProgressChanged += (s,a) => { ... };

Здравствуйте, Sinclair, Вы писали:

I>>А что, Assert.IsTrue(a != b) уже рокет саенс и надо обяательно писать говнокод ?
S>Нет, не обязательно. Но когда мы видим многократно повторённый код, приведённый WH, мы прозреваем наличие паттерна, даже если его никто заранее не описал.

А если любой другой код многократно повторён ?

I>>на счет reusable я погорячился

I>>flexible — возможность легко и быстро привести код в соответствие изменяющимся требованиям.
S>Это вы, имхо, только что сами придумали. У банды про вот это как раз ничего нет. Потому что их паттерны никак не позволяют "легко и быстро привести код в соответствие изменяющимся требованиям". Там скорее про то, что можно "согнуть под конкретное место использования".

Изменения разумеется не любые а то и разговору не было.

I>>Проверяем твое высказывани — копипастим код под конкретный набор требований и меняем требования.
I>>Если копипаста flexible, то не составит труда внести изменения.
S>Ну, давайте пример изменения требований. И посмотрим, каков труд в случае "копипасты", и каков — в случае "ГоФ".

Мне это пока сложновато, осталось два дня до отпуска, так что извини.

I>>Я с самого начала говорю о том, откуда берутся паттерны и почему они актуальны. Практически все что сказано в этой статье при паттерны, применимо к паттернам из GoF. Вероятно ты понимаешь паттерн именно как фиксированое описание

S>Я уже привёл своё определение паттерна. Вы внезапно присылаете ссылку на "паттерны мышления", которая про совершенно другие вещи с похожим названием. Понимаете?

Я с самого начала говорил и говорю именно про это. Вещи эти никакие не другие, это вобщем одно и то же.

I>>Реализация паттерна перекочевала в язык и с этого момента стала абстракцией, это естественный процесс, я повторяю это уже раз наверное пяццот.
S>Вы это не повторяете, а пытаетесь спорить ровно с этим утверждением. Это мы с WH утверждаем, что паттерны должны перекочевать в язык и стать абстракцией, и с этого момента сами паттерны нафиг не нужны в 99.99999% случаев. А вы притягиваете за уши любые аргументы, лишь бы с этим поспорить.

Не паттерны, а их реализация. Ну реализовали скажем обсервер в языке. Что, автоматически все рукописные реализации исчезнут ? Это как минимум.

I>>Здесь нет ничего про ЯП. Например нельзя сказать, C# это, С++ или Java или F#.
S>Здесь очень много про ЯП. Можно сказать, что это точно не дотнет (т.к. этот паттерн в дотнете нахрен не упал, при наличии готовой абстракции), и точно не SQL (потому что там нет объектов), и точно не чистый функциональный язык, т.к. там нет изменяемого состояния.

Готовая абстракция не означает, что и все код будет ей соответствовать.

S>Итого, остаётся С++ либо Джава — что интуитивно было понятно с самого начала, т.к. именно под них и затачивала свои паттерны Банда. И стыдливые попытки спрятать этот факт за туманностью формулировок не помогают.

Возьми пролог и напиши аналог микрософт офиса со всеми приблудами, ну, хотя бы приблизительно. Внезапно, тебе потребуются все эти паттерны. А язык — пролог.

I>>Я привел основную часть и этого достаточно что бы найти решение, потому что паттерн сам по себе решением не является и являться не может.
S>Да ладно. Может вы всё же посмотрите определение термина Паттерн — хотя бы в wiki?

Решение с моей т.з. = код или подробная модель которую можно перевести в код. Обсервер например это ни то ни другое. И стратегия, и фабрика и тд и тд и тд. Вот конкретный UML для обсервера уже может считаться решением, но это, внезапно, не паттерн а уже реализация паттерна.

I>>Я выбросил слишком много обсерверов в проектах на C# что бы поверить в магию "рассказать человеку про event".
I>>Рассказать это слишком мало, нужно что бы человек прочувствовал event своими руками, а потом прочувствовал этими же руками разницу между event и самопальным Observer. А далее ему надо дать несколько задач что бы он сам свел их к обсерверу.
S>Судя по вашему описанию, эти люди не знали про event, зато знали паттерн Observer. Что служит аргументом в пользу меня — то есть того, что учить паттернам вреднее, чем учить языку.

Знали примерно так — вон форма, а у ней событие OnClick.

S>Точно так же я могу ожидать того, что дельфист-новичок, начитавшись ГоФ, может броситься писать классы фабрик, вместо того, чтобы изучить TClass и виртуальные конструкторы.

Так и будет.

S>>>Что вы называете "фактом использования паттерна"? Постановку задачи, или готовое решение?
I>>Проблема + некоторое решение.
S>Ок. Вы предлагаете переходить к решению от "Проблема + некоторое решение"? Зачем, если решение уже есть?

В общем случае я не знаю, в какой из паттернов эффективнее свернуть говнокод. Если я пишу новый код, то опять же, через пару тройку циклов рефакторинга в коде спокойно может быть совершенно не то, что в ём было изначально. Меня интересует в основном сложность поддержки и количетсво кода, а какие там паттерны — дело десятое. Иногда кода становится меньше, если избавиться от эвента, а иногда его становится меньше если этот эвент ввести.

I>>Я привел описание, покажи что в нем не так для той задачи что я упомянул: Слоистый коктейль -> справочник по плотности напитков -> список рецептов -> план работ/закупок.
S>То, что вы решили задачу крайне неэффективно. Для сформулированной вами задачи достаточно нагуглить рецепт коктейля Б-52, или мохито, или ещё чего-то конкретного. А ваше "решение" (в котором решения-то и нету — где коктейль??? У вас пока что только план по построению плана) запросто может привести к коктейлю из растительного масла и кока-колы, которым можно удивить только в неприятном смысле.

Цитирую себя " Предположим, например, ты хочешь удивить друзей разными рецептами кровавой мери, но сам ты не бармен и тебе нужен список вариантов + список ингредиентов и тд. "
Как видишь, твое решение Б-52 или мохито мягко говоря задаче не удовлетворяет, а в моём случае маслу и коле просто неоткуда взяться

Все даже проще — "кровавая мери" уже можно рассматривать как паттерн, в котором основной ингредиент это томатный сок.

I>>Факт что этот вырожденый случай вполне вписывается в мою теорию

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

Ты сказал для начала "Надо понимать, что именно делает данный инструмент, вот и всё.". Я же объясняю, что этого недостаточно. Нету предела этому самому пониманию. Почему и как именно мозг заимствует модели откуда угодно — не ясно, но это факт.
Почему нужно учить паттерны — эти самые паттерны предшествуют абстракциям/понятиям. Нет хороших абстракций, вводи их. Не можешь — учи паттерны. Пример Эрика Мейера и linq с Rx показывает, что абстракции вроде простые, а почему то понадобилось ажно 15 лет что бы найти внятное решение.

S>Эффекты второго порядка — контроль компилятора. Поэтому нативно поддержанная абстракция всегда лучше, чем подпрограмма с неизвестной компилятору семантикой.
S>Скажем, в случае "говнокода" про ассерт, компилятор может нас предупредить про unreachable code, если мы заведомо нарушаем условие ассерта. То же самое можно сделать в случае нативной абстракции assert. В случае Assert.IsTrue() компилятор нам ничем не поможет — он понятия не имеет о том, что в случае вычисления аргумента в false будет брошено исключение и весь следующий код пойдёт лесом.

Это объясняет, почему реализации паттернов сначала уходят в инфраструктуру, а потом — в язык. Разве я с этим спорю ?

I>>Ну вобще не ясно, как проверить какой набор знаний об этих итератора у тебя уже был заранее.
S>Придётся поверить мне на слово.

Пудозреваю минимум лет десять программирования ?

I>>Вообще, зачем знать эти детали ? Паттерн избавляет тебя от этого. Если ты задетектил паттерн как ДКА, то и решение будет искаться именно с учетом ДКА. А если вдруг тебе пришло в голову короутина, то и решение будет искаться именно таким образом.
S>Я не понимаю этот набор слов. Я ничего не задетектил. Я просто заметил, что yield return превращает "энергичный" императивный код в "ленивый", позволяя вернуться к исполнению нашего императивного кода тогда, когда мы будем к этому готовы. Мне всё равно — ДКА там или демон Максвелла.

Ты не просто заметил, ты еще и просигналил о том что заметил. Все вместе это "задетектил"

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

S>Просто есть удобная абстракция, с известными (из документации) наблюдаемыми свойствами.

Прежде чем использовать эту абстракцию, пудозреваю ты накидал возможно не одну кучу кода в APM, так или нет ?

I>>Можно обойтись и без заглядывания непосредтсвенно в код, например если есть лет десять опыта и ты уже в курсе короутин, автоматов и прочих вещей, то из одного описания в мсдн + пару собственных попыток можно построить адекватную модель.
S>Мне не надо строить адекватную модель. Мне надо хорошо понимать, что за поведение у yield return. Многократные перечитывания GoF и Фаулера этому никак не помогут.

А в чем разница между "строить адекватную модель" и "хорошо понимать что за поведение у yield return" ? По моему наличие понимания == наличие адекватной модели.

I>>Вопрос в том, как разработчик не имея твоего багажа выдать точно такое же решение. У тебя есть ответ ?
S>Есть — учите матчасть. Под матчастью я понимаю знание того, как и для чего надо применять используемые инструменты.

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

I>>Нельзя допускать к разработке людей, которые не понимают как работает виртуальная машина — так будет правильно. Для этого в университетах, что характерно даже в Мит и Стенфорде, студентов обучают довольно низкоуровневым вещам.
S>Какая виртуальная машина? Windbg не показывает виртуальных машин. Он показывает конкретный целевой код.
S>Нет, я не против того, чтобы это знать. Я вообще обоими руками за профайлеры и отладчики — но я не верю, что нужно всю жизнь готовиться к такому случаю.

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

S>>>Простите, я не понимаю. Можно какой-то пример того, как я перебираю решения при помощи "паттернов"?
I>>см про слоистый коктейль и блочные итераторы.
S>Оба примера говорят в мою пользу. См. выше.

Совсем неочевидно с учетом примеров про Б-52 или мохито в качестве вариантов кровавой мери

Здравствуйте, Ikemefula, Вы писали:

I>А если любой другой код многократно повторён ?
Про любой код речи не было. Посмотрите в тему топика. Вы понимаете, что из утверждения "все голуби — птицы" нельзя вывести утверждение "все птицы — голуби"?
Вообще, копипаста делится на устранимую в рамках языка (тогда она результат некомпетентности) и неустранимую.
Вот второе — это и есть паттерн.

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

I>Я с самого начала говорил и говорю именно про это. Вещи эти никакие не другие, это вобщем одно и то же.
На этом можно было бы закончить, т.к. вы выбрали какую-то неортодоксальную трактовку термина.
Никто в топике не утверждал, что паттерны мышления — копипаста. Это, очевидно, ложное утверждение.
А вот паттерны софтостроения (то, чем занимался Фаулер и ГоФ) — копипаста.
Уже одного этого достаточно, чтобы понять, что "одним и тем же" эти два вида паттернов являться никак не могут.

I>Не паттерны, а их реализация. Ну реализовали скажем обсервер в языке. Что, автоматически все рукописные реализации исчезнут ? Это как минимум.
Реализации — не исчезнут. Исчезнет потребность в них.

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

I>Возьми пролог и напиши аналог микрософт офиса со всеми приблудами, ну, хотя бы приблизительно. Внезапно, тебе потребуются все эти паттерны. А язык — пролог.
Не смешите меня так сильно, сегодня ещё не пятница. Может, вы попробуете привести пример реализации хотя бы одного паттерна — скажем, Bridge, на языке Пролог?

I>Решение с моей т.з. = код или подробная модель которую можно перевести в код. Обсервер например это ни то ни другое.
С чего бы это? Observer даёт подробные инструкции о том, как и что переводить в код.
И стратегия, и фабрика и тд и тд и тд. Вот конкретный UML для обсервера уже может считаться решением, но это, внезапно, не паттерн а уже реализация паттерна.
Это не реализация паттерна, а неотъемлемая часть паттерна — его решение.

I>Знали примерно так — вон форма, а у ней событие OnClick.
Вы подтверждаете мои подозрения.

I>Так и будет.
Ну так надо учить людей абстракциям, а не паттернам.

I>Цитирую себя " Предположим, например, ты хочешь удивить друзей разными рецептами кровавой мери, но сам ты не бармен и тебе нужен список вариантов + список ингредиентов и тд. "
I>Как видишь, твое решение Б-52 или мохито мягко говоря задаче не удовлетворяет, а в моём случае маслу и коле просто неоткуда взяться

Как неоткуда? Из справочника плотностей напитков. Вы же не думаете, что в нём будет только джин, водка, томатный сок, и соус табаско.
I>Все даже проще — "кровавая мери" уже можно рассматривать как паттерн, в котором основной ингредиент это томатный сок.
Всё гораздо хуже. Без знаний о том, как именно наливать напитки, вы даже из правильных ингредиентов получите мерзкую смесь.

I>Почему нужно учить паттерны — эти самые паттерны предшествуют абстракциям/понятиям. Нет хороших абстракций, вводи их. Не можешь — учи паттерны. Пример Эрика Мейера и linq с Rx показывает, что абстракции вроде простые, а почему то понадобилось ажно 15 лет что бы найти внятное решение.
Абстракции — сложные.

I>Это объясняет, почему реализации паттернов сначала уходят в инфраструктуру, а потом — в язык. Разве я с этим спорю ?
Да, не знаю зачем.

I>Пудозреваю минимум лет десять программирования ?
Двадцать.

I>Прежде чем использовать эту абстракцию, пудозреваю ты накидал возможно не одну кучу кода в APM, так или нет ?
Нет.

S>>Мне не надо строить адекватную модель. Мне надо хорошо понимать, что за поведение у yield return. Многократные перечитывания GoF и Фаулера этому никак не помогут.

I>А в чем разница между "строить адекватную модель" и "хорошо понимать что за поведение у yield return" ? По моему наличие понимания == наличие адекватной модели.
Ок, если в ваше понимание адекватной модели входит только наблюдаемое поведение — тогда мы говорим об одном и том же. Но подробности реализации (те самые, которые указывают в паттерне) тут не нужны.

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

Нет. Нужно выяснить, что он делает.

I>Разве я говорю что надо всю жизнь готовиться к такому ? Вполне достаточно освоить азы низкоуровневого программирования что бы худо-бедно сориентировать буде какой случай возникнет.
Паттернов — много. Не все из них сводятся к вызову функции в stdcall.

Здравствуйте, Ikemefula, Вы писали:

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

Здравствуйте, Sinclair, Вы писали:

I>>А если любой другой код многократно повторён ?
S>Про любой код речи не было. Посмотрите в тему топика. Вы понимаете, что из утверждения "все голуби — птицы" нельзя вывести утверждение "все птицы — голуби"?
S>Вообще, копипаста делится на устранимую в рамках языка (тогда она результат некомпетентности) и неустранимую.
S>Вот второе — это и есть паттерн.

Ни в коем случае.

I>>Изменения разумеется не любые а то и разговору не было.
S>Ну вот видите.
I>>Мне это пока сложновато, осталось два дня до отпуска, так что извини.
S>Не переживайте. После отпуска вам это тоже будет сложновато, т.к. паттерны и есть копипаста. Другого варианта нет.

Если подходить со стороны "это всё равно копипаста" то с таким же успехом можно любой код назвать копипастой

I>>Не паттерны, а их реализация. Ну реализовали скажем обсервер в языке. Что, автоматически все рукописные реализации исчезнут ? Это как минимум.
S>Реализации — не исчезнут. Исчезнет потребность в них.

Совсем необязательно. Есть например всевозможные оптимизации, есть случаи с несколькими языками. Например в C# встроены итераторы. Открываем класс Enumerable и видим, что наравне с православными итераторами, если реализации паттерна в чистом виде. Опаньки !

И второй момент — объясни, чем обсервер отличается от эвента. Например, что если есть некоторый язык, в котором есть та же фича, но называется как нибудь иначе, например — сигнал. Как с этим быть ?

I>>Готовая абстракция не означает, что и все код будет ей соответствовать.
S>Вы опять спорите с утверждением, которого никто не делал. Зачем?

Я показываю что цифра 99.99999% взята с потолка и не соответсвует действительности.

I>>Возьми пролог и напиши аналог микрософт офиса со всеми приблудами, ну, хотя бы приблизительно. Внезапно, тебе потребуются все эти паттерны. А язык — пролог.
S>Не смешите меня так сильно, сегодня ещё не пятница. Может, вы попробуете привести пример реализации хотя бы одного паттерна — скажем, Bridge, на языке Пролог?

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

I>>Решение с моей т.з. = код или подробная модель которую можно перевести в код. Обсервер например это ни то ни другое.
S>С чего бы это? Observer даёт подробные инструкции о том, как и что переводить в код.

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

S>И стратегия, и фабрика и тд и тд и тд. Вот конкретный UML для обсервера уже может считаться решением, но это, внезапно, не паттерн а уже реализация паттерна.
S>Это не реализация паттерна, а неотъемлемая часть паттерна — его решение.

"решение" является частью паттерна, только решение не то, что нам надо, а скорее "мета-решение".

I>>Цитирую себя " Предположим, например, ты хочешь удивить друзей разными рецептами кровавой мери, но сам ты не бармен и тебе нужен список вариантов + список ингредиентов и тд. "
I>>Как видишь, твое решение Б-52 или мохито мягко говоря задаче не удовлетворяет, а в моём случае маслу и коле просто неоткуда взяться

S>Как неоткуда? Из справочника плотностей напитков. Вы же не думаете, что в нём будет только джин, водка, томатный сок, и соус табаско.

В данном случае я могу спокойно опираться на свой предыдущий опыт или отфильтровать сомнительные коктейли на стадии приготовления. Паттерны это не запрещают.

I>>Все даже проще — "кровавая мери" уже можно рассматривать как паттерн, в котором основной ингредиент это томатный сок.
S>Всё гораздо хуже. Без знаний о том, как именно наливать напитки, вы даже из правильных ингредиентов получите мерзкую смесь.

Это все указано прямо в том справочнике

То есть, вместо того, что бы каждому становиться барменом, как ты предлагаешь(==учить надо абстракциям), любой может получить приемлемое решение в конкретной ситуации.

I>>Почему нужно учить паттерны — эти самые паттерны предшествуют абстракциям/понятиям. Нет хороших абстракций, вводи их. Не можешь — учи паттерны. Пример Эрика Мейера и linq с Rx показывает, что абстракции вроде простые, а почему то понадобилось ажно 15 лет что бы найти внятное решение.
S>Абстракции — сложные.

Значи всё еще хуже. Можно смело ожидать что большинство программистов их просто не поднимет в требуемый срок. WH например ратует за избавление индустрии от всех таких программистов

I>>Это объясняет, почему реализации паттернов сначала уходят в инфраструктуру, а потом — в язык. Разве я с этим спорю ?
S>Да, не знаю зачем.

Я уже раз пятьсот сказал, что такое движение это естественный процесс. Стало быть если я счем то спорю, то явно не с этим

I>>Пудозреваю минимум лет десять программирования ?
S>Двадцать.

То есть, твой случай можно спокойно скипнуть.

I>>Прежде чем использовать эту абстракцию, пудозреваю ты накидал возможно не одну кучу кода в APM, так или нет ?
S>Нет.

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

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

S>Нет. Нужно выяснить, что он делает.

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

I>>Разве я говорю что надо всю жизнь готовиться к такому ? Вполне достаточно освоить азы низкоуровневого программирования что бы худо-бедно сориентировать буде какой случай возникнет.
S>Паттернов — много. Не все из них сводятся к вызову функции в stdcall.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Она не могла перестать быть паттерном, потому что реализация паттерна никогда паттерном и не была. Сам же паттерн актуален даже если есть поддержка в языке.
S>К сожалению, приемлемых аргументов в пользу этого утверждения вы привести не можете. Оказывается, подавляющему большинству архитекторов этот паттерн совершенно неактуален при наличии абстракции. И даже программисту при отладке на низком уровне нужен не паттерн, а то, как именно он реализован в конкретной платформе.

Как называется эта абстракция и как быть если он реализована в другом языке иначе и называется иначе ?

Здравствуйте, Ikemefula, Вы писали:

I>Если подходить со стороны "это всё равно копипаста" то с таким же успехом можно любой код назвать копипастой

Нет, не любой.

I>Совсем необязательно. Есть например всевозможные оптимизации, есть случаи с несколькими языками. Например в C# встроены итераторы. Открываем класс Enumerable и видим, что наравне с православными итераторами, если реализации паттерна в чистом виде. Опаньки !
Что вы называете "реализацией паттерна в чистом виде"?

I>И второй момент — объясни, чем обсервер отличается от эвента. Например, что если есть некоторый язык, в котором есть та же фича, но называется как нибудь иначе, например — сигнал. Как с этим быть ?
Проектировать архитектуру в терминах сигналов.

Фича же может быть реализована по-разному. Скажем, в Delphi "евенты", которые были просто свойствами процедурного типа, не поддерживали множественность подписчиков. Это сильно повлияло на архитектуру DataSet и DataSource, которая занимает центральное место во всей VCL.
То есть поверх языковых средств был реализован отдельный паттерн для развязки подписчиков и публишеров. В C# нужды в этом паттерне нет, т.к. множественные подписчики работают из коробки.

I>Что бы реализовать такой софт придется всунуть в пролог например весь православный ООП.
Не торопитесь с примером — я схожу за попкорном.

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

I>"решение" является частью паттерна, только решение не то, что нам надо, а скорее "мета-решение".
Конечно же это "мета-решение". Потому что "решение", которое нужно — это готовый код.
Когда у нас есть готовый код, мы не называем это "паттерном". Мы называем это "библиотекой", и даём её скачать бесплатно либо за деньги.
Посмотрите на то, как реализуется INotifyPropertyChanged — чистой воды копипаста. Поэтому решения — нет. Есть "мета решение" — "вызывайте PropertyChanged() из каждого сеттера". То есть мы знаем, как решить задачу, но не можем выразить это языковыми средствами. Ок, в новом фреймворке немножечко сократили копипасту при помощи нового атрибута и магии компилятора. Тем не менее, она всё ещё осталась, и никаких средств по избавлению от неё нету.
Поэтому мы по-прежнему имеем паттерн, а не решение.
Решением был бы макрос Nemerle или аннотация Java, которые бы заставляли компилятор автоматически генерировать копипасту за нас.
Тогда бы "Notify Property Changed Pattern" был бы не нужен.

I>В данном случае я могу спокойно опираться на свой предыдущий опыт или отфильтровать сомнительные коктейли на стадии приготовления. Паттерны это не запрещают.
Ну, то есть мы имеем "знание паттернов", которое не мешает и не помогает в процессе решения задачи.

I>>>Все даже проще — "кровавая мери" уже можно рассматривать как паттерн, в котором основной ингредиент это томатный сок.
S>>Всё гораздо хуже. Без знаний о том, как именно наливать напитки, вы даже из правильных ингредиентов получите мерзкую смесь.

I>Это все указано прямо в том справочнике

Что именно указано в справочнике?

I>Значи всё еще хуже. Можно смело ожидать что большинство программистов их просто не поднимет в требуемый срок. WH например ратует за избавление индустрии от всех таких программистов

Нет. Он ратует за избавление индустрии от книг типа GoF. Вместо паттернов ентерпрайз приложений можно иметь RoR и профит.

I>А что ты делал двадцать лет ? Писал примитивный императивный код и даже не пробовал ни асихронное программирование, ни функциональное, ни ООП?
Конечно же я пробовал ООП. Но большую часть времени из этих 20 лет никаких yield return в природе не существовало.

I>Я немного сомневаюсь, что до того, как изобрести конкретную короутину, ты не написал ни одного итератора.
Своих реализаций IEnumerable? Не, ни разу не потребовалось. Всегда хватало штатных коллекций.
Зато как только появился iterator block, я сразу стал пользовать его направо и налево — скажем, для того, чтобы превратить обход дерева в обычный foreach. Потому что делать это стало легко и приятно:

public IEnumerable<T> IterateWithChildren()(
{
  yield return this;
  foreach(var item in this)
    yield return item;
}

В С# 1.0 даже мысли не возникало о том, чтобы такое сделать.

Здравствуйте, Ikemefula, Вы писали:

I>Как называется эта абстракция и как быть если он реализована в другом языке иначе и называется иначе ?
Абстракция называется "вызов метода", "вызов процедуры", или "вызов функции". Она присутствует в нативном виде во всех императивных языках, начиная примерно с шестидесятых. Как именно она реализована, обычно мало кого интересует. Скажем, в JS вызов методов "внутри" устроен сильно не так, как в С++, тем не менее это совершенно не мешает читать JS-ный код, и проектировать систему с использованием JS.

Здравствуйте, Sinclair, Вы писали:

I>>Как называется эта абстракция и как быть если он реализована в другом языке иначе и называется иначе ?
S>Абстракция называется "вызов метода", "вызов процедуры", или "вызов функции". Она присутствует в нативном виде во всех императивных языках, начиная примерно с шестидесятых. Как именно она реализована, обычно мало кого интересует. Скажем, в JS вызов методов "внутри" устроен сильно не так, как в С++, тем не менее это совершенно не мешает читать JS-ный код, и проектировать систему с использованием JS.

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

Здравствуйте, Sinclair, Вы писали:

I>>Совсем необязательно. Есть например всевозможные оптимизации, есть случаи с несколькими языками. Например в C# встроены итераторы. Открываем класс Enumerable и видим, что наравне с православными итераторами, если реализации паттерна в чистом виде. Опаньки !
S>Что вы называете "реализацией паттерна в чистом виде"?

Значит реализован именно паттерн итератор, а ен просто код который похож и на итератор и на обсервер и на что угодно.

I>>И второй момент — объясни, чем обсервер отличается от эвента. Например, что если есть некоторый язык, в котором есть та же фича, но называется как нибудь иначе, например — сигнал. Как с этим быть ?
S>Проектировать архитектуру в терминах сигналов.

S>Фича же может быть реализована по-разному. Скажем, в Delphi "евенты", которые были просто свойствами процедурного типа, не поддерживали множественность подписчиков. Это сильно повлияло на архитектуру DataSet и DataSource, которая занимает центральное место во всей VCL.
S>То есть поверх языковых средств был реализован отдельный паттерн для развязки подписчиков и публишеров. В C# нужды в этом паттерне нет, т.к. множественные подписчики работают из коробки.

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

I>>Что бы реализовать такой софт придется всунуть в пролог например весь православный ООП.
S>Не торопитесь с примером — я схожу за попкорном.

Уже всё сказано. Кроме как заимствованием парадигм эту задачу не решить.

I>>"решение" является частью паттерна, только решение не то, что нам надо, а скорее "мета-решение".
S>Конечно же это "мета-решение". Потому что "решение", которое нужно — это готовый код.
S>Когда у нас есть готовый код, мы не называем это "паттерном". Мы называем это "библиотекой", и даём её скачать бесплатно либо за деньги.

Ты называл и продолжаешь называть неустранимую копипасту, т.е. код, паттерном. Следовательно ты или путаешь понятия или для тебя код и есть паттерн.

S>Посмотрите на то, как реализуется INotifyPropertyChanged — чистой воды копипаста. Поэтому решения — нет. Есть "мета решение" — "вызывайте PropertyChanged() из каждого сеттера". То есть мы знаем, как решить задачу, но не можем выразить это языковыми средствами. Ок, в новом фреймворке немножечко сократили копипасту при помощи нового атрибута и магии компилятора. Тем не менее, она всё ещё осталась, и никаких средств по избавлению от неё нету.
S>Поэтому мы по-прежнему имеем паттерн, а не решение.
S>Решением был бы макрос Nemerle или аннотация Java, которые бы заставляли компилятор автоматически генерировать копипасту за нас.
S>Тогда бы "Notify Property Changed Pattern" был бы не нужен.

Каким словом назвать этот механизм, что бы другому человеку было понятно, как это использовать ? Снова "функция" ?

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

I>>В данном случае я могу спокойно опираться на свой предыдущий опыт или отфильтровать сомнительные коктейли на стадии приготовления. Паттерны это не запрещают.
S>Ну, то есть мы имеем "знание паттернов", которое не мешает и не помогает в процессе решения задачи.

Если ты бармен — то это не нужно. Если ты просто хочешь сделать десяток коктейлей, паттерны сэкономят тебе несколько лет подготовки.
Как вариант, если ты знаешь вообще всё, эдакий Бог Девелопер, то ясное дело, паттерны тебе не нужны. Более тго — абстракции тоже не нужны.

I>>Это все указано прямо в том справочнике

S>Что именно указано в справочнике?

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

I>>Значи всё еще хуже. Можно смело ожидать что большинство программистов их просто не поднимет в требуемый срок. WH например ратует за избавление индустрии от всех таких программистов

S>Нет. Он ратует за избавление индустрии от книг типа GoF. Вместо паттернов ентерпрайз приложений можно иметь RoR и профит.

Можно. Прогресс идет совсем в другом направлении.

I>>А что ты делал двадцать лет ? Писал примитивный императивный код и даже не пробовал ни асихронное программирование, ни функциональное, ни ООП?
S>Конечно же я пробовал ООП. Но большую часть времени из этих 20 лет никаких yield return в природе не существовало.

Это можно эмулировать десятком способов, не было только языковой поддержки. Например в winapi есть такая вещь, как файберы — очень интересная штукенция.

S>Зато как только появился iterator block, я сразу стал пользовать его направо и налево — скажем, для того, чтобы превратить обход дерева в обычный foreach. Потому что делать это стало легко и приятно:

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sinclair, Вы писали:

S>>Конечно же я пробовал ООП. Но большую часть времени из этих 20 лет никаких yield return в природе не существовало.

I>Это можно эмулировать десятком способов, не было только языковой поддержки.
Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

Здравствуйте, Ikemefula, Вы писали:

I>А что нам даёт такое название ? Вот с обсервером понятно, с эвентом — понятно. С сигналом — тоже понятно. Теперь называем это функцией и что ?

Название само по себе — ничего не даёт. Ни для обзёрвера, ни для эвента, ни для сигнала, ни для функции. Названия вообще ничего не дают — это символы. Чтобы они что-то давали, за названием должно быть описание.
Вот лично у вас вряд ли есть проблемы с пониманием, что такое "вызов функции".

Здравствуйте, Ikemefula, Вы писали:

класс Enumerable и видим, что наравне с православными итераторами, если реализации паттерна в чистом виде. Опаньки !
I>Значит реализован именно паттерн итератор, а ен просто код который похож и на итератор и на обсервер и на что угодно.
Я не понимаю, что вы называете "паттерном итератор". Где можно прочитать про этот паттерн?
Я не понимаю, что вы называете православными итераторами.

I>Обсервер можно спокойно использовать когда есть и эвенты, и сигналы и даже самопальные реализации. Вот в чем его фокус как паттерна.
Что вы называете "использовать обзёрвер"? Пока что я вижу только одно использование (в рамках C#) — одни люди педалят самопальные реализации, другие потом их вычищают, заменяя на event.
Мне такое использование не кажется сколь нибудь практичным.

I>Уже всё сказано. Кроме как заимствованием парадигм эту задачу не решить.
Да ну прекратите же вы плести ерунду. На всякий случай напомню, что все тьюринг-полные языки вычислительно эквивалентны.
Это, в частности, означает, что любую задачу можно решить на любом таком языке.

I>Ты называл и продолжаешь называть неустранимую копипасту, т.е. код, паттерном. Следовательно ты или путаешь понятия или для тебя код и есть паттерн.
Нет. Копипаста — это не код, это явление. Это ситуация, когда программист вынужден копипастить. А код — это результат применения паттерна.

I>Каким словом назвать этот механизм, что бы другому человеку было понятно, как это использовать ? Снова "функция" ?

Всё зависит от того, как именно я буду решать эту задачу. Например, я могу иметь notifying property. С вот таким синтаксисом:

public notifying int Size { get; set;}

А ещё я могу иметь просто язык разметки классов, определённый так, чтобы вообще все свойства сразу были notifying:

model class Person
{
  string FirstName;
  string LastName;
  string readonly Name = string.Join(" ", FirstName, LastName); 
}

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

I>Ну упрячешь ты реализацию в язык, что с того ? Откуда другой человек узнает, что эта мулька годится для биндинга ? И почему ему вообще должно прийти в голову решение с биндингом ?
Ну, вот каким-то же образом в Delphi люди догадывались, для чего использовать property? Надо полагать, узнавали из документации.

I>Если ты бармен — то это не нужно. Если ты просто хочешь сделать десяток коктейлей, паттерны сэкономят тебе несколько лет подготовки.
Паттерны — нет. Сэкономят решения. Например, http://www.ozon.ru/context/detail/id/5885959/
I>Можно. Прогресс идет совсем в другом направлении.
Да? А мне как раз казалось, что прогресс в 21 веке всё-таки сдвинулся с мёртвой точки. До этого 10 лет считалось, что всё уже реализовано, а дефицит полезных абстракций можно восполнить при помощи "паттернов". А потом пришёл C#, в каждый релиз которого добавляли больше фич, чем в джаву за десятилетие, и народ начал думать "а может, и правда хватит издеваться над программистами?"

I>Это можно эмулировать десятком способов, не было только языковой поддержки. Например в winapi есть такая вещь, как файберы — очень интересная штукенция.

Покажите мне, как эмулировать Enumerable.TakeWhile на файберах. Его устройство в терминах yield return мне понятно.

I>То есть, ты основательно наигрался, прежде чем изобрести конкретную короутину ?
Конечно. Я отлично понимал, как работает yield return. Безо всяких "паттернов".

Здравствуйте, Sinclair, Вы писали:

I>>Значит реализован именно паттерн итератор, а ен просто код который похож и на итератор и на обсервер и на что угодно.
S>Я не понимаю, что вы называете "паттерном итератор". Где можно прочитать про этот паттерн?
S>Я не понимаю, что вы называете православными итераторами.

В данном случае это паттерн итератор описан в GoF. Православный итератор — это именно ООП , как в GoF, а не с модными словами вроде yield return.

I>>Обсервер можно спокойно использовать когда есть и эвенты, и сигналы и даже самопальные реализации. Вот в чем его фокус как паттерна.
S>Что вы называете "использовать обзёрвер"? Пока что я вижу только одно использование (в рамках C#) — одни люди педалят самопальные реализации, другие потом их вычищают, заменяя на event.

Использовать это прежде всего оперировать им в разговоре с самим собой или с кем то еще для поиска и принятия решения.

I>>Уже всё сказано. Кроме как заимствованием парадигм эту задачу не решить.
S>Да ну прекратите же вы плести ерунду. На всякий случай напомню, что все тьюринг-полные языки вычислительно эквивалентны.
S>Это, в частности, означает, что любую задачу можно решить на любом таком языке.

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

I>>Ты называл и продолжаешь называть неустранимую копипасту, т.е. код, паттерном. Следовательно ты или путаешь понятия или для тебя код и есть паттерн.
S>Нет. Копипаста — это не код, это явление. Это ситуация, когда программист вынужден копипастить. А код — это результат применения паттерна.

Ладно, годная отмазка

I>>Каким словом назвать этот механизм, что бы другому человеку было понятно, как это использовать ? Снова "функция" ?

S>Всё зависит от того, как именно я буду решать эту задачу. Например, я могу иметь notifying property. С вот таким синтаксисом:
S>

S>public notifying int Size { get; set;} 
S>

А где же тогда абстракции ?

Не лучше ли паттерны и рассматривать как универсальный язык ?

S>А ещё я могу иметь просто язык разметки классов, определённый так, чтобы вообще все свойства сразу были notifying:
S>

S>model class Person
S>{
S>  string FirstName;
S>  string LastName;
S>  string readonly Name = string.Join(" ", FirstName, LastName); 
S>}
S>

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

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

I>>Ну упрячешь ты реализацию в язык, что с того ? Откуда другой человек узнает, что эта мулька годится для биндинга ? И почему ему вообще должно прийти в голову решение с биндингом ?
S>Ну, вот каким-то же образом в Delphi люди догадывались, для чего использовать property? Надо полагать, узнавали из документации.

А непосвященному надо знать толкьо NotifyPropertyChanged что бы знать как юзать эту мульку, и даже документация не нужна.

I>>Если ты бармен — то это не нужно. Если ты просто хочешь сделать десяток коктейлей, паттерны сэкономят тебе несколько лет подготовки.
S>Паттерны — нет. Сэкономят решения. Например, http://www.ozon.ru/context/detail/id/5885959/

С коктейлями — вполне возможно, здесь новое решение легко найти и опробовать.

I>>Можно. Прогресс идет совсем в другом направлении.
S>Да? А мне как раз казалось, что прогресс в 21 веке всё-таки сдвинулся с мёртвой точки. До этого 10 лет считалось, что всё уже реализовано, а дефицит полезных абстракций можно восполнить при помощи "паттернов". А потом пришёл C#, в каждый релиз которого добавляли больше фич, чем в джаву за десятилетие, и народ начал думать "а может, и правда хватит издеваться над программистами?"

Так сам подумай что это значит. Люди голосуют за джаву в которой фичи появляются очень медленно. А ты с WH предлагаешь навводить поддержки всего и вся в ЯП.

I>>Это можно эмулировать десятком способов, не было только языковой поддержки. Например в winapi есть такая вещь, как файберы — очень интересная штукенция.
S>

Покажите мне, как эмулировать Enumerable.TakeWhile на файберах. Его устройство в терминах yield return мне понятно.

Я про твою асинхронную короутину. Файбер точно так же можно остановить в любой точне и с неё потом продолжить.

>>То есть, ты основательно наигрался, прежде чем изобрести конкретную короутину ?
S>Конечно. Я отлично понимал, как работает yield return. Безо всяких "паттернов".

А мне непонятно было это слово и когда первый раз увидел его, залез внутрь, глянул что там итератор построеный на автомате и все свойства узнал прямо из этой модели. позже, когда я узнал про coroutines, я сразу подумал про этот самый yield return. На тот момент у меня было намного меньше, чем 20 лет опыта.

Здравствуйте, Sinclair, Вы писали:

I>>А что нам даёт такое название ? Вот с обсервером понятно, с эвентом — понятно. С сигналом — тоже понятно. Теперь называем это функцией и что ?

S>Название само по себе — ничего не даёт. Ни для обзёрвера, ни для эвента, ни для сигнала, ни для функции. Названия вообще ничего не дают — это символы. Чтобы они что-то давали, за названием должно быть описание.

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

Здравствуйте, samius, Вы писали:

I>>Это можно эмулировать десятком способов, не было только языковой поддержки.
S>Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

Файберы.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Это можно эмулировать десятком способов, не было только языковой поддержки.
S>>Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

I>Файберы.
Что Файберы? Т.е. эмуляции yield return я не увижу, я правильно понял? И видимо должен удовлетвориться словом Файберы и пойти прикручивать их к C#-у?

Здравствуйте, samius, Вы писали:

I>>>>Это можно эмулировать десятком способов, не было только языковой поддержки.
S>>>Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

I>>Файберы.
S>Что Файберы? Т.е. эмуляции yield return я не увижу, я правильно понял? И видимо должен удовлетвориться словом Файберы и пойти прикручивать их к C#-у?

До свидания.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>До свидания.
Пока

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, __kot2, Вы писали:

__>>паттерны это естественные конструкции, которые возникают по мере разработки архитектуры
WH>Не правильно.
WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.
WH>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен.
WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.

я смотрю что многие программисты зажрзнались со своими дотнетами, джавами, и прочими пхп.
многие забыли (а кто-то и не знает), что кроме задач где есть "предметная область" с абстрактрыми сущностями типа документов, проводок и т.п.,
есть задачи где есть "конкретные сущности" типа "10К соединений", "макс. 20 мс задержка", "всего 128К памяти в контроллере".
никакой ваш замечательный ДСЛ не учтет, что одни данные надо выделить на стеке, другие в хипе, одни с выравниванием 8 потому что надо быстро, другие — с выравниваним 1, потому что их много,
одни — в списке, чтобы указатель не менялся, другие в векторе — чтобы кеш проца работал.

есть много программ, на которых держится наш мир (сервера в интернете, прошивки в мобильнике), где нет того что можно назвать "предметной областью" и сделать ДСЛ.
там есть только обычные структуры данных, не имеющие отношения к "объектам реальной жизни", и код который их меняет.

но вот что интересно, domain и DSL там нет, а архитектура и паттерны проектирования есть.

Здравствуйте, Abyx, Вы писали:

A>я смотрю что многие программисты зажрзнались со своими дотнетами, джавами, и прочими пхп.
A>многие забыли (а кто-то и не знает), что кроме задач где есть "предметная область" с абстрактрыми сущностями типа документов, проводок и т.п.,
Во-во. И лезут со своими паттернами вместо того чтобы сделать ДСЛ и оперировать данными сущностями.

A>есть задачи где есть "конкретные сущности" типа "10К соединений", "макс. 20 мс задержка", "всего 128К памяти в контроллере".
A>никакой ваш замечательный ДСЛ не учтет, что одни данные надо выделить на стеке, другие в хипе, одни с выравниванием 8 потому что надо быстро, другие — с выравниваним 1, потому что их много,
A>одни — в списке, чтобы указатель не менялся, другие в векторе — чтобы кеш проца работал.
Вот как раз ДСЛ это учтет очень хорошо.
Я не могу обогнать свои ДСЛ рукописным кодом. Ибо они такие оптимизации проворачивают, что руками их не сделать.

A>есть много программ, на которых держится наш мир (сервера в интернете, прошивки в мобильнике), где нет того что можно назвать "предметной областью" и сделать ДСЛ.
Есть. То что ты её не видишь это от того что ты не умеешь её находить.

A>но вот что интересно, domain и DSL там нет, а архитектура и паттерны проектирования есть.

Это от того что у разработчиков знаний не хватает.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Abyx, Вы писали:

A>я смотрю что многие программисты зажрзнались со своими дотнетами, джавами, и прочими пхп.
A>многие забыли (а кто-то и не знает), что кроме задач где есть "предметная область" с абстрактрыми сущностями типа документов, проводок и т.п.,
A>есть задачи где есть "конкретные сущности" типа "10К соединений", "макс. 20 мс задержка", "всего 128К памяти в контроллере".
A>никакой ваш замечательный ДСЛ не учтет, что одни данные надо выделить на стеке, другие в хипе, одни с выравниванием 8 потому что надо быстро, другие — с выравниваним 1, потому что их много,
A>одни — в списке, чтобы указатель не менялся, другие в векторе — чтобы кеш проца работал.

A>есть много программ, на которых держится наш мир (сервера в интернете, прошивки в мобильнике), где нет того что можно назвать "предметной областью" и сделать ДСЛ.
A>там есть только обычные структуры данных, не имеющие отношения к "объектам реальной жизни", и код который их меняет.

A>но вот что интересно, domain и DSL там нет, а архитектура и паттерны проектирования есть.

И ты тоже не понял главного: предметная область есть и здесь, в её терминах и нужно решать задачу. Если в нашем распоряжении много ресурсов — компилятор DSL сгенерирует код, использующий эти ресурсы. Если ресурсов мало — компилятор DSL сгенерирует код, эффективно работающий в 128 кб памяти, использующий только стек и т. п. При этом исходный код на самом DSL остаётся без изменений! Это по сути аналогично тому, как исходный код на C и C++ компилируется под разные платформы/ОСи.
Ещё раз: архитектур мало (мобильная, настольная, серверная, что-то ещё), программ под эти архитектуры много (тысячи их!). Что легче: переписывать эти тысячи программ под каждую архитектуру (имея при этом один компилятор) или иметь несколько компиляторов (DSL), учитывающих особенности этих архитектур (не меняя при этом тысячи исходников)?

Здравствуйте, WolfHound, Вы писали:

A>>я смотрю что многие программисты зажрзнались со своими дотнетами, джавами, и прочими пхп.
A>>многие забыли (а кто-то и не знает), что кроме задач где есть "предметная область" с абстрактрыми сущностями типа документов, проводок и т.п.,
WH>Во-во. И лезут со своими паттернами вместо того чтобы сделать ДСЛ и оперировать данными сущностями.

Нет на каждый проект по человеку вроде Эрика Мейера, пичалька.

A>>есть много программ, на которых держится наш мир (сервера в интернете, прошивки в мобильнике), где нет того что можно назвать "предметной областью" и сделать ДСЛ.
WH>Есть. То что ты её не видишь это от того что ты не умеешь её находить.

"вместо того чтобы сделать ДСЛ и оперировать данными сущностями"

A>>но вот что интересно, domain и DSL там нет, а архитектура и паттерны проектирования есть.

WH>Это от того что у разработчиков знаний не хватает.

Правильно. И построение ДСЛ как минимум повышает минимальную планку по знаниям.

Здравствуйте, koodeer, Вы писали:

K>Ещё раз: архитектур мало (мобильная, настольная, серверная, что-то ещё), программ под эти архитектуры много (тысячи их!). Что легче: переписывать эти тысячи программ под каждую архитектуру (имея при этом один компилятор) или иметь несколько компиляторов (DSL), учитывающих особенности этих архитектур (не меняя при этом тысячи исходников)?

Подождём лет 5, посмотрим что выйдет из N2. Я думаю что ДСЛ в том виде, в котором предлаегает WH есть утопия в чистом виде, потому что построить сам язык, то есть именно язык, даже не говоря про компилятор, нужно обладать просто гигантским опытом и знаниями. Тенденции на рынке труда показывают, что таких людей в среднем становится все меньше и меньше.
По моему нужно изыскивать решения для приведения энергичного кода в ленивый. Если такой инструмент появится, то для программистов достаточно будет той небольшой базы императивного программирования которую дают в вузах.

Здравствуйте, Ikemefula, Вы писали:

WH>>Это от того что у разработчиков знаний не хватает.
I>Правильно. И построение ДСЛ как минимум повышает минимальную планку по знаниям.
Построение ДСЛ это работа архитектора. Я уже раз пятьсот это говорил. И, конечно же, если посадить за нее джуниора ничего хорошего не получится. Точно так же как ничего хорошего не получится, если дать джуниору дизайнить проект даже на жалкие 10-20 тысяч строк. Даже если джуниор талантливый. Есго всеравно учить надо.
Зато если посадить джуниора, писать на ДСЛ результат будет намного лучше, чем на языке общего назначения, даже если за ним будет присматривать архитектор. Ибо автомат присмотрит намного лучше, чем один архитектор за десятком другим джуниоров.

Я вообще не понимаю твое стремление инженерную работу поручить неучам. Ты хотел быть жить в доме или ходить по мосту, спроектированном неучем? Думаю, что нет. Так почему ты считаешь что неучи могут проектировать программы?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Подождём лет 5, посмотрим что выйдет из N2. Я думаю что ДСЛ в том виде, в котором предлаегает WH есть утопия в чистом виде, потому что построить сам язык, то есть именно язык, даже не говоря про компилятор, нужно обладать просто гигантским опытом и знаниями. Тенденции на рынке труда показывают, что таких людей в среднем становится все меньше и меньше.
Создание архитектуры задача значительно более сложная.
Ибо тебе не только нужно создать язык. Сущности и взаимодействия предметной области задают семантику языка. А их тебе нужно будет определить в любом случае. Синтаксис задача тривиальная.
Но и натянуть его на другой. С другими сущностями, которые взаимодействуют иначе. Причем так чтобы код не скатился в говно. А это задача очень сложная. Я бы даже сказал что это самая сложная задача при создании архитектуры.
Написать компилятор проще. С Н2 это будет очень просто. А все по тому, что нам не нужно беспокоится о том, что генерируемый код будет говном. Главное чтобы правильно работал. Иногда чтобы быстро работал. Кстати быстрый код обычно скатывается в говно. Да ты и сам это знаешь.

I>По моему нужно изыскивать решения для приведения энергичного кода в ленивый. Если такой инструмент появится, то для программистов достаточно будет той небольшой базы императивного программирования которую дают в вузах.
Чего?

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

Да и что ты от этого преобразования получить собрался? Вообще не понимаю.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>По моему нужно изыскивать решения для приведения энергичного кода в ленивый. Если такой инструмент появится, то для программистов достаточно будет той небольшой базы императивного программирования которую дают в вузах.
WH>Чего?

Да и что ты от этого преобразования получить собрался? Вообще не понимаю.

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

Здравствуйте, WolfHound, Вы писали:

WH>Построение ДСЛ это работа архитектора. Я уже раз пятьсот это говорил. И, конечно же, если посадить за нее джуниора ничего хорошего не получится. Точно так же как ничего хорошего не получится, если дать джуниору дизайнить проект даже на жалкие 10-20 тысяч строк. Даже если джуниор талантливый. Есго всеравно учить надо.

На большинстве софтверных контор и проектах архитектор это просто девелопер у которого больше опыта чем у других. Например у всех опыт полгода-года, а у архитектора может быть полтора-два

WH>Я вообще не понимаю твое стремление инженерную работу поручить неучам. Ты хотел быть жить в доме или ходить по мосту, спроектированном неучем? Думаю, что нет. Так почему ты считаешь что неучи могут проектировать программы?

Я предпочитаю работать с тем, кто есть на рынке труда а не ждать чудес. Неучи — ты сам это слово употребил — успешно сдают проекты безо всяких ДСЛ и немерлов. Странно, да ? Они, представь, пишут код с "паттернами" в самом что ни есть императивном духе ООП.

Здравствуйте, WolfHound, Вы писали:

I>>Подождём лет 5, посмотрим что выйдет из N2. Я думаю что ДСЛ в том виде, в котором предлаегает WH есть утопия в чистом виде, потому что построить сам язык, то есть именно язык, даже не говоря про компилятор, нужно обладать просто гигантским опытом и знаниями. Тенденции на рынке труда показывают, что таких людей в среднем становится все меньше и меньше.
WH>Создание архитектуры задача значительно более сложная.

Мне интересно, как ты это посчитал ? Я вот наблюдаю ровно противоположное.

Здравствуйте, Ikemefula, Вы писали:

I>На большинстве софтверных контор и проектах архитектор это просто девелопер у которого больше опыта чем у других. Например у всех опыт полгода-года, а у архитектора может быть полтора-два

Я видел, что у таких "получается". Дешевле нанять дрогущего IT'а чем терпеть такую разработку.

I>Я предпочитаю работать с тем, кто есть на рынке труда а не ждать чудес. Неучи — ты сам это слово употребил — успешно сдают проекты безо всяких ДСЛ и немерлов. Странно, да ? Они, представь, пишут код с "паттернами" в самом что ни есть императивном духе ООП.
Успешно? Без надсмотрщика уровня, например AVK? Ну-ну.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

WH>>Создание архитектуры задача значительно более сложная.
I>Мне интересно, как ты это посчитал ? Я вот наблюдаю ровно противоположное.
Ты не можешь это наблюдать. Ты не создаешь языки. Я создаю.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Превращение энергичного в ленивый упрощает реализацию многих вещей. Например можно забыть про APM и прочую ересь.
Про что забыть?

I>Например ViewModel это как раз костыль из за отсутствия хороших возможностей такого вот преобразования.
ViewModel не может быть костылем просто по тому, что это чистые данные, которые отображаются в ГУИ. Это просто неотъемлемая часть ГУИ.

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Превращение энергичного в ленивый упрощает реализацию многих вещей. Например можно забыть про APM и прочую ересь.
WH>Про что забыть?

Про APM и прочую ересь. Кэп.

I>>Например ViewModel это как раз костыль из за отсутствия хороших возможностей такого вот преобразования.
WH>ViewModel не может быть костылем просто по тому, что это чистые данные, которые отображаются в ГУИ. Это просто неотъемлемая часть ГУИ.

Это неотъемлимая часть в конкретной архитектуре.

WH>Да и как ты собрался упростить реализацию, если преобразование должно сохранить семантику?
WH>Это же будет все та же императивщина только работающая на порядок другой медленней.

На порядок другой — это в нынешних условиях. К слову, этого уже достаточно что бы выбросить APM.

Здравствуйте, WolfHound, Вы писали:

WH>>>Создание архитектуры задача значительно более сложная.
I>>Мне интересно, как ты это посчитал ? Я вот наблюдаю ровно противоположное.
WH>Ты не можешь это наблюдать. Ты не создаешь языки. Я создаю.

Думаешь мне надо самому создавать языки что бы замечать создают ли их другие ?

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

Кстати говоря, пример с Linq или RX не в твою пользу. Архитектур насоздавали тонны, а язык родили всего один.

Здравствуйте, Ikemefula, Вы писали:

I>Про APM и прочую ересь. Кэп.
Advanced Power Management?
Actions per minute?
Advanced Problems in Mechanics?
Association for Project Management?
...
Так что такое APM?

I>Это неотъемлимая часть в конкретной архитектуре.
Она есть всегда. Просто иногда её так размывают, что ее становится не видно за горой говнокода.
Но что бы ты не делал, а первичные данные, на основе которых рисуется ГУИ есть всегда. Это и есть ViewModel.

I>На порядок другой — это в нынешних условиях. К слову, этого уже достаточно что бы выбросить APM.
Я не знаю что такое APM.
Я не понимаю, как замедление кода на пару порядков без изменения его семантики может упростить жизнь.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>На большинстве софтверных контор и проектах архитектор это просто девелопер у которого больше опыта чем у других. Например у всех опыт полгода-года, а у архитектора может быть полтора-два

WH>Я видел, что у таких "получается". Дешевле нанять дрогущего IT'а чем терпеть такую разработку.

Теоретически. На практике этот найм заканчивается так — "прошло уже полгода, если через месяц не найдете гуру, мы отдаём проект студентам". Зарплатой этот вопрос не решается в принципе, это трудно понять но это так.
Я знаю много примеров когда конторы задирали планку чуть не вдвое выше максимальной по рынку и оставались ни с чем.

I>>Я предпочитаю работать с тем, кто есть на рынке труда а не ждать чудес. Неучи — ты сам это слово употребил — успешно сдают проекты безо всяких ДСЛ и немерлов. Странно, да ? Они, представь, пишут код с "паттернами" в самом что ни есть императивном духе ООП.
WH>Успешно? Без надсмотрщика уровня, например AVK? Ну-ну.

Да, именно так. "Надсмотрщик" может вообще быть непрограммистом. Это просто представитель заказчика, все что ему надо — обеспечивать внятные требования, проверять промежуточные результаты в реальных условиях и следить за динамикой багов.
Грамотно построеный процесс позволяет радикально снизить проходную планку для девелоперов. Многие фирмы только этим и живут. У меня, к слову, специфика совсем другая — на тот случай если ты продолжишь играть в игру "а у тебя всё плохо".

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

Я так понял, любой проект говно если в ём нет немерле и писаных на ём дсл ?

Заказчик выдвигает требования. Программа может удовлетворять этим требованиям и быть непригодной для реальной работы. Чьи это проблемы ?
Парадокс, но тоже самое ты видишь практически везде в сфере услуг например.
Есть только одно требование: "заказчик доволен результатами внедрения программы" Фокус в том, что его очень тяжело формализовать в более конкретных терминах. И к слову, многие "студенческие" проекты удовлетворяют этому требованию. Можешь по привычке придраться к словам, начни со слова "многие"

Здравствуйте, Ikemefula, Вы писали:

I>Думаешь мне надо самому создавать языки что бы замечать создают ли их другие ?

И что же ты замечаешь?

I>ДСЛ я использую и создаю для своих нужд, не расстраивайся.
Что-то сомневаюсь. Иначе бы ты не писал кучу ерунды, которая полностью противоречит действительности.

I>Как минимум ДСЛ это конкретная архитектура + язык. Вобщем уже этого достаточно, что бы понять, что ДСЛ будет сложнее чем просто архитектура.

Проще. Я рядом писал почему.

I>Кстати говоря, пример с Linq или RX не в твою пользу. Архитектур насоздавали тонны, а язык родили всего один.
В мою. Ибо в микрософт поняли, что натянуть всё на C# не получается. И дали очередную фичу на которую можно относительно удобно натянуть еще несколько задач.
Если бы C# можно было легко расширять, то LINQ никогда бы не появился.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>...
WH>Так что такое APM?

OMG !!! Async Programming Model

I>>Это неотъемлимая часть в конкретной архитектуре.
WH>Она есть всегда. Просто иногда её так размывают, что ее становится не видно за горой говнокода.
WH>Но что бы ты не делал, а первичные данные, на основе которых рисуется ГУИ есть всегда. Это и есть ViewModel.

Эти первичные данных и нахрен не упали.

I>>На порядок другой — это в нынешних условиях. К слову, этого уже достаточно что бы выбросить APM.
WH>Я не знаю что такое APM.
WH>Я не понимаю, как замедление кода на пару порядков без изменения его семантики может упростить жизнь.

Что значит "изменение семантики" ? Покажи на примере.

Здравствуйте, WolfHound, Вы писали:

I>>Думаешь мне надо самому создавать языки что бы замечать создают ли их другие ?

WH>И что же ты замечаешь?

Люди, которые разрабатывают пригодную архитектуру большей частью разрабатывают непригодные языки. Чего то нехватает, ибо код на этих языках скатывается в говно еще быстрее, чем код на С# скажем.

I>>ДСЛ я использую и создаю для своих нужд, не расстраивайся.
WH>Что-то сомневаюсь. Иначе бы ты не писал кучу ерунды, которая полностью противоречит действительности.

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

I>>Как минимум ДСЛ это конкретная архитектура + язык. Вобщем уже этого достаточно, что бы понять, что ДСЛ будет сложнее чем просто архитектура.
WH>

Проще. Я рядом писал почему.

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

I>>Кстати говоря, пример с Linq или RX не в твою пользу. Архитектур насоздавали тонны, а язык родили всего один.
WH>В мою. Ибо в микрософт поняли, что натянуть всё на C# не получается. И дали очередную фичу на которую можно относительно удобно натянуть еще несколько задач.
WH>Если бы C# можно было легко расширять, то LINQ никогда бы не появился.

То есть, ты тоже считаешь, что для разработки самого языка нужен Эрик Мейер а не просто любой девелопер ? Если так, то всё в порядке.

Здравствуйте, Ikemefula, Вы писали:

I>Теоретически. На практике этот найм заканчивается так — "прошло уже полгода, если через месяц не найдете гуру, мы отдаём проект студентам". Зарплатой этот вопрос не решается в принципе, это трудно понять но это так.
I>Я знаю много примеров когда конторы задирали планку чуть не вдвое выше максимальной по рынку и оставались ни с чем.
Они гарантированно останутся ни с чем, если наймут студентов на проект больше 1000 строк.

I>Да, именно так. "Надсмотрщик" может вообще быть непрограммистом. Это просто представитель заказчика, все что ему надо — обеспечивать внятные требования, проверять промежуточные результаты в реальных условиях и следить за динамикой багов.
Бред. Если он не программист он никогда не поймет что проект сваливается в говно до того как проект туда окончательно свалится. И уж точно не сможет это предотвратить.
Ну, увидит он, что багов куча и что дальше? Что он сделает?
Разгонит исполнителей и наймет новых, чтобы переписали?

I>Грамотно построеный процесс позволяет радикально снизить проходную планку для девелоперов. Многие фирмы только этим и живут. У меня, к слову, специфика совсем другая — на тот случай если ты продолжишь играть в игру "а у тебя всё плохо".
Те ты тупо теоретизируешь?

I>Я так понял, любой проект говно если в ём нет немерле и писаных на ём дсл ?

Сразу слив засчитываем?

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

I>Есть только одно требование: "заказчик доволен результатами внедрения программы" Фокус в том, что его очень тяжело формализовать в более конкретных терминах. И к слову, многие "студенческие" проекты удовлетворяют этому требованию. Можешь по привычке придраться к словам, начни со слова "многие"

Удовлетворяют или "ох блин что же мне всучили и судится с этими уродами дороже выйдет"

Или еще вариант персонал использующий софт плачет, а начальству наплевать.
Короче прокуратура по такому жулью плачет.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>OMG !!! Async Programming Model
Первый раз вижу данное сокращение.
На первых пяти страницах гугла его тоже нет.

I>Эти первичные данных и нахрен не упали.

И что же тогда в ГУИ отображается?

I>Что значит "изменение семантики" ? Покажи на примере.
Нет. Лучше ты покажи, что это за "приведения энергичного кода в ленивый" и что оно даёт.

И как это всё решает проблемы с асинхронным и реактивным программированием мне тоже совершенно не ясно.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Люди, которые разрабатывают пригодную архитектуру большей частью разрабатывают непригодные языки. Чего то нехватает, ибо код на этих языках скатывается в говно еще быстрее, чем код на С# скажем.
Правда? Что-то не замечал.

I>Это не объяснение, а просто описание общих вещей. Про сложность введения языка там ничего нет. Мне что то кажется для общего случая надо обладать скилами примерно как у Эрика Мейера.
Нет этой сложности.
Вообще нет.
Сложности есть с придумыванием языков общего назначения на которые потом будут натягиваться другие предметные области.
Сложностей с созданием ДСЛ нет.
Ты их придумал.

WH>>В мою. Ибо в микрософт поняли, что натянуть всё на C# не получается. И дали очередную фичу на которую можно относительно удобно натянуть еще несколько задач.
WH>>Если бы C# можно было легко расширять, то LINQ никогда бы не появился.
I>То есть, ты тоже считаешь, что для разработки самого языка нужен Эрик Мейер а не просто любой девелопер ? Если так, то всё в порядке.
Я написал прямо противоположное. Если бы люди могли делать свои расширения под свои задачи Эрик Мейер остался бы не при делах.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>OMG !!! Async Programming Model
WH>Первый раз вижу данное сокращение.
WH>На первых пяти страницах гугла его тоже нет.

На первых страницах гугла много чего нет, тебя это удивляет ?

I>>Эти первичные данных и нахрен не упали.
WH>

И что же тогда в ГУИ отображается?

Неважно, для обработки UI это не самое главное. События на порядок важнее, а откуда ты возьмешь значение, из свойства или из функции или еще откуда — дело десятое.

I>>Что значит "изменение семантики" ? Покажи на примере.
WH>Нет. Лучше ты покажи, что это за "приведения энергичного кода в ленивый" и что оно даёт.

Из самых известных это например применения AsyncEnumerator из Power Threading Library.

WH>И как это всё решает проблемы с асинхронным и реактивным программированием мне тоже совершенно не ясно.

Я в курсе что тебе не ясно, не надо повторять.

Здравствуйте, WolfHound, Вы писали:

I>>Люди, которые разрабатывают пригодную архитектуру большей частью разрабатывают непригодные языки. Чего то нехватает, ибо код на этих языках скатывается в говно еще быстрее, чем код на С# скажем.
WH>Правда? Что-то не замечал.

Правда. Архитектура не должна быть идеальным решением. Решает текущие задачи — отлично. Заниматься рафинированием понятий и абстракций для введения качественного ДСЛ требует дополнительных скилов, экспериментов даже без реализации компилятора.

I>>Это не объяснение, а просто описание общих вещей. Про сложность введения языка там ничего нет. Мне что то кажется для общего случая надо обладать скилами примерно как у Эрика Мейера.
WH>Нет этой сложности.
WH>Вообще нет.

Ну да, свободное владение теорией категорий и прочей математикой не в счёт ?

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

Да, и теорию категорий тоже я придумал.

I>>То есть, ты тоже считаешь, что для разработки самого языка нужен Эрик Мейер а не просто любой девелопер ? Если так, то всё в порядке.
WH>Я написал прямо противоположное. Если бы люди могли делать свои расширения под свои задачи Эрик Мейер остался бы не при делах.

"Если б могли" — судя по тому, что выхлопа кроме как у Мейера нет, то разговор можно и закончить.

Здравствуйте, Ikemefula, Вы писали:

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

I>Неважно, для обработки UI это не самое главное. События на порядок важнее, а откуда ты возьмешь значение, из свойства или из функции или еще откуда — дело десятое.
Рука лицо.
Подумай, чем занимаются в обработчиках событий...
Правильно изменением ViewModel и переливанием из неё во View.
То, что студенты из-за недостатка образования часто запихивают ViewModel во View не отменяет ViewModel.

I>Из самых известных это например применения AsyncEnumerator из Power Threading Library.

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

WH>>И как это всё решает проблемы с асинхронным и реактивным программированием мне тоже совершенно не ясно.
I>Я в курсе что тебе не ясно, не надо повторять.
Ты делаешь заявления вселенского масштаба.
Нужно выяснить, что за ними стоит.
Выяснил. За ними стоит глупость такого же масштаба. Честно говоря, не удивлен.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Правда. Архитектура не должна быть идеальным решением. Решает текущие задачи — отлично. Заниматься рафинированием понятий и абстракций для введения качественного ДСЛ требует дополнительных скилов, экспериментов даже без реализации компилятора.
Не соответствует действительности.

I>Ну да, свободное владение теорией категорий и прочей математикой не в счёт ?
Не нужно.

I>"Если б могли" — судя по тому, что выхлопа кроме как у Мейера нет, то разговор можно и закончить.
Есть. Когда пытаются.
Ну и не забывай, что проблемы языков общего назначения совершенно никак не относятся к языкам конкретного назначения.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>На первых страницах гугла много чего нет, тебя это удивляет ?
WH>Удивляет реакция на то, что кто-то не знает придуманную тобой аббревиатуру.

Не расстраивайся, я и msdn придумал
http://msdn.microsoft.com/en-us/library/ms228963.aspx

I>>Неважно, для обработки UI это не самое главное. События на порядок важнее, а откуда ты возьмешь значение, из свойства или из функции или еще откуда — дело десятое.
WH>Рука лицо.
WH>Подумай, чем занимаются в обработчиках событий...

В кратце — вычисляют необходимые изменения в model. При чем в случае преобразования энергичного кода в ленивы не нужно "обработчиках", нужна только одна функция.

I>>Из самых известных это например применения AsyncEnumerator из Power Threading Library.
WH>

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

Axum или erlang тебе тоже не нравятся ?

I>>Я в курсе что тебе не ясно, не надо повторять.
WH>Ты делаешь заявления вселенского масштаба.
WH>Нужно выяснить, что за ними стоит.
WH>Выяснил. За ними стоит глупость такого же масштаба. Честно говоря, не удивлен.

Думаю раз ты видишь эту глупость, то она на твоей стороне монитора, скорее всего в виде прослойки между креслом и монитором.

Здравствуйте, WolfHound, Вы писали:

I>>Правда. Архитектура не должна быть идеальным решением. Решает текущие задачи — отлично. Заниматься рафинированием понятий и абстракций для введения качественного ДСЛ требует дополнительных скилов, экспериментов даже без реализации компилятора.
WH>Не соответствует действительности.

На твоем примере про ERP мы это уже проходили, спасибо, не надо.

I>>Ну да, свободное владение теорией категорий и прочей математикой не в счёт ?
WH>Не нужно.

На твоем примере про ERP мы это уже проходили, спасибо, не надо.

I>>"Если б могли" — судя по тому, что выхлопа кроме как у Мейера нет, то разговор можно и закончить.
WH>Есть. Когда пытаются.
WH>Ну и не забывай, что проблемы языков общего назначения совершенно никак не относятся к языкам конкретного назначения.

ты передергиваешь
1 там про макры, а не дсл
2 "проще разработать какую-то феньку нужную в 5 местах и без параметров, и какую-то очень похожую феньку (даже внешне точно такую-же) для 5 других мест, чем лепить универсальную, конфигурируемую через кучу параметров мега-фень, способную покрыть все эти 10 мест и ещё 20 гипотетических похожих."

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

Вобщем если ты не возражаешь, можно закончить, ибо ты слишком часто передёргиваешь

Здравствуйте, Ikemefula, Вы писали:

I>Не расстраивайся, я и msdn придумал
I>http://msdn.microsoft.com/en-us/library/ms228963.aspx
Ты уж извини, что я за всем, что придумывает майкрософт не слежу.

I>В кратце — вычисляют необходимые изменения в model. При чем в случае преобразования энергичного кода в ленивы не нужно "обработчиках", нужна только одна функция.
Пример кода можно?

I>Axum или erlang тебе тоже не нравятся ?
Axum не смотрел, но в эрланг данная функциональность встроена в язык.
В C# её эмулируют на механизме, который создан для генерации последовательностей.
Почувствуй разницу.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Теоретически. На практике этот найм заканчивается так — "прошло уже полгода, если через месяц не найдете гуру, мы отдаём проект студентам". Зарплатой этот вопрос не решается в принципе, это трудно понять но это так.
I>>Я знаю много примеров когда конторы задирали планку чуть не вдвое выше максимальной по рынку и оставались ни с чем.
WH>Они гарантированно останутся ни с чем, если наймут студентов на проект больше 1000 строк.

Практика не подтверждает твой вывод. Крайне редко проект проваливается на стороне девелопмента. Это настолько редкий случай что им можно смело пренебречь. Маркетинг и управление, в частности управление требованиями, приводят к провалу в 99.99999% случаев.

I>>Да, именно так. "Надсмотрщик" может вообще быть непрограммистом. Это просто представитель заказчика, все что ему надо — обеспечивать внятные требования, проверять промежуточные результаты в реальных условиях и следить за динамикой багов.
WH>Бред. Если он не программист он никогда не поймет что проект сваливается в говно до того как проект туда окончательно свалится. И уж точно не сможет это предотвратить.
WH>Ну, увидит он, что багов куча и что дальше? Что он сделает?
WH>Разгонит исполнителей и наймет новых, чтобы переписали?

Мне лень устраивать ликбез по управлению проектом. Хочешь, созадай новую тему в соответсвующем форуме.

I>>Грамотно построеный процесс позволяет радикально снизить проходную планку для девелоперов. Многие фирмы только этим и живут. У меня, к слову, специфика совсем другая — на тот случай если ты продолжишь играть в игру "а у тебя всё плохо".
WH>Те ты тупо теоретизируешь?

То есть, не надо быть курицей, что бы видеть куриные яйца.

I>>Я так понял, любой проект говно если в ём нет немерле и писаных на ём дсл ?

WH>Сразу слив засчитываем?

Ты отвечай по существу, не увиливай.

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

Неважно, на зп или натурой. Это всегда проблема заказчика. Дальше осталось понять простую вещь — программа в принципе не может быть лучше своих требований.
Для тех требований, что в 80-90% проектов, хватает девелоперов с опытом работы до 5 лет а часто и вовсе студентов.

I>>Есть только одно требование: "заказчик доволен результатами внедрения программы" Фокус в том, что его очень тяжело формализовать в более конкретных терминах. И к слову, многие "студенческие" проекты удовлетворяют этому требованию. Можешь по привычке придраться к словам, начни со слова "многие"

WH>Удовлетворяют или "ох блин что же мне всучили и судится с этими уродами дороже выйдет"

Очевидно это не подходит под "доволен результатами внедрения программы".

WH>Или еще вариант персонал использующий софт плачет, а начальству наплевать.

Очевидно и это не подходит под "доволен результатами внедрения программы".

WH>Короче прокуратура по такому жулью плачет.

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

Здравствуйте, Ikemefula, Вы писали:

I>На твоем примере про ERP мы это уже проходили, спасибо, не надо.
И что же ты проходил?

I>ты передергиваешь
Ни разу.

I>1 там про макры, а не дсл
Это и есть ДСЛ. Они семантику языка очень сильно поменяли.

I>То есть, у людей не то что дсл не вышел, даже фремворка толком не вышло, ибо пилят одно и то же, для чуточку разных случаев.
Именно что ДСЛ и вышли.
Ибо ДСЛ заточен на конкретную задачу, и другие решает плохо.
Точить ДСЛ под все задачи идея заведомо провальная. О чем и написано.
Но ты хочешь всемогутер на все случаи жизни. Оставайся на C#. Это такой всемогутер и есть. Он решает все задачи, но решает их все плохо.

I>Вобщем если ты не возражаешь, можно закончить, ибо ты слишком часто передёргиваешь

Ни разу.
Но таки да. Можно закончить. Полезной информации от тебя всё равно не будет.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>На твоем примере про ERP мы это уже проходили, спасибо, не надо.
WH>И что же ты проходил?

Ты обещал дсл и не смог его предложить.

I>>1 там про макры, а не дсл
WH>Это и есть ДСЛ. Они семантику языка очень сильно поменяли.

Они поменяли только внешний вид.

I>>То есть, у людей не то что дсл не вышел, даже фремворка толком не вышло, ибо пилят одно и то же, для чуточку разных случаев.
WH>Именно что ДСЛ и вышли.
WH>Ибо ДСЛ заточен на конкретную задачу, и другие решает плохо.
WH>Точить ДСЛ под все задачи идея заведомо провальная. О чем и написано.

Не под все, а вполне конктерные:
"какую-то феньку ... и какую-то очень похожую феньку "

WH>Но ты хочешь всемогутер на все случаи жизни. Оставайся на C#. Это такой всемогутер и есть. Он решает все задачи, но решает их все плохо.

Передергиваешь.

I>>Вобщем если ты не возражаешь, можно закончить, ибо ты слишком часто передёргиваешь

WH>Ни разу.
WH>Но таки да. Можно закончить. Полезной информации от тебя всё равно не будет.

До свидания.

Здравствуйте, Ikemefula, Вы писали:

I>Практика не подтверждает твой вывод. Крайне редко проект проваливается на стороне девелопмента. Это настолько редкий случай что им можно смело пренебречь. Маркетинг и управление, в частности управление требованиями, приводят к провалу в 99.99999% случаев.
Учитывая, что задача управления нанять адекватных исполнителей можно заключить, что 100% провалов происходят из-за управления.
Вот только если человек не понимает, кого он нанимает, он не может нанять адекватных исполнителей. Ну, разве что ему очень сильно повезет.
Например, я могу опознать хорошего программиста. Но не смогу опознать хорошего разработчика авиационных двигателей. Ибо в них ничего не понимаю.

I>Мне лень устраивать ликбез по управлению проектом. Хочешь, созадай новую тему в соответсвующем форуме.
Ну, уж нет. Не выкрутишься.
Как не программист поймет, что исполнители заваливают проект и что он сможет сделать?
Я смогу понять это через пару недель после начала работы глядя на код. Что может не программист на данном этапе? А ничего он не сможет. Он просто не поймет все эти закорючки.

I>>>Я так понял, любой проект говно если в ём нет немерле и писаных на ём дсл ?

WH>>Сразу слив засчитываем?
I>Ты отвечай по существу, не увиливай.
Разговор идет про то, что проекты могут делать неучи.
А ты сваливаешь все на немерле.
Твое виляние очевидно.

WH>>Удовлетворяют или "ох блин что же мне всучили и судится с этими уродами дороже выйдет"

I>Очевидно это не подходит под "доволен результатами внедрения программы".
А как ты определяешь "доволен результатом"?
Методику в студию.
Ибо "не устроил скандал" == "доволен результатом" методика не правильная.

WH>>Или еще вариант персонал использующий софт плачет, а начальству наплевать.
I>Очевидно и это не подходит под "доволен результатами внедрения программы".
Правда? А глядя на того кто заказал софт исполнителю про это не скажешь. Ему плевать.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Не расстраивайся, я и msdn придумал
I>>http://msdn.microsoft.com/en-us/library/ms228963.aspx
WH>Ты уж извини, что я за всем, что придумывает майкрософт не слежу.

Эту модель придумал не микрософт. Я например эту аббревиатуру видел в книгах и либах еще до того, как на винду перешел.

I>>В кратце — вычисляют необходимые изменения в model. При чем в случае преобразования энергичного кода в ленивы не нужно "обработчиках", нужна только одна функция.
WH>Пример кода можно?

Ничем не отличается от примера в конце сообщения.

I>>Axum или erlang тебе тоже не нравятся ?
WH>Axum не смотрел, но в эрланг данная функциональность встроена в язык.

Как это упрощает жизнь в эрланде и аксуме понятно ?
Axum например сдох не родившись. Эрланг есть только в узкой нише. Нужен точно такой же механизм но в самом массовом ЯП безо всяких эмуляций.

WH>В C# её эмулируют на механизме, который создан для генерации последовательностей.
WH>Почувствуй разницу.

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

I>>Думаю раз ты видишь эту глупость, то она на твоей стороне монитора, скорее всего в виде прослойки между креслом и монитором.
WH>Так ты код покажи. А то только болтаешь языком.

      private static IEnumerator<Int32> Process(AsyncEnumerator ae, String server, String message) {
         TcpClient client = new TcpClient(server, 12000);
         Stream stream = client.GetStream();
         Byte[] outputString = Encoding.UTF8.GetBytes(message);
         Byte[] outputData = new Byte[1 + outputString.Length];
         outputData[0] = (Byte)outputString.Length;
         Array.Copy(outputString, 0, outputData, 1, outputString.Length);

         stream.BeginWrite(outputData, 0, outputData.Length, ae.End(), null);
         yield return 1;

         stream.EndWrite(ae.DequeueAsyncResult());

         Byte[] inputData = new Byte[1 + 255];
         stream.BeginRead(inputData, 0, 1, ae.End(), null);
         yield return 1;

         // Server closed connection
         if (stream.EndRead(ae.DequeueAsyncResult()) == 0) { client.Close(); yield break; }

         // Start to read 'length' bytes of data from server
         Int32 dataLength = inputData[0];
         Array.Resize(ref inputData, 1 + dataLength);

         Int32 bytesReadSoFar = 0;
         while (bytesReadSoFar < dataLength) {
            stream.BeginRead(inputData, 1, dataLength, ae.End(), null);
            yield return 1;

            // Get number of bytes read from server
            Int32 numBytesReadThisTime = stream.EndRead(ae.DequeueAsyncResult());

            // Server closed connection
            if (numBytesReadThisTime == 0) { client.Close(); yield break; }

            // Continue to read bytes from server until all bytes are in
            bytesReadSoFar += (Byte)numBytesReadThisTime;

         }

         // All bytes have been read, Show the server's result
         String result = Encoding.UTF8.GetString(inputData, 1, inputData[0]);
         Console.WriteLine("Received={0}", result);
         client.Close();
      }

Здравствуйте, Ikemefula, Вы писали:

I>>>На твоем примере про ERP мы это уже проходили, спасибо, не надо.
WH>>И что же ты проходил?
I>Ты обещал дсл и не смог его предложить.
Его можно предложить только после анализа задачи.
Максимум, что было с вашей стороны, это AVK вывалил кусок кода, по которому ничего не ясно. На все вопросы были получены ответы из серии "это не важно".

WH>>Это и есть ДСЛ. Они семантику языка очень сильно поменяли.
I>Они поменяли только внешний вид.

Ты сообщение то читал?

WH>>Ибо ДСЛ заточен на конкретную задачу, и другие решает плохо.
WH>>Точить ДСЛ под все задачи идея заведомо провальная. О чем и написано.
I>Не под все, а вполне конктерные:
I>"какую-то феньку ... и какую-то очень похожую феньку "
И что же тут конкретного? А ничего.

WH>>Но ты хочешь всемогутер на все случаи жизни. Оставайся на C#. Это такой всемогутер и есть. Он решает все задачи, но решает их все плохо.
I>Передергиваешь.
Ни разу.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:

I>>Цитирую себя: "функция в детстве была паттерном 'вызов подпрограммы'"

I>>Реализация паттерна перекочевала в язык и с этого момента стала абстракцией, это естественный процесс, я повторяю это уже раз наверное пяццот.
WH>После чего перестала быть паттерном.
WH>О чем я тебе с самого начала и говорил.
+1

WH>Теперь осталось только понять, что любой паттерн можно засунуть в язык.
Chain-of-responsibility непонятно как засунуть в язык.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:

I>>Практика не подтверждает твой вывод. Крайне редко проект проваливается на стороне девелопмента. Это настолько редкий случай что им можно смело пренебречь. Маркетинг и управление, в частности управление требованиями, приводят к провалу в 99.99999% случаев.
WH>Учитывая, что задача управления нанять адекватных исполнителей можно заключить, что 100% провалов происходят из-за управления.

А в огороде дядька. 80-90% проектов это "взять в базе, положить на форму; взять на форме, положить в базу". Техническая сложность этих проектов около нуля. При этом здесь крутится столько денег, что конторы позволяют себе только этим и заниматься не глядя ни на что другое.

Теперь взгляни на себя со стороны — ты предлагаешь для проектов, где техническая сложность нулевая, набрать суровых архитектором с десятками лет опыта

I>>Мне лень устраивать ликбез по управлению проектом. Хочешь, созадай новую тему в соответсвующем форуме.
WH>Ну, уж нет. Не выкрутишься.
WH>Как не программист поймет, что исполнители заваливают проект и что он сможет сделать?
WH>Я смогу понять это через пару недель после начала работы глядя на код. Что может не программист на данном этапе? А ничего он не сможет. Он просто не поймет все эти закорючки.

См. выше.

I>>>>Я так понял, любой проект говно если в ём нет немерле и писаных на ём дсл ?

WH>>>Сразу слив засчитываем?
I>>Ты отвечай по существу, не увиливай.
WH>Разговор идет про то, что проекты могут делать неучи.

на проект нужно набирать людей в соответсвтии с 1 технической сложностью проекта 2 состоянием рынка труда.
Про техническую сложность см выше.

WH>>>Удовлетворяют или "ох блин что же мне всучили и судится с этими уродами дороже выйдет"

I>>Очевидно это не подходит под "доволен результатами внедрения программы".
WH>А как ты определяешь "доволен результатом"?
WH>Методику в студию.
WH>Ибо "не устроил скандал" == "доволен результатом" методика не правильная.

Доволен результатом значит заказчик достиг с помощью софта свои цели, в контексте бизнеса конечно. НАпример заказчику нужна была автоматизация некоторых рабочих мест. Пошел профит == заказчик доволен.

WH>>>Или еще вариант персонал использующий софт плачет, а начальству наплевать.
I>>Очевидно и это не подходит под "доволен результатами внедрения программы".
WH>Правда? А глядя на того кто заказал софт исполнителю про это не скажешь. Ему плевать.

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

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

см выше

Здравствуйте, WolfHound, Вы писали:

I>>>>На твоем примере про ERP мы это уже проходили, спасибо, не надо.
WH>>>И что же ты проходил?
I>>Ты обещал дсл и не смог его предложить.
WH>Его можно предложить только после анализа задачи.
WH>Максимум, что было с вашей стороны, это AVK вывалил кусок кода, по которому ничего не ясно. На все вопросы были получены ответы из серии "это не важно".

АВК вдобавок объяснял десять или более постов.

WH>>>Ибо ДСЛ заточен на конкретную задачу, и другие решает плохо.
WH>>>Точить ДСЛ под все задачи идея заведомо провальная. О чем и написано.
I>>Не под все, а вполне конктерные:
I>>"какую-то феньку ... и какую-то очень похожую феньку "
WH>И что же тут конкретного? А ничего.

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

Здравствуйте, WolfHound, Вы писали:

WH>>>Ибо ДСЛ заточен на конкретную задачу, и другие решает плохо.
WH>>>Точить ДСЛ под все задачи идея заведомо провальная. О чем и написано.
I>>Не под все, а вполне конктерные:
I>>"какую-то феньку ... и какую-то очень похожую феньку "
WH>И что же тут конкретного? А ничего.

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

Здравствуйте, artelk, Вы писали:

WH>>Теперь осталось только понять, что любой паттерн можно засунуть в язык.
A>Chain-of-responsibility непонятно как засунуть в язык.

Это просто функция. Она делается через специальные отношения вроде owner, paren, children и тд. Но в отрыве от задачи это не совсем понятно.

Здравствуйте, artelk, Вы писали:

A>Chain-of-responsibility непонятно как засунуть в язык.
Как засунуть сфероконя в язык действительно не ясно.
Тут надо брать конкретную задачу и решать.
Тогда сразу всё станет просто.
Ибо весь смысл ДСЛ это заточка под совершенно конкретную задачу.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Эту модель придумал не микрософт. Я например эту аббревиатуру видел в книгах и либах еще до того, как на винду перешел.
А гугл про нее не знает. Значит аббревиатура, мягко говоря, редкая.

I>>>В кратце — вычисляют необходимые изменения в model. При чем в случае преобразования энергичного кода в ленивы не нужно "обработчиках", нужна только одна функция.
WH>>Пример кода можно?
I>Ничем не отличается от примера в конце сообщения.
Правда? Тот код строго последовательный. А пользователь тыкает, куда попало в произвольном порядке... Это тебя не смущает?

I>Как это упрощает жизнь в эрланде и аксуме понятно ?
Как это поможет при создании ГУИ не понятно.

I>Axum например сдох не родившись. Эрланг есть только в узкой нише. Нужен точно такой же механизм но в самом массовом ЯП безо всяких эмуляций.
Не правильно. Нужен механизм расширения языков.
Тогда мы сможем сделать всё, что нам нужно.
В том числе и данную функциональность. Без всяких эмуляций.
Посмотри, что народ с немерлом делает.
http://user1663.netfx45lab.discountasp.net/
Сколько ты будешь ждать пока микрософт изволит повторить?

I>Поздравляю, ты открыл америку.
I>Цитирую себя: "нужно изыскивать решения для приведения энергичного кода в ленивый. Если такой инструмент появится"
I>Тебе все здесь понятно ?
Да.
Ты понимаешь, что натягивание фичей на язык, в котором этих фич нет плохо.
Но почему-то споришь с необходимостью расширяемых языков в которые можно добавить любую фичу без компромиссов.

I>>>Думаю раз ты видишь эту глупость, то она на твоей стороне монитора, скорее всего в виде прослойки между креслом и монитором.
WH>>Так ты код покажи. А то только болтаешь языком.
И к чему этот говнокодище?
Асинхронное программирование получается ужасным. Проще чем пилить всё на калбеках, но всё равно ужасно.
Реактивное вообще не получается.
Реактивное делается так http://user1663.netfx45lab.discountasp.net/

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

WH>>Максимум, что было с вашей стороны, это AVK вывалил кусок кода, по которому ничего не ясно. На все вопросы были получены ответы из серии "это не важно".
I>АВК вдобавок объяснял десять или более постов.
Все его посты состояли из фразы "это не важно" чуть менее чем полностью.

I>Ты сам себе противоречишь. Определись, 5 случаев это конкретная задача или нет. Как определишься, продолжим.
Ты говоришь, что нужно точить ДСЛ под оба случая.
При этом про случаи ничего не известно.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>На пример Linq — это всемогутор ? По моему разумению вполне конкретная задача — запросы к некоторым источникам писать.
I>Проверяем твою идейку — пишем не linq а мульку для 5 случав запросов, потом рядом пишем снова мульку для 5 запросов которые очень похожие на первые 5.
I>В итоге два макроса а случай как был конкретным, так и остался.

То-то тот же IT хочет добавить в linq кучу ключевых слов типа insert, delete и много чего еще.
При этом в других задачах нужны другие ключевые слова.
При этом есть куча задач, для которых многое ключевые слова linq не нужны.
Вот и получается, что для разных случаев проще воспроизвести маленькую часть повторяющихся ключевых слов и не парится с тем, что в одном случае нужно одно, а в другом другое.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Теперь взгляни на себя со стороны — ты предлагаешь для проектов, где техническая сложность нулевая, набрать суровых архитектором с десятками лет опыта

Если этим архитекторам дать ДСЛ. А для данных типовых проектов легко делается типовой ДСЛ. То они будут делать эти проекты настолько быстрее, дешевле и качественней студентов, что даже не смешно.

Делать проекты тупыми инструментами и тупыми исполнителями это очень дорого и рискованно.

WH>>Ну, уж нет. Не выкрутишься.
WH>>Как не программист поймет, что исполнители заваливают проект и что он сможет сделать?
WH>>Я смогу понять это через пару недель после начала работы глядя на код. Что может не программист на данном этапе? А ничего он не сможет. Он просто не поймет все эти закорючки.
I>См. выше.
Не виляй.
Как не программист сможет понять, что проект идет в говно?
Ответ на этот простой вопрос будет?

I>на проект нужно набирать людей в соответсвтии с 1 технической сложностью проекта 2 состоянием рынка труда.
I>Про техническую сложность см выше.
Это не важно. Неучи всё равно не справятся.

I>Доволен результатом значит заказчик достиг с помощью софта свои цели, в контексте бизнеса конечно. НАпример заказчику нужна была автоматизация некоторых рабочих мест. Пошел профит == заказчик доволен.
Только заказчик не знает, что профит мог бы быть намного больше.
А если бы он знал что вместо его мотыги ему дали лошадь с плугом (относительно мотыги пошёл профит), а могли бы дать трактор, причем в несколько раз дешевле, чем он заплатил за клячу и на год раньше...
Короче к прокурору.

I>Если заказчику насрать, что на его стороне плак и ной, то странно ожидать толковых требований. А если не насрать, то неясно, к чему твой пример.
К тому что "успех" проекта, который сделали неучи, может быть лишь видимостью обусловленный массой факторов, которые не связаны с самим проектом.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>На пример Linq — это всемогутор ? По моему разумению вполне конкретная задача — запросы к некоторым источникам писать.
I>>Проверяем твою идейку — пишем не linq а мульку для 5 случав запросов, потом рядом пишем снова мульку для 5 запросов которые очень похожие на первые 5.
I>>В итоге два макроса а случай как был конкретным, так и остался.
WH>

То-то тот же IT хочет добавить в linq кучу ключевых слов типа insert, delete и много чего еще.
WH>При этом в других задачах нужны другие ключевые слова.
WH>При этом есть куча задач, для которых многое ключевые слова linq не нужны.
WH>Вот и получается, что для разных случаев проще воспроизвести маленькую часть повторяющихся ключевых слов и не парится с тем, что в одном случае нужно одно, а в другом другое.

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

Здравствуйте, WolfHound, Вы писали:

WH>>>Максимум, что было с вашей стороны, это AVK вывалил кусок кода, по которому ничего не ясно. На все вопросы были получены ответы из серии "это не важно".
I>>АВК вдобавок объяснял десять или более постов.
WH>Все его посты состояли из фразы "это не важно" чуть менее чем полностью.

Это мягко говоря враньё.

I>>Ты сам себе противоречишь. Определись, 5 случаев это конкретная задача или нет. Как определишься, продолжим.
WH>Ты говоришь, что нужно точить ДСЛ под оба случая.
WH>При этом про случаи ничего не известно.

Разумеется под оба. И это не значит, что получится всемогутор. Что получается в проекте, если пилить под каждые 5 случаев использования я уже описывал — хаос.

Здравствуйте, Ikemefula, Вы писали:

WH>>Все его посты состояли из фразы "это не важно" чуть менее чем полностью.
I>Это мягко говоря враньё.
Открой ветку да посмотри. Ничего по существу задачи он не сказал.

I>Разумеется под оба. И это не значит, что получится всемогутор.
Ты говоришь именно про всемогутер. Ибо разные 5 случаев могут только казаться похожими.

I>Что получается в проекте, если пилить под каждые 5 случаев использования я уже описывал — хаос.

Ничего ты не описывал. И описывать не мог. Максимум фантазировать. Ибо опыта в данном вопросе у тебя нет.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Linq используется куда большче, чем в 5 случаях и тем не менее остаётся конкретным случаем, а не всемогутором.
Ты вообще прочитал написанное? Тут написано, что Linq не адекватен для многих случаев. Это факты. И никакой демагогией ты тут не отвертишься.
И из этих фактов следует что его проще переизобрести для разных случаев чем каждый страдать от того что есть лишние и не хватает нужных ключевых слов.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Эту модель придумал не микрософт. Я например эту аббревиатуру видел в книгах и либах еще до того, как на винду перешел.
WH>А гугл про нее не знает. Значит аббревиатура, мягко говоря, редкая.

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

I>>Ничем не отличается от примера в конце сообщения.
WH>Правда? Тот код строго последовательный. А пользователь тыкает, куда попало в произвольном порядке... Это тебя не смущает?

Правда. Нисколько.

I>>Как это упрощает жизнь в эрланде и аксуме понятно ?
WH>Как это поможет при создании ГУИ не понятно.

ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.

I>>Axum например сдох не родившись. Эрланг есть только в узкой нише. Нужен точно такой же механизм но в самом массовом ЯП безо всяких эмуляций.
WH>Не правильно. Нужен механизм расширения языков.
WH>Тогда мы сможем сделать всё, что нам нужно.
WH>В том числе и данную функциональность. Без всяких эмуляций.
WH>Посмотри, что народ с немерлом делает.
WH>http://user1663.netfx45lab.discountasp.net/
WH>Сколько ты будешь ждать пока микрософт изволит повторить?

Извини, я в вебе мало чего понимаю.

I>>Поздравляю, ты открыл америку.
I>>Цитирую себя: "нужно изыскивать решения для приведения энергичного кода в ленивый. Если такой инструмент появится"
I>>Тебе все здесь понятно ?
WH>Да.
WH>Ты понимаешь, что натягивание фичей на язык, в котором этих фич нет плохо.

OMG !!! Сравни "Если такой инструмент появится" c "такой инструмент появился и это yield return в C#"

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

Пока нет вакансий по Nemerle им смело можно пренебречь. Я не люблю экспериментировать на себе.

WH>И к чему этот говнокодище?
WH>Асинхронное программирование получается ужасным. Проще чем пилить всё на калбеках, но всё равно ужасно.

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

WH>Реактивное вообще не получается.

Ты похоже вообще не читаешь.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:

I>>Linq используется куда большче, чем в 5 случаях и тем не менее остаётся конкретным случаем, а не всемогутором.
WH>Ты вообще прочитал написанное? Тут написано, что Linq не адекватен для многих случаев. Это факты.

Правильно. Но он не писался в духе "для 5 случаев".

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

Разумеется, а еще проще изобретать его для каждого случая — бери да копипасти.

Здравствуйте, WolfHound, Вы писали:

WH>>>Все его посты состояли из фразы "это не важно" чуть менее чем полностью.
I>>Это мягко говоря враньё.
WH>Открой ветку да посмотри. Ничего по существу задачи он не сказал.

Но ты вещаешь как будто у него и работаешь

I>>Разумеется под оба. И это не значит, что получится всемогутор.
WH>Ты говоришь именно про всемогутер. Ибо разные 5 случаев могут только казаться похожими.

Нет, по моему "очень похожи" и "только кажутся похожими" это разные вещи и про это в том сообщении ничего нет.
ты не у hi_octane работаешь ?

I>>Что получается в проекте, если пилить под каждые 5 случаев использования я уже описывал — хаос.
WH>

Ничего ты не описывал. И описывать не мог. Максимум фантазировать. Ибо опыта в данном вопросе у тебя нет.

Очередное враньё в твоем исполнении
http://rsdn.ru/forum/philosophy/4718846.1.aspx

Здравствуйте, WolfHound, Вы писали:

I>>Теперь взгляни на себя со стороны — ты предлагаешь для проектов, где техническая сложность нулевая, набрать суровых архитектором с десятками лет опыта

WH>Если этим архитекторам дать ДСЛ. А для данных типовых проектов легко делается типовой ДСЛ. То они будут делать эти проекты настолько быстрее, дешевле и качественней студентов, что даже не смешно.

Они вообще это не будут делать, им это скучно.

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

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

WH>>>Я смогу понять это через пару недель после начала работы глядя на код. Что может не программист на данном этапе? А ничего он не сможет. Он просто не поймет все эти закорючки.
I>>См. выше.
WH>Не виляй.
WH>Как не программист сможет понять, что проект идет в говно?
WH>Ответ на этот простой вопрос будет?

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

Если не влияет, вопрос закрыт. Если влияет, то как именно.
Динамика багов отражает проблемы в проекте, это что, новость ? Прогонять сценарии пользоваля это новость ? Контрибутить баги это новость ? Отслеживать расход времени на разработку это тоже по твоему новость ?
С такими вопросами ты, походу, кроме как в одиночку то и не работал нигде. Соболезную.

I>>на проект нужно набирать людей в соответсвтии с 1 технической сложностью проекта 2 состоянием рынка труда.
I>>Про техническую сложность см выше.
WH>Это не важно. Неучи всё равно не справятся.

Неучи конечно не справятся, а для 80-90% задач за глаза хватает людей от студента 4го курса до молодого специалиста с опытом 5 лет.

I>>Доволен результатом значит заказчик достиг с помощью софта свои цели, в контексте бизнеса конечно. НАпример заказчику нужна была автоматизация некоторых рабочих мест. Пошел профит == заказчик доволен.
WH>Только заказчик не знает, что профит мог бы быть намного больше.

Возможный профит оценивается заранее и заказчик или соглашается на него или не соглашается. Например — хочу серверный софт под 1000 юзеров. Ему говорят — можем 100 за 9 млн $, он говорит — хорошо. Или так — пошли нахрен. Или так — может 1000 за 20 млн $, тут тоже варианты, от "хорошо" до "пошли нахрен"

WH>А если бы он знал что вместо его мотыги ему дали лошадь с плугом (относительно мотыги пошёл профит), а могли бы дать трактор, причем в несколько раз дешевле, чем он заплатил за клячу и на год раньше...

И где ты таких тупых заказчиков берешь ?

WH>Короче к прокурору.

Может чтото не так, если у тебя такие заказчики тупые ?

I>>Если заказчику насрать, что на его стороне плак и ной, то странно ожидать толковых требований. А если не насрать, то неясно, к чему твой пример.
WH>К тому что "успех" проекта, который сделали неучи, может быть лишь видимостью обусловленный массой факторов, которые не связаны с самим проектом.

Эта "видимость" почему то воспроизводится слишком регулярно.

Здравствуйте, Ikemefula, Вы писали:

I>Гугл про неё знает, только совпадающие аббревиатуры к программухе не относятся и на порядки более популярны чем любой запрос по программухе.
Её даже в википедии нет. Короче неуловимый Джо как он есть.

WH>>Правда? Тот код строго последовательный. А пользователь тыкает, куда попало в произвольном порядке... Это тебя не смущает?
I>Правда. Нисколько.
Мда.

I>ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.
И в чем ты видишь проблемы?
Или ты хочешь сказать, что виртуальные коллекции, которые физически загружают, только небольшое окно уже отменили?
И главное как последовательный код это будет решать?

WH>>http://user1663.netfx45lab.discountasp.net/
WH>>Сколько ты будешь ждать пока микрософт изволит повторить?
I>Извини, я в вебе мало чего понимаю.
Не виляй. Это чистый MVVM.
Из ВЕБ там только примитивный HTML который не знать невозможно.

I>OMG !!! Сравни "Если такой инструмент появится" c "такой инструмент появился и это yield return в C#"
Он не появился. yield return данную задачу не решает.

I>Пока нет вакансий по Nemerle им смело можно пренебречь. Я не люблю экспериментировать на себе.
Есть. Я сейчас пишу на немерле за зарплату выше рынка.

I>Разумеется, потому что нет поддержки в языке.
А несколькими строчками ты утверждал, что это yield return.

I>Нужна возможность описать конкретный воркфлоу в одной единсвенной функции, даже если кнопочки ты нажимаешь где попало. Как это будет выполняться, синхронно, асинхронно — дело десятое. Главное что энергичный код будет сделан ленивым.
Зачем в ГУИ "воркфлоу"?
Короче повтори на этом своем "воркфлоу" в том синтаксисе, который тебе нравится любую из демок http://user1663.netfx45lab.discountasp.net/

WH>>Реактивное вообще не получается.
I>Ты похоже вообще не читаешь.
Я тебе показал, что такое реактивное программирование.
То, что ты показываешь, к нему не относится.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Правильно. Но он не писался в духе "для 5 случаев".
И поэтому он не подходит ни для одного.

I>Разумеется, а еще проще изобретать его для каждого случая — бери да копипасти.
Так что ты будешь делать с лишними словами? И что более важно с теми, которых не хватает?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

WH>>Если этим архитекторам дать ДСЛ. А для данных типовых проектов легко делается типовой ДСЛ. То они будут делать эти проекты настолько быстрее, дешевле и качественней студентов, что даже не смешно.
I>Они вообще это не будут делать, им это скучно.
На C# скучно. Но когда у тебя ДСЛ то нет.
Ибо 99% процентов времени он будет тратить на анализ задачи.
А её запись на ДСЛ будет короче, чем на русском.

I>Определись для себя, как говнокод влияет на результат и в чем это может проявляться.
Мда. Говнокод заваливает проекты. Причем если первую итерацию еще иногда удаётся сдать, то поддержка будет адом.

I>Если не влияет, вопрос закрыт. Если влияет, то как именно.
I>Динамика багов отражает проблемы в проекте, это что, новость ? Прогонять сценарии пользоваля это новость ? Контрибутить баги это новость ? Отслеживать расход времени на разработку это тоже по твоему новость ?
1)Что из этого знает человек, который в разработке программ ничего не понимает.
2)Если он видит что багов много что дальше? Он не знает причину. И исполнители будут вещать, что это всё нормально. Так у всех и всегда. И скоро они всё исправят. Не забывай, по твоей версии заказчик в программировании ничего не понимает.

I>Неучи конечно не справятся, а для 80-90% задач за глаза хватает людей от студента 4го курса до молодого специалиста с опытом 5 лет.
Без опытного надсмотрщика они завалят проект с вероятность 99%.
А с опытным надсмотрщиком им на порядок эффективнее дать ДСЛ.

WH>>Только заказчик не знает, что профит мог бы быть намного больше.
I>Возможный профит оценивается заранее и заказчик или соглашается на него или не соглашается. Например — хочу серверный софт под 1000 юзеров. Ему говорят — можем 100 за 9 млн $, он говорит — хорошо. Или так — пошли нахрен. Или так — может 1000 за 20 млн $, тут тоже варианты, от "хорошо" до "пошли нахрен"
И как он узнает что:
Исполнитель может это сделать?
И главное что сервер под 100К пользователей на самом деле стоит 100К$?

Он же в программировании ничего не понимает.

WH>>А если бы он знал что вместо его мотыги ему дали лошадь с плугом (относительно мотыги пошёл профит), а могли бы дать трактор, причем в несколько раз дешевле, чем он заплатил за клячу и на год раньше...
I>И где ты таких тупых заказчиков берешь ?
Я? Это ты их берешь.
Ибо те, кто доволен деятельностью студентов, попадают именно в эту категорию.

I>Эта "видимость" почему то воспроизводится слишком регулярно.
1)Заказчик не знает, что его кинули.
2)Конкретным людям со стороны заказчика не выгодно поднимать шум.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

WH>>>>Все его посты состояли из фразы "это не важно" чуть менее чем полностью.
I>>>Это мягко говоря враньё.
WH>>Открой ветку да посмотри. Ничего по существу задачи он не сказал.
I>Но ты вещаешь как будто у него и работаешь

Не улавливаю логику. Из чего получается, что я работаю у AVK? Если бы я у него работал, я бы понимал его пример.

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

WH>>

Ничего ты не описывал. И описывать не мог. Максимум фантазировать. Ибо опыта в данном вопросе у тебя нет.
I>Очередное враньё в твоем исполнении
I>http://rsdn.ru/forum/philosophy/4718846.1.aspx
Ты там так и не рассказал, что там происходит. Да и не ты это делал.
Всё что ты продемонстрировал это полную неспособность сформулировать задачу.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>Пока нет вакансий по Nemerle им смело можно пренебречь. Я не люблю экспериментировать на себе.
WH>Есть. Я сейчас пишу на немерле за зарплату выше рынка.

тогда тебе надо уволиться.
создай вакансию — поддержи немерле!

Здравствуйте, Abyx, Вы писали:

A>тогда тебе надо уволиться.
A>создай вакансию — поддержи немерле!
Напротив. Если останусь, вакансий будет намного больше.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>Архитектур насоздавали тонны, а язык родили всего один.

Потому что нет удобных средств создания языков! Немерлисты постоянно талдычат об этом. Были бы такие средства — новые языки пеклись бы как пирожки.

Между тем, одним из таких средств является xml. Чтобы создать новый язык на базе xml достаточно определить схему. Определяем схему — получаем язык разметки, или даже язык программирования — XSLT. И такие языки клепаются десятками! Возьмём XAML — это новый язык. Причём внутри него реализован ещё один DSL — язык привязки данных.

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

Здравствуйте, koodeer, Вы писали:

I>>Архитектур насоздавали тонны, а язык родили всего один.

K>Потому что нет удобных средств создания языков! Немерлисты постоянно талдычат об этом. Были бы такие средства — новые языки пеклись бы как пирожки.

И какой инструмент поможет тебе изобрести абстракции за 1 год а не за 15 лет, как это было в обсуждаемом случае ?

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

Здравствуйте, WolfHound, Вы писали:

I>>Но ты вещаешь как будто у него и работаешь

WH>Не улавливаю логику. Из чего получается, что я работаю у AVK? Если бы я у него работал, я бы понимал его пример.

Перепутать авк и хайоктан — доказательство что ты вообще не помнишь контекст

I>>Нет, по моему "очень похожи" и "только кажутся похожими" это разные вещи и про это в том сообщении ничего нет.
WH>Но ты строишь далеко идущие выводы, по которым получается что hi_octane делает лишнюю работу.

Симптомы которые он перечисляет мне очень хорошо знакомы. Полной картины пока нет, но оснований для сомнений вполне достаточно.

WH>Ты там так и не рассказал, что там происходит. Да и не ты это делал.
WH>Всё что ты продемонстрировал это полную неспособность сформулировать задачу.

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

Здравствуйте, WolfHound, Вы писали:

I>>Правильно. Но он не писался в духе "для 5 случаев".
WH>И поэтому он не подходит ни для одного.

Вообще говоря линк подходит много где и всемогутором не является — ни разу.

I>>Разумеется, а еще проще изобретать его для каждого случая — бери да копипасти.
WH>Так что ты будешь делать с лишними словами? И что более важно с теми, которых не хватает?

Этот вопрос я задавал тебе раз 5 или 6. Если у тебя нет качественных абстракций, все твои языки будут мусором и тебе придется нанять человека вроде Эрика Мейера.

Здравствуйте, WolfHound, Вы писали:

WH>>>Если этим архитекторам дать ДСЛ. А для данных типовых проектов легко делается типовой ДСЛ. То они будут делать эти проекты настолько быстрее, дешевле и качественней студентов, что даже не смешно.
I>>Они вообще это не будут делать, им это скучно.
WH>На C# скучно. Но когда у тебя ДСЛ то нет.
WH>Ибо 99% процентов времени он будет тратить на анализ задачи.
WH>А её запись на ДСЛ будет короче, чем на русском.

Да без разницы, на чём. Для 80-90% проектов техническая сложность около нуля. Высококлассных специалистом можно заинтересовать только этой самой технической сложностью.
Или ты и предлагаешь решить этот вопрос с помощью ДСЛ ?

I>>Определись для себя, как говнокод влияет на результат и в чем это может проявляться.
WH>Мда. Говнокод заваливает проекты. Причем если первую итерацию еще иногда удаётся сдать, то поддержка будет адом.

Это общие слова. Говнокод дает целый ряд наблюдаемых и проверяемых эффектов. Вопрос — тебе они известны ?

I>>Если не влияет, вопрос закрыт. Если влияет, то как именно.
I>>Динамика багов отражает проблемы в проекте, это что, новость ? Прогонять сценарии пользоваля это новость ? Контрибутить баги это новость ? Отслеживать расход времени на разработку это тоже по твоему новость ?
WH>1)Что из этого знает человек, который в разработке программ ничего не понимает.

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

WH>2)Если он видит что багов много что дальше? Он не знает причину.

Я написал про динамику,а не что багов много. Сколько багов ни есть, важна динамика — частота появления новых, частота реопенов, частота фиксов, частота ошибок эстимейтов.
Собственно динамика однозначно показывает состояние проекта.

>И исполнители будут вещать, что это всё нормально. Так у всех и всегда.

Твой опыт/кругозор обсуждать не будем, идёт ?

>И скоро они всё исправят. Не забывай, по твоей версии заказчик в программировании ничего не понимает.

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

I>>Неучи конечно не справятся, а для 80-90% задач за глаза хватает людей от студента 4го курса до молодого специалиста с опытом 5 лет.
WH>Без опытного надсмотрщика они завалят проект с вероятность 99%.

Зеваю — у меня в получае ходьбы есть около 5 крупных контор, у которых контингент это люди от студентов до 5 лет опыта и представь, не только сущетсвуют, но еще и расширяются.

WH>А с опытным надсмотрщиком им на порядок эффективнее дать ДСЛ.

Опытному разрабу будет скучно, ему нужна техническая сложность.

WH>И как он узнает что:
WH>Исполнитель может это сделать?
WH>И главное что сервер под 100К пользователей на самом деле стоит 100К$?

Тендер. Отзывы. Похожие проекты. Консультации специальных контор. Я могу рассказать много вариантов как это делается.

WH>Он же в программировании ничего не понимает.

Эта проблема вообще в сфере услуг, а не только в программировании. И для неё есть решения.
Что самое интересное — ДСЛ здесь ничего не меняет. Студент научится лепить ДСЛ, впишет себе этот баззворд в резюме и его будут продавать заказчикам.

WH>>>А если бы он знал что вместо его мотыги ему дали лошадь с плугом (относительно мотыги пошёл профит), а могли бы дать трактор, причем в несколько раз дешевле, чем он заплатил за клячу и на год раньше...
I>>И где ты таких тупых заказчиков берешь ?
WH>Я? Это ты их берешь.

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

WH>Ибо те, кто доволен деятельностью студентов, попадают именно в эту категорию.

Ты похоже так и не понял, что у каждого проекта есть определенная техническая сложность.

I>>Эта "видимость" почему то воспроизводится слишком регулярно.
WH>1)Заказчик не знает, что его кинули.

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

WH>2)Конкретным людям со стороны заказчика не выгодно поднимать шум.

Заговор да по всему миру !!! Ты вообще в курсе, что студентов и молодых специалистов в раз больше чем опытных разрабов ?

Здравствуйте, WolfHound, Вы писали:

I>>Гугл про неё знает, только совпадающие аббревиатуры к программухе не относятся и на порядки более популярны чем любой запрос по программухе.
WH>Её даже в википедии нет. Короче неуловимый Джо как он есть.

Буду знать, какой источник является для тебя авторитетным

I>>ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.
WH>И в чем ты видишь проблемы?

Разумеется в сложности реализации взаимодействия.

WH>Или ты хочешь сказать, что виртуальные коллекции, которые физически загружают, только небольшое окно уже отменили?

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

WH>>>http://user1663.netfx45lab.discountasp.net/
WH>>>Сколько ты будешь ждать пока микрософт изволит повторить?
I>>Извини, я в вебе мало чего понимаю.
WH>Не виляй. Это чистый MVVM.
WH>Из ВЕБ там только примитивный HTML который не знать невозможно.

Что мне должно быть понятно из примера для двух контролов ?

Я не знаю сколько кода нужно другими инструментами.

I>>OMG !!! Сравни "Если такой инструмент появится" c "такой инструмент появился и это yield return в C#"
WH>Он не появился. yield return данную задачу не решает.

Правильно, не появился. Потому я и пишу "если ... появится" — это, на всякий, будущее время, а не прошедшее.

I>>Пока нет вакансий по Nemerle им смело можно пренебречь. Я не люблю экспериментировать на себе.
WH>Есть. Я сейчас пишу на немерле за зарплату выше рынка.

Три вакансии или сколько там, в джетбрейнс, не в счет. Эдак окажется что специалистов на нашем внутреннем дсл будет на порядок больше

I>>Разумеется, потому что нет поддержки в языке.
WH>А несколькими строчками ты утверждал, что это yield return.

"если ... появится" — это, как ты понимаешь, написано после того, как yield return уже появился. Подумай хорошо, чего ты хочешь сказать.

I>>Нужна возможность описать конкретный воркфлоу в одной единсвенной функции, даже если кнопочки ты нажимаешь где попало. Как это будет выполняться, синхронно, асинхронно — дело десятое. Главное что энергичный код будет сделан ленивым.
WH>Зачем в ГУИ "воркфлоу"?

Например для того, что бы качественно обрабатывать юзеринпут. Но вообще я не говорил что это нужно исключительно для ГУИ.

I>>Ты похоже вообще не читаешь.
WH>Я тебе показал, что такое реактивное программирование.
WH>То, что ты показываешь, к нему не относится.

Примеры для случае в два контрола меня не интересуют.

Здравствуйте, Ikemefula, Вы писали:

I>>>Правильно. Но он не писался в духе "для 5 случаев".
WH>>И поэтому он не подходит ни для одного.
I>Вообще говоря линк подходит много где и всемогутором не является — ни разу.
Ага, конечно.
И по тому, что он так хорошо подходит народ пишет так

(from ...
select ...).Take(...)

Что же линк так сплоховал то?
Где слово take? А как насчет insert и delete? И главное где мой flatten?

WH>>Так что ты будешь делать с лишними словами? И что более важно с теми, которых не хватает?
I>Этот вопрос я задавал тебе раз 5 или 6.
Ты не мог задать этот вопрос. По тому, что ты даже не понимаешь где проблема.

I>Если у тебя нет качественных абстракций, все твои языки будут мусором и тебе придется нанять человека вроде Эрика Мейера.
Он сделал линк. Проблема линка в том, что идеологически там может быть весьма произвольный набор слов. Но реализация фиксирована.
И поэтому получается, что там либо есть лишние слов, либо не хватает слов и приходится лепить костыли типа того что выше. А обычно и то и другое.
Так что никто не может сделать фиксированный язык хорошо работающий всегда.
Следовательно, для любого фиксированного языка можно найти бесконечное множество задач, для которых он будет мусором.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

WH>>>>>>>>Максимум, что было с вашей стороны, это AVK вывалил кусок кода, по которому ничего не ясно. На все вопросы были получены ответы из серии "это не важно".
I>>>>>>>АВК вдобавок объяснял десять или более постов.
WH>>>>>>Все его посты состояли из фразы "это не важно" чуть менее чем полностью.
I>>>>>Это мягко говоря враньё.
WH>>>>Открой ветку да посмотри. Ничего по существу задачи он не сказал.
I>>>>Но ты вещаешь как будто у него и работаешь
WH>>Не улавливаю логику. Из чего получается, что я работаю у AVK? Если бы я у него работал, я бы понимал его пример.
I>Перепутать авк и хайоктан — доказательство что ты вообще не помнишь контекст

Это кто тут контекст не помнит?

I>Симптомы которые он перечисляет мне очень хорошо знакомы. Полной картины пока нет, но оснований для сомнений вполне достаточно.
Они тебе не могут быть известны, поскольку ты не понимаешь предмет.

I>Вроде как в прошлый раз ты задачу правильно понял при чем предложил именно то решение от котог мы отказались. Не боись — я майнтейнил этот код достаточно долго что бы разобраться что к чему и какие проблемы дает тот подход который ты предлагаешь.
Но ты ничего не сказал. Всё что ты сказал сводится к реляционной алгебре.
И решается с пол пинка.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>>>Гугл про неё знает, только совпадающие аббревиатуры к программухе не относятся и на порядки более популярны чем любой запрос по программухе.
WH>>Её даже в википедии нет. Короче неуловимый Джо как он есть.
I>Буду знать, какой источник является для тебя авторитетным

Не является. Но если аббревиатура не попала даже туда, то значит, она волнует людей меньше чем немерле.

I>>>ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.
WH>>И в чем ты видишь проблемы?
I>Разумеется в сложности реализации взаимодействия.
Бла-бла-бла. Конкретики как обычно не будет?

WH>>Или ты хочешь сказать, что виртуальные коллекции, которые физически загружают, только небольшое окно уже отменили?
I>Я хучу сказать, что вариантов UI намного больше чем "только небольшое окно"

БРЕД! Просто по тому, что на экране может поместиться только очень не большое количество данных.

I>Что мне должно быть понятно из примера для двух контролов ?

Я не знаю сколько кода нужно другими инструментами.
Ты тут вещаешь про UI а сам не знаешь как выглядит код для пары контролов на обычных технологиях?
Забавно.

I>"если ... появится" — это, как ты понимаешь, написано после того, как yield return уже появился. Подумай хорошо, чего ты хочешь сказать.
В очередной раз восстанавливаем контекст.

WH>>>>>И как это всё решает проблемы с асинхронным и реактивным программированием мне тоже совершенно не ясно.
I>>>>Я в курсе что тебе не ясно, не надо повторять.
WH>>>Ты делаешь заявления вселенского масштаба.
WH>>>Нужно выяснить, что за ними стоит.
WH>>>Выяснил. За ними стоит глупость такого же масштаба. Честно говоря, не удивлен.
I>>Думаю раз ты видишь эту глупость, то она на твоей стороне монитора, скорее всего в виде прослойки между креслом и монитором.
WH>Так ты код покажи. А то только болтаешь языком.
код по ссылке
Автор: Ikemefula
Дата: 31.08.12
.

Так зачем ты показал на yield return в качестве примера решения проблемы?

I>>>Нужна возможность описать конкретный воркфлоу в одной единсвенной функции, даже если кнопочки ты нажимаешь где попало. Как это будет выполняться, синхронно, асинхронно — дело десятое. Главное что энергичный код будет сделан ленивым.
WH>>Зачем в ГУИ "воркфлоу"?
I>Например для того, что бы качественно обрабатывать юзеринпут. Но вообще я не говорил что это нужно исключительно для ГУИ.
Опять бла-бла-бла.

WH>>Я тебе показал, что такое реактивное программирование.
WH>>То, что ты показываешь, к нему не относится.
I>Примеры для случае в два контрола меня не интересуют.
Ты не можешь показать всю круть своего подхода даже на двух контролах.

Перепиши пример Introduction из этой демки. http://user1663.netfx45lab.discountasp.net/
Посмотрим. Получится ли у тебя короче.
Можешь даже на воображаемом языке, в котором есть все нужные тебе плюшки писать.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>И по тому, что он так хорошо подходит народ пишет так
WH>

WH>(from ...
WH>select ...).Take(...)
WH>

WH>Что же линк так сплоховал то?
WH>Где слово take? А как насчет insert и delete? И главное где мой flatten?

Query Comprehension вдруг стал Linq ? Вот так новость

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

WH>>>Так что ты будешь делать с лишними словами? И что более важно с теми, которых не хватает?
I>>Этот вопрос я задавал тебе раз 5 или 6.
WH>Ты не мог задать этот вопрос. По тому, что ты даже не понимаешь где проблема.

С твоей верой спорить не будем.

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

И давно Query Comprehension вдруг стал Linq ?

WH>И поэтому получается, что там либо есть лишние слов, либо не хватает слов и приходится лепить костыли типа того что выше. А обычно и то и другое.

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

Здравствуйте, WolfHound, Вы писали:

I>>>>ГУИ они разные. Там где контента много, а получить уведомления об изменении модели сложно, ViewModel не годится. Он годится для случаев, когда контента мало и изменения хорошо локализованы и легкодоступны.
WH>>>И в чем ты видишь проблемы?
I>>Разумеется в сложности реализации взаимодействия.
WH>Бла-бла-бла. Конкретики как обычно не будет?

ViewModel годится для случаев, где сценарии пользователя достаточно примитивны а требования меняются не часто, соответсвенно контролы простые, их мало. Пример — формочка логина, регистрации и тд.

WH>>>Или ты хочешь сказать, что виртуальные коллекции, которые физически загружают, только небольшое окно уже отменили?
I>>Я хучу сказать, что вариантов UI намного больше чем "только небольшое окно"
WH>

БРЕД! Просто по тому, что на экране может поместиться только очень не большое количество данных.

Это заблуждение. Пример — гуглмап.

I>>Что мне должно быть понятно из примера для двух контролов ?

Я не знаю сколько кода нужно другими инструментами.
WH>Ты тут вещаешь про UI а сам не знаешь как выглядит код для пары контролов на обычных технологиях?
WH>Забавно.

Забавно, что ты путаешь контекст. Как в веб разные инструменты описывают UI не имею понятия. В десктопе это делается почти полностью визуально. По крайней мере лазить в код дизайнера приходится от силы раз в пару месяцев.

I>>"если ... появится" — это, как ты понимаешь, написано после того, как yield return уже появился. Подумай хорошо, чего ты хочешь сказать.
...
WH>Так зачем ты показал на yield return в качестве примера решения проблемы?

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

WH>>>Я тебе показал, что такое реактивное программирование.
WH>>>То, что ты показываешь, к нему не относится.
I>>Примеры для случае в два контрола меня не интересуют.
WH>Ты не можешь показать всю круть своего подхода даже на двух контролах.

Я показал это даже без контролов, на примере Power Library. Конкретно в случае UI это полезно для обработки сложных сценариев в юзеринпуте, например игры, редакторы и тд и тд.

WH>Перепиши пример Introduction из этой демки. http://user1663.netfx45lab.discountasp.net/
WH>Посмотрим. Получится ли у тебя короче.
WH>Можешь даже на воображаемом языке, в котором есть все нужные тебе плюшки писать.

Я честно не сильно понимаю этот пример.

Здравствуйте, WolfHound, Вы писали:

I>>Перепутать авк и хайоктан — доказательство что ты вообще не помнишь контекст

WH>Это кто тут контекст не помнит?

Тот, кто с твоего аккаунта попутал хайоктан с авк. Ищи сам,я к твоему аккаунту не имею доступа.

I>>Симптомы которые он перечисляет мне очень хорошо знакомы. Полной картины пока нет, но оснований для сомнений вполне достаточно.
WH>Они тебе не могут быть известны, поскольку ты не понимаешь предмет.

Думаешь что бы чувствовать боль надо быть врачом ? Да, сильно

I>>Вроде как в прошлый раз ты задачу правильно понял при чем предложил именно то решение от котог мы отказались. Не боись — я майнтейнил этот код достаточно долго что бы разобраться что к чему и какие проблемы дает тот подход который ты предлагаешь.
WH>Но ты ничего не сказал. Всё что ты сказал сводится к реляционной алгебре.
WH>И решается с пол пинка.

Это вычислительная модель. А вот майнтейнить код в таком виде, как ты предложил очень тяжело и это провереный факт. Нужны качественные абстракции и тогда язык сам собой становится компактным.
На пример linq — куча народу пробует прикрутить к нему insert и delete, но пока что даже до внятного языка дело не дошло, получаются монстры для частных случаев. Как только будет найдена хорошая абстрация — это перекочует в язык.
До той поры городить языки как ты предлагаешь смысла нет,более того, это усложняет майнтенанс.

Здравствуйте, Ikemefula, Вы писали:

I>ViewModel годится для случаев, где сценарии пользователя достаточно примитивны а требования меняются не часто, соответсвенно контролы простые, их мало. Пример — формочка логина, регистрации и тд.
Бла-бла-бла. Обоснование будет?

WH>>>>Или ты хочешь сказать, что виртуальные коллекции, которые физически загружают, только небольшое окно уже отменили?
I>>>Я хучу сказать, что вариантов UI намного больше чем "только небольшое окно"
WH>>

БРЕД! Просто по тому, что на экране может поместиться только очень не большое количество данных.
I>Это заблуждение. Пример — гуглмап.
Ты сам-то понимаешь, про что говоришь?
Гугломап это самый яркий пример в мою пользу.
Ибо в каждый конкретный момент тебе показывают очень маленький кусочек огромный карты.
Это и есть "небольшое окно".

I>Забавно, что ты путаешь контекст. Как в веб разные инструменты описывают UI не имею понятия. В десктопе это делается почти полностью визуально. По крайней мере лазить в код дизайнера приходится от силы раз в пару месяцев.
Ты бы сразу сказал, что делаешь только примитивный ГУИ.
Я бы время не тратил.
Ибо если нужен шаг в сторону, то визуальный редактор идет лесом.

I>Для того, что бы показать, в каком направлении хочется получить инструмент. Пока нужно обращать внимание на контроль ресурсов, императивная парадигма будет основной в мейнстриме. Соответсвенно все что нужно вложить в студента — это знания императивного программирования. Дальше он сможет решить любую задачу.
Вот так стразу совсем любую? Просто нет слов.

I>Я показал это даже без контролов, на примере Power Library. Конкретно в случае UI это полезно для обработки сложных сценариев в юзеринпуте, например игры, редакторы и тд и тд.
Бла-бла-бла.
Код для данных двух едитов в студию.
Или можно уже слив засчитывать?

WH>>Перепиши пример Introduction из этой демки. http://user1663.netfx45lab.discountasp.net/
I>Я честно не сильно понимаю этот пример.
Что можно не понять в данном примере?
Тут есть еще кто-то кто не понял, что делает это пример?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Ikemefula, Вы писали:

I>>>Перепутать авк и хайоктан — доказательство что ты вообще не помнишь контекст

WH>>Это кто тут контекст не помнит?
I>Тот, кто с твоего аккаунта попутал хайоктан с авк. Ищи сам,я к твоему аккаунту не имею доступа.
Я восстановил разговор.
Но ты не смог его даже его перечитать.
Наверное, пора перестать с тобой разговаривать.
Ибо даже не в состоянии восстановить контекст, когда тебе его полностью пересказали.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

I>>>>Перепутать авк и хайоктан — доказательство что ты вообще не помнишь контекст

WH>>>Это кто тут контекст не помнит?
I>>Тот, кто с твоего аккаунта попутал хайоктан с авк. Ищи сам,я к твоему аккаунту не имею доступа.
WH>Я восстановил разговор.
WH>Но ты не смог его даже его перечитать.
WH>Наверное, пора перестать с тобой разговаривать.
WH>Ибо даже не в состоянии восстановить контекст, когда тебе его полностью пересказали.

Бывает, ну да не важно.

Здравствуйте, WolfHound, Вы писали:

I>>ViewModel годится для случаев, где сценарии пользователя достаточно примитивны а требования меняются не часто, соответсвенно контролы простые, их мало. Пример — формочка логина, регистрации и тд.
WH>Бла-бла-бла. Обоснование будет?

У меня 1 вью и на нем до 100К бизнес-объектов. Как это реализовать в виде VM ? Можешь показать хороший пример ? И это не кнопки, не гриды, и вообще нет стандартных контролов.

I>>Это заблуждение. Пример — гуглмап.
WH>Ты сам-то понимаешь, про что говоришь?
WH>Гугломап это самый яркий пример в мою пользу.
WH>Ибо в каждый конкретный момент тебе показывают очень маленький кусочек огромный карты.
WH>Это и есть "небольшое окно".

"только очень не большое количество данных" — маленький кусочек карты показывает ОЧЕНЬ большое количество данных.
Теперь представь, что каждый объект на карте можно таскать, изменять свойства и тд и тд и тд.

I>>Забавно, что ты путаешь контекст. Как в веб разные инструменты описывают UI не имею понятия. В десктопе это делается почти полностью визуально. По крайней мере лазить в код дизайнера приходится от силы раз в пару месяцев.
WH>Ты бы сразу сказал, что делаешь только примитивный ГУИ.
WH>Я бы время не тратил.
WH>Ибо если нужен шаг в сторону, то визуальный редактор идет лесом.

ViewModel точно так же идёт лесом немногим позже.

I>>Для того, что бы показать, в каком направлении хочется получить инструмент. Пока нужно обращать внимание на контроль ресурсов, императивная парадигма будет основной в мейнстриме. Соответсвенно все что нужно вложить в студента — это знания императивного программирования. Дальше он сможет решить любую задачу.
WH>Вот так стразу совсем любую? Просто нет слов.

Любую из повседневных.

I>>Я показал это даже без контролов, на примере Power Library. Конкретно в случае UI это полезно для обработки сложных сценариев в юзеринпуте, например игры, редакторы и тд и тд.
WH>Бла-бла-бла.
WH>Код для данных двух едитов в студию.
WH>Или можно уже слив засчитывать?

http://rsdn.ru/forum/decl/4874580.1

I>>Я честно не сильно понимаю этот пример.
WH>Что можно не понять в данном примере?
WH>Тут есть еще кто-то кто не понял, что делает это пример?

Тебя смущает, что же можно не понимать в незнакомой области ?

Здравствуйте, Ikemefula, Вы писали:

I>>>Я показал это даже без контролов, на примере Power Library. Конкретно в случае UI это полезно для обработки сложных сценариев в юзеринпуте, например игры, редакторы и тд и тд.
WH>>Бла-бла-бла.
WH>>Код для данных двух едитов в студию.
WH>>Или можно уже слив засчитывать?
I>http://rsdn.ru/forum/decl/4874580.1
Ясно. Кода не будет. Значит, засчитываем слив.

I>Тебя смущает, что же можно не понимать в незнакомой области ?

Ты тут рядом пишешь про сложные УИ которые показывают одновременно 100К объектов и тут же путаешься в двух контролах.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, WolfHound, Вы писали:

WH>>>Бла-бла-бла.
WH>>>Код для данных двух едитов в студию.
WH>>>Или можно уже слив засчитывать?
I>>http://rsdn.ru/forum/decl/4874580.1
WH>Ясно. Кода не будет. Значит, засчитываем слив.

Мне лень.

I>>Тебя смущает, что же можно не понимать в незнакомой области ?

WH>Ты тут рядом пишешь про сложные УИ которые показывают одновременно 100К объектов и тут же путаешься в двух контролах.

А что тут странного, я не клепал формочек уже не помню сколько времени

А в веб вообще ни одной не склепал, более того, даже ни одной странички самостоятельно не оформил.

Здравствуйте, VladD2, Вы писали:

I>>Передергиваешь в очередной раз. С чего ты взял что текстовые заведомо лучше графических ?
VD>Не важно. Важно, что ты таки принял точку зрения, что для решения сложных задач ДСЛ-и подходят куда лучше чем ЯОН-ы.

Попытка подмены тезиса оппонента. Он говорил сугубо о текстовых DSL, которые обязательно требуют тонны идентификаторов для всех "промежуточных" элементов программы. В графических DSL этого требования нет.

I>>В некоторых областях текстовые будут лучше, до тех пор пока не появится качественная графическая информация.
VD>Вот хорошая область — разговоры в форумах. Очень много времени на них уходит. Как жаль, что для этого не придумали качественных графических ДСЛ-е. Приходится по старинке использовать текст.

Графическое представление не исключает текстовых элементов. Т.е. банальный TreeView — это уже графика в полный рост. Выделения, разметка и прочий гипертекст — тоже.

            var co = Generator.New<string>(c =>
                                   {
                                       c.yield("1");
                                       c.yield("2");
                                       c.yield("3");
                                       c.yield("4");
                                       c.yield("5");
                                       c.yield("6");
                                   });

            foreach (var item in co)
            {
                Console.WriteLine(item);
            }

В С++, java и даже православном Цэ возможен точно такой же подход при чем безо всякой поддержки компилятора. Да хоть в ассемблере пиши.

Здравствуйте, Sinclair, Вы писали:

I>>Это можно эмулировать десятком способов, не было только языковой поддержки. Например в winapi есть такая вещь, как файберы — очень интересная штукенция.
S>

Покажите мне, как эмулировать Enumerable.TakeWhile на файберах. Его устройство в терминах yield return мне понятно.

Точно так же, как и без файберов

Надеюсь идея ясна:

            Func<string, bool> predicate = s => s!= null;
            var co = Coroutine.New<string>(c =>
                                           {
                                               string x;
                                               do
                                               {
                                                   x = c.yield(); // это можно врапнуть в итератор, см ниже
                                                   if(predicate(x))
                                                   {
                                                       c.yield(x);
                                                       continue;
                                                   }
                                                   break;
                                               } while (true);
                                           });
            ...
            var co = Coroutine.New<string>(c =>
                                           {
                                               string x;
                                               foreach(var x in с.source)
                                               {
                                                   if(predicate(x))
                                                   {
                                                       c.yield(x);
                                                       continue;
                                                   }
                                                   break;
                                               } while (true);
                                           });

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, samius, Вы писали:

I>>>Это можно эмулировать десятком способов, не было только языковой поддержки.
S>>Можно взглянуть на хотя бы один способ эмуляции yield return без поддержки языка?

T>Наконец то дошли руки ответить
T>

T>            var co = Generator.New<string>(c =>
T>                                   {
T>                                       c.yield("1");
T>                                       c.yield("2");
T>                                       c.yield("3");
T>                                       c.yield("4");
T>                                       c.yield("5");
T>                                       c.yield("6");
T>                                   });

T>            foreach (var item in co)
T>            {
T>                Console.WriteLine(item);
T>            }
T>

T>В С++, java и даже православном Цэ возможен точно такой же подход при чем безо всякой поддержки компилятора. Да хоть в ассемблере пиши.

Я не увидел здесь ничего, напоминающего yield, кроме имени метода yield. Пример изоморфен следующему коду

List<string> co = Generator.NewList<string>(List<string> c =>
{
   c.Add("1");
   c.Add("2");
   ...
});

Здравствуйте, samius, Вы писали:

S>Я не увидел здесь ничего, напоминающего yield, кроме имени метода yield. Пример изоморфен следующему коду

Вроде как нужен был код "эмуляции yield return без поддержки языка"

S>

S>List<string> co = Generator.NewList<string>(List<string> c =>
S>{
S>   c.Add("1");
S>   c.Add("2");
S>   ...
S>});  
S>

Изоморфен, только разница в том, что твой энергичный а мой ленивый:

            var co = Generator.New<string>(c =>
                                           {
                                             int i = 0;
                                             while(true) 
                                                c.yield((i++).ToString());
                                           });

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, samius, Вы писали:

S>>Я не увидел здесь ничего, напоминающего yield, кроме имени метода yield. Пример изоморфен следующему коду

T>Вроде как нужен был код "эмуляции yield return без поддержки языка"
Да-да

T>Изоморфен, только разница в том, что твой энергичный а мой ленивый:
T>

T>            var co = Generator.New<string>(c =>
T>                                           {
T>                                             int i = 0;
T>                                             while(true) 
T>                                                c.yield((i++).ToString());
T>                                           });
T>

мой тоже можно сделать ленивым. Но вопрос не в этом.
co.Any() когда-нибудь вернет управление? Если да, то за счет чего?

Здравствуйте, samius, Вы писали:

T>>Изоморфен, только разница в том, что твой энергичный а мой ленивый:
T>>

T>>            var co = Generator.New<string>(c =>
T>>                                           {
T>>                                             int i = 0;
T>>                                             while(true) 
T>>                                                c.yield((i++).ToString());
T>>                                           });
T>>

S>мой тоже можно сделать ленивым. Но вопрос не в этом.
S>co.Any() когда-нибудь вернет управление? Если да, то за счет чего?

Конечно вернет, а что тут особенного ? При чем вычислится ровно один элемент. А если например ты будешь вызывать вот так Any(x => x == "тарелка борща"); то никогда не вернет.

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, samius, Вы писали:

T>>>

T>>>            var co = Generator.New<string>(c =>
T>>>                                           {
T>>>                                             int i = 0;
T>>>                                             while(true) 
T>>>                                                c.yield((i++).ToString());
T>>>                                           });
T>>>

S>>co.Any() когда-нибудь вернет управление? Если да, то за счет чего?

T>Конечно вернет, а что тут особенного ? При чем вычислится ровно один элемент. А если например ты будешь вызывать вот так Any(x => x == "тарелка борща"); то никогда не вернет.

За счет чего while(true) остановится на одном элементе?

Здравствуйте, samius, Вы писали:

T>>Конечно вернет, а что тут особенного ? При чем вычислится ровно один элемент. А если например ты будешь вызывать вот так Any(x => x == "тарелка борща"); то никогда не вернет.

S>За счет чего while(true) остановится на одном элементе?

Очевидно, за счет средств ОС — потоки, файберы. Никакого обмана.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Tanker, Вы писали:

T>>Здравствуйте, samius, Вы писали:

T>>>>

T>>>>            var co = Generator.New<string>(c =>
T>>>>                                           {
T>>>>                                             int i = 0;
T>>>>                                             while(true) 
T>>>>                                                c.yield((i++).ToString());
T>>>>                                           });
T>>>>

S>>>co.Any() когда-нибудь вернет управление? Если да, то за счет чего?

T>>Конечно вернет, а что тут особенного ? При чем вычислится ровно один элемент. А если например ты будешь вызывать вот так Any(x => x == "тарелка борща"); то никогда не вернет.

S>За счет чего while(true) остановится на одном элементе?

как там товарищ на шарпе/java это сделает — не знаю, но например на дельфи такое делается махинациями со стеком http://habrahabr.ru/post/157777/ . Естественно на плюсах такое повторить без проблем можно.

Здравствуйте, Jack128, Вы писали:

J>как там товарищ на шарпе/java это сделает — не знаю, но например на дельфи такое делается махинациями со стеком http://habrahabr.ru/post/157777/ . Естественно на плюсах такое повторить без проблем можно.

Можно и штаны через голову одеть. Вот генераторы образца 2003 года на файберах http://msdn.microsoft.com/en-us/magazine/cc164086.aspx
Но по моему это глупусть, на потоках намного проще а издержки те же самые.

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, samius, Вы писали:

T>>>Конечно вернет, а что тут особенного ? При чем вычислится ровно один элемент. А если например ты будешь вызывать вот так Any(x => x == "тарелка борща"); то никогда не вернет.

S>>За счет чего while(true) остановится на одном элементе?

T>Очевидно, за счет средств ОС — потоки, файберы. Никакого обмана.
К сожалению, не вижу никакого повода для того что бы средства ОС вмешались в цикл while(true) и на потоках и файберах обеспечили бы разрывность его выполнения. Этот цикл в коде на C# не отличается от многих других, которые не нуждаются в файберах.

Здравствуйте, samius, Вы писали:

T>>Очевидно, за счет средств ОС — потоки, файберы. Никакого обмана.
S>К сожалению, не вижу никакого повода для того что бы средства ОС вмешались в цикл while(true) и на потоках и файберах обеспечили бы разрывность его выполнения. Этот цикл в коде на C# не отличается от многих других, которые не нуждаются в файберах.

Если ты забыл, то разговор был про "хотя бы один способ эмуляции yield return без поддержки языка".
А вот поводов использовать потоки и файберы хотя бы для генераторов выше крыши даже в С#, хочешь, создай новый тред,а я покажу примеры, правда может не сейчас а как водится через пару месяцев.

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, samius, Вы писали:

T>>>Очевидно, за счет средств ОС — потоки, файберы. Никакого обмана.
S>>К сожалению, не вижу никакого повода для того что бы средства ОС вмешались в цикл while(true) и на потоках и файберах обеспечили бы разрывность его выполнения. Этот цикл в коде на C# не отличается от многих других, которые не нуждаются в файберах.

T>Если ты забыл, то разговор был про "хотя бы один способ эмуляции yield return без поддержки языка".
Я пока ни одного не увидел. Начал читать статью по твоей ссылке про корутины на MC++.
T>А вот поводов использовать потоки и файберы хотя бы для генераторов выше крыши даже в С#, хочешь, создай новый тред,а я покажу примеры, правда может не сейчас а как водится через пару месяцев.
Я же не утверждал что нет поводов использовать потоки и файберы. Я про то, что на мой взгляд цикл из твоего примера ничем не отличается от любых других циклов без yield, await и т.п. Мне непонятно, почему он будет выполняться частями.

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, Sinclair, Вы писали:

I>>>Это можно эмулировать десятком способов, не было только языковой поддержки. Например в winapi есть такая вещь, как файберы — очень интересная штукенция.
S>>

Покажите мне, как эмулировать Enumerable.TakeWhile на файберах. Его устройство в терминах yield return мне понятно.

T>Точно так же, как и без файберов

Если "точно так же", то в чём смысл использовать файберы?

T> Надеюсь идея ясна:
Нет. Без описания типа вашего c, или хоты бы без кода функций yield() идея совершенно неясна.
Ну и для понятности стоило бы всё-таки привести код Enumerable.TakeWhile, а не пару малопонятных корутин.

Здравствуйте, samius, Вы писали:

T>>Если ты забыл, то разговор был про "хотя бы один способ эмуляции yield return без поддержки языка".
S>Я пока ни одного не увидел. Начал читать статью по твоей ссылке про корутины на MC++.

T>>А вот поводов использовать потоки и файберы хотя бы для генераторов выше крыши даже в С#, хочешь, создай новый тред,а я покажу примеры, правда может не сейчас а как водится через пару месяцев.
S>Я же не утверждал что нет поводов использовать потоки и файберы. Я про то, что на мой взгляд цикл из твоего примера ничем не отличается от любых других циклов без yield, await и т.п. Мне непонятно, почему он будет выполняться частями.

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

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, samius, Вы писали:

S>>Я же не утверждал что нет поводов использовать потоки и файберы. Я про то, что на мой взгляд цикл из твоего примера ничем не отличается от любых других циклов без yield, await и т.п. Мне непонятно, почему он будет выполняться частями.

T>Ты напиши по русски, а то я не понимаю какой ещ цикл ты хочешь увидеть. Вроде бесконечный цикл и any я тебе показал

Вроде как уже написал. И по-русски.

Здравствуйте, Sinclair, Вы писали:

T>>Точно так же, как и без файберов

S>Если "точно так же", то в чём смысл использовать файберы?

Смысл в том, что короутины получаеются взрослые, со всеми прибамбасами — рекурсией, вызовом других короутин и тд и тд. В C# скажем нет возможности сделать var x = yield; кроме как разводить грязь навроде

var request = new Request<string>();
...
yield return request; 
var x = request.Value;

T>> Надеюсь идея ясна:
S>Нет. Без описания типа вашего c, или хоты бы без кода функций yield() идея совершенно неясна.

        public void yield(R value)
        {
            _next.Send(value); // отдать по цепочке
        }

        public R yield()
        {
            return _input.Get(); // блокирующий ресурс, будит вызывающий код, для примера см BlockingCollection
        }

c это просто враппер вокруг короутины для доступа к методам yield

S>Ну и для понятности стоило бы всё-таки привести код Enumerable.TakeWhile, а не пару малопонятных корутин.

Мне комбинаторs не нужены, лень тестировать и отлаживать, вот, накидал приблизительный код, адаптировал из имеющихся комбинаторов и тестов (where + select). Вобще комбинаторы здесь баловство, все хочется выпилить полноценный Linq2Co, но руки не дойдут

        public static Co<T> TakeWhile<T>(this Co<T> pipe, Func<T, bool> predicate)
        {
            return pipe.Then(c => 
            {
                while (true)
                {
                    var x = c.yield(); // read from input
        
                    if (predicate(option.Value))
                    {
                        c.yield(option.Value); // write to output
                        continue;
                    }
                    break;
                }
            });
        }

...
       [TestMethod]
        public void LinqSimpleTest()
        {
            var source = Co.New<string>();
            var result = new StringBuilder();
            var x = (from s in source where isNumber(s) select s).TakeWhile(x => x != "6").Then(n => saveTo(result));

            f.Send("1");
            f.Send("2");
            f.Send("text");
            f.Send("4");
            f.Send("5");
            f.Send("6");
            f.Close();

            Assert.AreEqual("1245", result.ToString());
        }

Здравствуйте, samius, Вы писали:

S>>>Я же не утверждал что нет поводов использовать потоки и файберы. Я про то, что на мой взгляд цикл из твоего примера ничем не отличается от любых других циклов без yield, await и т.п. Мне непонятно, почему он будет выполняться частями.

T>>Ты напиши по русски, а то я не понимаю какой ещ цикл ты хочешь увидеть. Вроде бесконечный цикл и any я тебе показал

S>Вроде как уже написал. И по-русски.

Потому что функция выполняется в отдельном потоке. Каждый вызов yield явно останавливает с помощнь Monitor.Wait а каждый вызов MoveNext итератора пробуждает xthtp Monitor.PulseAll.

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, samius, Вы писали:

T>Потому что функция выполняется в отдельном потоке. Каждый вызов yield явно останавливает с помощнь Monitor.Wait а каждый вызов MoveNext итератора пробуждает xthtp Monitor.PulseAll.
Вот теперь идея понятна, спасибо. Разве что я не соглашусь что это эмуляция yield return.
Так же, наверное можно, на цикле сообщений сэмулировать. Все-таки это эмуляция семантики, но не конкретного решения с машиной состояний и замыканием.

Здравствуйте, samius, Вы писали:

T>>Потому что функция выполняется в отдельном потоке. Каждый вызов yield явно останавливает с помощнь Monitor.Wait а каждый вызов MoveNext итератора пробуждает xthtp Monitor.PulseAll.
S>Вот теперь идея понятна, спасибо. Разве что я не соглашусь что это эмуляция yield return.
S>Так же, наверное можно, на цикле сообщений сэмулировать. Все-таки это эмуляция семантики, но не конкретного решения с машиной состояний и замыканием.

Я эмулировал не шарповкий yield, а питоновские короутины. Генератор это баловства ради прямо сегодня написал, что бы разобраться с монитором.

Здравствуйте, Tanker, Вы писали:

T>Здравствуйте, samius, Вы писали:

S>>Так же, наверное можно, на цикле сообщений сэмулировать. Все-таки это эмуляция семантики, но не конкретного решения с машиной состояний и замыканием.

T>Я эмулировал не шарповкий yield, а питоновские короутины. Генератор это баловства ради прямо сегодня написал, что бы разобраться с монитором.

Вот оно что, я об этом узнал лишь сейчас.

Здравствуйте, Tanker, Вы писали:

T>Смысл в том, что короутины получаеются взрослые, со всеми прибамбасами — рекурсией, вызовом других короутин и тд и тд. В C# скажем нет возможности сделать var x = yield; кроме как разводить грязь навроде
T>

T>var request = new Request<string>();
T>...
T>yield return request; 
T>var x = request.Value;
T>

Брр. Во-первых, мы говорили не про корутины, а про Enumerable Pattern.
Во-вторых, в C# скажем есть возможность сделать

var x = await getX;

T>        public void yield(R value)
T>        {
T>            _next.Send(value); // отдать по цепочке
T>        }

T>        public R yield()
T>        {
T>            return _input.Get(); // блокирующий ресурс, будит вызывающий код, для примера см BlockingCollection
T>        }
T>

Кто такие _next и _input? Как устроены Send и Get?
У меня складывается впечатление, что вы пытаетесь переизобрести RxLib, совместив IObservable и IEnumerable в вашем Co.

T>c это просто враппер вокруг короутины для доступа к методам yield
А что завёрнуто внутрь этого враппера?

S>>Ну и для понятности стоило бы всё-таки привести код Enumerable.TakeWhile, а не пару малопонятных корутин.

T>Мне комбинаторs не нужены, лень тестировать и отлаживать, вот, накидал приблизительный код, адаптировал из имеющихся комбинаторов и тестов (where + select). Вобще комбинаторы здесь баловство, все хочется выпилить полноценный Linq2Co, но руки не дойдут

T>

T>        public static Co<T> TakeWhile<T>(this Co<T> pipe, Func<T, bool> predicate)
T>        {
T>            return pipe.Then(c => 
T>            {
T>                while (true)
T>                {
T>                    var x = c.yield(); // read from input
        
T>                    if (predicate(option.Value))
T>                    {
T>                        c.yield(option.Value); // write to output
T>                        continue;
T>                    }
T>                    break;
T>                }
T>            });
T>        }

T>...
T>       [TestMethod]
T>        public void LinqSimpleTest()
T>        {
T>            var source = Co.New<string>();
T>            var result = new StringBuilder();
T>            var x = (from s in source where isNumber(s) select s).TakeWhile(x => x != "6").Then(n => saveTo(result));

T>            f.Send("1");
T>            f.Send("2");
T>            f.Send("text");
T>            f.Send("4");
T>            f.Send("5");
T>            f.Send("6");
T>            f.Close();

T>            Assert.AreEqual("1245", result.ToString());
T>        }
T>

1. Похоже на опечатку. Вы имели в виду var f = (from s in ...), и x.Value?
2. А чего так сложно-то? В оригинале мы имеем

public static IEnumerable<T> TakeWhile<T>(this IEnumerable<T> source, Predicate<T> predicate)
{
  foreach(var x in source)
    if (predicate(x))
      yield return x;
    else 
      break;
    }

3. У вас всё ещё не видно поддержки стандартных енумераторов. Это ограничивает интероперабельность со стандартными коллекциями. Или она таки есть, но я её не вижу?
4. Енумераторное решение помимо Send и Get работает с IDisposable, гарантируя освобождение ресурсов. У вас как с поддержкой исключений? Получит ли корутина аналог Dispose() в тот момент, когда вызывающая её корутина решила "хватит" (как это происходит в настоящем TakeWhile)?
5. Могу ли я скормить один и тот же источник в два разных TakeWhile? Вот так:

[TestMethod]
public void LinqSimpleTest()
{
  var source = new List<string>();
  var result = new StringBuilder();
  var x1 = (from s in source where isNumber(s) select s).TakeWhile(x => x != "6").GetEnumerator();
  var x2 = (from s in source where isNumber(s) select s).TakeWhile(x => x != "2").GetEnumerator();
  source.AddRange(new string[] {"1", "2", "text", "4", "5", "6"});
  foreach(var i1 in x1)
    Console.WriteLn(i1);
  foreach(var i2 in x2)
    Console.WriteLn(i2);

Ввша реализация с _next.Send() меня настораживает.
Также настораживает то, что я не вижу способа в корутине работать с разнотипными значениями. У вас оба yield имеют тип T. Непонятно, как мне сделать

async string FormatUser(Task<string> name, Task<int> age)
{
   return await name + ", " await age + ", лет";
}

T>Но по моему это глупусть, на потоках намного проще а издержки те же самые.
Насчёт издержек есть внутренне чувство ошибочности. AFAIR, файберы а) не отжирают по мегабайту стека на рыло в адресном пространстве процесса и б) значительно дешевле переключают контекст.
Скажем, в серверном приложении заводить целый отдельный поток каждый раз, как кто-то напишет from i in items where i.name.Length > 0 выглядит несколько страшным.

Здравствуйте, Sinclair, Вы писали:

S>Во-вторых, в C# скажем есть возможность сделать
S>

S>var x = await getX;
S>

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

S>Кто такие _next и _input? Как устроены Send и Get?

_next это следующая короутина. _input это вход, просто блокирующий ресурс. Для примера можно взять BlockingCollection<>, будет оно самое, только я написал свой, с целью разобраться с мониторами.

S>У меня складывается впечатление, что вы пытаетесь переизобрести RxLib, совместив IObservable и IEnumerable в вашем Co.

Короутины древнее не только IEnumerable, но всех дотнетов, виндовсов и линуксов вместе взятых. Так что скорее await и yield return выглядят попыткой изобрести короутины.
Скажем на короутинах эвенты и коллекции можно обрабатывать одним и тем же кодом.
Кроме того, RX это реактивный код, а мне нужен императивный.

T>>c это просто враппер вокруг короутины для доступа к методам yield
S>А что завёрнуто внутрь этого враппера?

Изоляция чисто для интелисенса, а то короутина поддерживает IEnumerable например.

T>>Мне комбинаторs не нужены, лень тестировать и отлаживать, вот, накидал приблизительный код, адаптировал из имеющихся комбинаторов и тестов (where + select). Вобще комбинаторы здесь баловство, все хочется выпилить полноценный Linq2Co, но руки не дойдут

S>1. Похоже на опечатку. Вы имели в виду var f = (from s in ...), и x.Value?

Да, опечатка. Я говорил, что это приблизительный код.

S>2. А чего так сложно-то? В оригинале мы имеем

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

S>3. У вас всё ещё не видно поддержки стандартных енумераторов. Это ограничивает интероперабельность со стандартными коллекциями. Или она таки есть, но я её не вижу?

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

S>4. Енумераторное решение помимо Send и Get работает с IDisposable, гарантируя освобождение ресурсов. У вас как с поддержкой исключений? Получит ли корутина аналог Dispose() в тот момент, когда вызывающая её корутина решила "хватит" (как это происходит в настоящем TakeWhile)?

С исключениями посложнее из за отдельного потока. Исключения буду делать по мере необходимости. Пока "я пейшу бес ашыбок".

S>5. Могу ли я скормить один и тот же источник в два разных TakeWhile? Вот так:

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

S>Ввша реализация с _next.Send() меня настораживает.

Это именно то ради чего я начал изучать короутины

S>Также настораживает то, что я не вижу способа в корутине работать с разнотипными значениями. У вас оба yield имеют тип T.

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

Здравствуйте, Sinclair, Вы писали:

T>>Но по моему это глупусть, на потоках намного проще а издержки те же самые.
S>Насчёт издержек есть внутренне чувство ошибочности. AFAIR, файберы а) не отжирают по мегабайту стека на рыло в адресном пространстве процесса и б) значительно дешевле переключают контекст.
S>Скажем, в серверном приложении заводить целый отдельный поток каждый раз, как кто-то напишет from i in items where i.name.Length > 0 выглядит несколько страшным.

Дотнет в общем случае не поддерживает файберы и требует слишком большого количества телодвижений:

Since fibers running managed code all exist on the same thread, switching between them causes problems for the exception handlers on a "managed" fiber. To avoid this I hook in the CLR host from unmanaged code, and using four undocumented APIs I inform the runtime about the presence of fibers, and notify it just before switching between fibers.

У файбера как минимум свой стек + fiber local storage. А мегабайт стека у потока можно и уменьшить, это как раз и не проблема. Переключение потоков много времени занимает, я как нибудь сделаю замеры, сравню с питоновской динамикой, не думаю что результаты будут провальными.

Либа то не ради Linq2Co начиналась, Linq это побочный эффект. Задача телеграфа, Odd Word problem и подобные очень легко решаются на короутинах. Без толковой поддержки в самом рантайме linq просто баловство, т.к. поток будет на каждый источник, комбинатор, транзитный и терминальный узлы. Т.е. одна строчка на linq в N комбинаторов породит 2N потоков, оптимизациями я пока не планирую заниматься, мне сейчас нужен как можно более чистый и читабельный код.

Здравствуйте, Tanker, Вы писали:

T>_next это следующая короутина.
Откуда корутина "знает", кто там следующий?

T>_input это вход, просто блокирующий ресурс. Для примера можно взять BlockingCollection<>, будет оно самое, только я написал свой, с целью разобраться с мониторами.
С мониторами всё не так, как с фиберами. Если чо. Использование потоков для корутин — это жуткий, чудовищный оверкилл.

S>>У меня складывается впечатление, что вы пытаетесь переизобрести RxLib, совместив IObservable и IEnumerable в вашем Co.

T>Короутины древнее не только IEnumerable, но всех дотнетов, виндовсов и линуксов вместе взятых. Так что скорее await и yield return выглядят попыткой изобрести короутины.

И тем не менее.

T>Скажем на короутинах эвенты и коллекции можно обрабатывать одним и тем же кодом.
T>Кроме того, RX это реактивный код, а мне нужен императивный.
Вы что-то путаете. Императивный код — это IEnumerable, и он уже есть. Именно Rx потенциально позволяет обрабатывать евенты и коллекции одним и тем же кодом, т.к. содержит врапперы для превращения одного в другое.

T>Изоляция чисто для интелисенса, а то короутина поддерживает IEnumerable например.

S>>2. А чего так сложно-то? В оригинале мы имеем

T>Потому что это все таки эмуляция короутин, а не сами короутины. Я не в курсе всей математики короутин, потому не могу сказать, реализовал ли я общий случай, взяв за основу питоновские короутины.
Ну вот отсюда и мораль, что "эмуляция" выходит чудовищно дорогостоящей по ресурсам и многословной в синтаксисе.

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

Мне пока нравится идея Rx — в том смысле, что некоторый код удобнее писать в "активном" стиле, а некоторый — в "пассивном". "Пассивный" стиль — это всякие бесконтекстные штуки, типа "когда смениласьСистемнаяЦветоваяСхема -> ПерерисуйВсеОкна". Как только нужен контекст (скажем, детект дабл-клика), программирование в таком стиле превращается в адов кошмар. Я хочу иметь простой и понятный код, который описывает, как из потока кликов выделить дабл-клики, и простота и понятность требуют активного стиля. А сами дабл-клики — бесконтекстны, поэтому для их обработки я хочу писать в пассивном стиле.
Потому Rx выглядит сексуально — в нём оба стиля присутствуют, с возможностью явного переключения.
Побочный эффект — возможность писать "как бы активный" код, который на самом деле реактивный.
Единственное преимущество такого кода перед традиционным — низкое потребление ресурсов. Потому что если я хочу решить задачу "отпарсить HTTP-запрос по мере его прихода в сокет", то проще всего это сделать через blocking input.
Но это требует целого отдельного потока, который жрёт стек, но большую часть времени спит и затрудняет шедулинг.
IOCP гораздо эффективнее, но он требует пассивного стиля написания, что усложняет работу.
Хочу сразу всё — писать код парсинга в "активном стиле", но автоматически преобразовывать его в "реактивный" без отжирания ресурсов ОС.
Хочу иметь возможность так выворачивать не только работу с дискретными множествами (IEnumerable<T>), но и с потоками.
Потому что я хочу взять парсер XML, который имеет наглость активно читать из переданного ему StreamReader, в лучшем случае блокируя поток в ожидании инпута, и подсунуть к нему AntiStream, в который я буду пихать байты в удобном мне темпе.

T>С исключениями посложнее из за отдельного потока. Исключения буду делать по мере необходимости. Пока "я пейшу бес ашыбок".
Пока что я вижу сложности не в потоках, а в том, что у вас нет никакой семантики для Dispose.

T>Конечно. Но вообще говоря linq это не то, ради чего нужны короутины. Меня прежде всего интересует возможность делать энергичный императивный код ленивым.
Непонятно, как это будет работать с учётом единственности _next.

T>Да, библиотечка далека от завершения. Я на ней в основном проверяю кое какие идеи, это не продакшн код. Правда публиковать его не буду, хочу все таки опробовать в продакшне.

удачи. Да, не трогайте фиберы — вам не удастся их завести без манипуляций с CLR Host.

Здравствуйте, Tanker, Вы писали:
T>Либа то не ради Linq2Co начиналась, Linq это побочный эффект. Задача телеграфа, Odd Word problem и подобные очень легко решаются на короутинах.
А можно привести сами задачи? А то мне кажется, что на Rx или Linq или async/await они решаются ещё легче.

T>Без толковой поддержки в самом рантайме linq просто баловство, т.к. поток будет на каждый источник, комбинатор, транзитный и терминальный узлы. Т.е. одна строчка на linq в N комбинаторов породит 2N потоков, оптимизациями я пока не планирую заниматься, мне сейчас нужен как можно более чистый и читабельный код.
Именно поэтому я и считаю решение на потоках с мониторами не более чем курьёзом.

Здравствуйте, Sinclair, Вы писали:

T>>Либа то не ради Linq2Co начиналась, Linq это побочный эффект. Задача телеграфа, Odd Word problem и подобные очень легко решаются на короутинах.
S>А можно привести сами задачи? А то мне кажется, что на Rx или Linq или async/await они решаются ещё легче.

http://c2.com/cgi/wiki?OddWordProblem, там есть ссылка на решения чуть не на всех языках
http://code.google.com/p/coroutines/wiki/UserGuide — там есть описание задачи и само решение

Здравствуйте, Sinclair, Вы писали:

T>>_next это следующая короутина.
S>Откуда корутина "знает", кто там следующий?

Конвейер жостко связаный и мутабельный, по крайней мере в текущей реализации. Как сделать иммутабельный я пока что не пробовал.

S>Вы что-то путаете. Императивный код — это IEnumerable, и он уже есть. Именно Rx потенциально позволяет обрабатывать евенты и коллекции одним и тем же кодом, т.к. содержит врапперы для превращения одного в другое.

IEnumerable это pull. RX это push. Мне же надо сразу и то и другое.

S>Потому Rx выглядит сексуально — в нём оба стиля присутствуют, с возможностью явного переключения.

Вот это я не понял, поясни пожалуйста. Как детектить дабл клики я знаю. А что такое активный стиль в RX ?

S>Единственное преимущество такого кода перед традиционным — низкое потребление ресурсов. Потому что если я хочу решить задачу "отпарсить HTTP-запрос по мере его прихода в сокет", то проще всего это сделать через blocking input.
S>Но это требует целого отдельного потока, который жрёт стек, но большую часть времени спит и затрудняет шедулинг.

blocking input нормально решается с короутинами. Шедулинг будет такой же как и с await.

S>IOCP гораздо эффективнее, но он требует пассивного стиля написания, что усложняет работу.
S>Хочу сразу всё — писать код парсинга в "активном стиле", но автоматически преобразовывать его в "реактивный" без отжирания ресурсов ОС.

Это и есть короутины

T>>С исключениями посложнее из за отдельного потока. Исключения буду делать по мере необходимости. Пока "я пейшу бес ашыбок".
S>Пока что я вижу сложности не в потоках, а в том, что у вас нет никакой семантики для Dispose.

Диспозить вобщем не проблема, но я это даже не начинал,

T>>Конечно. Но вообще говоря linq это не то, ради чего нужны короутины. Меня прежде всего интересует возможность делать энергичный императивный код ленивым.
S>Непонятно, как это будет работать с учётом единственности _next.

По дефолту _next это короутина Fork. Собтсвенно из за этого и получается 2N потоков. Т.е. цепь может выглядет реально вот так

source->Fork->Where->Fork->TakeUntil->Fork->Select->Fork\
            \                                            ->Join->Fork->terminal
            \>Where->Fork->TakeWhile->Fork->Select->Fork/

А можно даже завести цикл и получится один из вариантов рекурсии.

Здравствуйте, Tanker, Вы писали:
T>Конвейер жостко связаный и мутабельный, по крайней мере в текущей реализации. Как сделать иммутабельный я пока что не пробовал.
Ок, понятно.
Имхо, вам стоит покопать в сторону Task<T>. Очень похожий функционал, плюс будете иметь синтаксическую поддержку в языке.

T>IEnumerable это pull. RX это push. Мне же надо сразу и то и другое.
IObservable и IEnumerable дуальны.
Вызываете IEnumerable.ToObservable() и получаете Push. Вызываете foreach(item in observable) — и получаете Pull. См. http://msdn.microsoft.com/en-us/library/hh211873(v=vs.103).aspx
T>Вот это я не понял, поясни пожалуйста. Как детектить дабл клики я знаю. А что такое активный стиль в RX ?
Ну собственно это и есть активный стиль. Когда я пишу алгоритм над IObservable так, как будто это pull, пользуясь либо IEnumerable, либо Query Comprehension.

T>blocking input нормально решается с короутинами. Шедулинг будет такой же как и с await.
Ну то есть вы эмулируете await, только без синтаксической поддержки. Смысл неясен. Особенно пугают упоминания monitor.PulseAll и прочие прожорливые вещи.

T>Это и есть короутины

Корутины — это всего лишь один из способов представить требуемое. И не факт, что самый хороший.
T>Диспозить вобщем не проблема, но я это даже не начинал,
Диспозить проблема в присутствии исключений. Почитайте блог Липперта на предмет особенностей обработки исключений в iterator block.

T>А можно даже завести цикл и получится один из вариантов рекурсии.
Интересно.

Здравствуйте, __kot2, Вы писали:

WH>>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.
WH>>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен.
WH>>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
WH>>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
__>есть жутчайшие языки программирования, которые возникли просто по ошибке и которые давно стоит закопать — например, sql. он как чемипалый пяти..
__>не имеет смысла плодить языки, да и не все языки, которые хорошо решают одну задачу сделаны с умом

Вот на SQL не надо наговаривать. Отличный язык запросов для релятиционных БД.

И вообще складывается ощущение, что критика SQL вызвана его не заннием.

Здравствуйте, 11molniev, Вы писали:
1>Вот на SQL не надо наговаривать. Отличный язык запросов для релятиционных БД.
1>И вообще складывается ощущение, что критика SQL вызвана его не заннием.
у меня была (да и есть) возможность сравнить профессиональный sql и C# код, написанный часто даже одним человеком. sql — гавнище в столбик и копипаста, C# — ну ниче так. что говорит скорее об ограничениях языка, чем о том, что его кто-то не знает.

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, 11molniev, Вы писали:
1>>Вот на SQL не надо наговаривать. Отличный язык запросов для релятиционных БД.
1>>И вообще складывается ощущение, что критика SQL вызвана его не заннием.
__>у меня была (да и есть) возможность сравнить профессиональный sql и C# код, написанный часто даже одним человеком. sql — гавнище в столбик и копипаста, C# — ну ниче так. что говорит скорее об ограничениях языка, чем о том, что его кто-то не знает.

Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение?

Здравствуйте, 11molniev, Вы писали:
1>Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение?
под C# я подразумеваю C#

обвчный код где классики между собой взаимодействуют вызывая методы

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, 11molniev, Вы писали:
1>>Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение?
__>под C# я подразумеваю C#

обвчный код где классики между собой взаимодействуют вызывая методы
Пример?

Здравствуйте, 11molniev, Вы писали:
1>Здравствуйте, __kot2, Вы писали:
__>>Здравствуйте, 11molniev, Вы писали:
1>>>Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение?
__>>под C# я подразумеваю C#

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

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, 11molniev, Вы писали:
1>>Здравствуйте, __kot2, Вы писали:
__>>>Здравствуйте, 11molniev, Вы писали:
1>>>>Покажите пример. И под C# Вы подразумеваете LINQ? Или его функциональное расширение?
__>>>под C# я подразумеваю C#

обвчный код где классики между собой взаимодействуют вызывая методы
1>>Пример?
__>я не могу взять показать код из проекта.
ок, понимаю.
__>мой sql код гавно, тем более что sql я не знаю.
не факт, возможно я не сталкивался с вашей ситуации и даю однобокую оценку.
хотя отсутствие опыта использования sql мне кажется более вероятным.
__>если хотите, можете показать любой не примитивный sql код который гавном не считаете
приведите задачу, что за запрос нужен. Будет не совсем коректно если я накатаю сферический запрос в вакууме для сферической базы.

Здравствуйте, Sinclair, Вы писали:

T>>Вот это я не понял, поясни пожалуйста. Как детектить дабл клики я знаю. А что такое активный стиль в RX ?
S>Ну собственно это и есть активный стиль. Когда я пишу алгоритм над IObservable так, как будто это pull, пользуясь либо IEnumerable, либо Query Comprehension.

Я запутался, что значит в таком случае пассивный и реактивный стили ? Мог бы ты для сравнения примером в RX продемонстрировать ?

T>>blocking input нормально решается с короутинами. Шедулинг будет такой же как и с await.
S>Ну то есть вы эмулируете await, только без синтаксической поддержки. Смысл неясен. Особенно пугают упоминания monitor.PulseAll и прочие прожорливые вещи.

int result = await<int>().FromDelay(5000).Then(() => 100); 
или
int result = await<int>().AsyncResult(xxx);

Вызывающий код сам решит, как ему вызывать короутину которая содержит await. Если не надо никаких UI, то все будет работать как будто с синхронным кодом. Если надо таки работать независимо, то короутина будет запускаться ну например через метод async.
monitor.PulseAll +Wait ни разу не тяжелее того шедулинга, который в C# для async + await.
Есть проблемы — если из короутины напрямую дергать например контролы, здесь всегда будет вызов из другого потока.

T>>Это и есть короутины

S>Корутины — это всего лишь один из способов представить требуемое. И не факт, что самый хороший.
T>>Диспозить вобщем не проблема, но я это даже не начинал,
S>Диспозить проблема в присутствии исключений. Почитайте блог Липперта на предмет особенностей обработки исключений в iterator block.

В c# yield, грубо говоря, сам же и вызывает внешний код, потому внешний код может забросить исключение в генератор == короутины в C# просто баловство

У нормальных короутин есть свой контекст. Все можно обработь внутри короутины или при желании перебросить внешнемоу кода. Помех от внешнего кода не будет. Исключения внешнего кода будет обрабатывать внешний код.
Т.е. я могу написать вот так

           var g = new Generator<string>(yield =>
            {
              try
              { 
                 using(var res = Resource())
                 {
                   yield(res.Something()); 

                   throw new Exception(); 
                 }
              }
              catch(Exception ex)
              {
                DoSomething1();
                throw;
              }
              finally()
              {
                DoSomething2();
              }
            });
...
try
{
   foreach(var item in g) // если надо, MoveNext бросит исключение
   {
       throw new Exception() // это исключение никода не попадет в короутину, ибо стеки разные
   }
}
catch(Exception ex)
{

}

T>>А можно даже завести цикл и получится один из вариантов рекурсии.
S>Интересно.

Я хочу получить нечто вроде:

var q := new queue

coroutine produce
    loop
        while q is not full
            create some new items
            add the items to q
        yield to consume

coroutine consume
    loop
        while q is not empty
            remove some items from q
            use the items
        yield to produce

Здравствуйте, Tanker, Вы писали:

T>Я запутался, что значит в таком случае пассивный и реактивный стили ? Мог бы ты для сравнения примером в RX продемонстрировать ?
Пассивный стиль (он же реактивный) — это

public bool ReceiveDataChunk(byte[] data)
{
  ..
}

Активный стиль — это, понятное дело,

var readBytes = source.ReadDataChunk(buffer, count);

Я не очень понимаю, какой пример из Rx тут необходим.

T>

T>int result = await<int>().FromDelay(5000).Then(() => 100); 
T>или
T>int result = await<int>().AsyncResult(xxx); 
T>

T>Вызывающий код сам решит, как ему вызывать короутину которая содержит await. Если не надо никаких UI, то все будет работать как будто с синхронным кодом. Если надо таки работать независимо, то короутина будет запускаться ну например через метод async.
Непонятно. Внутри await() у вас должен быть способ отдать управление. Я вижу ровно два варианта:
1. Вызвать некий _next.GetControl(), увеличив глубину стека. Тот, кто у нас _next, может в свою очередь снова вызвать нас в своём теле метода, и так далее. Всё происходит в одном потоке, но с каждым пинг-понгом между продюсером/консумером нарастает глубина стека.
2. Вызвать некий _monitor.PulseAll, передав управление в другой поток. Стек "замёрзнет", но мы будем тратить по native thread (омг!) на каждую "корутину".
3. Вызвать SwitchToFiber(). Это наиболее приемлемый по ресурсам

T>monitor.PulseAll +Wait ни разу не тяжелее того шедулинга, который в C# для async + await.
С чего бы это вдруг? Monitor.PulseAll подразумевает наличие других потоков. На всякий случай процитирую общеизвестное:

The async and await keywords don't cause additional threads to be created. Async methods don't require multithreading because an async method doesn't run on its own thread

А всё потому, что настоящий async, в отличие от вашего самопального, не углубляется в стек, а наоборот — возвращает управление.

T>Есть проблемы — если из короутины напрямую дергать например контролы, здесь всегда будет вызов из другого потока.
Проблемы у вас не в этом. Проблемы в том, что вы имеете O(N) потоков, а это пипец как дорого. Если бы не было async/await, то такая реализация имела бы смысл в некоторых изолированных сценариях (скажем, в сервере бы её ни в жизни не стали запускать). С учётом наличия изкоробочного async/await, ваша реализация корутин не более полезна, чем ДеСметовская арифметика натуральных чисел на основе лямбд и игрек-комбинатора.

T>В c# yield, грубо говоря, сам же и вызывает внешний код, потому внешний код может забросить исключение в генератор == короутины в C# просто баловство

Ну, не стоит так грубо

Всё же есть разница между "вызывает внешний код" и "возвращает управление внешнему коду".

T>У нормальных короутин есть свой контекст. Все можно обработь внутри короутины или при желании перебросить внешнемоу кода. Помех от внешнего кода не будет. Исключения внешнего кода будет обрабатывать внешний код.
T>Т.е. я могу написать вот так
T>

T>           var g = new Generator<string>(yield =>
T>            {
T>              try
T>              { 
T>                 using(var res = Resource())
T>                 {
T>                   yield(res.Something()); 

T>                   throw new Exception(); 
T>                 }
T>              }
T>              catch(Exception ex)
T>              {
T>                DoSomething1();
T>                throw;
T>              }
T>              finally()
T>              {
T>                DoSomething2();
T>              }
T>            });
T>...
T>try
T>{
T>   foreach(var item in g) // если надо, MoveNext бросит исключение
T>   {
T>       throw new Exception() // это исключение никода не попадет в короутину, ибо стеки разные
T>   }
T>}
T>catch(Exception ex)
T>{

T>}
T>

Осталось выяснить, каким образом вы собрались обработать ваш finally DoSomething2(), если исключение, брошенное в foreach "никогда не попадёт в корутину". Тот же вопрос и про res.Dispose(), который надо бы сделать в cвязи с выходом из using{}.
Я же говорю — читайте Липперта.

T>Я хочу получить нечто вроде:
T>

T>var q := new queue

T>coroutine produce
T>    loop
T>        while q is not full
T>            create some new items
T>            add the items to q
T>        yield to consume

T>coroutine consume
T>    loop
T>        while q is not empty
T>            remove some items from q
T>            use the items
T>        yield to produce
T>

Что-то мне подсказывает, что async/await тут будут как раз в тему.

Здравствуйте, Sinclair, Вы писали:

S>Я не очень понимаю, какой пример из Rx тут необходим.

Я понял, спасибо.

T>>Вызывающий код сам решит, как ему вызывать короутину которая содержит await. Если не надо никаких UI, то все будет работать как будто с синхронным кодом. Если надо таки работать независимо, то короутина будет запускаться ну например через метод async.
S>Непонятно. Внутри await() у вас должен быть способ отдать управление. Я вижу ровно два варианта:
S>1. Вызвать некий _next.GetControl(), увеличив глубину стека. Тот, кто у нас _next, может в свою очередь снова вызвать нас в своём теле метода, и так далее. Всё происходит в одном потоке, но с каждым пинг-понгом между продюсером/консумером нарастает глубина стека.
S>2. Вызвать некий _monitor.PulseAll, передав управление в другой поток. Стек "замёрзнет", но мы будем тратить по native thread (омг!) на каждую "корутину".
S>3. Вызвать SwitchToFiber(). Это наиболее приемлемый по ресурсам

У меня это п.2, файбров ведь не предвидится. Есть возможности для оптимизации, но это пока что фантазии.

S>А всё потому, что настоящий async, в отличие от вашего самопального, не углубляется в стек, а наоборот — возвращает управление.

Хорошо, я понял

T>>Есть проблемы — если из короутины напрямую дергать например контролы, здесь всегда будет вызов из другого потока.
S>Проблемы у вас не в этом. Проблемы в том, что вы имеете O(N) потоков, а это пипец как дорого. Если бы не было async/await, то такая реализация имела бы смысл в некоторых изолированных сценариях (скажем, в сервере бы её ни в жизни не стали запускать). С учётом наличия изкоробочного async/await, ваша реализация корутин не более полезна, чем ДеСметовская арифметика натуральных чисел на основе лямбд и игрек-комбинатора.

S>Осталось выяснить, каким образом вы собрались обработать ваш finally DoSomething2(), если исключение, брошенное в foreach "никогда не попадёт в корутину". Тот же вопрос и про res.Dispose(), который надо бы сделать в cвязи с выходом из using{}.
S>Я же говорю — читайте Липперта.

Уже читаю

А если так:

using(var g = new Generator(yield=>{}))
{
...
}

T>>Я хочу получить нечто вроде:
T>>

T>>var q := new queue

T>>coroutine produce
T>>    loop
T>>        while q is not full
T>>            create some new items
T>>            add the items to q
T>>        yield to consume

T>>coroutine consume
T>>    loop
T>>        while q is not empty
T>>            remove some items from q
T>>            use the items
T>>        yield to produce
T>>

S>Что-то мне подсказывает, что async/await тут будут как раз в тему.

А как это сделать на asynk/await ?

	От:	WolfHound
	Дата:	15.08.12 18:39
	Оценка:	+2 -3

	От:	akasoft
	Дата:	15.08.12 20:16
	Оценка:

	От:	__kot2
	Дата:	15.08.12 21:39
	Оценка:

	От:	Nuseraro
	Дата:	16.08.12 06:50
	Оценка:

	От:	Nuseraro
	Дата:	16.08.12 06:54
	Оценка:	1 (1) +2 -1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	16.08.12 10:20
Оценка:	+1 -1

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	17.08.12 04:07
Оценка:

От:	AlexCab	LinkedIn
Дата:	17.08.12 18:27
Оценка:	+1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	17.08.12 22:22
Оценка:	+2

	От:	Игoрь
	Дата:	18.08.12 15:07
	Оценка:	12 (1) +6

От:	Sinclair	https://github.com/evilguest/
Дата:	20.08.12 05:14
Оценка:

От:	VladD2	www.nemerle.org
Дата:	20.08.12 20:14
Оценка:

От:	Философ	http://vk.com/id10256428
Дата:	27.08.12 05:34
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	30.08.12 11:05
Оценка: