О дизайне и ФП

[gaperton]

Тут thesz узнал из достоверных источников, что я решаю свою задачку на Эрланге, и уже запустил рекламую компанию

Comments

[kurilka]

А вот вопрос по поводу - насколько выбор языка имплементации сказывается на итоговом дизайне решения? На твой взгляд?

хороший вопрос

[gaperton]

На микроуровне - будут различия, на крупном уровне будут сходства. Чем крупнее уровень, тем меньше дизайн (декомпозиция) будет зависеть от языка. Сепень вариаций зависит от разницы в языках. Взгляни на дизайн моего решения на крупном уровне - следующий пост в блоге.

Я не использую ничего кроме модулей, решение "чистое" и "строгое". Оно может быть без изменений перенесено в любой ФЯ. И по декомпозиции один-в-один похоже на ОО дизайн. Вот, ИМХО, наглядная иллюстрация.

Re: хороший вопрос

[kurilka]

Пост обязательно прочитаю.
А так получается, что все эти флеймы статик vs. динамик, имератив vs. функциональщина есть большей частью лишь частности, а главное, чтоб серое вещество в черепной коробке присутствовало?
Но разве не сказываются на дизайне те самые идио..матические решения, которые будут на C++ от того же Эрланга сильно отличаться?

Re: хороший вопрос

[gaperton]

На "детальном дизайне" - сказываются однозначно, они его во многом определяют. На просто "дизайне" - тоже да, но в существенно меньшей степени. В посте я объясняю почему так.

[mstone]

А можно попросить подробностей про архитектурные ошибки в Одиссее? Просто первая и третья, на первый взгляд, не выглядят ошибками (вполне себе варианты, со своими плюсами и минусами), и тем интереснее, почему же они стали камнем преткновения. А придумывание своего языка - это, по моему опыту, наоборот, одна из самых ужасных архитектурных ошибок: всё равно потом получится тот же бейсик, только кривой, состоящий из сплошных заплат, недокументированный и изобилующий багами.

[gaperton]

Первая вызывает вполне конкретные проблемы

[mstone]

Да, с базой vs. файловая система понятно - ключевой момент, действительно, описан, в пункте 5 :). В текущем проекте мы имеем весь описанный геморрой с базой по полной программе, но понятно заради чего: счёт записям идёт на десятки миллионов

[gaperton]

> Да, с базой vs. файловая система понятно - ключевой момент, действительно, описан, в пункте 5 :). В текущем проекте мы имеем весь описанный геморрой с базой по полной программе, но понятно заради чего: счёт записям идёт на десятки миллионов.

Я не знаю вашего случая, но мне кажется, и в вашем случае жизнь станет немного легче, если не увлекаться нормализацией базы. То есть, хранить информацию, по которой не предвидится поиск, в текстовых полях, в виде XML, штоб нарушала нафиг первую нормальную форму. Индескные поля, по которым идет поиск, можно задавать отдельно параметрами хранимых процедур.

Что-то подобное мы тоже проходили

[dmagin]

Хороший дизайн - это устойчивый (нехрупкий) дизайн.
В том смысле, что малое изменение входных параметров (ф. требований) - реализуется малым изменением выходных (в алгоритмах и структуре данных).

Для того, чтобы достичь устойчивости предлагается использовать контроль связности - система должна быть слабо связанной.

Возможно. Хотя на мой взгляд, слабая связность - следствие нормализации.

Как пример,- с точки зрения структуры два нижеприведенных выражения не эквивалентны:

a*b1 + a*b2 + a*b3 <> a*(b1 + b2 + b3

Re: Что-то подобное мы тоже проходили

[gaperton]

> Если переменная "a" в приведенных выражениях в принципе не меняется (вечная константа), то разница в связности двух выражений особого значения не имеет

Re: Что-то подобное мы тоже проходили

[dmagin]

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