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

Зачем нужен калькулятор?

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

Преимущества функционального программирования зиждется на нескольких "столпах":
1. "Чистые" функции или функции без "побочных эффектов". Т.е. результат функции зависит только от параметров и больше ни от чего. В обратную сторону - функция никак не может влиять на своё "окружение", кроме как вернуть результат вычисления.
2. Сюда естественно вписываются концепты "stateless" или "отсутствие состояния", и "immutability", т.е. неизменяемость данных. Это важные штуки для многопоточного программирования.
3. В ФП широко используются "ленивые" вычисления. Т.е. функция вычисляется только тогда, когда нужен её результат. Это несёт свои преимущества, например позволяет оперировать концептом "бесконечных" коллекций.
4. В ФП применяется композиция и частичное применение функций. Первое позволяет создать новую функцию как последовательное применение существующих функций. А второе - переходить от функций с несколькими параметрами к композиции функций с одним параметром. В комбинации с ленивыми вычислениями становится возможной редукция, т.е. отбрасывание "ненужных" вычислений.
(я тут сознательно опустил развесистую систему типов и всё, что с этим связано, поскольку это больше в сторону ML-семейства языков, а ФП значительно ширее)

Основное преимущество ФП - то, что под это дело разработан неслабецкий мат.аппарат: https://ru.wikipedia.org/wiki/Теория_категорий
Что, например, даёт возможность математически доказывать выполнимость программ.
Отсутствие состояния и неизменяемость позволяет писать гарантированно безопасные многопоточные программы.
Ленивые вычисления в некоторых случаях сильно эффективнее традиционного "жадного" подхода.

Есть свои минусы. Самый большой - это IO, т.е. взаимодействие с окружением. Редко какая программа существует как "конь в вакууме". Нужно читать/писать ввод/вывод, рисовать UI, обращаться к БД и т.д. Всё это плохо вписывается в концепцию "чистоты", если не коренным образом ломает её. Разные ФЯП решают её по разному, но в целом подходы похожи: давайте сделаем некий "закуток", которому будет можно немножко императива и там будем работать с внешним миром.
Кроме того, практически все современные CPU - это "исполнители", а не "вычислители" (а GPU как раз наоборот). И исполнение функциональных программ по сути меняет парадигму. (попытки реализовать универсальный вычислитель программ в виде LISP-машины широкого распространения и развития не получили).
Откуда возникают определенные издержки: например, реализация statless, immutability и lazy evaluation повышают требования к памяти.

Уф!

Но должен заметить, что в реальности ФП гораздо ближе, чем вы думаете.
Каждый, кто писал формулы в Excel занимался именно функциональным программированием :)

(2) Теперь мы сможем математически доказать правильность программы. Это круто!
Неужели больше не будет багов?

(0) Это программирование без переменных

(4) Только "внутри". Все общение с внешним миром по прежнему багоопасно

А где у программы "нутрь" а где "наружа" - вопрос философский. По моим ощущениям на интерфейс всегда уходит гораздо больше сил, чем на начинку

(5) Может без глобальных переменных?

(4) Это давно было можно, т.е. мат.аппарат есть см. например https://ru.wikipedia.org/wiki/Логика_Хоара

Проблема в доказательстве программ "в окружении". Т.е. число внешних зависимостей и их комбинаций (привет "Це из эн по ка") может быть таково, что выполнение формального доказательства не представляется возможным в разумные сроки.

(7) в ФП этот вопрос решен однозначно: всё, что не внутри функции - "наружа".

(0) изучи лисп. Это не так сложно, как кажется. Я в универе изучал. Лисп даже в автокаде применяется. Можешь еще XSLT посмотреть - там тоже функциональное.
(8) да, в этом беда ФП, контекст надо тянуть через все функции

(5) переменные там есть, но в математическом смысле :)

(11) ну главное, что не через запись в справочник

(11) лучше Haskell :)
лисп не производит такого мозговыворачивательного эффекта (по крайней мере, мне лисп был понятен сразу).

а вот Haskell способен подарить немало интересных эмоций программисту :)
книга раз: https://www.ohaskell.guide/
книга два: http://learnyouahaskell.com/chapters (на русском http://learnhaskellforgood.narod.ru/learnyouahaskell.com/introduction.html)

или можно посмотреть на elm.
я его представляю как lite-версию Haskell для написания Web UI https://elm-lang.org/

(0) Функциональное программирование от объектного отличается, только постановщиками задач. На функциональном программирование постановщик Дейкстра и Кнут, на нем пишут виндовз и  10 строк кода в день и получают за это огромные деньги в микрософт. А в ООП постановщики тупые П..ды, где постановка задачи меняется 2 раза в день.

Где постановщики ТП, без ООП работа превращается в кровавый ентерпрайз и стоит миллионы зелени.

(16) >> На функциональном программирование постановщик Дейкстра и Кнут, на нем пишут виндовз и  10 строк кода в день

пить с утра - плохая привычка.

(17) да мы почти все каждый день пользуемся программами на ФЯ, даже не догадываясь. Сервисы Whatsapp написаны на эрланге. И большая часть AWS, на котором пол Интернета держится.

(19) Мы каждый день пользуемся Excel, а ведь там ФП, как нам уже объяснили в (3).

(18) Это я контраста добавил. ООП придумали, под быстроменяющиеся условия и дешевое сопровождение кода. Что важно в бизнесе и в гейм деве. Где например гейм дизайнер(тп), чета я поиграла в вашу игру, она какая то скучная, перепишите все нафиг. Или тут акция изменилась, надо все нафиг переписать.
зы
я не пью уже вообще года 4.

Ну по мне это вот всё относительно: здесь чистое ФП, здесь его немножко, а это еще нет
Это как с паттернами - применили мы паттерн абстрактная фабрика или еще нет?
Немного философия

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

(22),(23) по-моему, по-нормальному написано в (2). Вы код на лиспе когда-нибудь видели? Если да, то все сразу становится на свои места

оно вообще в принципе другое. Это как другая вселенная

представьте себе что вам надо написать прогу одной формулой в экселе. Вот это примерно оно.

(24) Если это на пальцах, то я балерина.

(26) Виндовз, драйвера и контролеры написаны одной формулой в экселе? Ну, ну.

А ещё было логическое программирование и язык Prolog. С текстом программы в виде набора предикатов и фактов.

(28) так а с чего ты взял что Windows и драйверы написаны на ФП?
Это чушь собачья. Винда написана на С/С++/Asm, дрова также.
Говорю - не надо пить с утра.

(28) Может, ты полагаешь что ФП - это просто функции и процедуры вместо объектов -> Си - язык функциональный?
Ну так это неправильно. ФП это совсем другое.

(24) с лиспом все понятно
в C++/C#/Java есть ФП?

(32) да

(30) я не правильно вопрос понял. Я думал суть вопроса отличие процедурного программирование от ООП. В функциональном программировании я вообще ничего не понимаю. И вообще не знал, что оно есть. Признаю ошибки, забираю все слова назад.

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

(32) я бы сказал так - есть элементы. Добавленные в разное время и в разном количестве. В С++ (в самом современном его стандарте) поменьше, в С# побольше, в JS, насколько я знаю, больше всего.

(35) слово функциональный вносит путаницу, это да. А прикол в том что функция в ФП понимается математически, а не как кусок кода.

Цитата:
"доказательство корректности делает программу дороже на порядок (примерно в 10 раз)"
https://ru.wikipedia.org/wiki/Логика_Хоара

В Екселе же есть всякие условные конструкции в формулах?...

(37) один хрен чисто функциональных исполнителей-вычислителей не существует
и будет некая прокладка-интерпретатор императивная

(40)+ имхо ФП это просто очередная высокоуровневая абстракция, которая иногда упрощает написание софта но усложняет его выполнение

(39) аналог функции ? () в 1С. И все.

(0) кури Kotlin, там функциональщина уже как мать родна. Даже с интерфейсом её подружили
https://developer.android.com/jetpack/compose/tutorial

(39) есть ЕСЛИ, ЕОШИБКА и т.д.

+(43) вот тут код нагляднее
https://www.youtube.com/watch?v=SMOhl9RK0BA

(19) ну эрланг, как я понимаю, для серверов и проектировался. Там же размножение и распараллеливание процессов - самая лучшая реализация, как я понял.

у лисра есть современный диалект - Clojure

https://habr.com/ru/post/256017/

*лиспа

(37) Давно пора и в 1с сделать функции чистыми, а всю грязь оставить процедурам!

Интересное объяснение)
https://ibb.co/VWCjF84
https://ibb.co/j6Q9FrY

(37) Ценное пояснение.

(49) с учетом что процедура это просто функция которая не возвращает результат да?
во многих ЯП нет процедур, только функции, возвращающие от 0 до N результатов

(39) так ФП не запрещает условные конструкции. Вы без условий ту же рекурсию не сделаете. Другое дело, как условия в функциональных языках реализованы.

(52) Не надо парадигмы переносимого ассемблера под названием "Си" натягивать на проблемно-ориентированный язык "1C"!

(49) В 1С функция не является объектом первого класса

(55) Главное чтобы побочных эффектов гарантированно не было. А всякое "метапрограммирование" здесь не нужно.

(56) "чтобы побочных эффектов гарантированно не было" - тогда в функциях придется запретить выполнение запросов и даже обращение "через точку" к свойствам ссылок

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

(57) А как обращение через точку или выполнение запроса может привести к побочным эффектам?

(59) так обращение через точку к ссылке это с довольно большой вероятностью запрос. Если только требуемое значение не было закэшировано ранее.

(59) Результат такой функции зависит не только от параметров

Lisp - динозавр. Его современная альтернатива - Clojure

(61) А, вы в этом смысле. Но это не является побочным эффектом, это скорее является отсутствием полной детерминированности и повторяемости. Побочный эффект - это изменение контекста вызова функции.

(52) в функциональном ЯП функция это не совсем то же, что и 1с. Там функции это не просто функции, но и как бы объекты. Представь что ты в 1С написал (присвоил функцию переменной)

МояФункцияПеременная = Функция МояФункция(А, Б, В)
  Возврат А+Б+В;
КонецФункции

и потом передаёшь МояФункцияПеременная в другие функции или юзаешь в текущем коде

ВычислитьА(МояФункцияПеременная, ДругаяПеременная);
ВычислитьБ(МояФункцияПеременная, ТретьяПеременная);

(64) Это ты сейчас Joseph Stalin функциональным языком назвал? ))

Раз тут знатоки FP собрались, разъясните мне как FP пересекается с замыканиями. Это неотъемлемая часть FP или отъемлемая?

(65) даже не знаю что это за зверь

(67)JS

как обычно правда где-то посередине

(66) Замыкание ловит все задействованные переменные внутри функции и превращает их в неявные параметры. Можно и без них, но с ними удобнее.

(65) А разве нет (в том числе)? Какие фишки FP в js недоступны?

(70) То есть ответ - замыкания не являются неотъемлемой частью FP? Тогда следующий вопрос - есть ли функциональные языки, где их нет?
Меня почему этот аспект интересует. Замыкания ведь требуют принципиально другой реализации "под капотом". Фактически функция с замыканием является экземпляром объекта, а не привычной функцией.

(65) ну, может не чистокровное ФП, но оно там есть

(72) Замыкания — это синтаксический сахар. Можно без них, но тогда придётся явно передавать параметры.

(73) В современном с++ оно тоже есть. через stdlib
Class template std::function is a general-purpose polymorphic function wrapper. Instances of std::function can store, copy, and invoke any CopyConstructible Callable target -- functions, lambda expressions, bind expressions, or other function objects, as well as pointers to member functions and pointers to data members.

кстати, скоро в исполнитель и новый элемент завезут элементы функционального программирования
https://wonderland.v8.1c.ru/blog/anons-novykh-vozmozhnostey-yazyka-1s-ispolnitel/

(76) кросивое. А есть инсайды, куда все движется? Неужели станут ERP на Исполнителе переписывать

(77) Типа того: https://wonderland.v8.1c.ru/blog/novaya-tekhnologiya-razrabotki-prilozheniy/

ИМХО, самое прикольное - что в "Элемент" настоящую модульность завезли.
"Приложения и библиотеки могут использовать объекты из других библиотек. При этом объекты из других библиотек не встраиваются в использующий их проект. Вместо этого в проекте определяется зависимость от библиотеки определенной версии.
Предполагается, что вместо больших монолитных решений разработчики будут создавать слабосвязанные блоки. Эти блоки будет удобнее разрабатывать и поддерживать, а также можно будет повторно использовать в разных решениях. Для этого в технологии будут реализованы области видимости, определяемые разработчиками интерфейсы и другие возможности."

(79) а пакетный менеджер уже завезли туда, чтобы разруливать зависимости?

(80) Понятия не имею.

(74) Передавать как ref параметры. Ибо в замыкании они могут меняться. В том же C# создается анонимный класс https://habr.com/ru/post/141270/

Что меня еще поразило - что они успели запилить "облачный конфигуратор". Вот это очень некислый объем работ. И выводящий новое решение в современные тренды.

82+ https://ru.stackoverflow.com/questions/233227/Реализация-замыканий-в-c

(83) да вскод наверняка допилили

(85) мне по скринам так же показалось

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

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

(83) ну такое себе. Скорее даже минус, чем плюс. Когда накрутят дорогобохатый интерфейс IDE, начнёт она радовать долгими откликами. Вскод это же утилита для быстрой подправки кода, когда нет доступа к полноценной IDE. Там веб-морда оправдана. Тут-то она нафига. Всё равно тушка программиста будет физически привязана к определенному рабочему месту, на который чё хошь ставь

В java вон вообще решили замыкания не завозить. И правильно сделали, ИМХО. В мультипарадигменном решении они нафиг не уперлись.

(89) вскод это полноценная иде уже. для какого нибудь тs - js лучше и нет наверно

(91) в современных IDE, типа Visual Studio или IntelliJ IDEA, понавешано дофига всяких инструментов на все случаи жизни. Любая профессиональная IDE к стремится обвеситься инструментами. Вскод это сильно урезанная версия Visual Studio, в которой по-большому счету только редактор кода, отладчик, и средства рефакторинга

(92) ты ее не открывал чтоли никогда?

(93) чёйта? открывал

кмк там на любое желание плагин есть

(95) всё-таки изначально это лёгенький редактор кода с довольно простым интерфейсом. Сравни, например, с андроидстудией (под капотом у неё IntelliJ IDEA)
https://developer.android.com/studio

(96) Да не такой уж он и легенький и простенький. Все познается в сравнении. Хватает редакторов значительно шустрее.
Ну и сейчас идет тенденция на вынос тяжелых операций в бекенд.
Та же InteliJ выкатила возможность работы в IDE через тонкий клиент (все тяжелые операции над проектом будут делаться в бекенде) и еще выкатила будущего конкурента VS - Fleet. Тоже с возможностями распределенного функционирования. Оно конечно пока кастрированное, но говорят значительно шустрее того же VS как редактор.

(97) так у нас-то бекенд. Про то и разговор, что фирма 1с решила использовать лайтовую IDE для бекенда. А годно ли получится?

(96) изначально и 1с думали что бухи будут сами писать

(0) ФП - это по существу дерево,
где корень это внешние/входящие события
а все ветки это функции возвращающие значения.

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

(98) Будем посмотреть. Но концептуально все выглядит довольно годно.
А джаваскриптовский движок vs даже в поле html документа в 1С вполне ничего так шустрит на примере этого проекта: https://github.com/Pr-Mex/vanessa-automation

вроде бы нас в вузе учили функциональному программированию на примере языка РЕФАЛ

а еще Lisp

(101) согласен, будем посмотреть. Но смутные сомнения терзают уже сейчас. Оно ведь как может случиться. Взять те же конфигуратор и EDT. Если в них работать с микроконфигурациями, типо демобазы с ИТС, то всё летает. Но стоит водрузить полноценную современную конфигурацию (УТшку, или ни дай бох ERPшку), всё начинает хромать, каждоеинтерактивное действие притормаживает. Также может получиться с этим элементом и евоным веб-конфигуратором. Пока это всё разрабатывается, юзаются какие-то мелкие проекты, работает нормально. Когда оно уплывёт в полноценный энтерпрайз, появятся здоровенные проекты с исходниками в гигабайт, тут-то веб-конфигуратор может и сдуться

(99) во-во. А пришли к конфигурациям, в которых развёрнутое дерево метаданных можно час скроллить

как всегда: начали весело за функциональное программирование, пришли к тому, что EDT - гамно.

(106) А что, это не так?

(104) Тормоза конфигураторов вызваны одной проблемой - хранением конфигурации в блобе с необходимостью парсинга при построении дерева метаданных и создании кэша. Если уйти от этой морально устаревшей парадигмы и хранить метаданные в отдельных табличках и записях базы - тормозов не будет...

(108) так кэш конфигурации есть.

(109) Угу, который хранится хрен знает где и хрен знает как обеспечивается его согласованность при сбоях клиента. Судя по многочисленным советам "почистить кэш" - не очень хорошо он работает.

(108) в EDT конфигурация хранится в файлах, но что-то лучше не стало

(111) Ну так, EDT это же джава, а где это видано, чтобы джава не тормозила?)