Там описан пример решения маленькой задачи с строго определенным входом, строго определенным выходом и без внутреннего состояния. Это совершенно никак не похоже на крупномасштабные (ну ладно уж крупномасштабные, даже просто среднемасштабные) проекты в которых внутренее состояние системы является значимым.
Re[2]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Да, спасибо, упомянутую работу я читал несколько лет назад. Но, насколько я помню, товарищ Армстронг таки толком не останавливался на конкретике и на хранении состояния (mnesia она априори под рукой). Впрочем я могу и ошибаться. Стоит перечитать ?
Re[6]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Вы уж простите, товарищ lomeo, что я выскажусь несколько огульно, но у меня складывается впечатление (очень надеюсь что ошибочное) что когда FP-программистам задаешь вопрос о крупномасштабной архитектуре (presentation tier + buisenss logic tier + integration/persistence tier + resource tier) они вместо прямого ответа начинают песню либо о типах, либо о монадах, т.е. о достаточно мелких детялях. Вас просили показать пример законченного многозвенного приложения выполненного в функциональном стиле, ну или хотя бы проектную документацию из который было бы ясно как построить такое приложение. А Вы нам про монады, уж извините.
Re[4]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, lomeo, Вы писали:
FR>>Ты тут не совсем прав, вернее совсем не прав. В прототипировании динамика гораздо лучше статики. L>Я пробовал — длительное время прототипировал в python. Нет у динамики преимуществ, по сравнению со статическими языками, позволяющими так же кратко записывать мысль. Сейчас для прототипирования использую Haskell и Scala.
Я думаю, надо сравнивать сравнимое. Когда речь заходит о динамике, все почему-то берут какой-нибудь популяризированный язык с динамической типизацией, будь то ДжаваСкрипт или тот же питон, и начинают сравнивать его с чистым ФЯ. Это не совсем корректно, мне кажется.
Вот последнее время ковыряю Pure. Это тоже динамика. И его вот уже более корректно с Хаскелем сравнивать. Кстати, expression problem там решен
Re: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
). Вынужден констатировать что воз и поныне там: каждый кулик хвалит свое маленькое болотце, свои маленькие функции, классы, типы или монады, но никто не может охватить полностью (хотя бы приближенно) картину "с высоты птичьего полета" и объяснить как же все эти концепции (ООП, FP, event-driven, ...) увязать между собой построив высокоуровневую (в смысле детализации) архитектуру большой промышленной системы.
Re[3]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вот последнее время ковыряю Pure. Это тоже динамика. И его вот уже более корректно с Хаскелем сравнивать. Кстати, expression problem там решен
Задумайтейсь о том что случится когда Вам надоест "ковырять" и захочется что-то реальное написать. Вы столкнетесь с теми же проблемами что и я. "Ковырял" я довольно долго, лет примерно 8. Теперь хочется применить.
Re[4]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, borisman3, Вы писали:
B>Вот и объясните какой общепринятый способ архитектурного дизайна для функциональных программ. А уж сосредоточиться на задаче — это моя забота.
Так вы объясните саму задачу и используемые технологии; у кого был соответствующий опыт — поделятся Смысл использовать ФП ради использования ФП?
Re[6]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, borisman3, Вы писали:
B>Задумайтейсь о том что случится когда Вам надоест "ковырять" и захочется что-то реальное написать. Вы столкнетесь с теми же проблемами что и я. "Ковырял" я довольно долго, лет примерно 8. Теперь хочется применить.
И за 8 лет вы "не наковыряли" ни одного real world приложения на ФЯ?
Re: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, borisman3, Вы писали:
B>4) У пациента складываетя прочное мнение что FP хорошо на микроуровне, там где модель поведения программы тривиальна либо заранее известна.
Именно. FP рулит внутри метода, ООП — вне.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, borisman3, Вы писали:
S>Так вы объясните саму задачу и используемые технологии; у кого был соответствующий опыт — поделятся Смысл использовать ФП ради использования ФП?
Хорошо, мне хочется разработать обычное трехзвенное веб-приложение. Если бы я применял OOD я уже и без этой информации в точности знал бы с чего начать.
Смысл исполльзования ФП ради ФП состоит в том чтобы на примере научиться пользоваться этой парадигмой, причем желательно в крупном масштабе (не на уровне отдельного модуля).
Re[7]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, Воронков Василий, Вы писали:
ВВ>И за 8 лет вы "не наковыряли" ни одного real world приложения на ФЯ?
Да, это удивительно, но не наковырял. Более того, не наковырял даже проектной документации ни для одного большого рилворлдного ФП приложения. Единственное что мне известно из подобных проектов — это Erlang, но по определенным причинам это не самый удачный пример.
Re[2]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, borisman3, Вы писали:
IT>>Именно. FP рулит внутри метода, ООП — вне. B>А как же все заверения адептов что FP мол надо широко применять как отдельную (от ООП) парадигму ?
Заявлять можно что угодно, никто этого не запрещает. Только какой смысл отказываться от бенефитов которые даёт ООП. Так же нет смысла отказываться от бенефитов ФП. Тем более, что они между собой никак не конфликтуют и великолепно уживаются вместе.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, borisman3, Вы писали:
B>Хорошо, мне хочется разработать обычное трехзвенное веб-приложение. Если бы я применял OOD я уже и без этой информации в точности знал бы с чего начать.
Если неизвестно как сюда прикрутить ФП, не определились с технологиями/фреймворком/языком — зачем тут ФП?
B>Смысл исполльзования ФП ради ФП состоит в том чтобы на примере научиться пользоваться этой парадигмой, причем желательно в крупном масштабе (не на уровне отдельного модуля).
Кмк вы чуть-чуть опередили время ФП пока не мэйнстрим, поэтому привычного "превед! вот тебе фреймворк, вот тру-книжка, вот форум с кучей фанатов, видишь как всё просто!" нет.
Re[7]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, borisman3, Вы писали:
B>>Хорошо, мне хочется разработать обычное трехзвенное веб-приложение. Если бы я применял OOD я уже и без этой информации в точности знал бы с чего начать.
S>Если неизвестно как сюда прикрутить ФП, не определились с технологиями/фреймворком/языком — зачем тут ФП?
Для того, чтобы определиться с фреймворком и языком СНАЧАЛА пишутся архитектурные документы. Т.е. СНАЧАЛА надо хотя бы примерно систему осмыслить и разбить на запчасти, а уж ПОТОМ определяться с тем на каком фреймворке/языке это будет сделано. Теоретически я могу взять на вооружение OOD, разрисовать модули, классы, диаграммы потоков, последовательностей — путь, прямой как палка и пройденный не раз. Но не могу себе представить куда в этом прямом пути уложится FP хоть убей. Для ООП существует разработанная методология, для FP — похоже нихрена не существует, так народ и топчется на уровне отдельных методов (в лучшем случае — модулей).
Re[4]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, lomeo, Вы писали:
L>Я пробовал — длительное время прототипировал в python. Нет у динамики преимуществ, по сравнению со статическими языками, позволяющими так же кратко записывать мысль. Сейчас для прототипирования использую Haskell и Scala.
Я тоже, сейчас стараюсь прототипировать на OCaml, но питон по моему для этого часто лучше подходит, хотя как язык менее выразителен.
FR>>"Огромное" количество тестов в реальных системах оказывается вполне сопоставимым с количеством тестов FR>>для статических языков.
L>Даже для Java с generics не надо писать столько тестов, сколько для python.
Сравнивали уже здесь несколько раз, очень близко получается, вот например нашел:
Просто число тестов специально проверяющих типизацию в более-менее крупных проектах на динамике стремится к нулю,
"обычные" тесты вполне совмещают эту проверку.
FR>>Быстрое мутирование данных как раз проще в динамике за счет того что там эти данные более гибкие.
L>И огребаем кучу проблем, потому что expression problem никуда не девается, а компилятор уже не показывает ошибки Или покажи пример.
тесты показывают
Re[8]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
Здравствуйте, borisman3, Вы писали:
B>Да, это удивительно, но не наковырял. Более того, не наковырял даже проектной документации ни для одного большого рилворлдного ФП приложения. Единственное что мне известно из подобных проектов — это Erlang, но по определенным причинам это не самый удачный пример.
Так используют же многие языки в индустрии, в тех же финансов. В основном ML-семейства. Для Хаскеля, наверное, посложнее будет реал ворлд найти, но тоже встречаются. Мне вот шутер какой-то попадался на Хаскеле.
В действительности ситуация довольно простая. Есть задачи, которые хорошо ложатся на ФП. Если задачу можно представить в виде: данные на входе — цепочка трансформаций — данные на выходе, то это как раз оно и есть. На веб в принципе такая схема неплохо ложится. А есть задачи, которые на ФП не ложатся. Вы их можете попробовать решать на ФЯ, но наверное получится хуже, чем на ООЯ. В большом проекте задач обычно много и разных. Разделяете все на отдельные модули — какие-то можно разрабатывать в рамках ФП, какие-то — с использованием ООП. Ну вот, собственно, и все.
Только это должны быть именно отдельные модули. Мешать ООП и ФП по принципу — снаружи классы, а "мясо" внутри методов на ФП не стоит. Вообще такие советы, мне кажется, происходят из-за банального непонимания того, что есть ФП.
Re[3]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
неплохой пример ФП дизайна на Эрланге.
B>Там описан пример решения маленькой задачи с строго определенным входом, строго определенным выходом и без внутреннего состояния. Это совершенно никак не похоже на крупномасштабные (ну ладно уж крупномасштабные, даже просто среднемасштабные) проекты в которых внутренее состояние системы является значимым.
Ну грязь там есть в виде IO и она изолирована в отдельный модуль.
Ну и там вполне продемонстрировано то, что применяется и при декомпозиции больших программ: модульность, абстрактные типы данных,
функциональные интерфейсы. Да все это взято из модульного структурного программирования, как и в случае ООД/ООП.
Re[4]: OOD vs SA/SD (ну или OO vs FP раз уж на то пошло)
B>Это хорошие, верные, но слишком общие слова. Мне такжке следует разрабатывать хорошие программы. И вообще, правильно жить.
Нет не общие слова, а один из базовых паттернов, во всяком случае в строгих гибридных ФЯ.
Основная масса программы должна быть функционально чистой, вся грязь изолироваться в небольших отдельных
модулях/функциях.