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

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

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

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

G>

...

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

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

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

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

AF>> Хотя возможно, что я в этом ошибаюсь.
G>Подтвердить или опровергнуть это может только практика .
Вот это будет действительно интересно. Вроде я видел, что собирались делать резервирование авиабилетов на ФЯ. Интересно — что из этого выйдет...