Здравствуйте, AndreyFedotov, Вы писали:

AF>Здравствуйте, Gaperton, Вы писали:

AF> Я обратил внимание на интересную особенность статей и примеров по ФЯ (в том числе и этого): они все иллюстрируют, как здорово можно реализовать тот или иной алгоритм, и рассуждают об общих принципах. Но как правильно отметил bleed — и я с ним полностью согласен — я ни разу не видел примера или хотя бы намёка — как на ФЯ построить систему и чем система (а не отдельный алгоритм) — будет лучше, почему её удобнее было бы строить на ФЯ или удобнее было бы развивать на ФЯ, чем на ИЯ.
Что-то у меня дежа вю: ты какую статью читал? Да она вся — сплошной разжеванный и в рот положеный пример чем система будет лучше, почему ее удобнее строить и развивать на ФЯ. Рассчитанный на человека, не знающего ФЯ, так как более сложные примеры он просто не поймет (и в этом не ничего странного — надо для начала языку научится, а потом рассуждать о построении приложений). Чтобы не было сомнений, автор в конце пояснил специально.

В этой статье утверждается, что модульность — ключ к успешному программированию. Языки, которые стремятся улучшить производительность, должны поддерживать модульное программирование. Но новые правила видимости и механизмы раздельной трансляции недостаточны. Модульность — нечто большее, чем модули. Наша способность расчленять проблему на части зависит непосредственно от нашей способности склеить решения. Чтобы поддерживать модульное программирование, язык должен обеспечить хороший клей. Функциональные языки программирования обеспечивают два новых вида клея — функции высшего порядка и ленивые вычисления. При использовании этих клеев программы могут быть модуляризованы новыми и захватывающими способами, и мы дали много примеров этому. Маленькие и очень общие модули могут широко и многократно использоваться, облегчая последующее программирование. Это объясняет, почему функциональные программы намного меньше и почему их проще писать, чем обычные. Если какая то часть программы беспорядочна или сложна, программист должен попытаться разбить её на модули и обобщить части. Он должен попытаться использовать функции высшего порядка и ленивые вычисления как инструментальные средства для выполнения этой задачи.

Case studies и руководства по дизайну есть в книгах на английском — вот то что видел я (Concurrent Programming in Erlang) и OCaml (Developng Applications with OCaml), и есть еще. Подход к проектированию в Erlang можно обсудить подробно — как раз недавно имел дискуссию на эту тему с Joe Armstrong-ом — рассказал ему Вовиновский взгляд на Erlang (типа это на самом деле смолток ) — и он меня по стенке размазал . Там вроде как все просто, на самом деле.

AF> Если вся система — как это часто бывает в телекоме — это набор достаточно сложных алгоритмов, легко реализуемых на ФЯ, притом с примитивной структурой самой системы, то польза от ФЯ очевидна.
Ну, я бы не сказал, что структура телекомовского софта примитивна. Откуда дровишки, почему ты считаешь, что это бывает в телекоме часто? Система состоящая из миллиона строк кода, которая делает полезную работу (AXD switch), не может иметь примитивную структуру. И уж во всяком случае, складская система из 50 тыщ строк , не может иметь структуру сложнее .

AF> Но как быть, если алгоритмы просты, зато структура системы сложна (что бывает гораздо чаще — это бухгалтерские или ERP системы)?Есть большое подозрение — что здесь если и есть выигрышь у ФЯ языков (в чём я лично очень сомневаюсь) — то он минимален и просто не стоит того, что бы их применять.
Скорее всего ты прав. Надо будет подумать о бухгалтерии на ФЯ , это будет экстрим.

AF> Хотя возможно, что я в этом ошибаюсь.
Подтвердить или опровергнуть это может только практика .