Ну строительные кирпичики разные бывают, есть мелкие совсем, как в банде четырех описаные. А есть же паттерны для работы с БД вроде unit of work или active record, тоже кирпичики, хотя чуть крупнее. Или вот MVC совсем большой паттерн, определяющий дизайн на верхнем уровне. Про последние два непонятно, например, что изменится, если язык еще и ФП умеет. И насколько, дотустим, теже active record применимы в чистом функциональном языке и что в замен тогда?
Дело не в «функциональных языках», а в сложности домена самого по себе. Нет referential transparency, данные сами себя мутируют повсюду? Получите огромные проблемы и крайне неэффективный defensive copying повсюду, распишитесь. Либо ад с локами, дидлоками и прочим contention. Поэтому люди отказываются от самоизменяющихся объектов (объектов в ООП-стиле), берут иммутабельные структуры и чистые функции. События внезапно начинают поступать со всех сторон, а не только от пользователя? Между компонентами M, V и C появляется лаг в секунды? MVC разваливается, код начинает выглядеть как лапша из коллбеков и хаков. Люди пытаются использовать штуки вроде FRP и прочих Rx. Полная синхронизация на записи в БД становится невозможной? CRDT, vector clocks и прочая содомия ждут прямо за углом, споры о «какой бы ORM выбрать, чтобы поменьше писать?» вызывают максимум нервный смех. И так далее
( ... )
>Дело не в «функциональных языках», а в сложности домена самого по себе. Про какой именно домен идет речь? Потому что из описанного ниже, я этого не понял. Дальше идет несколько сумбурная критика ОО. При этом, понятно, какие профиты несут в себе чистые функции и неизменяемые объекты, но что делать с тем, что требования могут радикально меняться и, внезапно, противоречить уже имеющейся логике?
>акцент на reusability себя не оправдал, потому что «фреймворки» быстро превращаются в диких монстровЯ где-то вычитал интуитивное определение разницы между фреймворком и библиотекой. Там говорилось, что основное различие в том, что фреймворк сам вызывает твой код, а код библиотеки ты должен вызвать сам. Я думаю, что это близко к истине. И если отталкиваться от такого определения, то вполне понятно, почему фреймворки между самой плохо сочетаются - каждый из них хочет сам владеть потоком управления
( ... )
про тенденции -- как-то чуток перевёрнуто. Канпелятырь (либо dsl в общем виде) делается под какую-то область применения / задачу, позволяет решить её проще, ценой написания его самого. Если смысл имеет -- пишут, решают задачу с меньшими усилиями, и молодцы.
Так же обстоят дела и с говнокопательством типа "кустарные парсеры, валидаторы и сериализаторы" -- можно руками их лепить, можно инструментом, облегчающим дело. Иногда даже стоит написать такой инструмент, если форматов много. Ну, написал и сэкономил общее время -- молодец. Нет смысла писать (по ожидаемым затратам ресурсов), и сделал руками -- тоже молодец. (два других случая -- не молодец.)
Молодцы из обоих примеров -- и есть илитка. А чо не так?
По мне все так, я уважаю чужой труд. Я скорей про такое расхожее мнение, мол "говнотырпрайз, формачки всякие: сажаем макак с джавой или пыхом, на худой конец. они все и сделают", а для серьезных задач™ нужны более лучшие программисты с расчехленной функциональщиной. А я думаю, что подобные опердени как раз сложные и требуют использования практически всех доступных скилов.
Интересно, что содержимое комментария полностью опровергает его первую строку. Понятно, что доступные средства пока не очень хороши и кодогенерация видится выходом из ситуации. Только трудно оценить, насколько сложное поведение можно получать из декларативного описания модели. Ну и про изменения, ясно только то, что приходится руками все это делать. А допускать до реальных данных непонятно кого - это же саботаж работы компании в чистом виде. Но у меня ощущение, что не только среди программистов разработка внутренней автоматизации считается простейшей деятельностью, но и среди самих заказчиков. То есть нанять пару студентов, которые что-то там такое нарисует - нормальная практика. А в результате имеем уродливые медлительные небозопастные приложения и подтверждение тому, что с крудиками кто угодно справится.
Да, это знакомо. Повторять собственные рассуждения полугодовалой давности, чтобы вспомнить, почему тут сделано так сложно, хотя, казалось бы, могли бы обойтись "бац-бац и в продакшн".
DWH - интересная штука. Но мне сталкиваться еще не приходилось. Правда, судя по описаниям оно только часть проблемы решает - анализ и контроль. Но при этом надо еще сформировать это хранилище, а потом акутализировать постоянно.
>Насчёт же функциональщиков. То, что в объектном подходе паттерн, то для них - идиома. Можно переназвать, но суть не измениться. В любом случае, я как-то не вижу чтива про лучшие практики функционального программирования. Либо опыт не накоплен, либо не обощается.
\\(что касается фп, то я пока не понимаю, есть там какой-то свой подход к этому вопросу или нет)
на сколько я понимаю, у них там подход "мухи отдельно, котлеты отдельно" -- есть константная информация, а есть функции, которые её как-то между собой увъязывают :)
Умом-то это все понятно. А с практикой все сложнее гораздо. Банальный пример: загружается из базы коллекция объектов и привязывается ее к гриду, где пользователь может как-то менять данные. Потом жмет кнопку "схоронить", я обхожу коллекцию, нахожу измененные объекты, выполняю обновление. А как мне с отдельными неизменяемыми котлетами быть? При изменении объекта породить новый с измененным полем, потом перестроить иммутабельный список, удалив старый и добавив новый? При этом новые объекты полученные из старых должны хранить какую-то дельту (изменения) и правильно формировать ее при каждом копировании. И ещё придется следить, чтобы рабочаяя копия объекта всегда была одна, иначе вообще непонятно, как потом искать все эти копии и собирать их дельты воедино. Интуитивного понимания нет. Для ООП я открываю фу-фу-фу Фаулера и читаю про методики работы с данными, смотрю примеры реализации, оцениваю плюсы и минусы. А с ФП мне непонятно, куда смотреть, где брать рекомендации. Это интересно, конечно, решать сложные задачи™, но best practice
( ... )
Comments 21
я вот не считаю, и вот почему: если уж кодить на языке, который умеет только ООП, но не ФП, то вполне можно использовать паттерны как "кирпичики".
С другой же стороны, строго DO. NOT. WANT. кодить на таких языках.
Reply
Reply
Reply
Про какой именно домен идет речь? Потому что из описанного ниже, я этого не понял. Дальше идет несколько сумбурная критика ОО. При этом, понятно, какие профиты несут в себе чистые функции и неизменяемые объекты, но что делать с тем, что требования могут радикально меняться и, внезапно, противоречить уже имеющейся логике?
>акцент на reusability себя не оправдал, потому что «фреймворки» быстро превращаются в диких монстровЯ где-то вычитал интуитивное определение разницы между фреймворком и библиотекой. Там говорилось, что основное различие в том, что фреймворк сам вызывает твой код, а код библиотеки ты должен вызвать сам. Я думаю, что это близко к истине. И если отталкиваться от такого определения, то вполне понятно, почему фреймворки между самой плохо сочетаются - каждый из них хочет сам владеть потоком управления ( ... )
Reply
Так же обстоят дела и с говнокопательством типа "кустарные парсеры, валидаторы и сериализаторы" -- можно руками их лепить, можно инструментом, облегчающим дело. Иногда даже стоит написать такой инструмент, если форматов много. Ну, написал и сэкономил общее время -- молодец. Нет смысла писать (по ожидаемым затратам ресурсов), и сделал руками -- тоже молодец. (два других случая -- не молодец.)
Молодцы из обоих примеров -- и есть илитка. А чо не так?
Reply
Reply
Reply
Reply
Reply
Reply
Насчёт же функциональщиков. То, что в объектном подходе паттерн, то для них - идиома.
Reply
>Насчёт же функциональщиков. То, что в объектном подходе паттерн, то для них - идиома.
Можно переназвать, но суть не измениться. В любом случае, я как-то не вижу чтива про лучшие практики функционального программирования. Либо опыт не накоплен, либо не обощается.
Reply
Э? Именно суть разная.
DWH - это сбор из разных источников и размещение в удобном для различного применения виде. Анализ - это BI
Reply
Reply
на сколько я понимаю, у них там подход "мухи отдельно, котлеты отдельно" -- есть константная информация, а есть функции, которые её как-то между собой увъязывают :)
Reply
Банальный пример: загружается из базы коллекция объектов и привязывается ее к гриду, где пользователь может как-то менять данные. Потом жмет кнопку "схоронить", я обхожу коллекцию, нахожу измененные объекты, выполняю обновление. А как мне с отдельными неизменяемыми котлетами быть? При изменении объекта породить новый с измененным полем, потом перестроить иммутабельный список, удалив старый и добавив новый? При этом новые объекты полученные из старых должны хранить какую-то дельту (изменения) и правильно формировать ее при каждом копировании. И ещё придется следить, чтобы рабочаяя копия объекта всегда была одна, иначе вообще непонятно, как потом искать все эти копии и собирать их дельты воедино.
Интуитивного понимания нет. Для ООП я открываю фу-фу-фу Фаулера и читаю про методики работы с данными, смотрю примеры реализации, оцениваю плюсы и минусы. А с ФП мне непонятно, куда смотреть, где брать рекомендации. Это интересно, конечно, решать сложные задачи™, но best practice ( ... )
Reply
Leave a comment