Функциональная парадигма

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

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

А лог с помощью

import Debug.Trace

sum :: (Num t, Show t) => t -> t -> t
sum a b = traceShow res $ res
          where res = a + b

я в курсе, про лямбды, паттерн матчинг

использую это в коде на C++

Кончай врать, в C++ нет паттерн-матчинга.

А зачем применять её целиком? Юзай там, где легко ложится, чтобы быть уверенным, что часть кода состоит из «чистых» функций и не заботит тебя более, остальное пиши в любимом стиле.

Функциональные языки нужны не больше, чем ООП в чистом виде, иначе бы не плодились static методы в ООП.

https://wiki.haskell.org/All_About_Monads#The_Writer_monad

о-о-пе это инкапсуляция, сокрытие состояния. А наличие состояния — это главное препятствие для concurrency. Особенно если оно где-то скрыто и ты не знаешь, что может привести к data race.

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

Поэтому о-о-пе сакс.

Сакс те, кто мечтает о волшебной пилюле, которая за тебя напишет многопоточный код. В реальности, нужна производительность - залезай вглубь и чем глубже к аппаратуре тебе даст приблизиться твое окружение - тем быстрее сможешь сделать свой софт. А если производительность не особо нужна - то конкурентность на основе GIL рулит.

Это бред. Читай Actor Model — это реально Ъ-конкурентная модель.

Ща тебе местные фанаты эрланга расскажут, что есть только одна тру Actor Model - та, которая в эрланге. Остальные, как тут говорят, сакс.

cast eao197

Если рассматривать настоящее ООП, а не эту помойку, типа жабы, то это чуть ли не синонимы, на Хьюитта сильно повлияли идеи Кея, а первые версии смоллтока, в свою очередь, были реальной имплементацией модели акторов.

ты про состояния говорил, а не про ООП, кстати

Ну, это решит проблему с логированием. А, если, допустим, другая проблема, есть длинная цепочка вызовов, и понадобилось в функции заюзать значение из конфига? В хаскеле нужно будет переколбасить вызовы, чтобы передать это значение, когда в других языках, где нет требования, чтобы все функции были чистыми, можно просто заюзать глобальную переменную или паттерн singleton/registry.

Не спорю. message passing это очень конкурентно. А о-о-пе — нет.

А вот я поспорю. message passing идет через, как минимум, кеш L2, а прямой вызов функции через регистры и L1. Так что параллелить код он сильно упрощает, но привносит серьезные накладные расходы. Поэтому использовать его нужно аккуратно (т.е. там, где требуется распараллеливание, но не для разбиения программы на функциональные блоки).

О, это жуть, да.

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

Кончай врать, в C++ нет паттерн-матчинга.

Спорим на 5 копеек, что шаблоны в C++ - это функциональщина с паттерн матчингом и иммутабельностью?

А зачем применять её целиком? Юзай там, где легко ложится, чтобы быть уверенным, что часть кода состоит из «чистых» функций и не заботит тебя более, остальное пиши в любимом стиле.

Ты сейчас описал большинство практичных мультипарадигменных языков начиная с C++, Java, Python, в которые перетаскивают полезные возможности из других языков.

Функциональные языки нужны не больше, чем ООП в чистом виде, иначе бы не плодились static методы в ООП.

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

Очень сложно чем-то изуродовать код на Java.

на скалу посмотри

А о-о-пе — нет.

Прочитайте про SCOOP в Eiffel. Бертранд Мейер с вами вряд ли согласиться.

Есть ощущение, что portquest2016 — это очередное воплощение anonimous-а. Так что без меня.

Есть ощущение, что portquest2016 — это очередное воплощение anonimous-а. Так что без меня.

О! :-) А как же прокачка скила в общении с неадекватами? :-)

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

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

Что-то в последнее время начали хайпить функциональное программирование.

Шутишь? С ним носятся лет 15 уже, не меньше. И ни один из мощщщных язычков так и не вылез в массы. Даже гибридная скала толком не взлетела, а сколько было энтузазизма среди борщехлебов.

Формочкоклепание оставь себе. Я про лупы говорю. Ясные и понятные. Вместо map.reduce.hujuce(x -> x.element {}$#@@#$ raz raz i <-()();;=v production!)));;{

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

лупы
Ясные и понятные.

http://sean-parent.stlab.cc/presentations/2013-09-11-cpp-seasoning/cpp-season...

Ты это ... объясняй, он меня отправляет про акторы читать, чтобы убедить в том, что ООП не препятствует конкурентности.

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

и пример тому тот же pony lang

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

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

Не тому ответил, кажется мне ты?

Спок, я всё вижу.

Ну так и норм. Чистота нужна учебным языкам. Считай Haskell - это Basic мира фп.

Не удержался.

Не тому ответил, кажется мне ты?

да, как-то умудрился промахнуться.

А вот я поспорю. message passing идет через, как минимум, кеш L2, а прямой вызов функции через регистры и L1

На чём основано это феерическое обобщение?

Чистота нужна учебным языкам.

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

Эммм, я думал тут всем очевидно, что чистота, иммутабельность и т.п. ортогональны функциональности языка. Да, приходим к основному вопросу философии - что есть ФП? Сравните Common Lisp с Haskell. Ах, первый - не функциональный, говорите? Тогда критерии в студию. Для меня - если функции объекты первого класса - то уже функциональный. Безо всяких упоминаний типизаций, АТД, чистоты, иммутабельности, каррирования и т.п.

Даже ты обманываешь, ибо их нет вообще.

Для меня - если функции объекты первого класса - то уже функциональный

А что для тебя «первого класса»?

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

возможность генерировать новые значения этого типа в качестве возвращаемого значения функций

Это автоматически подразумевает карринг.

Это автоматически подразумевает карринг.

Нет.

калечили мозги процедуральщиной начиная со школы, перелез на функциональщину моментально, как-то сразу легло (легче, чем с ООП, кстати)

возможность генерировать новые значения этого типа в качестве возвращаемого значения функций

Это автоматически подразумевает карринг.

Нет.

Окей.

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

Что, и в лиспах тоже после этой фразы автоматически нарисовался карринг? :)

И даже в Питоне. Который, по твоему определению, функциональный язык.

Ой, ну нинада передергивать. Язык может «поддерживать функциональную парадигму» (С), и в этом смысля являться ФЯ (в том числе). Тот же Лисп имеет сильную объектную систему, скажи теперь что он ООП язык.

Ой, ну нинада передергивать

Уже забыл, что говорил?

Ivana> Для меня - если функции объекты первого класса - то уже функциональный

Ivana> наличие функционального типа в языке, возможность генерировать новые значения этого типа в качестве возвращаемого значения функций.

Это Питон.

Язык может «поддерживать функциональную парадигму» (С)

Си не является функциональным по твоему определению.

Тот же Лисп имеет сильную объектную систему, скажи теперь что он ООП язык.

Зависит от определения ООП-языка «по Ivana».

Уже забыл, что говорил?

Нет, но смысл этих придирок? Еж - тоже птица, но как известно, гордая - пока не пнешь - не полетит! С++ (да и любой другой язык) с приходом лямбд по моему определению становится функциональным (в том числе). Даже таблички для детей рисуют на википедиях - список языков с плюсиками напротив разных свойств - в т.ч. и «поддержка функциональной парадигмы».

ЗЫ в результате обильного перекрестного опыления четкие границы рас языков стираются, так что «по Ivana» если и имеет смысл говорить о «функциональных языках» или «ООП языках», то только с определенными оговорками в плане мультипарадигменности и прочего.

Си не является функциональным по твоему определению.

Именно. Хорошо хоть в этом вопросе нет разногласий.

Нет, но смысл этих придирок?

В том, чтобы показать бессмысленность твоего определения.

Си не является функциональным по твоему определению.

Именно

Тогда непонятна фраза «язык может «поддерживать функциональную парадигму» (С)».

Т.е. пруфов у тебя, как обычно, нет.

Ты бы лучше о своих пруфах думал.

Смысл в глазах смотрящего. А объективно его нет ни в моем определении, ни в нашем диалоге, ни в наших жизнях.