GC — чего обидного-то? Абстракция GC часто протекает (как и другие абстракции).
А вы меньше слушайте фанатиков. Фанатики по обе стороны ебанутые. Тем не менее, их фанатичность и упорство приводит к тому, что они вылизывают некоторые концепции. Результатами их труда можно пользоваться вне оригинальных рамок.
Я не вижу особого смысла в задрачивании на чистое ФП вне академических областей. В практической области можно и нужно подбирать инструменты под задачу. Цель ведь создать что-то полезное, а не писать код ради кода.
Или вы считаете, что для защиты ФП нужно упарываться концепцией по самые гланды?
Кстати. LISPы же всегда славились своей практичностью. Они ориентированы на иммутабельность+ФП, но дают возможность писать код и в императивном стиле, и в ООП. Вопрос: вы пользовались этой возможностью или оставались в рамках полной чистоты?
А основая фича ФП — решить задачу ясно и малым количеством строк кода. Естественно, это не будет идеально подходить для всех нужд. И соответственно, си и фп друг на друга довольно плохо натягиваются.
Или вас смущает существование областей, в которых не нужно выдрачивать код?
Во, это уже больше похоже на дельный разговор. Вы уже делитесь своими задачами, вашим контекстом.
Давайте я уточню получше область, где ФП лучше не применять.
Задачи, в которых мы упираемся в ЦПУ — вот здесь лучше не лезть со всякой шнягой типа ФП, GC и прочим. Так, к примеру, в C# большинство людей понимают, что простое переписывание LINQ на foreach может дать 2x-4x в производительности.
Но только не везде эта производительность нужна. А вот выразительность нужна везде. ФП дает выразительность в некоторых задачах. Но это не zero-cost абстракция. Она имеет цену. Когда у вас накладные расходы на ФП достоточно малы для вас, то заменять ФП на что-то другое будет микрооптимизацией.
И я как-бы очень рад, что у вас есть performance critical задачи. Но есть куча областей, где их нет. Если для ваших задач что-то не подходит, то это не значит, что это что-то является бесполезной хуетой. То, что вы не видите задач, где ФП рулит скорее всего следство вашей специализации на performance critical задачах.
Теперь, о том, как мне помогает ФП. Задачи трансформации/обработки данных очень легко выражаются через map/filter/flatMap/toDictionary и тому подобное. И императивный код зачастую у меня занимает больше строк и менее понятен, чем ФП-подобный. Если я вижу проседание производительности из-за неэффективности ФП, то я делаю фоллбек на более низкий уровень.
И дополнительно: я не использую ФП как клей в масштабе всего проекта. У меня ФП является локальной оптимизацией выразительности, которая помогает сжать кучу кода до понимаемых размеров.
Соответственно, если снять с ваших примеров ограничения по performance, то ФП может рулить и бибикать за счет выразительности. Но в вашем случае это недоступно. Это не значит, что инструмент плохой. Он не подходит под вашу задачу.
В чем проблема-то? Вы же не хотите сказать, что в языке незаточенном под ФП так же легко работать с функциями как в языке заточенном под ФП? (Я подразумеваю, что вы знаете, что и в C, и в C++ можно передавать ссылки на функции, иначе было бы вообще глупо). Или вас смущает отсылка к C, а не к современным C++, в котором более-менее зарождается ФП?
А со штампами в чем проблема? Если аргументация типичная, но корректная, то это збс аргументация, нет?
Ваш пример легко допускается вне зависимости от парадигмы. Достаточно нанять идиота. А идиоту хоть золотой микроскоп суй, он все вокруг раздолбает.
Давайте какую-нибудь реальную задачу. Не связанную с системным программированием, ибо там ФП пока что не очень осмысленно применять. Потому что абстрактными примерами можно спорить хоть до скону веков.
Гм. Вы умудряетесь спорить о вещах, о которых не имеете ни малейшего понятия.
Во-первых, ООП не может быть следующей ступенью ФП, потому что «объекты — замыкания для бедных, замыкания — это объекты для бедных». Задание «написать свое ООП» является вводным для многих курсов по ФП.
Во-вторых, ваша идея о том, что процедурное программирование == функциональному страдает двумя болячками. Болячка первая: в ФП как-ни странно не функции, а замыкания (функция + захват переменных). Без замыканий, на чистых функциях нельзя получить мощь аналогичную ООП. Болячка вторая: процедуры нельзя легко передавать в другие процедуры. Что делает невозможным high-order functions. А high-order functions позволяют выразить как минимум 1/3 (мне лень считать) паттернов GoF. То, что вы в старом добром С могли передать ссылку на метод — это неудобная ерунда, которая убивает легкость ФП.
В-третьих, ООП и ФП можно смешивать, они не мешают друг другу на самом деле (если не вдаваться в экстремизм). Поэтому ООП и ФП реально таки являются параллельными ветками развития.
Почему возник хайп вокруг ФП? То, что вы видите в мейнстриме — это не хайп. Это уже опробованные инструменты, которые перетекли из академичных разработок в практичные сферы. Просто ФП позволяет некоторые задачи решать проще (но некоторые на нем решаются сложнее).
+