Что у нас в FP есть в плане анализа предметки

[metaclass]

и синтеза дизайна системы?
Тут народ вопросом задается: http://guamoka.livejournal.com/1047171.html

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

Comments

[dmzlj.livejournal.com]

Непонятно, в чем отличие от не-ФП.

[metaclass.livejournal.com]

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

[dmzlj.livejournal.com]

в плане "синтеза" есть опасность скатиться в микро-дизайн, и если топикстартер приводит в пример высеры Буча и GoF, то это 99% оно и есть, т.е не нужно.

Далее, нет никакого "FP". Есть Ocaml с классами (не к ночи) и навороченными параметрическими модулями, есть Haskell с тайпклассами, монадами (хехе) и простыми модулями, есть Scala (что там в ней есть), есть Erlang с его примочками. Везде есть модули, процессы, сообщения, но все равно нет никакого общего "FP", соответственно, надо смотреть.

[metaclass.livejournal.com]

Скала настоящий мультипарадигменный йязык, заодно и со статик типами.
В F# макросов не хватает для кошерности, а немерле меня пугает мертвостью.

[migmit.livejournal.com]

Макросы некошерны.

[metaclass.livejournal.com]

Да. А языки, где они не нужны, пугают людей :)

[jakobz.livejournal.com]

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

Что там будет на верхнем уровне - ООП, монады, стрелки, акторы и прочее - вопрос не про ФП совсем.

[dmzlj.livejournal.com]

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

[metaclass.livejournal.com]

Без полноценных статических типов грустно :)

[dmzlj.livejournal.com]

Типизация ортогональна. Scheme вполне функционален

[love5an.livejournal.com]

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

[v-l-a-d.livejournal.com]

а иммутабельность?
или она сама по себе логически вытекает из чего-то перечисленного?

[guamoka.livejournal.com]

в плане "синтеза" есть опасность скатиться в микро-дизайн, и если топикстартер приводит в пример высеры Буча и GoF, то это 99% оно и есть, т.е не нужно

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

[dmzlj.livejournal.com]

GoF про микродизайн, а Буч это натягивание сов на глобусы, вообще малоосмысленное чтение.

[guamoka.livejournal.com]

ГоФ- это не только (и не столько) микродизайн (боюсь даже спросить, что вы под этим утверждением понимаете). Бутч- вполне себе осмысленное чтение. Хоть и затянутое. Фаулера вполне достаточно.

[jakobz.livejournal.com]

Да тоже самое все подходит. Любителям фашизма можно даже UML-диаграммы рисовать.

[vit-r.livejournal.com]

Если брать Эрриксон, то они скорее всего документировали в виде CSD (call sequence diagram) и конечных автоматах. Диаграммы потоков данных и сообщений тоже полезны. А в остальном, те же яйца, только сбоку.

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

[guamoka.livejournal.com]

Я вот думаю, что не везде требуют соблюдать вуду-процессы с артефактами-uml-подробными спецификациями и прочим

Кстати, ребе, вы случайно не путает OO подход, моделирование, специфицирование и документирование c помощью, скажем UML? Чтобы использовать OO подход и даже использовать/знать РУП, не нужно ведь обязательно под страхом расстрела документировать каждую запятую в проекте на UML, утром получать документацию, а вечером сдавать? Ну, и "достаточность" тоже ведь не подразумивает, нарисовал две линии в юзкейзах, три- в моделях, четыре-пять- в спецификации имплементации?

[metaclass.livejournal.com]

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

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

[berezovsky.livejournal.com]

Проблема либо в, э-э-э-э-э, не до конца достаточной степени понятливости человека или отсутствии у него необходимой базы, на получение которой может быть нужно разное время, либо в недостаточной простоте языка, на котором ведётся объяснение. Чем тупее, тем лучше. Можно ввести базовые простые термины и называть их всегда одними же и теми словами. И даже не углубляться в суть, если для типичных задач это не нужно. Захочет - разберётся. Заебёт вопросами, например. А если не захочет, зачем тогда работать.

[justy-tylor.livejournal.com]

Для data modeling есть разница в кошерных sum types. Палитра низкоуровневых архитектурных приёмов больше зависит от языка, чем от парадигмы. Например, design patterns заплатки для Java от GoF. Или type classes в Haskell vs. попытки навести что-то подобное в OCaml.

Что касается OOA/OOD, то хороших слов у меня нет. Попытки сделать толковое начались только в BORO Партриджа (Chris Partridge "Business Objects: Re-Engineering for Re-Use"), но это, фактически, отход от object-oriented (как и последовавшие ISO 15926-2, Gellish, HQDM). А "проверенное временем" вуду, будь оно архитектурного или организационного уровня, всё больше про говно и солому,