Здравствуйте, __kot2, Вы писали:
__>паттерны это естественные конструкции, которые возникают по мере разработки архитектуры
Не правильно.
Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.
Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен.
Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
Здравствуйте, WolfHound, Вы писали:
WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
Видимо, за смелость платят людям другой профессии.
Здравствуйте, WolfHound, Вы писали: __>>паттерны это естественные конструкции, которые возникают по мере разработки архитектуры WH>Не правильно.
неправильно пишется
WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
основное свойство копипасты в том, что чтобы что-то одно поменять приходится менять код в куче разных мест.
паттерны этим не страдают
WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача. WH>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен. WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет. WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
есть жутчайшие языки программирования, которые возникли просто по ошибке и которые давно стоит закопать — например, sql. он как чемипалый пяти..
не имеет смысла плодить языки, да и не все языки, которые хорошо решают одну задачу сделаны с умом
Здравствуйте, WolfHound, Вы писали: WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области.
По-моему архитектура системы на языке общего назначения подразумевает, что какая-то часть проекта — дефакто внутренний DSL предметной области. Баланс между этой частью и её применением для проекта — один из важных компромиссов, зависящий главным образом от перспектив проекта.
Паттерны помогают нам быстро проектировать и то, и то.
Надо где-нибудь похоливарить на эту тему, но лучше не тут
Здравствуйте, __kot2, Вы писали:
WH>>есть жутчайшие языки программирования, которые возникли просто по ошибке и которые давно стоит закопать — например, sql. он как чемипалый пяти..
На практике вижу, что sql придуман очень талантливо — при желании в нем очень оперативно разбираются и успешно используют любые умные люди, даже очень далекие от программирования.
Наверное у вас есть какие-то доводы, но у меня первая мысль: "Совсем офигели"
Здравствуйте, __kot2, Вы писали:
__>неправильно пишется
Знаешь, почему на РСДН запрещено придираться к орфографии?
Правильно. По тому, что слившим товарищам не остается ничего другого.
__>основное свойство копипасты в том, что чтобы что-то одно поменять приходится менять код в куче разных мест. __>паттерны этим не страдают
Ага, конечно.
Посмотри на два применения одного паттерна и увидишь кучу идентичного кода, который повторяется по очень простым правилам.
Копипаста она и есть копипаста.
Причем такая, что повторяется настолько часто, что по ней даже книги пишут.
__>есть жутчайшие языки программирования, которые возникли просто по ошибке и которые давно стоит закопать —
Я не спорю. C#, Java, C, C++,... давно пора закопать.
__>например, sql. он как чемипалый пяти..
Вот про SQL не нужно. Его конечно можно было сделать лучше. Но с обработкой данных он справляется просто несравнимо лучше чем яезыки одбщего назначения.
На досуги попробуй ручками на С++, жабу или C# реализовать хотя бы пару запросов... так чтобы конкурентность и ACID были в полный рост.
Уверяю тебя, не осилишь.
__>не имеет смысла плодить языки, да и не все языки, которые хорошо решают одну задачу сделаны с умом
Языки, сделанные под конкретную задачу, даже если они сделаны не оптимально, всё равно на порядок другой порвут языки общего назначения.
Пример выше.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Nuseraro, Вы писали:
N>По-моему архитектура системы на языке общего назначения подразумевает, что какая-то часть проекта — дефакто внутренний DSL предметной области. Баланс между этой частью и её применением для проекта — один из важных компромиссов, зависящий главным образом от перспектив проекта.
Архитектура проекта существует лишь с одной целью.
Чтобы код на языке общего назначения не скатился совсем в говно.
А его туда очень сильно тянет. Просто по тому, что язык общего назначения не имеет никакого понятия о том, что есть в предметной области.
N>Паттерны помогают нам быстро проектировать и то, и то.
Не помогают. Паттерны механизм исключительно коммуникационный.
N>Надо где-нибудь похоливарить на эту тему, но лучше не тут
Тут в самый раз. В крайнем случае, всегда можно отцепить ветку.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
N>>По-моему архитектура системы на языке общего назначения подразумевает, что какая-то часть проекта — дефакто внутренний DSL предметной области. Баланс между этой частью и её применением для проекта — один из важных компромиссов, зависящий главным образом от перспектив проекта. WH>Чтобы код на языке общего назначения не скатился совсем в говно. WH>А его туда очень сильно тянет. Просто по тому, что язык общего назначения не имеет никакого понятия о том, что есть в предметной области.
Вот я и пишу, что какая-то часть кода общего назначения должна начинать дружить с предметной областью, особенно с действительно значимыми её кусками.
Т.е. если для небольшого приложения подойдет
if (a != b)
{
throw new Exception(string.Format("Хотели {0}, а получилось {1}",a,b));
}
То для приложения или библиотеки выплывают специальные симпатичные вещи, типа
Assert.AreEqual(a,b, "Хотели {0}, а получилось {1}",a,b);
И это по сути тот же DSL.
N>>Паттерны помогают нам быстро проектировать и то, и то. WH>Не помогают. Паттерны механизм исключительно коммуникационный.
Не совсем понял, что вы имеете в виду.
Мне кажется, что идею паттернов очень губит "та самая книжка", в которой описаны "те самые паттерны", из которых треть устарела, а треть ушла на уровень языка во многие языки. В принципе я согласен, что паттерны — это по сути "копипасты высокого порядка", являющиеся решением для конкретных задач.
Что я имею в виду под помощью в проектировании. Сталкиваясь с новой задачей мы формулируем её в общем виде и задаёмcя вопросом: как решается задача вообще? Как принято её решать? И да, если уже есть подходящие нам решения, мы "копируем" их в свой проект, подгоняя под себя. Так мы не тратим время на велосипед.
Здравствуйте, Nuseraro, Вы писали:
N>Вот я и пишу, что какая-то часть кода общего назначения должна начинать дружить с предметной областью, особенно с действительно значимыми её кусками.
Это утопия. Такого не бывает.
Разве что мы говорим про язык с развитыми макросами. Но тут по сути мы получаем изменение языка.
N>И это по сути тот же DSL.
ДСЛ это когда
assert a == b;
а все остальное сделается само.
Но в данном случае мы имеем крайне примитивный случай.
Попробуй проделать тоже самоё с чем то, что не так близко к ЯОН и у тебя начнутся огромные проблемы.
В плоть до того что тебе придется создавать полноценный ДСЛ. Но не в виде красивого текста, а в виде нагромождения руками собираемого АСТ.
И потом его интерпретировать, получив дикие тормоза.
WH>>Не помогают. Паттерны механизм исключительно коммуникационный. N>Не совсем понял, что вы имеете в виду.
То и имею что паттерны годятся только для того чтобы сказать другому человеку что ты использовал визитер или там декоратор. И он тебя поймет.
N>Мне кажется, что идею паттернов очень губит "та самая книжка", в которой описаны "те самые паттерны", из которых треть устарела, а треть ушла на уровень языка во многие языки. В принципе я согласен, что паттерны — это по сути "копипасты высокого порядка", являющиеся решением для конкретных задач.
Идею паттернов губит то, что это копипаста.
Причем такая копипаста, что убрать ее можно только изменив язык.
N>Что я имею в виду под помощью в проектировании. Сталкиваясь с новой задачей мы формулируем её в общем виде и задаёмcя вопросом: как решается задача вообще? Как принято её решать? И да, если уже есть подходящие нам решения, мы "копируем" их в свой проект, подгоняя под себя. Так мы не тратим время на велосипед.
А надо так: Есть ли для данной предметной области язык. Если есть. То не тратим, врем на велосипед.
Если нет. То придётся писать язык.
Ибо если это не хелло ворлд на сотню строк, то язык очень сильно сократит объем работы.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Не правильно. WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
Неправильно. Это решение типовой задачи.
WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.
Паттерны возникают там, где много похожих задач. Отсюда следует что паттерны есть вообще везде где есть более одной задачи. Обеспечиваешь поддержку паттерна в языке и результатом будет паттерн более высокого уровня, просто многие паттерны не имеют общеупотребительных имен т.к. испольльзуюся буквально повсеместно и никого это не пугает.
WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
В предметной области уже есть паттерны...
WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
Здравствуйте, WolfHound, Вы писали:
__>>основное свойство копипасты в том, что чтобы что-то одно поменять приходится менять код в куче разных мест. __>>паттерны этим не страдают WH>Ага, конечно. WH>Посмотри на два применения одного паттерна и увидишь кучу идентичного кода, который повторяется по очень простым правилам. WH>Копипаста она и есть копипаста. WH>Причем такая, что повторяется настолько часто, что по ней даже книги пишут.
От этого никуда не уйти, в принципе. можно только уменьшить размеры копипасты и заменить одну копипасту на другую.
__>>есть жутчайшие языки программирования, которые возникли просто по ошибке и которые давно стоит закопать — WH>Я не спорю. C#, Java, C, C++,... давно пора закопать.
У тебя должно быть хорошее объяснение почему эти вещи не теряют популярности, а до кучи набирают популярность такие вещи как питон, джаваскрипт, руби или ПХП!!!
__>>например, sql. он как чемипалый пяти.. WH>Вот про SQL не нужно. Его конечно можно было сделать лучше. Но с обработкой данных он справляется просто несравнимо лучше чем яезыки одбщего назначения. WH>На досуги попробуй ручками на С++, жабу или C# реализовать хотя бы пару запросов... так чтобы конкурентность и ACID были в полный рост. WH>Уверяю тебя, не осилишь.
Зависит от данных которые нужно обрабатывать. Попробй на sql обрабатывать изображения или хотя бы задачи маршрутизации решать хотя бы в самом простейшем виде — охренеешь.
__>>не имеет смысла плодить языки, да и не все языки, которые хорошо решают одну задачу сделаны с умом WH>Языки, сделанные под конкретную задачу, даже если они сделаны не оптимально, всё равно на порядок другой порвут языки общего назначения.
В каком смысле "порвут" ? По стоимости разработки ? По стоимости сопровождения ? Быстродействию ? Потреблению памяти ? По кривой вхождения ? По всем вместе взятым ? По любому подмножеству ? В любой временной перспективе ?
Здравствуйте, WolfHound, Вы писали:
WH>Архитектура проекта существует лишь с одной целью. WH>Чтобы код на языке общего назначения не скатился совсем в говно. WH>А его туда очень сильно тянет. Просто по тому, что язык общего назначения не имеет никакого понятия о том, что есть в предметной области.
Архитектура нужна для управления сложностью решаемых задач. Код скатывается в говно — пусть скатывается. Архитектура нужна для того, что бы можно работать с проектом даже если код скатывается в говно.
N>>Паттерны помогают нам быстро проектировать и то, и то. WH>Не помогают. Паттерны механизм исключительно коммуникационный.
Свойство вычленять паттерны и оперировать ими присуще уже животным, у человека оно развито гораздо сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>ДСЛ это когда WH>assert a == b;
Внезапно — это уже паттерн, ага , только минимум копипасты
N>>Не совсем понял, что вы имеете в виду. WH>То и имею что паттерны годятся только для того чтобы сказать другому человеку что ты использовал визитер или там декоратор. И он тебя поймет.
А еще нужно что бы ты сам помнил. Помнить что реализован паттерн из некоторого семейства проще, чем запоминать все детали реализации.
WH>А надо так: Есть ли для данной предметной области язык. Если есть. То не тратим, врем на велосипед. WH>Если нет. То придётся писать язык. WH>Ибо если это не хелло ворлд на сотню строк, то язык очень сильно сократит объем работы.
Если задача хорошо изолирована, то язык сократит. А если нет, то на создание языка уйдет примерно столько же времени, как на развитие естественного языка
Здравствуйте, 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>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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 гипотетических похожих.
Здравствуйте, Ikemefula, Вы писали:
I>От этого никуда не уйти, в принципе. можно только уменьшить размеры копипасты и заменить одну копипасту на другую. То-то я уменьшаю копипасту до таких размеров, что она исчезает.
I>У тебя должно быть хорошее объяснение почему эти вещи не теряют популярности, а до кучи набирают популярность такие вещи как питон, джаваскрипт, руби или ПХП!!!
Кобол в свое время тоже набирал.
I>Зависит от данных которые нужно обрабатывать. Попробй на sql обрабатывать изображения или хотя бы задачи маршрутизации решать хотя бы в самом простейшем виде — охренеешь.
Я и не говорил, что на SQL можно все обрабатывать.
Но обработку тех данных, на которые заточен SQL сделать проще, чем на SQL очень не просто.
I>В каком смысле "порвут" ? По стоимости разработки ? По стоимости сопровождения ? Быстродействию ? Потреблению памяти ? По кривой вхождения ? По всем вместе взятым ? По любому подмножеству ? В любой временной перспективе ?
На задачах размером больше хелловролд по всем параметрам. И чем задача больше, тем сильнее отрыв.
Скажем, я сейчас занимаюсь оптимизацией, которую никогда бы не стал делать руками.
Ибо тот код, который будет генерироваться, просто невозможно написать руками без ошибок.
Тут даже не порядки. Тут возможно против невозможно.
При этом исходный ДСЛ не изменится. Совсем.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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>А теперь ДЗЕН вынесенный из этого проекта:
WH>Ближе к концу мы уже не стремились лепить библиотечные навороты и расширять фреймворк, а скорее старались заменять макросами рукопашный код насовсем но локально. Т.е. гораздо проще разработать какую-то феньку нужную в 5 местах и без параметров, и какую-то очень похожую феньку (даже внешне точно такую-же) для 5 других мест, чем лепить универсальную, конфигурируемую через кучу параметров мега-фень, способную покрыть все эти 10 мест и ещё 20 гипотетических похожих.
