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

[metaclass]

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

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

Comments

[metaclass.livejournal.com]

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

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

[berezovsky.livejournal.com]

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