Почти год просидел на Erlang. Писали (и пишем сейчас) платформу для обслуживания социальной функциональности в наших приложениях. Не первый год с Erlang, но опыта набрались много. Рассказали об этом на конфе, слайды можно найти здесь — goo.gl/BYoJx2 (там больше подробностей о предметной области и разработке). В команде 2 человека пишут на Erlang (возможно скоро будет 3). Приложение уже очень большое (!). Разрабатывали как в книжках пишут: быстрый beta-прототип (запущенный и работающий), потом полноценное приложение, production release и суппорт, сейчас очень активно развиваем функционал.

«Почти год» — потому что часть времени пишу на Clojure. Использую на том же проекте, но для другой серверной задачи. Впервый попробовал ClojureScript (с самим Clojure работаю уже более 2х лет). Очень доволен: архитектурой, кодом, скоростью разработки. В текущем году обязательно расскажу и об этом опыте на какой-нибудь из предстоящих конференций.

По мелочам:
* Читал курсы по Erlang, — много, догло и с домашними заданиями. Заинтересованных много. Подумываю в этом году повторить.
* Принял участие в разработке компилятора языка Elm (на Haskell).
* Ровно год назад сделал библиотеку Fn.py «Functional programming in Python: implementation of missing features to enjoy FP» (goo.gl/9f7vXG) — народу вроде как понравилось.
* Прочитал 11 докладов о функциональном программировании и смежных областях (список здесь kachayev.github.io/talks ).
* Изучил Racket, прочитал несколько новых книг по FP.
* Посидел со Scala, делая домашки для курса «Reactive programming» — еще раз убедился, что не хочу возвращаться на Scala (мое личное мнение, не обращайте внимания, если вам нравится).
* Поковырялся с Elixir, попытался немного креативно поэкспериментировать, но дальше креатива не пошел (goo.gl/EnrrF4 ).

Помню как-то на fprog в Харькове обсуждался этот вопрос. Тогда сошлись на том, что «функциональный язык это тот язык, который набрался наглости назвать себя функциональным». Есть четкое определение «функционального программирования». Идеально функциональный язык, только lambda calculus в чистом виде. Все практические имплементации — под вопросом.

На сколько я знаю лиспы, то в Common Lisp / Scheme точно есть много не функциональных вещей. Вроде как «самым функциональным» получается Haskell, потому что явное отделение чистого кода от side effects.

Предположу, что GSM маршрутизатор, наверное зафиксирован каким-то протоколом лет на десять.

Если бы...

Расскажите, пожалуйста про проект на ФЯ для реального мира.

Приходите на Kyiv FProg следующий — как раз буду рассказывать о нашем опыте.

В общем, сочту этот комментарий больше стебом, чем реальной заинтересованность. Так как гуглится без проблем. Посмотрите на компании, пользующиеся Clojure (на вскидку в голову приходит Prismatic, Relevance). По Erlang список получиться тоже не сложно (Amazon, Whatsapp, Heroku, Github, Velti, Echo, Bugsense и др). Погуглите использование Scala / Clojure / Haskell в Twitter / Facebook / Yammer / тд

В замечательных, сказочных ФЯ можно скормить собакам не только еду, но и упряжку и самого Беллью, а если покруче завернуть, то и всё белое безмолвие.

Это о системе типизации. Совершенно ортогонально обсуждаемому. При этом адекватные системы типизации — как раз таки удел современных ФЯ. (ну если не брать Scala, но и там Java-наследия хватает с ее кастами).

Но как только заказчики приходят из реального мира (Hello, real World!), а не из задачника по математическим олимпиадам, то знание паттернов и ООП резко увеличивает шансы на успешное завершение проекта.

Суровый вброс. Руслан Шевченко писал недавно здесь статью по поводу иллюзионной очевидности мейнстрима. Пишут в реальном мире на ФЯ, нормальные real world проекты (могу это гарантировать личным опытом). Зависимость успешности проекта от применения или не применения ООП никем еще не доказана.

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

Lambda calculus VS. turing machine — вычислительные системы. Декларативное и императивное программирование — формализированные концептуальные подходы, базирующиеся на соответствующей вычислительной моделе (моделях). ООП — некая императивная парадигма, попытка навести порядок (одна из многих, вряд ли самая удачная).

Можно сравнивать ООП c F-coalgebra, или с ADT (с existential types) или даже с System-F (в разрезе records + subtype / parametric polymorphism). Но этого никто не делает.

ФП против ООП

Не вижу смысла в такой баталии, в принципе. Есть смысл сравнивать функциональный и императивный подход. Или еще лучше — декларативное программирование (ФП как частный случай) и императивное программирование. ФП vs. ООП — это разные «весовые категории».

От только у вас такое же понимание паттернов как и у тех кто требует цитирования ГоФ

По фотографии диагностируете?

И снова все та же сказка про 3 кита и объекты которые описывают реальный мир.

Никакой связи не вижу.

мутирующие объекты

Если у вас объекты не мутируют, то значит не имеют своего «поведения», потому что поведение будет определятся явной передачей состояния в метод (значит простую функцию) и не может по разному реагировать на сообщения от других объектов (читай, детерминирован). Т.е. у вас остаются values в чистом виде и (возможно) список функций (вполне возможно) с partial application на первый аргумент. И фокус с наследованием здесь уже не пройдет. В чем тогда ООП-шность?

Да чушь собачья.

Банда четырех паттерны не выдумала, а описала и систематизировала. Поэтому до них писали код с теми же паттернами (местами лучше, местами хуже) — просто не знали как это все называется.

in-place mutability

возможность поменять значение по адресу памяти / указателю / названию property класса или даже set-методу (все описаное все равно сводится к пункту один). антоним immutability.

Описанная проблема с «заучиванием и цитированием» GoF упирается в тот факт, что без паттернов писать на «ООП» невозможно. Чем больше хотите написать, тем больше вам нужно паттернов. Поэтому об этом целые книги написаны. Почему так получилось?

Началось все давно — с простой идеи отказаться от оператора goto. Процесс отказа достаточно затянулся (было много адептов старого подхода), но в итоге это привнесло в программирование такую замечательную штуку как «модульность». Теперь код __нужно__ разделять на куски для переиспользования, и у нас для этого уже есть много подходов: функции / процедуры / модули / пакеты / сопрограммы / классы / тд. Разделять код оказалось просто, главное было начать.

Но затем стал другой вопрос: как разделенный код собрать в приложение? Тут появляется понятие composatibility, и подчеркну — именно composability (т.е. возможно __просто__ связать несколько участков кода в один) и есть ключевым вопросом, который в общем случае не так просто решить. Первый миф ООП, главное — разделить код на правильные куски, не верьте — главное суметь потом это собрать.

Composability функций очень высока, кроме side-effects случаев, отсюда исходит мощь и сила ФП. У классов в ООП — практически нулевая. И с «философской» точки зрения, и с чисто технической. Скрытый state внутри объекта, in-place mutability — худшее, что можно придумать с точки зрения попыток соединить два участка кода (под словом «соединить» можете читать также «протестировать», «перенести», «реиспользовать», «заменить»). Отсюда и появляются все эти паттерны, потому что объекты изначально «недружные» друг к другу нужно как-то уживать.

Вот есть у вас Еда и Собака. Может ли Еда скормиться Собаке? Или Собака может Еду съесть? Или нужен Человек, который Собаку накормит Едой? И где хранить информацию о том, что Еда может быть Съедена, а Собака Накормлена? Чем дальше в лес — тем злее дятлы. Тем толще книги о паттернах. И тем дальше вы от сути ситуации «еда −10, сытость +5».

Хотите разобраться в ООП — учите Haskell, или еще лучше ML (но на нем никто не пишет, поэтому будет скучновато). Посмотрите Camp/OCaml.