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

(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 это же джава, а где это видано, чтобы джава не тормозила?)