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

S>Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.

Откуда статистика? F# же! Nemerle, clojure. если мы про JVM/NET.
Про common lisp молчу.

S>Имх., отличительная черта всех, кто применяет функциональные языки — высокомерие. Как бы смотрят сверху вниз на простых смертных, которые в функциональщине столько не продвинулись.
откуда вы это взяли?
не знаю, более дружелюбного пособия не видел http://lisper.ru/pcl/

S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?

Использую F# для обработки данных, очень удобно, структурируешь данных,
загружаешь, манипулируешь, сохраняшь в файл. всё интерактивно (в vs code).
т.е. куски кода я могу многократно переписывать/перезапускать не теряя уже загруженных данных.
такой подход к разработке, когды ты можешь манипулировать с реальными данными, очень сильно ускоряет разработку и делает код более простым и надежным.
Отсюда и популярость clojure. Насчет kotlin не знаю, не люблю подражательный подход.
Еще был опыт написания на Nemerle небольшой программы.
Тоже удивительный эффект блабла. Размышля в терминах модулей и типов быстро и просто был реализован функционал построения графиков.

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

S>Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.

С чего ты вообще решил, что Котлин — функциональный, да ещё и распространённый в ФП?? Глупый вброс какой-то.

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

Это чистая правда! Кто-то решил, что если почесать яйцо правой рукой через левый карман, то он достиг чего-то большего, чем те, кто просто использовал левую руку.
Прикол в том, что их навыки точно так же глупы. Чтобы писать "лего параллелизируемые" программы, вообще не нужно ФП! Достаточно мозга и "библиотеки трэдов".


S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?

Вообще никак не помогает. ФП ортогонален нормальному человеческому мышлению (императивному), а значит лишь повышает сложность кода и уж тем более сопровождаемость.
Ключ качественно кода (для проф.инженера) далеко не скорость разработки, а понимаемость и сопровождаемость. "Лучше день потерять, потом за 5 минут долететь". Любая долгоживущая система нуждается в улучшениях, поэтому простой императивный код будет куда полезнее для бизнеса, чем хитровы;;;;;нные вложения на ФП.

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


K>Вообще никак не помогает. ФП ортогонален нормальному человеческому мышлению (императивному)

не согласен. аналогия: сотрудник-модуль с должностыми обязанностями(функциями).
намного проще чем это ваше Оооо!ПЭ.

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

S>>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?

K>Вообще никак не помогает. ФП ортогонален нормальному человеческому мышлению (императивному), а значит лишь повышает сложность кода и уж тем более сопровождаемость.
K>Ключ качественно кода (для проф.инженера) далеко не скорость разработки, а понимаемость и сопровождаемость. "Лучше день потерять, потом за 5 минут долететь". Любая долгоживущая система нуждается в улучшениях, поэтому простой императивный код будет куда полезнее для бизнеса, чем хитровы;;;;;нные вложения на ФП.

гм, т.е. LINQ, лямбды не используешь, продолжаешь for фигачить?

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

S>Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.
Начнем с того, что Kotlin по существу это исправленная Java c улучшенным синтаксисом. Да, строго говоря это отдельный язык, но на практике Kotlin юзают именно так в абсолютном большинстве случаев. B Java с восьмой версии столь же функциональна, как и Kotlin. А кому было невтерпеж — те вполне использовали функциональные расширения и до восьмой версии.

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

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

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

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

K> ФП ортогонален нормальному человеческому мышлению (императивному),

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

Привычка (заметной) части программистов к императивному подходу не означает, что так делают все.

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


S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?

Вот кстати, неплохой ответ ЗА ФП
https://dev.to/jhewlett/creating-a-functional-wrapper-in-f-5hgp

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

S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?

и вот https://youtu.be/e1HnlsIL8EE
как указал великий дядя Боб сначала кажется хорошей идеей науярить код по-быстрому.
однако если задача сложная то большую часть времени все равно займет продумывание реализации
и в данном случае F# будет помогать думать.

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

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

так, вообще-то везде и во всем, и в ИТ, и в других профессиях. У сапожника тоже свое высокомерие, ведь он умеет ремонтировать обувь, а ты — нет. Т.е. ты как бы беспомощный сосунок в его мире.

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

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

S>>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?

vaa>Вот кстати, неплохой ответ ЗА ФП
vaa>https://dev.to/jhewlett/creating-a-functional-wrapper-in-f-5hgp

Так а в чём аргумент ЗА? Такое и в императивных языках сплошняком во всяких билдер классах — все методы устанавливают параметр и возвращают this. Используется как длинная строка только из методов точно так же как результат в статье:

let request =
    Http.createRequest "https://hacker-news.firebaseio.com/v0/item/8863.json" Get
    |> withTimeout (TimeSpan.FromSeconds 2.)
    |> withHeader ("Accept", "application/json")

Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?

https://www.youtube.com/watch?v=9SOFqWYpf9Y

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

T>Здравствуйте, Shmj, Вы писали:
S>>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?

T>https://www.youtube.com/watch?v=9SOFqWYpf9Y

У меня от этого видео все шаблоны порвало

Один из комментов огонь

А это точно кутузка а не машина для буйных больных лиспом?

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

P>Так а в чём аргумент ЗА? Такое и в императивных языках сплошняком во всяких билдер классах — все методы устанавливают параметр и возвращают this.
Визуально согласен, отличий немного, но отличие все же есть, в примере каждая часть это независимая функция(лего), в билдере же все функции из цепочки вшиты в экземляр класса.

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

P>Так а в чём аргумент ЗА? Такое и в императивных языках сплошняком во всяких билдер классах — все методы устанавливают параметр и возвращают this. Используется как длинная строка только из методов точно так же как результат в статье:

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

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

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

P>>Так а в чём аргумент ЗА? Такое и в императивных языках сплошняком во всяких билдер классах — все методы устанавливают параметр и возвращают this.
vaa>Визуально согласен, отличий немного, но отличие все же есть, в примере каждая часть это независимая функция(лего), в билдере же все функции из цепочки вшиты в экземляр класса.
Не обязательно. В C# можно такую цепочку вызовов построить через методы расширения. Т.е. автор исходного класса мог и не знать о том, какие методы мы хотим к нему "привинтить".

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

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

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

vaa>и получим Функцию, то что она вызывается через точку лишь сахар. т.е. определенное стремление мэйнстрима к функциональщине есть.
Тут есть интересный момент.
С точки зрения теории, цепочка функций и билдер — это строгие противоположности.
То есть, к примеру, Кей считал, что каждый вызов вроде builder.WithTimeout(msec:2000) — это отправка сообщения, на которое билдер реагирует изменением своего состояния. Этакий "отдельный компьютер".
А вот в ФП вызовы типа WithTimeout(builder, 2000) порождают копию билдера.

Забавным образом, организация функций в цепочку синтаксически приятнее выглядит в ОО-языках.
Ну, вот readonly struct в C#. Вроде того же DateTime.Now().AddDays(5) — тут у нас благодаря синтаксису вызова instance метода не нужно каскадировать скобки.
Ответом на это со стороны ФП и являются всякие аппликаторные скобки вроде |> в F# или ->> в clojure.

Забавнее всего — обратное проникновение в классическое ООП с состоянием, в виде fluent интерфейсов, которые одновременно меняют состояние и возвращают this.
Хотя на мой вкус это перебор — слишком легко спутать конструкцию "породи мне из объекта А объект Б при помощи вот такой цепочки преобразований" с "необратимо испорти состояние А".

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


S>Хотя на мой вкус это перебор — слишком легко спутать конструкцию "породи мне из объекта А объект Б при помощи вот такой цепочки преобразований" с "необратимо испорти состояние А".
возможно, но мне каскады скобок нравятся тем что вносят ясность и однозначность
в порядок вызова

((*) ((+) 1 1) 2);;

Здравствуйте, vaa, Вы писали:
vaa>возможно, но мне каскады скобок нравятся тем что вносят ясность и однозначность
vaa>в порядок вызова
vaa>

vaa>((*) ((+) 1 1) 2);;
vaa>

Если хочется ясности в порядке вызова, всегда можно сделать скобки обязательными в инфиксных вызовах: ((1 + 1) * 2).
Но речь не о них, а о customers.Where(c=>c.Name == "John").OrderBy(c=>c.Age).Skip(10).Take(5) против Take(Skip(OrderBy(Where(customers, c=>c.Name=="John"), c=>c.Age), 10), 5);
На той же кложе мы не будем писать (take 5 (drop 10 (sort #(> (.age %1) (.age %2)) (filter #(= (.name %) "John") customers)))).
Мы будем писать

(->> customers
  (filter #(= (.name %) "John"))
  (sort #(> (.age %1) (.age %2))
  (drop 10)
  (take 5)
)

Т.е. фактически имеем сахар для object-style-chain записи, как раз для избавления от каскада скобок.

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

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


K>>Вообще никак не помогает. ФП ортогонален нормальному человеческому мышлению (императивному)

vaa>не согласен. аналогия: сотрудник-модуль с должностыми обязанностями(функциями).
vaa>намного проще чем это ваше Оооо!ПЭ.

Сотрудник-модуль — это такой же класс с "единой ответственностью", просто это из SOLID.

И я не увидел тут опровержения — ты что, думаешь в стиле ЛИСПа что ли?? Возьми рецепт любой кухарки — там ИМПЕРАТИВНО излагают пункт за пунктом что надо делать. Это и есть самый естественный путь в ИТ. Что за кретины набежали со своими минусами — ума не приложу — видимо, ФП им напрочь мозг выел. Заодно и совесть.