Здравствуйте, mrTwister, Вы писали:

T>Подумалось вот, что в современных объектно-ориентарованных языках вроде как появляются почти все важные фичи функциональных, но это почему-то мало что меняет. Почему так? И тут я понял, что парадигма языка определяется не его фичами, как ни странно. Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный, а если на объектах, то сколько бы функциональных фичей в язык ни добавляли, он так навсегда и останется объектно-ориентированным.

Языка язык может поддерживать ту или иную парадигму или не поддерживать. Поддержка может варьироваться в широком диапазоне. Например, C# 1.0 не поддерживал ФП от слова — никак. А C# поддерживает ФП уже почти как полноценный ФЯ.

Недостаточная поддержка ФП в C# 6.0-8.0 вынуждает иногда выбирать императивное решение. А иногда оно (императивное решение) является объективно лучшим выбором. Скажем не смысла извращаться с фуекцинальщиной если вам нужно сделать GUI. На чистых ФЯ такие задачи превращаются в некрасивые решения.

Есть чистые ФЯ, которые кроме не предоставляют никаких стилей кроме процедурного и функционально. На них ты вынужден писать в функциональном стиле, так как других попросту нет.

Ну, а отношение людей определяется не возможностями языка, а целым комплексом комплексов. Иными словами отношение зависит от предрассудков.

Люди привыкшие к ООП и императивному стилю часто выбирают такие решения, если даже есть хорошая функциональная альтернатива.

Лично я не вижу смысла заморачиваться. ООП и ФП отлично сочетаются. ФП прекрасно подходит на уровень реализации методов и как более безопасное решение когда нужно работать с многопоточностью. ИП (императивное программирование) и ООП отлично подходят для моделирования, которое удобно для разработки ГУЯ и изменяемых документов.

Здравствуйте, СвободуАнжелеДевис, Вы писали:

САД>достаточно любой нормальной книги по функциональному языку, что бы иметь возможность применять этот подход на любом языке

Книжек никогда не достаточно. Нужна практика.

Здравствуйте, mrTwister, Вы писали:

T>В теории да, но на практике нет. C# имеет точно такую же поддержку функций, как и в F# и там тоже всю логику можно в описывать только на функциях, все необходимое для этого там уже есть, удобство использования с точки зрения синтаксиса примерно такое же, только вот так практически никто не делает и не будет делать.

Какой-то набор заблуждений. Поддержка функций — это процедурное программирование. Его поддерживают все языки включая ассемблер.

Поддержка же ФП в C# до сих пор недостаточна. Для полноценной поддержки нужен полноценный пттерн-матчинг, неизменяемые типы и алгебраические типы. Все это пока только в проектах новых стандартов.

Та часть поддержки ФП, когда в C# есть на сегодня боле чем пригодна для использования функционального стиля. Скажем лямбды, замыкания, функции высшего порядка — это все сделано не плохо и во всю используетя.

T>А на F# пишут на функциях, хотя тоже можно и в процедурном

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

T>и в объектно-ориентированном стиле писать, все фичи для этого есть. Разница только в том, что на F# стандартная библиотека написана на функциях, а в C# на классах и объектах и именно это определяет, как язык будут потом использовать и в каком стиле на нем писать.

Огромная библиотека дотнета — это тоже стандартная библиотека F# и она в сто раз больше, чем те мелкие костыли, что написаны специально для F#.

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

Библиотеки F# отличаются не тем, что они "написаны на функциях", а тем, что они приспособлены для карринга и обработки списков. Если бы F# не возился с каррингом ему за глаза хватило бы Linq.

Например, Nemerle специальные библиотеки не нужны. Он отлично пользуется Linq. При этом писать в функциональном стиле в нем получается ни чуть не хуже чем в F#.

Будут в C# такие же возможности по поддержке ФП как в Nemerle и F#, на шарпе можно будет точно так же писать в функциональном стиле, а выбор стиля будет завесить от задачи или тараканов в голове разработчиков.

Здравствуйте, mrTwister, Вы писали:

T>Но важнее тут даже то, что со стандартной библиотекой, хочешь не хочешь, а взаимодействовать придется много, и если ты пишешь с ней в разных парадигмах, то тебе будет больно. Поэтому, парадигма стандартной библиотеки определяет то, как на ЯП будут писать программы.

Это заблуждение. Больно тебе может только если язык препятствует использованию парадигмы или ты сам недотягиваешь и делаешь глупости.

А библиотеки, как правильно сказал IT, тупо дотягиваются до нужд. Для поддержки ФП вообще достаточно библиотеки работы со списками (вроде Linq). Остальные библиотеки — это прикладные решения для решения конкретных задач. И вот тут уже вопрос как они организованы. Хочешь реализовать библиотеку в функциональном ситле — реализуй. Главное чтобы язык тебе не припасовал в этом.

Здравствуйте, netch80, Вы писали:

N>"На функциях" — это значит, что функции — объекты первого класса.

Нифига это не значит. Это твои домыслы. На функциях, значит функциях.

N>В C без дополнительных средств генерации замыканий (типа libjit) такого не бывает в принципе, а с этими средствами — дорого (компилятор не умеет оптимизировать). Поэтому C — не функциональный язык.

А какое отношение функции имеют к замыканиям?

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

Здравствуйте, mrTwister, Вы писали:

T>У него слишком маленькая пользовательская база, чтобы что-то там доказывать.

Плохому танцору всегда яйца мешают (ц). Плохим танцорам нужны базы и истории успеха. Хорошим достаточно самим попробовать.

Вот IT попробовал и у него вопросов не возникло. Мы вот Nemerle в продавшее используем.

T>Кроме того, я сам наверняка не знаю, но очень подозреваю, что функцинальщина там разве что на уровне методов классов.



А в F# функциональщина на каком уровне? Или скажем в Хаскеле?

T>То есть декомпозция строится не на workflow, как в ФП, а все еще объектно-ориентированная.

Декомпозиция — это твои проблемы. У тебя есть выбор. Хочешь делаешь ее на объектах, хочешь на функциях, а объекты преобразуешь через них.

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

T>То, что внутри методов классов используются лямбды с паттерн-матчингом и прочей функциональщиной делает код немного приятнее, но по большому счету ничего не меняет, программа как была объектно-ориентированной, так ей и осталась.

Так стиль программирования вообще ничего не меняет, кроме того что код становится удобнее, читабельнее и более легко поддерживается. В результате ведь все равно получается программа, которую исползает пользователь. И если она работает, то пользователя не трогает стиль на котором она написана.

Все фичи ЯП — это просто возможности, которые при грамотном применении, позволяют решить сложные задачи проще.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, scf, Вы писали:

scf>>Не совсем. "Функциональные ЯП" принципиально не имеют фич для программирования в ООП стиле. Их основная идея — убрать из языка, или максимально затруднить, возможность написания "грязного" кода. С другой стороны, почти все ООП языки — это сборная солянка самых разных подходов; как хочешь, так и пиши.

VD>Твоя стройная теория разбивается о целый рад функциональных ЯП поддерживающих ООП:
VD>1. OCaml.
VD>2. F#.
VD>3. Nemerle.
VD>4. Scala.

Про первые три не скажу, но Скала — это гибридный язык.

Здравствуйте, scf, Вы писали:

scf>Про первые три не скажу, но Скала — это гибридный язык.

Они все гибридные. Но позиционируются именно как функциональные, так как ФП в них поддерживается очень хорошо. OCaml расшифровывается как Objective Caml. Что расшифровывается как Categorical Abstract Machine Language.

Здравствуйте, VladD2, Вы писали:

VD>Недостаточная поддержка ФП в C# 6.0-8.0 вынуждает иногда выбирать императивное решение. А иногда оно (императивное решение) является объективно лучшим выбором. Скажем не смысла извращаться с фуекцинальщиной если вам нужно сделать GUI. На чистых ФЯ такие задачи превращаются в некрасивые решения.

Расскажи это авторам и пользователям React, пусть посмеются.

Здравствуйте, VladD2, Вы писали:

VD>Какой-то набор заблуждений. Поддержка функций — это процедурное программирование. Его поддерживают все языки включая ассемблер.

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

VD>Поддержка же ФП в C# до сих пор недостаточна. Для полноценной поддержки нужен полноценный пттерн-матчинг, неизменяемые типы и алгебраические типы. Все это пока только в проектах новых стандартов.

Возможность делать неизменяемые и алгебраические типы в C# всегда была. Паттерн-матчинг — это просто небольшой сахар, который мало на что влияет, и уж точно он не делает программу функциональной. Просто более удобный switch.

VD>Та часть поддержки ФП, когда в C# есть на сегодня боле чем пригодна для использования функционального стиля. Скажем лямбды, замыкания, функции высшего порядка — это все сделано не плохо и во всю используетя.
Но декомпозция при этом преимущественно объектно-ориентированная, я про нее. То, как реализовали методы никакой роли не играет, сложность программы определяется высокоуровневой декомпозицией, а не тем, как методы классов написали.

VD>Еще раз. "на функциях" — это и есть процедурное программирование. А функциональное — это когда ты используешь преобразование данных.
Еще раз (тм). "На функциях" означает композицию функций с активным использованием функций высшего порядка. Преобразование данных, естественно, никуда не девается, но именно функциональная композиция является определяющим фактором.

VD>Огромная библиотека дотнета — это тоже стандартная библиотека F# и она в сто раз больше, чем те мелкие костыли, что написаны специально для F#.
И?

VD>И в стандартной библиотеке есть тот же Линк, которые по сути является стандартным набором функций высшего порядка.
Все так. И если бы не наличие линка в стандартной библиотеке, то в реальных прикладных программах на C# функций высшего порядка было бы намного меньше, чем сейчас. Именно это я и пытают донести.

VD>Библиотеки F# отличаются не тем, что они "написаны на функциях", а тем, что они приспособлены для карринга и обработки списков. Если бы F# не возился с каррингом ему за глаза хватило бы Linq.
Карринг — это и есть функции высшего порядка, и вполне логично, что стандартная библиотека заточена на использование функций высшего порядка. Благодаря этому декомпозиция с использованием ФВП в F# значительно сильнее распространена, чем в C#, несмотря на то, что в C# тоже есть ФВП

VD>Будут в C# такие же возможности по поддержке ФП как в Nemerle и F#, на шарпе можно будет точно так же писать в функциональном стиле, а выбор стиля будет завесить от задачи или тараканов в голове разработчиков.
Какие бы фичи в C# ни добавили, стиль будет определяться стилем стандартной библиотеки. И да, повторюсь, я не про то, как именно написаны методы классов, я про декомпозицию задачи на подзадачи и композицию кода. Именно они определяют стиль, а не то, используются ли в методах if'ы, или паттерн-матчинг.

Здравствуйте, VladD2, Вы писали:

VD>Это заблуждение. Больно тебе может только если язык препятствует использованию парадигмы или ты сам недотягиваешь и делаешь глупости.

VD>А библиотеки, как правильно сказал IT, тупо дотягиваются до нужд. Для поддержки ФП вообще достаточно библиотеки работы со списками (вроде Linq). Остальные библиотеки — это прикладные решения для решения конкретных задач. И вот тут уже вопрос как они организованы. Хочешь реализовать библиотеку в функциональном ситле — реализуй. Главное чтобы язык тебе не припасовал в этом.

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

Здравствуйте, VladD2, Вы писали:

VD>А в F# функциональщина на каком уровне? Или скажем в Хаскеле?
На уровне декомпозиции задачи на workflow и композиции кода с помощью ФВП

VD>Декомпозиция — это твои проблемы. У тебя есть выбор. Хочешь делаешь ее на объектах, хочешь на функциях, а объекты преобразуешь через них.
Совершенно верно, речь про то, что выбор в большей степени зависит от стиля стандартной библиотеки. И вот есть один и тот же язык, поддерживающий разные парадигмы: javascript. И при этом в зависимости от того, какая гуи библиотека используется: react или angular, вся программа пишется либо в функциональном стиле, либо в объектно-ориентированном. При этом язык, задача и даже программисты одни и те же.

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

Не думаю, что программисты на React больные на голову. Все-таки признанная топовая гуи библиотека на сегодняшний день. State of the art так сказать.

Здравствуйте, mrTwister, Вы писали:

T>Расскажи это авторам и пользователям React, пусть посмеются.

А что удивит людей делающих УЙ над в доску императиными браузерами? Там императивщины хоть жопой жуй. Даже на основной странице примеры императивные.

Поддержка ФП на ЖабаСкрипте очно ограниченная. Не больше чем в современном Шарпе. И вот даже на ней люди делаю костыли, чтобы создание гуя было более декларативно. В Шарпе тоже есть ВПФ с биндингом и MVVM. Но это никак не скрывает того факта, что те же VM-ки зачастую проще и лучше делать изменяемыми.

Здравствуйте, mrTwister, Вы писали:

T>Естественно, имеются ввиду функции высшего порядка.

Это не хрина не естественно понимать ФВП под термином функция. Это проблема в твоей голове. Все остальные под функциями понимают функции, которые есть везде и известы еще со школы.

T>Потому что именно функции высшего порядка позволяют делать функциональную композицию кода и соответствующую декомпозицию задачи. Странно, что приходится пояснять эту очевидную мысль

Как ФВП сейчас есть в любом современном языке. Но этого явно недостаточно чтобы удобно писать код в функциональном сител.

T>Возможность делать неизменяемые и алгебраические типы в C# всегда была. Паттерн-матчинг — это просто небольшой сахар, который мало на что влияет, и уж точно он не делает программу функциональной. Просто более удобный switch.

Вопрос удобства. Или придется признать и C образца 1980-го года функциональным языком и даже объектно-ориентированным. Винду же сделали ООП на нем?

Более того. Можно обойтись goto, if-ом и разными там операторами. Остальное воротить в виде костылей поверх. Так что у нас и ассемблер уже ФП стал.

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

Алгебраические типы используется только если их удобно использовать. Иначе это тупо наследования и паттерны. А при этом проще и проектировать в ОО-стиле.

T>Но декомпозция при этом преимущественно объектно-ориентированная, я про нее. То, как реализовали методы никакой роли не играет, сложность программы определяется высокоуровневой декомпозицией, а не тем, как методы классов написали.

Это вопрос выбора дизайна. Никто тебя не заставляет создавать классы там не они не нужны. А раз ты их создал, значит они удобнее нежели ФП.

Ну, ты сам себе противоречишь. С одной стороны ты говоришь о том, что на классах можно эмулировать алгебраические типы, например, а сдругой сетуешь на применение классов. Но как иначе то? Сэмулировав АлгТД на классах ты получил ОО-решение эмулирующее АлгТД.

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

И если ты посмотришь в корень, то поймешь, что в императивных задачах (коих 90% на практике) ФП прекрасно вписывается на нижнем уровне (врутри функций или какиъ-то блоков). Вот пример с Реактом очень хорошо это показывает. Сам браузер в доску императивен. Он весь состоит из состояния меняющегося во времени и событий. А обертка в виде Реакта позволяет описывать отдельные реакции и даже их группы в функциональном виде.

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

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

VD>>Огромная библиотека дотнета — это тоже стандартная библиотека F# и она в сто раз больше, чем те мелкие костыли, что написаны специально для F#.
T>И?

Доказательство ложности твоего утверждения.

T>Все так. И если бы не наличие линка в стандартной библиотеке, то в реальных прикладных программах на C# функций высшего порядка было бы намного меньше, чем сейчас. Именно это я и пытают донести.

Да чушь это. Просто такие библиотеки были бы сторонними и их было бы 100500. Это конечно же вызвало бы проблемы, но они они были бы.

T>Карринг — это и есть функции высшего порядка, и вполне логично, что стандартная библиотека заточена на использование функций высшего порядка. Благодаря этому декомпозиция с использованием ФВП в F# значительно сильнее распространена, чем в C#, несмотря на то, что в C# тоже есть ФВП

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

Скала и Немерл не имеют такого механизма, но это не значит, что в них есть проблемы с композицией функций.

Так что карринг — это догма. Ее педалируют фанаты.

T>Какие бы фичи в C# ни добавили, стиль будет определяться стилем стандартной библиотеки. И да, повторюсь, я не про то, как именно написаны методы классов, я про декомпозицию задачи на подзадачи и композицию кода. Именно они определяют стиль, а не то, используются ли в методах if'ы, или паттерн-матчинг.

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

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

Но вот на Немерле я пишу ФП-код куда чаще и больше, потому у меня в распоряжении не только ФВП и замыкания, но еще АлгТД, ПМ, локальные функции, куда более мощный вывод типов. И я не зацикливаюсь на ФП или ООП. Тот же Немерл позволяет мне писать макры, которые иногда дают куда большие преимущества.

Зачастую ФП используется для клепания убогиъ ДСЛ. А на макрах я могу клепать ДСЛ отличного качества. И мне на фиг не нужен ФП, если я решу задачу проще, элегантнее, а решение будет более производительным.

Здравствуйте, mrTwister, Вы писали:

T>Это заблуждение (тм). Программы декомпозируются и структурируются примерно тем же способом, которым структурированы и декомпозированы самые популярные библиотеки. Речь именно о высокоуровневом дизайне на уровне контрактов/интерфейсов/композиции, а не о том, как методы внутри написаны. На последнее вообще плевать.

Это твои комплексы. Остальные берут внешние библиотеки/фрэймворки или пишут свои.

И, кстати, Linq превосходит по качеству и полноте очень многие библиотеки ФЯ. Кончено заслуга в этом того, что ее автором был один из авторов Хаскеля, знавший толк в том, что делает. Но дело не только в этом. Ко всему прочему при разработке Linq было уделено не мало внимания проектированию. Даже имена для функций были выбраны боле удачно. Все эти безликие Map-ы и т.п. не добавляют понятности в ФП.

Здравствуйте, mrTwister, Вы писали:

T>На уровне декомпозиции задачи на workflow и композиции кода с помощью ФВП

Это называется процедурная декомпозиция. Они доступна везде.

В F# нет никаких иных средств декомпозиции которых не было бы в C#. И большинство сложных программ написанных на F# использует классы.

T>Совершенно верно, речь про то, что выбор в большей степени зависит от стиля стандартной библиотеки. И вот есть один и тот же язык, поддерживающий разные парадигмы: javascript. И при этом в зависимости от того, какая гуи библиотека используется: react или angular, вся программа пишется либо в функциональном стиле, либо в объектно-ориентированном. При этом язык, задача и даже программисты одни и те же.

Да не зависит это от библиотек. Это зависит от наличия средств в языке, и от тараканов в твоей голове. Ну, нет классов в Хаскле или МЛ-е, значит и декомпозицию на них не сделать.

T>Не думаю, что программисты на React больные на голову. Все-таки признанная топовая гуи библиотека на сегодняшний день. State of the art так сказать.

Реакт — это библиотека к на сквозь императивному ЖабаСкрипту. И код с его использованием напичкан императивом. То что отдельные обработчики и рендеры сделаны в функциональном стиле и подтверждает, что ФП — этоличное средство для реализации отдельных функций или типов, но никак не общее решение для больших систем. Вон тебе на главной странице Ректа пример с таймером и установкой состояния.

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

Делаем поиск по "примеры на React" и первые же примеры содержат React.createClass и Timer.

Дык я и на Шарпе могу использовать декларативный WPF и биндинг. Только, во вью-моделях я зачастую использую изменяемое состояние, а сами модели — это классы.

И, да, я когда пишу на Шарпе я стараюсь не делать состояния без необходимости. Многие мои модели неизменяемые. Я предпочитаю неизменяемость там где это возможно, а там где невозможно пытаюсь менять состояние скопом (атомарно, большими транзакциями).

Короче, твои мысли — это всего лишь проблемы тараканов в твоей голове.

1. В ООП нет никаких проблем. Вполне себе отличное средство для многих задач.
2. ФП не панацея, а такое же средство как ООП. Его можно использовать для улучшения и упрощения кода, а можно и на оборот (поверь, я на такое насмотрелся).
3. Использование ФП скорее определяется знаниями, умениями, а главное, желанием разработчика (традициями, привычками, тараканами в голове).
4. Язык может стимулировать к использованию ФП представляя удобные средства.
5. Библиотеки не только не определяющие в данном вопросе, но и развиваются под тенденции. Вот стало в Шарпе больше ФП и в нем появилась функциональная библиотека. А, скажем, библиотека работы с файлами не может быть функциональной по определению, так как сама запись в файл — императив.

Здравствуйте, VladD2, Вы писали:

VD>А что удивит людей делающих УЙ над в доску императиными браузерами? Там императивщины хоть жопой жуй. Даже на основной странице примеры императивные.

Дай угадаю, ты сделал этот глубокомысленный вывод, потому что не нашел в примерах паттерн-матчинга?

VD>Поддержка ФП на ЖабаСкрипте очно ограниченная. Не больше чем в современном Шарпе. И вот даже на ней люди делаю костыли, чтобы создание гуя было более декларативно. В Шарпе тоже есть ВПФ с биндингом и MVVM. Но это никак не скрывает того факта, что те же VM-ки зачастую проще и лучше делать изменяемыми.

И тем не менее, сейчас тренд в современных гуи библиотеках задается реактом и его unidirectional data flow

Здравствуйте, VladD2, Вы писали:

VD>Это не хрина не естественно понимать ФВП под термином функция. Это проблема в твоей голове. Все остальные под функциями понимают функции, которые есть везде и известы еще со школы.

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

T>>Потому что именно функции высшего порядка позволяют делать функциональную композицию кода и соответствующую декомпозицию задачи. Странно, что приходится пояснять эту очевидную мысль

VD>Как ФВП сейчас есть в любом современном языке. Но этого явно недостаточно чтобы удобно писать код в функциональном сител.

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

VD>Вопрос удобства. Или придется признать и C образца 1980-го года функциональным языком и даже объектно-ориентированным. Винду же сделали ООП на нем?
Паттерн-матчинг одинаково делает более удобным как написание ФП кода, так и императивного.

VD>Более того. Можно обойтись goto, if-ом и разными там операторами. Остальное воротить в виде костылей поверх. Так что у нас и ассемблер уже ФП стал.
Ну вот когда ты напишешь стандартную библиотеку для ассемблера в ФП стиле, то есть оперирующую функциями высшего порядка, тогда и приходи.

VD>В общем, не моли чушь. ФП — это язык на котором удобно писать в функциональном сотлей. Одних лишь ФВП недостаточно.
Верно, нужна еще соответствующая стандартная библиотека


VD>Алгебраические типы используется только если их удобно использовать. Иначе это тупо наследования и паттерны. А при этом проще и проектировать в ОО-стиле.
В "удобно используются" входит прежде всего "удобно используются вместе со стандартной библиотекой"

VD>Это вопрос выбора дизайна. Никто тебя не заставляет создавать классы там не они не нужны. А раз ты их создал, значит они удобнее нежели ФП.
Все так, удобнее в данном контекста. Но контекст определяется не только задачей и фичами языка, но и стандартной библиотекой. Речь про то, что добавлять в язык фичи не затачивая под них стандартную библиотеку не имеет никакого смысла. C# можно с ног до головы обмазать ФП фичами и это ничего не изменит, если не модифицировать под них стандартную библиотеку.

VD>Ну, ты сам себе противоречишь. С одной стороны ты говоришь о том, что на классах можно эмулировать алгебраические типы, например, а сдругой сетуешь на применение классов. Но как иначе то? Сэмулировав АлгТД на классах ты получил ОО-решение эмулирующее АлгТД.

Классы — это еще не значит ОО. ОО — это классы, инкапсулирующие изменяемое состояние и предоставляющие методы для модификации этого состояния.

VD>Вот ты Реакт тут приводил. Вот это и есть попытка исползовать фунциональные фичи для облегчения решения вполне обыйденных императивных задач.

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

VD>И если ты посмотришь в корень, то поймешь, что в императивных задачах (коих 90% на практике) ФП прекрасно вписывается на нижнем уровне (врутри функций или какиъ-то блоков). Вот пример с Реактом очень хорошо это показывает. Сам браузер в доску императивен. Он весь состоит из состояния меняющегося во времени и событий. А обертка в виде Реакта позволяет описывать отдельные реакции и даже их группы в функциональном виде.

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

VD>В лес. Не надо нам твои извращения в терминалогии навязывать. Тут бее уже 5 человек указали на ее ошибочность. Привыкай к общепринятой. На функциях — процедурно. На ФВП — с использованием ФП. И то с натяжкой. Как я уже говорил основным показателем является не функции и даже не их высшие порядки (это только инструмент), а преобразование данных, в отличии от их модификации в императивном подходе. И кстати, ООП вполне себе может быть основан на преобразовании данных, а не на их изменении. Т.е. никак не противоречит функциональщине.

Привыкай, что в человеческом языке одно и то же слово может обозначать разные понятия и конкретное понятие зависит от контекста. В данном случае контекст записан в названии темы: "Отличие функционального ЯП от объектно-ориентированого". Соответственно, под функцией имеется ввиду то, что под ней имеют ввиду в ФП языках.

VD>>>Огромная библиотека дотнета — это тоже стандартная библиотека F# и она в сто раз больше, чем те мелкие костыли, что написаны специально для F#.
T>>И?
VD>Доказательство ложности твоего утверждения.
Не доказывает, как раз наоборот. Если ты писал на F#, то должен знать, что каждый раз, когда касаешься классов из .net фреймворка ощущение, что наступил в кучу говна и делать ты это будешь только от большой нужды. Именно из-за этого наиболее важные и используемые вещи на F# переписывают с учетом специфики и удобства использования из F#. И не потому что в F# нет каких-то важных фич, или из него неудобно использовать классы. Просто там принято декомпозировать код иначе и писать код в другом стиле.

VD>Да чушь это. Просто такие библиотеки были бы сторонними и их было бы 100500. Это конечно же вызвало бы проблемы, но они они были бы.
Их было бы 100500, но все продолжали бы использовать то, что есть в BCL

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

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

VD>Я уж не говорю, что библиотеки не в языке, а для платформы.

Язык связан с платформой, более того, как правила он определяет платформу.

VD>Но я тебе привел пример Linq, который есть и прекрасно используется. Если я пишу код обрабатывающий списки, я волен выбирать между применением Linq и циклами. Иногда я выбираю циклы. Но иногда и Linq. Для выбора того и другого есть ряд предпосылок, которые рассматриваются в каждом конкретном случае.
Я не про написание циклов говорю, а про функциональную и ОО декомпозицию. При чем тут написание циклов?

Здравствуйте, VladD2, Вы писали:

T>>На уровне декомпозиции задачи на workflow и композиции кода с помощью ФВП
VD> Это называется процедурная декомпозиция. Они доступна везде.

Процедурная декомпозиция — это очень маленькое подмножество функциональной. Практически все стандартные ФП паттерны завязаны на ФВП, которых нет в процедурных языках.

VD>В F# нет никаких иных средств декомпозиции которых не было бы в C#. И большинство сложных программ написанных на F# использует классы.
Как правило, явно классы в F# используются только для взаимодействия с другим .net кодом.

T>>Совершенно верно, речь про то, что выбор в большей степени зависит от стиля стандартной библиотеки. И вот есть один и тот же язык, поддерживающий разные парадигмы: javascript. И при этом в зависимости от того, какая гуи библиотека используется: react или angular, вся программа пишется либо в функциональном стиле, либо в объектно-ориентированном. При этом язык, задача и даже программисты одни и те же.
VD>Да не зависит это от библиотек. Это зависит от наличия средств в языке, и от тараканов в твоей голове. Ну, нет классов в Хаскле или МЛ-е, значит и декомпозицию на них не сделать.
Язык один и тот же — javascript (ну или typedcript, сути не меняет). И программист один и тот же с одними и теме же тараканами в голове. Даже задача одинаковая. Но в случае с реактом он будет писать в ФП стиле, а в случае с ангуляром в ООП.

VD>Реакт — это библиотека к на сквозь императивному ЖабаСкрипту. И код с его использованием напичкан императивом. То что отдельные обработчики и рендеры сделаны в функциональном стиле и подтверждает, что ФП — этоличное средство для реализации отдельных функций или типов, но никак не общее решение для больших систем. Вон тебе на главной странице Ректа пример с таймером и установкой состояния.

На реакте общепринят flux

VD>Делаем поиск по "примеры на React" и первые же примеры содержат React.createClass и Timer.

В энный раз повторяю — я про декомпозицию задачи, а не про написание методов. Программы на реакте декомпозируются с помощью архитектурного паттерна unidirectional data flow.

VD>Дык я и на Шарпе могу использовать декларативный WPF и биндинг. Только, во вью-моделях я зачастую использую изменяемое состояние, а сами модели — это классы.
Все так, а на реакте не используют изменяемое состояние во вью моделях. Об этом и речь.

VD>1. В ООП нет никаких проблем. Вполне себе отличное средство для многих задач.
Я ничего не писал о проблемах в ООП, при чем тут это?

VD>2. ФП не панацея, а такое же средство как ООП. Его можно использовать для улучшения и упрощения кода, а можно и на оборот (поверь, я на такое насмотрелся).
Я не писал, чт оФП — это панацея, при чем тут это?

VD>3. Использование ФП скорее определяется знаниями, умениями, а главное, желанием разработчика (традициями, привычками, тараканами в голове).
Все так. А вот традиции и привычки задаются используемой стандартной библиотекой.

VD>4. Язык может стимулировать к использованию ФП представляя удобные средства.
Средства языка без поддержки стандартной библиотеки имеют малое влияние на традиции.

VD>5. Библиотеки не только не определяющие в данном вопросе, но и развиваются под тенденции. Вот стало в Шарпе больше ФП и в нем появилась функциональная библиотека. А, скажем, библиотека работы с файлами не может быть функциональной по определению, так как сама запись в файл — императив.
Функциональная часть там очень крохотная, которая мало на что влияет, только на уровне методов.

Здравствуйте, mrTwister, Вы писали:

T>Подумалось вот, что в современных объектно-ориентарованных языках вроде как появляются почти все важные фичи функциональных, но это почему-то мало что меняет. Почему так? И тут я понял, что парадигма языка определяется не его фичами, как ни странно. Парадигма ЯП определяется его стандартной библиотекой. Если стандартная библиотека написана на функциях, значит и язык функциональный, а если на объектах, то сколько бы функциональных фичей в язык ни добавляли, он так навсегда и останется объектно-ориентированным.

И все таки ФП отличаются от ООП именно синтаксисом и реализацией, вот тут подтверждение:

Fun Fact: I have heard a bunch of stories of folks finding bugs in their server code as they switched from JS to Elm.
The decoders people write end up working as a validation phase, catching weird stuff in JSON values.
So when NoRedInk switched from React to Elm, it revealed a couple bugs in their Ruby code!

https://guide.elm-lang.org/effects/json.html

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