Применимы ли паттерны GoF для LISP?

По-существу, стало быть, нечего ответить? Вы я так понял тоже не признаёте применимость паттернов в лиспе, чисто по религиозным причинам

Да никакой это не тролль. Просто парень молодой еще, все такими были:)

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

> Научился делить и теперь готов найти новое решение теоремы Ферма

Откуда у вас такие нездоровые домыслы, я что вас чем-то задел? Я всего-навсего пытаюсь узнать, насколько применимы мои привычные инструменты к новому языку. :)

ГоФ — это не инструмент. Это всего лишь толковый словарь. Странно, что ты без него и шагу ступить не можешь. Именно эту мысль тебе и пытаются разъяснить.

Задание на дом. Сколько и каких паттернов сможешь найти в SICP?

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

Такого же мнения и я о вас. Удачи.

> Задание на дом. Сколько и каких паттернов сможешь найти в SICP?

По какому праву вы берётесь задавать мне домашнее задание?
Если хотите, чтобы я выполнил для вас работу, давайте заключать договор подряда

> Такого же мнения и я о вас. Удачи.

...сказал хомячок ястребу :) всего хорошего

Да мы уже все поняли, что у тебя комплексы в силу низкой компетентности. Лети-лети.

Аргументы кончились, начался переход на личности? ;) Я на самом деле против вас ничего не имею. У нас с вами разные профессии просто, и нас интересуют разные аспекты проблемы построения ПО. Чего вы так завелись-то, я не понимаю?

> Да никакой это не тролль. Просто парень молодой еще

Он уже архитектор!!11

Чего вы так завелись-то, я не понимаю?

Потому, что ерунду говоришь. А это раздражает.

Видишь ли дело не в специальности. Я как бы не в деревянной коробке живу и повидал многое и архитекторов в том числе и что это такое и с чем едят представляю. Более того в паре шабашек выполнял роль архитектора в том числе. Дело в том, что мое окружение таково, что задачи связанные с «отношением и взаимодействием между сущностями» на столько просты на фоне остального, что подсильны рядовому программисту. Ну или по крайней мере тимлиду. Это совершенно не означает, что архитектор никогда не должен опускать до такого уровня. Напротив, я считаю что архитектор обязан писать какой-то код в проекте, ну или по крайней мере его читать. Тем не менее существуют задачи намного более «высокие». Например сформулировать а что вообще собой должна представлять разрабатываемая система. Иными словами, ответить на вопрос «что?». Ответ на вопрос «как?» - это уже реализация системы, а не проектирование. И те же отношения между сущностями это уже ответ на вопрос «как?». Тут я могу сослаться на Брукса. Если не согласны, спорьте лучше с ним, а не со мной :)

Он уже архитектор!!11

и просто пытается понять, да. если бы вместо Java был Python, я бы решил что к нам вернулся tia

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

> Он уже архитектор!!11

Надо было всё-таки написать «будущий архитектор», чтобы не провоцировать таких как вы на петросянство :)

Да, я считаю, что enterprise architect - закономерное развитие моей карьеры разработчика, и загодя готовлюсь к этому развитию. Что не так?

> Дело в том, что мое окружение таково, что задачи связанные с «отношением и взаимодействием между сущностями» на столько просты на фоне остального, что подсильны рядовому программисту.

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

> Например сформулировать а что вообще собой должна представлять разрабатываемая система. Иными словами, ответить на вопрос «что?».

На вопрос «что?» отвечают бизнес-аналитики и постановщики ТЗ. Либо ваша контора (и её задачи) настолько мелки, что эти должности совмещаются с архитектором, либо вы ни черта не понимаете в процессе разработки. Либо и то и другое вместе.

Задачи архитектора предельно чётко описываются следующей формулировкой:

Architecture is a set of structuring principles that enables a system to be comprised of a set of simpler systems each with its own local context that is independent of but not inconsistent with the context of the larger system as a whole.

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

> Ответ на вопрос «как?» - это уже реализация системы, а не проектирование.

А что, проектирование - это разве не неотъемлемая часть реализации?

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

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

«Архитектор? Это чё, дачу строить штоле? Не? А чё тогда? Нах нужен, гуляй вася...» - а потом удивляются, почему вдруг система перестаёт отвечать при росте нагрузки.

На вопрос «что?» отвечают бизнес-аналитики и постановщики ТЗ.

Еще раз, с эти иди спорить к Бруксу.

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

Как раз наоборот, наши задачи на столько сложны, что аналитики их не могут поставить в достаточном для реализации объеме. Аналитик, он все же спец по бизнесу. Он тебе не напишет: «сделать считалку такой-то аналитики на хадупе». Он просто напишет, что нужно так-то обсчитывать сотни гигабайт таких-то логов (к примеру). Решить, что это будет считалка на хадупе, а еще и запускаемая в облаке и состоящая из трех модулей: «загрузка, считалка, выгружалка» должен архитектор.

Т.е. основная задача архитектора - это декомпозиция.

Спорно. Заметь, декомпозируют что-то. А это что-то (систему) нужно тоже вначале придумать. Декомпозиция это уже следующий шаг, относящийся непосредственно к постановке задачи.

Как вы можете с серьёзным видом рассуждать о роли архитектора, не зная таких базовых вещей?

Я все это читал сто раз и слышал сто разных мнений. Даже такие: если тебе что-то говорит фамилия Фаулер, то по его мнению «классический» архитектор - это х*й, которого нужно гнать палками.

> Еще раз, с эти иди спорить к Бруксу.

Т.е. своих мыслей на тему дискуссии не имеется?

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

Значит, это не аналитики, а говно.

«классический» архитектор - это х*й, которого нужно гнать палками.

Пруф?

Т.е. своих мыслей на тему дискуссии не имеется?

Имеется. Вообще, если рассмотреть всю цепочку разработки, то на каждой стадии на входе имеется нечто отвечающее на вопрос «что?» а на выходе получается нечто, что отвечает на вопрос «как?». Причем при переходе на следующую стадию то, что было ответом на вопрос «как?» автоматически становится ответом на вопрос «что?». Так вот для программистов кто-то должен ответить на вопрос «что?». Если на это отвечает ТЗ, то, бинго, архитектор вообще не нужен. Если по ТЗ ясно, что дело темное, нужна еще она стадия, которая дополнит ТЗ ключевыми техническими решениями.

Значит, это не аналитики, а говно.

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

Пруф?

Who Needs an Architect?

> Вы я так понял тоже не признаёте применимость паттернов в лиспе, чисто по религиозным причинам

Паттерны в лиспе неприменимы, пока обратное не доказано. Так что «религиозные причины» - это как раз твоя точка зрения.

> Who Needs an Architect?

А, ну понятно. У него «кухарка должна управлять государством». Сами знаете, наверное, что из этого получилось?

«В спальне принимать пищу, в смотровой читать, в приемной одеваться, оперировать в комнате прислуги, а в столовой осматривать. Очень возможно, что Айседора Дункан так и делает. Может быть, она в кабинете обедает, а кроликов режет в ванной. Может быть. Но я не Айседора Дункан!..» (С)

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

Доказано. См. паттерн Observer в CL-GTK2, паттерны Bridge и Facade в bordeaux-threads, паттерн Application Controller у Архимага.

Where is your God now?

обсёрвер в GTK, а не cl-gtk2
cl-gtk2 это просто тонкая обертка.

Bridge и Facade в bordeaux-threads

Оох. Ну вот, я про это и говорил в http://www.linux.org.ru/forum/development/6510370/page2#comment-6518013

«Нормальный человек о „паттернах“ даже не вспомнить, а подумает - ну, решил задачу, ништяк, и пойдет пить кофе. Но не паттернодрочер. Паттернодрочер естественно сразу станет кричать о том, что мы тут применили два вида „фабрик“, „строитель“ и еще какую-нибудь хреноту типа „декоратора“. В особо запущенном случае еще и побежит дорабатывать наш код до „каноничного“ вида, типа как из GoF, засрет половину проекта жабоподобным говнокодом и добавит головной боли остальным разработчикам.»

> Доказано. См. паттерн Observer в CL-GTK2, паттерны Bridge и Facade в bordeaux-threads, паттерн Application Controller у Архимага.

По части обсервера тебе уже указали, пруфы Bridge и Facade ты не привел, а с наличием Application Controller у Архимага, думаю, не согласен сам Архимаг. Пойми простую вещь - если что-то в коде выглядит как паттерн, отсюда не следует, что это что-то является паттерном. Здесь важна семантика. Тебе уже не раз в этом треде приводили пример функции - на ассемблере функция будет паттерном, но значит ли это, что мы в любом высокоуровневом ЯП должны считать паттерном применение функции? Конечно, нет. Что-то имеет смысл считать паттерном лишь тогда, когда это приносит профит. В противном случае тот факт, что Х - паттерн, это уже низкий уровень чистой воды байтоебство. От низкоуровневых деталей следует всячески абстрагироваться. При любой возможности.

Я так и не понял, почему «назвать вещи своими именами» == «дрочерство»?

> По части обсервера тебе уже указали

Что указали? То, что CL-GTK2 есть обёртка, не отменяет факта применимости паттерна Observer в Common Lisp.

пруфы Bridge и Facade ты не привел

«Пруфы» очевидны для каждого, кто читал книжку «Design Patterns: Elements of Reusable Object-Oriented Software».

с наличием Application Controller у Архимага, думаю, не согласен сам Архимаг

Давайте, может, спросим у него самого?

> Я так и не понял, почему «назвать вещи своими именами» == «дрочерство»?

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

> Что указали? То, что CL-GTK2 есть обёртка, не отменяет факта применимости паттерна Observer в Common Lisp.

Это отменяет возможность делать выводы о применимости обсервера в CL на основе CL-GTK2.

«Пруфы» очевидны для каждого, кто читал книжку «Design Patterns: Elements of Reusable Object-Oriented Software».

Совершенно безосновательное утверждение. Как раз тот, кто читал эту книжку, найдет пруфы того, что никаких паттернов там не было. Еще раз - если некий код делает то же самое, что и паттерн, это не значит, что мы имеем паттерн.

Давайте, может, спросим у него самого?

Давайте.

> Некоторые участки кода на CL соответствуют определению ряда паттернов, но нужно ли это учитывать во время написания кода на CL? Нет, не нужно. Это не приносит пользы, это усложняет понимание и написание кода.

Почему?

> Как раз тот, кто читал эту книжку, найдет пруфы того, что никаких паттернов там не было.

Так приведите эти пруфы. Вы же ведь читали книжку, правда?

Еще раз - если некий код делает то же самое, что и паттерн, это не значит, что мы имеем паттерн.

Почему?

> Почему?

Потому что знание о том, что мешок с картошкой - дифференцируемое многообразие, излишне для разгрузки вагона.

> Так приведите эти пруфы.

Зачем? Это же _ты_ пытаешься всех убедить в том, что паттерны в CL нужны.

Почему?

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

У него «кухарка должна управлять государством». Сами знаете, наверное, что из этого получилось?

Он же сторонник agile (более того один из основателей направления). А в agile есть такое правило: все эти методики работают для людей с мозгами. То есть в agile, в идеале, нету места разработчикам не способным к проектированию. Так что аналогия с кухаркой не верна.

А лично я убедился на горьком опыте, что тупые исполнители в проекте не нужны - задачи понимаются не правильно, реализуются через жопу, в итоге нужно все переделать. Можно сослаться на то, что я пока еще зеленый манагер, так оно и есть, но такие же жалобы слышал и от матерых манагеров. Кстати, тут я как раз хлебнул того, что объектная декомпозиция не самое важное. С ней справляются более-менее хорошо даже слабенькие разрабы (возможно это заслуга высшего образования). Но боже мой, какой же говнокод в методах! Постоянные баги с concurrency. Херовые не читабельные не поддерживаемые юнит-тесты. И самое стремное - абсолютно через жопное понимание задач.

>>> с наличием Application Controller у Архимага, думаю, не согласен

сам Архимаг.

Давайте, может, спросим у него самого?

Давайте.

Хм, я не согласен. В основе RESTAS лежит совершенно иная идея, некий аналог pattern matching для URL, только основанный на унификации. Именно использование унификации отличает от других систем на основе routes и определяет дальнейший дизайн системы. А идея использовании унификации происходит не от изучения паттернов, а от изучения логики первого порядка (которой я как раз в начале разработки RESTAS занимался). Собственно, с определением Application Controller я познакомился только что и не вижу как его можно разумно применить к описанию и главное не вижу какой от этого может быть профит.

Судя по твоим комментариям, ты недалёкий, хамоватый тролль. Мои доводы не будут тобой восприняты адекватно. Потому я тебе их приводить не буду, пожалуй.

Если ответ jtootf'а тебе непонятен, то проблемы с головой таки у тебя.

Собссна: спасибо всем, кто делает лор таким дерьмищем, какое он есть сейчас.

> на ассемблере функция будет паттерном, но значит ли это, что мы в любом высокоуровневом ЯП должны считать паттерном применение функции? Конечно, нет.

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

если что-то в коде выглядит как паттерн, отсюда не следует, что это что-то является паттерном.

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

Разумеется, одинкоим индейцам в пампасах это нафик не нужно.

тот факт, что Х - паттерн, это уже низкий уровень чистой воды байтоебство.

Паттерн не может быть уровнем. Паттерн - это имя, просто __имя__ для категории программных конструкций. Такое же имя как «цикл» или «рекурсия» (которые ведь, тоже паттерны!).

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

в Patterns Hatching Влиссидес сокрушался о том, что GoF воспринимают как каталог стандартных решений, а не учебник о том, как эти решения получать. общий тезаурус это, конечно, неплохо, но с точки зрения проектирования куда полезней (и универсальней) думать в терминах анализа общности/изменчивости, приходя к тому или иному паттерну самостоятельно

тем более, что конкретная реализация может сильно варьироваться. сравни диаграммы для Strategy у GoF и Александреску, например: вроде бы говорим об одном и том же, а подразумевает каждый своё

> общий тезаурус это, конечно, неплохо, но с точки зрения проектирования куда полезней (и универсальней) думать в терминах анализа общности/изменчивости, приходя к тому или иному паттерну самостоятельно

Одно другого не отменяет. Конечно, не плохо самому додуматься до численного интегрирования, но знать, как его называют другие совсем не помешает.

тем более, что конкретная реализация может сильно варьироваться

Ну так потому он и «паттерн», а не сниппет для копипаста.

Ну так потому он и «паттерн», а не сниппет для копипаста.

это reductio ad rectum, как по мне. где грань между сниппетом уровня кода (для копипаста) и сниппетом уровня проектирования (для реализации)? в том, что во втором случае можно морщить лоб и с придыханием выдавать «я же архитектор»?

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

Коненчо, мы будем называть ее функцией. Мы не будем называть ее паттерном! Мы называем что-то паттерном, когда у нас в ЯП нету названий для этого чего-то. Если в языке нету ф-й, то мы можем завелосипедить ф-и, но это в рамках данного языка будет «паттерн функция», потому что такого понятия как «функция» в ЯП нет, мы не способны его выразить. Или, например, есть паттерн «пара одинаковых инструкций». Это (ясное дело) просто пара одинаковых инструкций и это очевидно паттерн, но мы можем написать в лиспе макрос, который принимает некую форму и вызывает ее дважды. и это будет не паттерн - это будет макрос. Нам не требуется привлекать лишние средства выражения (паттерна), мы можем все выразить в рамках понятий ЯП. или другой пример - условный оператор или оператор цикла. Если у нас есть только goto, то мы можем реализовать цикл, и это будет паттерном. Но если в нашем языке есть вещь под названием «оператор цикла», то, опять-таки, привлечения паттернов не требуется. Если что-то можно выразить в виде функции, класса, типа данных, макроса - вообще в рамках данного ЯП, то незачем называть это паттерном. вот все обсуждаемые паттерны в основном относятся к ООП-языкам, там есть понятие класса, но любой паттерн - не класс. Это совокупность классов/интерфейсов, зачастую с их реализацией. В ООП-языках обычно нету никакого такого объекта, который представил бы подобную совокупность, в результате мы ее выразхить не можем - и говорим, что это паттерн. Но если бы у нас был такой объект (назовем его pattern) мы бы могли его еализовать (один единственный раз и навсегда, как-то так pattern observer = blah blah blah) и потом когда нам нужен конкретный обсервер мы бы просто писали new observer(blah blah blah) (внутри аргументы паттерна) и вот он у нас есть. Мы бы могли писать библиотеки patterns (наверное, гофовские паттерны вошли бы в стандартную библиотеку) и т.п.. И в данном случае все, что можно было бы выразить при помощи pattern уже не было бы паттерном, потому что у нас есть специальное средство языка для выражения подобных сущностей. Привлекать что-то сбоку излишне.

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

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

Паттерн - это имя, просто __имя__ для категории программных конструкций.

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

Можно, конечно, абстрагироваться от циклов, функций, рекурсии

нет, можно (и нужно) абстрагироваться от того, что они являются паттернами.

Но если конструкции _другие_ (хотя и выполняющие ту же функцию)- это уже не паттерн

Паттерн - это ОБРАЗЕЦ решения какой-либо проблемы. Вообще нельзя говорить о конструкциях в коде паттерн это или нет. Ибо это в лучшем случае код написанный под влиянием паттерена.

Еще разочек: паттерн - это образец решения какой-либо ПРОБЛЕМЫ. Если у вас нет проблемы в силу выразительности языка, то и искать образец для подражания вам уже не нужно. Паттерны, они в книжке. В коде у вас абстракции. Тысячи их.

> где грань между сниппетом уровня кода (для копипаста) и сниппетом уровня проектирования (для реализации)?

В объёме изменений в сниппите. ;) Сниппет решает только одну частную задачу. Паттерн - образец для решения класса задач.

> Мы называем что-то паттерном, когда у нас в ЯП нету названий для этого чего-то.

Ошибка. Не важно, есть у нас в языке синтаксические средства для создания цикла или нет - цилк всё равно остаётся циклом и мы будем называть его циклом.

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

Вот в этом-то и ошибка. Эта реализация семантически может не иметь с паттерном ничего общего - оно просто выполняет ту же функцию. И вот так вот ты скажешь коллеге «у нас же тут декоратор» - а ведь это совсем не работает, как декоратор, оно только выполняет функцию декоратора.

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

Но паттерн не определяется только своей функцией.

Паттерн именно что определяется своей функцией в отношении конкретного кода. Мы можем отдельно рассмотреть то, что код является циклом, и отдельно - условие и тело конкретного цикла.

Можно, конечно, абстрагироваться от циклов, функций, рекурсии

нет, можно (и нужно) абстрагироваться от того, что они являются паттернами.

Ну давай по другому:

Можно, конечно, абстрагироваться от сложения, умножения, вычитания.

нет, можно (и нужно) абстрагироваться от того, что они являются операциям над числами.

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

Ошибка. Не важно, есть у нас в языке синтаксические средства для создания цикла или нет - цилк всё равно остаётся циклом и мы будем называть его циклом.

любой язык, в котром зигохистоморфные препроморфизмы не являются first-class values, является ущербным

я высказался

> я высказался

Полегчало? ;)

> я высказался

А ты правда понял то, что сказал?

долго ли надо курить Хаскелль, чтобы это понять? я из этого ничего не понял... http://www.haskell.org/haskellwiki/Zygohistomorphic_prepromorphisms