как нужно программировать в функциональном стиле

Не нужно программировать в функциональном стиле.

Например вот так задача решается в ООП стиле, а так в ФП

Тебе факториал и числа Фибоначчи нужны, что ли? Никаких других задач ФП не решает.

Просто не меняй значения переменных.

Ты так спрашиваешь, как будто ООПешники это такие существа которые способны понимать только информацию специально подготовленную их пораженных ООП мозгов.

Не знаю таких спецефичных книг, что бы прямо вся книга на них строится. Но в частности в многих книгах по хаскеллу иногда делаются, такие отсылки/аналогии к ООП, типо «класс в хаскелле это что-то вроде интерфейса в Java, но не совсем», или «Линзы это такие геттеры/сеттеры на стероидах».

Тут разные парадигмы. Нет смысла обучать функциональщине на основе ООП. Оно и так тебе будет мозги ломать, а ты еще хочешь пытаться связать это с ООП.

В целом могу посоветовать ohaskell.ru

Начни с использования функций вроде map, filter, reduce и так далее, а там втянешься.

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

!=

Просто не меняй значения переменных.

Сначала откажись от использования оператора присваивания, ну а потом и всё остальное подтянется само собой.

Изучай OCaml - готовый ООЯФП.

Можешь посмотреть книгу http://www.amazon.com/Functional-Programming-Patterns-Scala-Clojure/dp/193778...

В целом могу посоветовать ohaskell.ru

Душкин-tier.

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

http://www.cs.helsinki.fi/u/tpkarkka/alglib/k06/lectures/algorithms.html

учи эрланг.

Вы так говорите, будто ООП это что-то плохое и его надо заменить ФП. ООПу - оопово, ФП - фпово.

Начни с использования функций вроде map, filter, reduce и так далее, а там втянешься.

И будет у тебя ООП с удобной работой над коллекциями. А вот где же это ФП так и не поймёшь.

Если вкратце - в ООП у тебя некоторое состояние инкапсулировано в объекте - его внутренние переменные и внешние методы доступа; в ФП то же состояние является результатом выполнения некоторой функции.

ООП головного мозга так же плохо как ФП головного мозга.

Ну согласен. Поэтому и написал, что ООП методом надо решать задачи где ООП более всего подходит, а методом ФП там, где ФП более всего подходит. И с такой позиции странно видеть книжку, типа, в ООП так, а в ФП так. Хотя, если рассматривать, типа, тут в ООП эффективно, а ФП нет, а тут, наоборот, ООП неэффективно, а ФП да.

zinfandel пишет:

пораженных ООП мозгов.

Именно так я себя и чувствую, мозг закостенел в ООП так, что посмотрев на что то иное под ногами ощущаешь лишь зыбкое болото, смена парадигмы должна пройти как то помягче что ли. Что ФП предлагает взамен наследованию, инкапсуляции, полиморфизму? В чём мощь ФП? Как формализовать предметную область решения проблемы не в стиле ООП?

Спасибо за ссылки кстати.

Что ФП предлагает взамен наследованию, инкапсуляции, полиморфизму?

Ничего.

Ненужное динамическое поделие. Отсутствующая функциональная чистота, убогие гарды, убогая производительность, общая непредсказуемость, let it crash = bullshit.

Typical Erlang code (я вроде не нарушаю NDA, т.к. этот перл был, предположительно, скопипащен из какой-то говностатьи)

counter() ->
  receive
    {counter, N} ->
       self()!{counter, N+1},
       N;
    after 0 ->
       self()!{counter, 1},
       0
     end
  end.

...
lists:foreach(fun(A) -> {A, counter()} end, Blah)

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

Ну, для тебя может и typical, чо.

В чём мощь ФП?

В факториалах и числах фибоначчи.

Как формализовать предметную область решения проблемы не в стиле ООП?

Если проблема - не факториал и не числа фибоначчи, то никак.

Это не мой код, Шерлок.

Ах да, забыл сказать, что модель акторов в целом = зло, которое может работать только во влажных фантазиях теоретиков и в презентациях.

просто почитай темы на лоре по тегу фп и подобным. не срачи, а технические вопросы. таких примерно процентов 20, но всё же

Мощь ФП подхода проявляется когда ты перестаёшь держать в голове что-то типа: «так, а тут у меня итераторы могут протухнуть из-за изменения коллекции...»

И да, поскольку большинство функций в итоге получаются «чистыми», их комбинировать между собой становится легко, не надо думать что, кто, где сломает. А то, что не «чистое», лежит себе отдельно и ВНЕЗАПНО не вылезает.

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

Я для себя из тыкания палочкой тех же erlang и haskell кое-чего вынес и использую при написании кода на си, плюсах и прочих питонах.

что модель акторов в целом = зло,

Фу фу фу. Какое громкое слово - «зло»! Если каждую тупую бредятину называть «злом», то это очень быстро девальвирует значение настоящего, чистого Зла.

sicp уже советовали? потом ansi common lisp, главу про clos внимательно.

Ах да, забыл сказать, что модель акторов в целом = зло, которое может работать только во влажных фантазиях теоретиков и в презентациях.

Адепт csp?

Что ФП предлагает взамен наследованию, инкапсуляции, полиморфизму?

Ничего.

4.2

sicp уже советовали?

Еще нет, посоветую я: http://www.youtube.com/watch?v=a2Qt9uxhNSM http://www.youtube.com/watch?v=DCub3iqteuI

А что есть юзабельного и чисто функционального кроме Haskell, Clean и Mercury?

так задача решается в ООП стиле, а так в ФП

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

Скорее STM.

SICP уже читал?

По CLOS лучше Sonya Keene почитать.

Юзабельного и чисто функционального ничего нет.

Начни с использования функций вроде map, filter, reduce и так далее, а там втянешься.

Да это даже в жабе есть.

Я бы на примере Лиспа начал изучать функциональное программирование (или Scheme, или Clojure). Practical Common Lisp (http://www.gigamonkeys.com/book/) очень хорошая (и безплатная) книжка.

обычный быдлокод неосиляторов

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

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

Именно так я себя и чувствую, мозг закостенел в ООП так, что посмотрев на что то иное под ногами ощущаешь лишь зыбкое болото, смена парадигмы должна пройти как то помягче что ли. Что ФП предлагает взамен наследованию, инкапсуляции, полиморфизму? В чём мощь ФП? Как формализовать предметную область решения проблемы не в стиле ООП?

Начни с ООЯФП, будут тебе и объекты, и ФП, и их комбинирование.

Что ФП предлагает взамен наследованию, инкапсуляции, полиморфизму?

То же, что и ООП. Да-да, это все не есть исключительные свойства ООП.

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

Просто на данный момент методики ООП вколочены в некие рамки (паттерны-хренаторны), а ФПой никто не занимался в этом плане и у него этакий «флер» образовался раздолбайско-нонконформистский.

Ну и, сегодня ты не найдешь чистых ООП-ФП ни в жабо/сисярпо-проектах, ни в хаскеле. и это правильно.

Т.е. писать на функциональном языке в ООП стиле или смешанном с ним это нормально?

В общем пока вот что нашел: Functional Programming for the Object-Oriented Programmer

----------------------------------------------

В книге П.Хендерсон - Функциональное программирование. Применение и реализация посвящена целая глава 5 Соответствия между функциональными и императивными программами, в особенности подразделы

5.2 Функциональные эквиваленты императивных программ

5.3 Преобразование императивных программ в функциональные

---------------------------------------------------

В книге Роганова Н.А. Функциональное программирование: Учебное пособие для студентов высших учебных заведений - М.: ГИНФО посвящена целая глава «Глава VII Haskell как язык ООП», что весьма меня удивило, ведь хаскелл позиционируют как чисто функциональный язык.

--------------------------------------------------

Так же статья Джон Хьюз Сильные стороны функционального программирования где проводится аналогия со структурным программированием.

Ну вот почему фп-хетеры всегда требуют «что-нибудь чистаа фп»? Чем вам жабка-то не фп?

Что ФП предлагает взамен наследованию, инкапсуляции, полиморфизму?

Ну, хорошо. Если говорить о Haskell, то мой ответ будет таким.

Инкапсуляция есть из-коробки. Разруливается на уровне задаваемого списка экспорта из модуля. Мы можем явно сказать, что все внутренности модуля не экспортируются, а потому никому более не видны. Есть и трюки, которые позволяют создать внутренний скрытый и внешний модули. Наружу будет виден внешний модуль с обрезанным списком экспорта, а внутренний модуль будет доступен тем, кому надо внутри твоей программы/библиотеки. Внешний модуль будет просто реэкспортировать нужные сущности. Реэкспорт в Haskell - один из лучших виденных мною.

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

С наследованием не все так просто. Есть зависимости классов типов, но «классы типов» - это совсем не то, что обычно понимается в ООП под «типами классов».

К слову сказать, в первых версиях Smalltalk не было наследования типов классов. И очень часто наследование особо и не нужно, но по-разному бывает.

http://www.amazon.com/Functional-Programming-Classic-Techniques-Projects/dp/0...

http://www.amazon.com/Functional-Programming-Java-Developers-Concurrency/dp/1...

А теперь назови две причины, по которым этот кусок кода не работает.

Тут дело даже не в том, что люди не осилили fold или list comprehensions и даже, не к ночи будь помянут, process dictionary.

Тут раскрыта фундаментальная проблема акторов: message passing не становится простым, надёжным и предсказуемым, если обернуть его в красивый синтаксис.

Idris, Coq.

Idris и Coq — не general-purpose штуковины. И идрис пока сложно назвать полноценно юзабельным :)