When FP sucks?

В любом практически существующем проекте? :]

мы ждали вас К.О.

>В любом практически существующем проекте? :]

Логику существующих проектов можно хоть как-то понять если сразу читать SQL спрятанный за тупые ООП-layer'ы с ненужной перефасовкой данных.

> When FP sucks?

Откуда такая ненависть к родному языку, помноженная на незнание языка
чужого?

( Мы не про ФП сейчас говорим. )

> Логику существующих проектов можно хоть как-то понять если сразу читать SQL спрятанный за тупые ООП-layer'ы с ненужной перефасовкой данных.

+1. Хоть как-то разобраться в каком-нить говне типа Битрикса реально только взглянув на то, как демка лежит в БД.

> если сразу читать SQL

да-да, все проекты пишутся на SQL

> А где (в каких областях, классах задач) чистое functional programming хуже (код получается менее читаемым, более длинным и запутанным, при меньшей или схожей производительности), чем императивщина или ООП?

Прочти мотивацию к создаению DDC на Haskell wiki, там это политкорректно изложено. Вроде это 1. некоммутируемость монад 2. необходимость писать "монадический" map, отличающийся от обычного

Кроме того, от себя добавлю: иногда требуется ослабленный вариант "функциональности", например "без лени" (результат не зависит от порядка вызова функций, но меняется, если функцию вызвать лишний раз или не вызвать вообще). Такой ослабленный вариант функциональности может быть реализован явно не функционально, например используя global_variable++ (точнее, atomic_inc).

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

Это зависит сильно от читателя. Многим вот ООП-месиво кажется естественным и отлично читаемым (см. тред о ScalaQL). Для других императивная лапша с кучей временных переменных - самое естественное выражение мыслей. Для математиков же, например, функциональный стиль более естественен. Я встречал людей, которые долго не могли въехать, как это может быть: i = i+1. Так что, кому как...

Ну как бы чистое ФП по умолчанию stateless. Что бы хранить состояния нужно придумывать костыли. Да и сайд-эффекты как-то вкрутить в "чистый" код. В общем если приходиться много работать с состояниями и с нечистым кодом фп код становится похож на какашку.

>Я встречал людей, которые долго не могли въехать, как это может быть: i = i+1

Дык чего ж тут непонятного, результат выражения FALSE=) Привет прологфагам и всем другим противникам destructive assigment.

Смотрим на Erlang, и на то как там реализованы состояния... ;)

>Смотрим на Erlang, и на то как там реализованы состояния... ;)

Дык он же не чисто-функциональный. Я так понимаю присваивание (т.е. сохраниене состояния) через пересылку сообщений реализуется? Выходит, что посылка сообщения это сайд эффект. Тоже мне ФП...

> Дык чего ж тут непонятного, результат выражения FALSE=)

да ладно.. inf -- это валидное значение для float i;

> Кроме того, от себя добавлю: иногда требуется ослабленный вариант "функциональности", например "без лени"

Функциональность - это y = f(x), и никаких сайд-эффектов. Про ленивость в f ничего не сказано.

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

на самом деле ты сам того не хотя описал message passing программирование. наличие процесса - это уже состояние.

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

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