Из всей функциональщины, пожалуй, лишь 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 строк и сложную ФП-портянку вместо него. Я так понял, что подразумевался один код, написанный по-разному, и у вас есть готовый пример.
Я привёл пример, правда не из ФП, но тоже про то, как после более "правильного" языка код якобы становится лучше.
Здравствуйте, Буравчик, Вы писали:
Б>Они иногда помогают решать проблемы быстрее и проще. Иногда на них дольше и сложнее. А в большинстве случаев — разницы нет.
Приложения можно условно разделить на две большие категории — приложения с состоянием и приложения без состояния. Приложения с состоянием, обычно, писать на функциональном языке можно, но так как состояние надо постоянно обновлять то выходит или криво, или медленно, или и то и другое сразу.
А вот в случае с приложениями без состояния (со слабо выраженным состоянием) уже сильно иначе. Так как количество данных которые нужно обновлять сводится к минимуму, функциональная парадигма позволяет сильно ускорить разработку, т.к. убирает большой пласт логических ошибок связанных с неверным использованием разделяемых данных, синхронизациями, сложностями с написанием модульных тестов и т.д.
Б>Поэтому ФП языки до сих пор не сильно распространены. И поэтому ФП по чуть-чуть все же добавляют в "обычные" языки.
Как мне кажется причина в косности мышления разработчиков и управленцев. Всегда страшно взять новый, не знакомый инструмент, потом думать где и как искать людей. Плюс возрастает требование к квалификации, т.к. функциональный подход требует несколько иного мышления и как следствие людей которые в состоянии мыслить не только в императивном, но и функциональном ключе.
Здравствуйте, kaa.python, Вы писали:
KP>Как мне кажется причина в косности мышления разработчиков и управленцев.
Нет. Причина как раз в рациональном мышлении.
Ибо чтобы взваливать дополнительные риски в виде нового инструмента с непонятными перспективами поддержки и наличия квалифицированных девелоперов надо чтоб этот инструмент давал уже понятный бонус, который хотя бы уравновешивал риски.
А то мода на эзотерику штука проходящая, и обнаружить себя через год без возможности нанять людей для роста проекта перспектива так себе.
KP> Всегда страшно взять новый, не знакомый инструмент, потом думать где и как искать людей.
Совершенно правильно страшно. Ибо перспектива никого не найти куда реальнее чем гипотетические выгоды нового языка, которые может быть проявятся когда нить потом.
KP> Плюс возрастает требование к квалификации, т.к. функциональный подход требует несколько иного мышления и как следствие людей которые в состоянии мыслить не только в императивном, но и функциональном ключе.
И это тоже рациональное мышление.
S>Не, вы говорили про простой цикл на 10 строк и сложную ФП-портянку вместо него. Я так понял, что подразумевался один код, написанный по-разному, и у вас есть готовый пример.
Хмм... интересный у Вас ход мысли! Значит, Вы предполагаете — нет, в данном случае даже требуете! — чтобы T4r4sB, встретив когда-то лет 7 назад в чьем-то коде некую ФП-портянку, не просто ругнулся и пошел бы дальше по своим программистким делам, а бережно сохранил бы данный код на локальный жесткий диск, гуглдрайв, и ленточный накопитель. А в идеале еще и распечатал и повесил бы в рамочке на стену перед монитором, чтобы уж точно не потерять. Ведь иначе жеж пацаны не поверят, что такое бывает, и ответ держать придется перед самим Shtole!
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Хмм... интересный у Вас ход мысли! Значит, Вы предполагаете — нет, в данном случае даже требуете! — чтобы T4r4sB, встретив когда-то лет 7 назад в чьем-то коде некую ФП-портянку, не просто ругнулся и пошел бы дальше по своим программистким делам, а бережно сохранил бы данный код на локальный жесткий диск, гуглдрайв, и ленточный накопитель. А в идеале еще и распечатал и повесил бы в рамочке на стену перед монитором, чтобы уж точно не потерять. Ведь иначе жеж пацаны не поверят, что такое бывает, и ответ держать придется перед самим Shtole!
Зачем юродствовать? Человек написал: «Вместо простого цикла на 10 строк будет портянка из кучи шаблонов с перегрузками и рекурсией». Я попросил пример. Вообще, это азбука продуктивного обсуждения: не переливать из пустого в порожнее, делая глобальные утверждения, а объяснять на примерах. Человек отказался. Ну, его дело.
