Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.
Имх., отличительная черта всех, кто применяет функциональные языки — высокомерие. Как бы смотрят сверху вниз на простых смертных, которые в функциональщине столько не продвинулись.
Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
Здравствуйте, Shmj, Вы писали:
S>Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.
S>Имх., отличительная черта всех, кто применяет функциональные языки — высокомерие. Как бы смотрят сверху вниз на простых смертных, которые в функциональщине столько не продвинулись.
S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
Котлин не функциональный язык, он позволяет писать в функциональном стиле, но функциональным не является.
А вот Erlang, Elixir и Haskell являются функциональными языками и используются в коммерческой разработке, причем первые два весьма широко. И, да, они помогают решать проблемы быстрее и проще чем если делать тоже самое, но на не функциональном языке.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
Имхо. ФП — это когда люди, близкие к математике, но далекие от разработки, решили писать программы на чистых функциях. Это оказалось сложно, поэтому им пришлось придумать много новых концепций, упрощающих код. Результат все равно получился сложный, так что ФП в массы не пошел. Но отдельные наработки из ФП универсально полезны, в том числе в императивных языках. Это монадические операции и комбинаторы (map/flatMap/traverse), ADT, иммутабельные структуры данных, тайпклассы и просто более глубокое понимание того, что такое абстракция, что такое модульность кода, что такое модель данных.
К сожалению, в ФП сообществе много зашоренных агрессивных фанатов, но человек с опытом ФП даже на джаве будет писать иначе, чем человек без такого опыта. И его код будет проще и понятнее.
Здравствуйте, kaa.python, Вы писали:
KP>А вот Erlang, Elixir и Haskell являются функциональными языками и используются в коммерческой разработке, причем первые два весьма широко. И, да, они помогают решать проблемы быстрее и проще чем если делать тоже самое, но на не функциональном языке.
Они иногда помогают решать проблемы быстрее и проще. Иногда на них дольше и сложнее. А в большинстве случаев — разницы нет.
Поэтому ФП языки до сих пор не сильно распространены. И поэтому ФП по чуть-чуть все же добавляют в "обычные" языки.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Насколько эта функциональщина реально помогает?
Основная проблема заключается в том, что иммутабельность несколько противоречит эффективному использованию вычислительных ресурсов (если говорить про однопоток), следовательно помогать это может в достаточно ограниченных условиях.
S>Помогает ли сократить сроки разработки, помогает ли повысить качество?
Если использовать осмысленно и к месту, т.е. небольшими вкраплениями (как например LINQ), то скорее да.
Здравствуйте, Буравчик, Вы писали:
Б>Они иногда помогают решать проблемы быстрее и проще. Иногда на них дольше и сложнее. А в большинстве случаев — разницы нет.
Не согласен, я постоянно ловлю себя на мысли о том, что на Clojure было бы гораздо проще и элегантнее решение. Но, увы. С производительностью у нее не ахти.
Б>Поэтому ФП языки до сих пор не сильно распространены. И поэтому ФП по чуть-чуть все же добавляют в "обычные" языки.
Я вижу две основные проблемы: производительность и порог вхождения.
Здравствуйте, blacktea, Вы писали:
B>Не согласен, я постоянно ловлю себя на мысли о том, что на Clojure было бы гораздо проще и элегантнее решение. Но, увы. С производительностью у нее не ахти.
Ну так динамика же Поэтому и проще, и элегантнее, и производительность не ахти.
Здравствуйте, Shmj, Вы писали:
S>Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.
Kotlin не более функционален, чем, например, Java.
S>Имх., отличительная черта всех, кто применяет функциональные языки — высокомерие. Как бы смотрят сверху вниз на простых смертных, которые в функциональщине столько не продвинулись.
Это то же самое, что утверждать, что отличительная черта всех, кто применяет указатели — высокомерие. И дальше по тексту. Приёмы функционального программирования определённо имеют место быть в некоторых ситуациях. И знать их полезно. А как смотреть — это уже каждый сам решает в меру своего воспитания и системы ценностей. Кто-то и на уборщиц смотрит сверху вниз.
S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
Приёмы функционального программирования помогают:
1. Записывать некоторые участки кода короче и ясней. В основном это касается манипуляций с коллекциями.
2. Чистые функции можно невозбранно запускать в отдельных потоках. Т.е. порой можно переписав определённый участок кода на функциях без побочных эффектов, запускать эти функции в отдельных потоках, тем самым получив ускорение выполнения этого участка кода за счёт многопоточности. Это сделать легко, быстро, не требует особенного понимания многопоточности и это чаще всего не привносит багов. Переписать императивный код на многопоточный, с разделяемой памятью, ручными синхронизациями и прочим: требует высокой квалификации; довольно сложно; могут быть трудновоспроизводимые баги. А уж про всякие свободные от блокировок алгоритмы я вообще молчу, это удел гуру.
3. Упростить иерархию объектов, упростить некоторые паттерны проектирования. Например там, где в традиционном ООП нужно создавать родительский абстрактный метод с несколькими наследниками-реализациями, с ФП достаточно передать лямбду и никакой иерархии уже не нужно.
Это те места, в которых я вижу применение функционального подхода в классических императивных языках (к которым, безусловно, относится Kotlin, равно как и большинство коммерчески применяемых языков).
Здравствуйте, T4r4sB, Вы писали:
scf>>И его код будет проще и понятнее.
TB>Не будет. Вместо простого цикла на 10 строк будет портянка из кучи шаблонов с перегрузками и рекурсией.
Без примеров дискуссия обречена зайти в тупик
А то ведь вполне можно сказать, что вместо простого декларативный запроса, по которому сразу видно, что он делает, будет портянка со вложенными циклами и, скорее всего, с ошибками. Я тут читал (боюсь, человек и так на меня обиделся, поэтому без имён и ссылок, хотя мы все ошибаемся и это не обидно), как некто налетел на исчерпание места на диске. Вскрытие показало, что про одну из явно вызываемых функций он не дочитал, что у неё есть побочный эффект в виде логгинга, местами — значительного. Когда он это выяснил (кажется, кто-то процитировал маны), он негодовал, что разрабы — утырки, ну как можно делать такие опасные для жизни сайд-эффекты, мол?! А я вот считаю, надо или крестик снять (и читать супервнимательно про каждую долбанную императивную функцию), или трусишки надеть и переходить на новый декларативный API, если уж хочется писать в духе 'сделайХорошо(самЗнаешьКак)'. Мне кажется, когда пишут FP-style API, авторы вынуждены думать о таких вещах.
Не, вы говорили про простой цикл на 10 строк и сложную ФП-портянку вместо него. Я так понял, что подразумевался один код, написанный по-разному, и у вас есть готовый пример.
Здравствуйте, Shtole, Вы писали:
S>Здравствуйте, T4r4sB, Вы писали:
S>Не, вы говорили про простой цикл на 10 строк и сложную ФП-портянку вместо него. Я так понял, что подразумевался один код, написанный по-разному, и у вас есть готовый пример.
Я привёл пример, правда не из ФП, но тоже про то, как после более "правильного" языка код якобы становится лучше.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Буравчик, Вы писали:
Б>Они иногда помогают решать проблемы быстрее и проще. Иногда на них дольше и сложнее. А в большинстве случаев — разницы нет.
Приложения можно условно разделить на две большие категории — приложения с состоянием и приложения без состояния. Приложения с состоянием, обычно, писать на функциональном языке можно, но так как состояние надо постоянно обновлять то выходит или криво, или медленно, или и то и другое сразу.
А вот в случае с приложениями без состояния (со слабо выраженным состоянием) уже сильно иначе. Так как количество данных которые нужно обновлять сводится к минимуму, функциональная парадигма позволяет сильно ускорить разработку, т.к. убирает большой пласт логических ошибок связанных с неверным использованием разделяемых данных, синхронизациями, сложностями с написанием модульных тестов и т.д.
Б>Поэтому ФП языки до сих пор не сильно распространены. И поэтому ФП по чуть-чуть все же добавляют в "обычные" языки.
Как мне кажется причина в косности мышления разработчиков и управленцев. Всегда страшно взять новый, не знакомый инструмент, потом думать где и как искать людей. Плюс возрастает требование к квалификации, т.к. функциональный подход требует несколько иного мышления и как следствие людей которые в состоянии мыслить не только в императивном, но и функциональном ключе.
Здравствуйте, kaa.python, Вы писали:
KP>Как мне кажется причина в косности мышления разработчиков и управленцев.
Нет. Причина как раз в рациональном мышлении.
Ибо чтобы взваливать дополнительные риски в виде нового инструмента с непонятными перспективами поддержки и наличия квалифицированных девелоперов надо чтоб этот инструмент давал уже понятный бонус, который хотя бы уравновешивал риски.
А то мода на эзотерику штука проходящая, и обнаружить себя через год без возможности нанять людей для роста проекта перспектива так себе.
KP> Всегда страшно взять новый, не знакомый инструмент, потом думать где и как искать людей.
Совершенно правильно страшно. Ибо перспектива никого не найти куда реальнее чем гипотетические выгоды нового языка, которые может быть проявятся когда нить потом.
KP> Плюс возрастает требование к квалификации, т.к. функциональный подход требует несколько иного мышления и как следствие людей которые в состоянии мыслить не только в императивном, но и функциональном ключе.
И это тоже рациональное мышление.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
S>Не, вы говорили про простой цикл на 10 строк и сложную ФП-портянку вместо него. Я так понял, что подразумевался один код, написанный по-разному, и у вас есть готовый пример.
Хмм... интересный у Вас ход мысли! Значит, Вы предполагаете — нет, в данном случае даже требуете! — чтобы T4r4sB, встретив когда-то лет 7 назад в чьем-то коде некую ФП-портянку, не просто ругнулся и пошел бы дальше по своим программистким делам, а бережно сохранил бы данный код на локальный жесткий диск, гуглдрайв, и ленточный накопитель. А в идеале еще и распечатал и повесил бы в рамочке на стену перед монитором, чтобы уж точно не потерять. Ведь иначе жеж пацаны не поверят, что такое бывает, и ответ держать придется перед самим Shtole!
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Хмм... интересный у Вас ход мысли! Значит, Вы предполагаете — нет, в данном случае даже требуете! — чтобы T4r4sB, встретив когда-то лет 7 назад в чьем-то коде некую ФП-портянку, не просто ругнулся и пошел бы дальше по своим программистким делам, а бережно сохранил бы данный код на локальный жесткий диск, гуглдрайв, и ленточный накопитель. А в идеале еще и распечатал и повесил бы в рамочке на стену перед монитором, чтобы уж точно не потерять. Ведь иначе жеж пацаны не поверят, что такое бывает, и ответ держать придется перед самим Shtole!
Зачем юродствовать? Человек написал: «Вместо простого цикла на 10 строк будет портянка из кучи шаблонов с перегрузками и рекурсией». Я попросил пример. Вообще, это азбука продуктивного обсуждения: не переливать из пустого в порожнее, делая глобальные утверждения, а объяснять на примерах. Человек отказался. Ну, его дело.
Здравствуйте, 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, Вы писали:
S>>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
K>Вообще никак не помогает. ФП ортогонален нормальному человеческому мышлению (императивному), а значит лишь повышает сложность кода и уж тем более сопровождаемость. K>Ключ качественно кода (для проф.инженера) далеко не скорость разработки, а понимаемость и сопровождаемость. "Лучше день потерять, потом за 5 минут долететь". Любая долгоживущая система нуждается в улучшениях, поэтому простой императивный код будет куда полезнее для бизнеса, чем хитровы;;;;;нные вложения на ФП.
гм, т.е. LINQ, лямбды не используешь, продолжаешь for фигачить?
Здравствуйте, Shmj, Вы писали:
S>Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.
Начнем с того, что Kotlin по существу это исправленная Java c улучшенным синтаксисом. Да, строго говоря это отдельный язык, но на практике Kotlin юзают именно так в абсолютном большинстве случаев. B Java с восьмой версии столь же функциональна, как и Kotlin. А кому было невтерпеж — те вполне использовали функциональные расширения и до восьмой версии.
S>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
Зависит от задачи. При работе с асинхронщиной вполне помогает. Код становится гораздо более понятный, простой и читаемый. При этом еще из за отсутствия сайдэффектов и мутаций не нужно заморачиваться со всякими синхронизациями, что может даже повысить производительность.
Но. Если стоит специфическая задача выжать вообще все что можно из железа в рамках одного ядра процессора — будешь как миленький хреначить жесточайшую императивщину с мутациями, на элементарных массивах с повторным использованием уже созданных объектов, нарушая кучу книжных бест практик. В определенном месте будешь это все делать а не размазывая по всему коду.
А так, на деле. Функциональщина по существу — это ООП в пределе. Когда у класса ровно один метод с ровно одним аргументом, по существу SOLID в пределе, плюс дополнительными современными бест практиками что классы должны быть иммутабельными. Начни фанатично следовать ООП бест практикам, с учетом что у каждого объекта есть строго один метод, он жутчайше специализирован, и этот метод не меняет состояние а создает другой объект, и в пределе придешь к функциональному программированию, только с совершенно громоздким неудобным синтаксисом, с кучей дополнительных лишних абстракций, классами на ровном месте и т.д. А всякие паттерн матчинги и т.д — это просто синтаксический сахар, позволяющий писать более компактно и понятно.
Человеческое мышление не является в чистом виде ни императивным, ни функциональным. Ближе всего к нему событийно-управляемое построение с короткими зависимостями, но сами зависимости скорее строятся функционально (что от чего зависит), чем императивно (когда уже разложена последовательность выполнения). Императивность возникает только там, где это разложение уже сделано в явном виде.
Привычка (заметной) части программистов к императивному подходу не означает, что так делают все.
Здравствуйте, 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>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
Здравствуйте, 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.
Хотя на мой вкус это перебор — слишком легко спутать конструкцию "породи мне из объекта А объект Б при помощи вот такой цепочки преобразований" с "необратимо испорти состояние А".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Хотя на мой вкус это перебор — слишком легко спутать конструкцию "породи мне из объекта А объект Б при помощи вот такой цепочки преобразований" с "необратимо испорти состояние А".
возможно, но мне каскады скобок нравятся тем что вносят ясность и однозначность
в порядок вызова
Здравствуйте, 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)))).
Мы будем писать
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Kolesiki, Вы писали:
K>>Вообще никак не помогает. ФП ортогонален нормальному человеческому мышлению (императивному)
vaa>не согласен. аналогия: сотрудник-модуль с должностыми обязанностями(функциями). vaa>намного проще чем это ваше Оооо!ПЭ.
Сотрудник-модуль — это такой же класс с "единой ответственностью", просто это из SOLID.
И я не увидел тут опровержения — ты что, думаешь в стиле ЛИСПа что ли?? Возьми рецепт любой кухарки — там ИМПЕРАТИВНО излагают пункт за пунктом что надо делать. Это и есть самый естественный путь в ИТ. Что за кретины набежали со своими минусами — ума не приложу — видимо, ФП им напрочь мозг выел. Заодно и совесть.
Здравствуйте, AntoxaM, Вы писали:
AM>Здравствуйте, Kolesiki, Вы писали:
S>>>Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
K>>Вообще никак не помогает. ФП ортогонален нормальному человеческому мышлению (императивному), а значит лишь повышает сложность кода и уж тем более сопровождаемость. K>>Ключ качественно кода (для проф.инженера) далеко не скорость разработки, а понимаемость и сопровождаемость. "Лучше день потерять, потом за 5 минут долететь". Любая долгоживущая система нуждается в улучшениях, поэтому простой императивный код будет куда полезнее для бизнеса, чем хитровы;;;;;нные вложения на ФП.
AM>гм, т.е. LINQ, лямбды не используешь, продолжаешь for фигачить?
Да причём тут это?? Нашёл ещё аналогию... А если индеец воткнул себе в жопу перья — он теперь страус штоле?? Вот ты такую же чушь сказал.
Есть исторически сложившиеся элементы языка. Та же "лямбда" не более "функциональна", чем.... обычный указатель на функцию(!!!). Кой, напомню, прекрасно живёт в Си и почему-то ни один ФП язык не считается "наследником Си"
ФП — это вообще не про ваши местечковые ЛИНК или лямбды. ФП — это прежде всего ПАРАДИГМА, способ организации программы. Грубо говоря, человеку дали ведро функций и сказали — делай что хочешь, у нас больше ничего нет. Вкладывай, подставляй, комбинируй, но чтобы на выходе было "4". Есессно, от таких "парадигм" у нормального человека крыша едет!
А то, что в какой-нть C# добавили возможность "передать функцию", ну так это считай "добавили возможностей из Си"! что тут "функционального"-то? Просто ещё один вид параметров, как int или string.
Ох уж эти амбассадоры ФП-психушки... не понимают сути своей же парадигмы, но везде отчаянно аргументируют "а вы фсе используете наше ФП!". Может, у вас ещё "детство отняли"?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Kolesiki, Вы писали:
K>> ФП ортогонален нормальному человеческому мышлению (императивному),
N>Человеческое мышление не является в чистом виде ни императивным, ни функциональным. Ближе всего к нему событийно-управляемое построение с короткими зависимостями, но сами зависимости скорее строятся функционально (что от чего зависит), чем императивно (когда уже разложена последовательность выполнения). Императивность возникает только там, где это разложение уже сделано в явном виде.
N>Привычка (заметной) части программистов к императивному подходу не означает, что так делают все.
Господи, ну и чушь ты лепишь! Хорошо, отойдём от ИТ. Зайди на кухню, открой ЛЮБОЙ РЕЦЕПТ и скажи — в каком виде записан рецепт — в ФП или императивно? А это, на минуточку, практика ВСЕХ 7 МИЛЛИАРДОВ ЛЮДЕЙ. Хорошо ты так обделался, да?
ФП никогда не был И НЕ БУДЕТ методом построения программ, ибо мозг — это вам не стек и не машина Тьюринга. Мозг прочёл по ИМПЕРАТИВНОЙ инструкции "выполнить пункт 3" — он его выполнит и перейдёт к пункту 4. Вот это и есть МАКСИМАЛЬНО удобное для мозга построение программ — императивно.
Здравствуйте, Kolesiki, Вы писали:
K>Есть исторически сложившиеся элементы языка. Та же "лямбда" не более "функциональна", чем.... обычный указатель на функцию(!!!). Кой, напомню, прекрасно живёт в Си и почему-то ни один ФП язык не считается "наследником Си"
Ну неправда же. У лямбды есть bound context, позволяющий ссылаться на внешний скоуп. И, что самое важное, у лямбды есть синтаксический сахар, позволяющий объявить "указатель на функцию" прямо в том месте, где она используется, а не в соседней функции.
"код, идентичный ФП" можно отлично написать без лямбд, на тех же указателях на функции и анонимных классах, но это же будет не то. Синтаксический оверхед ломает всю идею.
K>А то, что в какой-нть C# добавили возможность "передать функцию", ну так это считай "добавили возможностей из Си"! что тут "функционального"-то? Просто ещё один вид параметров, как int или string.
Добавили по сути кодогенерацию. То yield, лямбды, async await порождают анонимные классы. А взято из ФП это или нет мне наплевать, однако это колоссально упрощает программирование.
Суть то в упрощении как написании так и чтении
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, scf, Вы писали:
K>>Есть исторически сложившиеся элементы языка. Та же "лямбда" не более "функциональна", чем.... обычный указатель на функцию(!!!). Кой, напомню, прекрасно живёт в Си и почему-то ни один ФП язык не считается "наследником Си"
scf>Ну неправда же. У лямбды есть bound context, позволяющий ссылаться на внешний скоуп. И, что самое важное, у лямбды есть синтаксический сахар, позволяющий объявить "указатель на функцию" прямо в том месте, где она используется, а не в соседней функции. scf>"код, идентичный ФП" можно отлично написать без лямбд, на тех же указателях на функции и анонимных классах, но это же будет не то. Синтаксический оверхед ломает всю идею.
Не стоит путать лямбда-функции и замыкания. Да, во многих языках это почти синонимы, но это в них просто так сложилось. А так, замыкания вполне себе существуют и не для анонимных функций (например для классических вложенных функций). Да и анонимные функций без замыканий тоже вполне себе могут существовать.
Здравствуйте, Kolesiki, Вы писали:
K>И я не увидел тут опровержения — ты что, думаешь в стиле ЛИСПа что ли?? Возьми рецепт любой кухарки — там ИМПЕРАТИВНО излагают пункт за пунктом что надо делать.
Нет, конечно.
Рецепт начинается с: например: возьмите ингредиенты: яйца, сахар, манка, мука, соль, сахар, кефир (указаны количества каждого). Это _функциональная_ зависимость: прежде чем собирать это, компоненты должны появиться, и кухарка решает задачу _зависимости_ — как именно реализовать — может, надо зайти в соседний подъезд в магазин, а, может, ещё съездить купить кур для яиц, посадить буряк для сахара и накопать шахту для соли. Это на входе.
1. Для приготовления шарлотки нам понадобятся четыре некрупных яблока, лучше отдавать предпочтение кислым сортам. Очищаем яблоки от плодоножек и семечек, нарезаем тонкими дольками.
2. Для приготовления теста просеиваем муку с разрыхлителем. Оставляем на время.
Любой кухарке известно, что чищенные и резаные яблоки сохнут. Значит, пункт 2 в норме должен быть выполнен до пункта 1, если хочется свежайших яблок. Связи между пунктами нет, могут быть выполнены в любом порядке. На самом деле пункт 1 нужен только перед пунктом 5.
(Или же завернуть плотно в кулёчек и отложить. Это не сказано, надо догадаться.)
3. Охлажденные куриные яйца разбиваем в высокую посуду и взбиваем с помощью миксера, постепенно увеличивая скорость. Добавляем сахарный песок. Продолжаем взбивать, пока масса не посветлеет и не увеличится в объеме.
4. Ставим скорость миксера на минимум и постепенно добавляем просеянную муку с разрыхлителем. Тесто должно получиться густым, как сметана, и быть однородным.
3 и 4 не делятся, ok. 4 зависит от 2.
5. Форму для выпечки смазываем сливочным маслом и присыпаем мукой (можно вместо муки посыпать панировочными сухарями с сахаром, так у готовой шарлотки появится хрустящая карамельная корочка) Кладем в форму подготовленные яблочные дольки, равномерно распределяем.
Снова внешние зависимости от компонентов, ok. Уже нужны яблочные дольки (пункт 1). На самом деле тесто ещё не нужно! Или его может готовить кто-то параллельно.
Дальше, да, пункты строго последовательно зависят друг от друга и записаны по порядку.
Так вот — резюмирую — тут много чисто функциональных зависимостей, которые 1) могут выполняться параллельно (резать и замешивать могут разные люди; готовить форму, разогревать духовку и т.д. — тоже), 2) могут переставляться, 3) не все прописаны (компоненты, плита/духовка, предварительный прогрев и всё такое).
Императивность описания — чисто внешняя форма, которая не должна обманывать (и не обманывает хоть немного опытную кухарку). Кухарка (повар) сама находит зависимости и переразлагает в ориентированный граф действий.
K> Это и есть самый естественный путь в ИТ. Что за кретины набежали со своими минусами — ума не приложу — видимо, ФП им напрочь мозг выел. Заодно и совесть.
Человек не императивен в своём поведении. Ближе всего к нашей конструкции — событийно-управляемое построение с приоритетными очередями коротких функциональных цепочек, которые сознательно перепланируются.
Здравствуйте, Kolesiki, Вы писали:
K>Господи, ну и чушь ты лепишь! Хорошо, отойдём от ИТ. Зайди на кухню, открой ЛЮБОЙ РЕЦЕПТ и скажи — в каком виде записан рецепт — в ФП или императивно?
См. только что отправленный комментарий. Если ты видишь формально последовательную запись и веришь этому, ты никогда не имел реальной практики готовки больше 2-3 случаев. Максимум что было — помогать жене/маме.
Ну или всё забыл, тоже может быть.
K> А это, на минуточку, практика ВСЕХ 7 МИЛЛИАРДОВ ЛЮДЕЙ.
Откуда ты знаешь, как пишутся рецепты в, например, Иране или в долине Балием? У аборигенов Рюкю?
У тебя есть точные данные расписывать за 7 миллиардов людей?
K> Хорошо ты так обделался, да?
Ты.
K>ФП никогда не был И НЕ БУДЕТ методом построения программ, ибо мозг — это вам не стек и не машина Тьюринга. Мозг прочёл по ИМПЕРАТИВНОЙ инструкции "выполнить пункт 3" — он его выполнит и перейдёт к пункту 4. Вот это и есть МАКСИМАЛЬНО удобное для мозга построение программ — императивно.
В случае кулинарии — работает максимум первые пару раз. Потом начинается редактирование в формат графа зависимостей. Да, многие это делают неосознанно и не могут сформулировать — для них естественно, что раз купил какой-нибудь латук-айсберг вчера, решив приготовить праздничный салат, то он уже есть.
Профессиональные повара держат в голове десятки и сотни зависимостей и способны без напряга сознания рассчитать любой график работ.
Здравствуйте, Kolesiki, Вы писали:
AM>>гм, т.е. LINQ, лямбды не используешь, продолжаешь for фигачить?
K>Да причём тут это?? Нашёл ещё аналогию... А если индеец воткнул себе в жопу перья — он теперь страус штоле?? Вот ты такую же чушь сказал.
K>Есть исторически сложившиеся элементы языка. Та же "лямбда" не более "функциональна", чем.... обычный указатель на функцию(!!!). Кой, напомню, прекрасно живёт в Си и почему-то ни один ФП язык не считается "наследником Си"
Возможность написать функцию по месту, и сразу передать куда надо, контроль типов этой функции, возможность обратиться к внешнему скоупу, да ещё всё это кратко и понятно — это всё элементы пришедшие из ФП.
В С от этого — только указатель передать. Да и не удивлюсь, если это в лиспе каком-нить подсмотрели.
LINQ-to-Object — так вообще в чистую работа с коллекциями как в ФП языках.
K>ФП — это вообще не про ваши местечковые ЛИНК или лямбды. ФП — это прежде всего ПАРАДИГМА, способ организации программы. Грубо говоря, человеку дали ведро функций и сказали — делай что хочешь, у нас больше ничего нет. Вкладывай, подставляй, комбинируй, но чтобы на выходе было "4". Есессно, от таких "парадигм" у нормального человека крыша едет!
ниасилил?
K>А то, что в какой-нть C# добавили возможность "передать функцию", ну так это считай "добавили возможностей из Си"! что тут "функционального"-то? Просто ещё один вид параметров, как int или string.
Этот всего лишь "ещё один вид параметров" позволяет делать композицию из функций и позволяет писать в ФП стиле
K>Ох уж эти амбассадоры ФП-психушки... не понимают сути своей же парадигмы, но везде отчаянно аргументируют "а вы фсе используете наше ФП!". Может, у вас ещё "детство отняли"?
Здравствуйте, Shmj, Вы писали:
S>Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.
Кстати говоря. Котлин более менее распространен в реальной разработке в значительной мере потому, что он содержит некоторые фичи, которые позволяют некоторые вещи, которые принято делать в функциональном стиле выполнять в императивном. Это касается в первую очередь асинхронщины. То есть поведение по умолчанию от толпы обезьян которые не ленятся — это callback hell. Кто поумнее и поопытнее — заюзают функциональные реактивные библиотеки, и будут всякими монадами отлавливать ошибки исполнения. А Котлин как раз позволяет писать асинхронщину максимально близко к императивному стилю, в некоторых случаях это оказывается очень удобно.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, ути-пути, Вы писали:
УП>>И никакого шума от скобок. S>Ну так и FPN тоже нормально разбирается безо всякого шума: * + 1 1 2
Они обе отвратительно разбираются, когда уровней в дереве операций более трёх.
С чего ты вообще решил, что Котлин — функциональный, да ещё и распространённый в ФП?? Глупый вброс какой-то. 
А если индеец воткнул себе в жопу перья — он теперь страус штоле?? 
