Нужно ли функциональное программирование вообще?

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

Нужность определяется субъективно для каждого, для вас, видимо, не нужно, ибо вы уже задаётесь этим вопросом. ФП есть, и своим фактом существования доказывает, что хотя бы одному человеку нужно. Когда оно вам понадобится, вы этим вопросом уже не задатитесь.

Сосёт любой частный подход, любая отдельно взятая парадигма. Не сосёт только их разумный выбор - каждой задаче свою парадигму. Одни задачи адекватно решаются только в рамках ФП, другим нужен ООП, третьи вообще только как FSM или dataflow формулируются, четвёртым нужна логика высших порядков. Если пытаться всё засунуть в одну парадигму, то получается жидкий кал с пузырьками.

>Одни задачи адекватно решаются только в рамках ФП,

Перечисли. В статье http://www.cs.utexas.edu/~arvindn/hughes/ как раз и говорится о том, что все функциональные фишки легко реализуются в Java и C#, нужно только приложить голову

Если приложить голову черты функциональных языков легко реализуются на ассемблере. Мысль понятна?

> Перечисли.

Например, простейший же компилятор - от парсера получаем AST, делаем пару-тройку проходов преобразования и выдаём ассемблерный код. На убогих недоязычках (Java, C#) придётся на каждый узел AST по классу заводить, рисовать страшенный и огромных размеров visitor, строго следуя дебильному GoFскому паттёрну, и всё это получится совершенно потом нечитабельным и неподдерживаемым - добавишь новый узел в AST, и хрен потом найдёшь все места, где его ещё упомянуть нужно. Совсем другое дело - функциональный язык с алгебраическими типами данных или же метаязык вроде Схемы - всё делается просто, коротко, изящно, и поймёт этот код даже тот, кто с языком не знаком.

А так - статья - говно. Я то же самое могу и про brainfuck написать, и про ассемблер x86.

> нужно только приложить голову

Есть гораздо более важные приложения для головы, чем тупая кодерёжка. Голову надо прикладывать при проектировании, а тратить силы и время на кодирование на столь многословных и write only языках - это для обезьянок. Умный человек таким бредом заниматься не станет.

> все функциональные фишки легко реализуются в Java и C#

гыргыргыр! Приведи-ка ооп веб-фреймворк, который хотя бы не сильно уступал бы uncommon web'у http://common-lisp.net/project/ucw/features.html

Кстати, статья вообще абсолютно быдловская и тупая. Я могу все тезисы быдлоавтора написать в одну строчку:

"Все функциональные и объектно-ориентированные языки общего назначения являются Тьюринг-полными."

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

> Приведи-ка ооп веб-фреймворк, который хотя бы не сильно уступал бы uncommon web'у http://common-lisp.net/project/ucw/features.html

например, http://seaside.st/, под впечатлением которого UCW и был написан.

> все функциональные фишки легко реализуются в Java и C#,

И тогда из элегантных методов ФП получаются монструозный boost, синтаксический мусор из анонимных классов в Java, visitor pattern итд.

похоже на какой-то развод. аффтар то-ли юморист, то-ли нлп'шник. утверждает что фп суксь, а рулит ооп, при этом приводя примеры и оговорки, которые показывают фактически обратное. %)

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

Но вот насчет uncommonWeb интересно пообщаться. У меня есть стойкое впечатление, что Рельсы(MVC) на неаяксовских задачах будут полаконичнее continuation-based решений.

Кроме того, считаю, что решение, когда шаблоны пишутся на схеме добавляют лишнюю работу. Например присылает верстальщик шаблон. В рельсах раскидываю управляющие конструкции по шаблону и не морочу колову с переводом его в Лисп-нотацию.

Потом синтаксис Лиспа хоть и является более гибким, в данном случае не дает преимущества, потому что Руби с удачной ООП моделью отлично ложится на такую задачу.

> В рельсах раскидываю управляющие конструкции по шаблону и не морочу колову с переводом его в Лисп-нотацию.

А я и в siscweb не заморачиваюсь - у меня макра есть, которая XHTML читает в Схемский код. И управляющие конструкции сколь угодно разнообразные втыкаются элементарно. В результате всё получается сугубо декларативно, никакого лишнего кода, но с другой стороны и предельно контроллируемо, я не ставлю себя в зависимость от разработчиков Рельсов а могу легко и непринуждённо эти свои макры расширить, благо язык для их описания сам тоже декларативный и очень простой.

> У меня есть стойкое впечатление, что Рельсы(MVC) на неаяксовских задачах будут полаконичнее continuation-based решений.

Почему, интересно? С рельсами я практически не знаком. В ucw особой разницы с точки зрения кодера между аяксовыми и неаяксовыми практически нету, только в неаяксовых вид урл может быть довольно уродливым.

> Кроме того, считаю, что решение, когда шаблоны пишутся на схеме добавляют лишнюю работу. Например присылает верстальщик шаблон. В рельсах раскидываю управляющие конструкции по шаблону и не морочу колову с переводом его в Лисп-нотацию.

Здесь я согласен с предыдущим оратором, кроме того, ИМХО верстальщик должен присобачивать css к готовому коду, и не вмешиваться в нутро самого хтмла. Выгода же от производства хтмл кода из шаблонов на ЯП вместо использования шаблонов весьма велика. Ибо при генерации хтмл можно использовать всю мощь ТП языка ничего при этом не теряя. Ну и зверинца из разных языков и шаблонов не появляется, что тоже неплохо.

> Потом синтаксис Лиспа хоть и является более гибким, в данном случае не дает преимущества, потому что Руби с удачной ООП моделью отлично ложится на такую задачу.

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

>я не ставлю себя в зависимость от разработчиков Рельсов а могу легко и непринуждённо эти свои макры расширить, благо язык для их описания сам тоже декларативный и очень простой

здесь разницы никакой имхо. Хотите расширить рельсы - пожалуйста, хотите писать на другом языке шаблонов - вот, выбирайте из существующих или напишите что-то свое. Ну, а для тех, кто любит писать на самом ЯП, дизайнерам доверяя только css, очень подходит markaby. Плюс, если рельс слишком много для поставленной задачи, можно взять тот же camping - там все тоже на компонентах построено.

Со statefull web-frameworks, которые на continuations построены, конечно все очень красиво и интересно. Такой уровень абстракции, разработчикам о сессиях думать не надо, все такое. Но, имхо, строить абстракцию statefull на базе stateless протокола ( http ) - это где-то то же,что и пудрой прыщи замазывать.

Есть существенная разница - прыщи можно вывести, да и сами пройдут неизбежно, а вот этот ссаный http никуда не денется, он тут, чтобы остаться навсегда. Так что это уродство приходится хоть чем-то стыдливо прикрывать.