Про Kotlin
От: Shmj Ниоткуда  
Дата: 12.12.21 03:02
Оценка: -3 :)
Из всей функциональщины, пожалуй, лишь Kotlin более менее распространен в реальной разработке.

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

Вопрос такой. Насколько эта функциональщина реально помогает? Помогает ли сократить сроки разработки, помогает ли повысить качество?
Re: Про Kotlin
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 12.12.21 03:58
Оценка: +2
Здравствуйте, Shmj, Вы писали:

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


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


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


Котлин не функциональный язык, он позволяет писать в функциональном стиле, но функциональным не является.

А вот Erlang, Elixir и Haskell являются функциональными языками и используются в коммерческой разработке, причем первые два весьма широко. И, да, они помогают решать проблемы быстрее и проще чем если делать тоже самое, но на не функциональном языке.
Re: Про Kotlin
От: scf  
Дата: 12.12.21 07:26
Оценка: +3 -1
Здравствуйте, Shmj, Вы писали:

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


Имхо. ФП — это когда люди, близкие к математике, но далекие от разработки, решили писать программы на чистых функциях. Это оказалось сложно, поэтому им пришлось придумать много новых концепций, упрощающих код. Результат все равно получился сложный, так что ФП в массы не пошел. Но отдельные наработки из ФП универсально полезны, в том числе в императивных языках. Это монадические операции и комбинаторы (map/flatMap/traverse), ADT, иммутабельные структуры данных, тайпклассы и просто более глубокое понимание того, что такое абстракция, что такое модульность кода, что такое модель данных.

К сожалению, в ФП сообществе много зашоренных агрессивных фанатов, но человек с опытом ФП даже на джаве будет писать иначе, чем человек без такого опыта. И его код будет проще и понятнее.
Re[2]: Про Kotlin
От: Буравчик Россия  
Дата: 12.12.21 07:41
Оценка: +3
Здравствуйте, kaa.python, Вы писали:

KP>А вот Erlang, Elixir и Haskell являются функциональными языками и используются в коммерческой разработке, причем первые два весьма широко. И, да, они помогают решать проблемы быстрее и проще чем если делать тоже самое, но на не функциональном языке.


Они иногда помогают решать проблемы быстрее и проще. Иногда на них дольше и сложнее. А в большинстве случаев — разницы нет.

Поэтому ФП языки до сих пор не сильно распространены. И поэтому ФП по чуть-чуть все же добавляют в "обычные" языки.
Best regards, Буравчик
Re: Про Kotlin
От: 4058  
Дата: 12.12.21 09:01
Оценка: -1
Здравствуйте, Shmj, Вы писали:

S>Вопрос такой. Насколько эта функциональщина реально помогает?


Основная проблема заключается в том, что иммутабельность несколько противоречит эффективному использованию вычислительных ресурсов (если говорить про однопоток), следовательно помогать это может в достаточно ограниченных условиях.

S>Помогает ли сократить сроки разработки, помогает ли повысить качество?


Если использовать осмысленно и к месту, т.е. небольшими вкраплениями (как например LINQ), то скорее да.
Re[3]: Про Kotlin
От: blacktea  
Дата: 12.12.21 10:12
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Они иногда помогают решать проблемы быстрее и проще. Иногда на них дольше и сложнее. А в большинстве случаев — разницы нет.


Не согласен, я постоянно ловлю себя на мысли о том, что на Clojure было бы гораздо проще и элегантнее решение. Но, увы. С производительностью у нее не ахти.

Б>Поэтому ФП языки до сих пор не сильно распространены. И поэтому ФП по чуть-чуть все же добавляют в "обычные" языки.


Я вижу две основные проблемы: производительность и порог вхождения.
Re[2]: Про Kotlin
От: T4r4sB Россия  
Дата: 12.12.21 11:12
Оценка: -1
Здравствуйте, scf, Вы писали:

scf>И его код будет проще и понятнее.


Не будет. Вместо простого цикла на 10 строк будет портянка из кучи шаблонов с перегрузками и рекурсией.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[3]: Про Kotlin
От: scf  
Дата: 12.12.21 11:32
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>Не будет. Вместо простого цикла на 10 строк будет портянка из кучи шаблонов с перегрузками и рекурсией.


Я не про упоротых с синдромом молотка, я про сильных программистов, знакомых с ФП.
Re[4]: Про Kotlin
От: T4r4sB Россия  
Дата: 12.12.21 12:18
Оценка:
Здравствуйте, scf, Вы писали:

scf>Я не про упоротых с синдромом молотка, я про сильных программистов, знакомых с ФП.


Тут очень тонкая грань, и иногда она гораздо тоньше, чем кажется
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[4]: Про Kotlin
От: Буравчик Россия  
Дата: 12.12.21 18:48
Оценка:
Здравствуйте, blacktea, Вы писали:

B>Не согласен, я постоянно ловлю себя на мысли о том, что на Clojure было бы гораздо проще и элегантнее решение. Но, увы. С производительностью у нее не ахти.


Ну так динамика же Поэтому и проще, и элегантнее, и производительность не ахти.
Best regards, Буравчик
Re: Про Kotlin
От: vsb Казахстан  
Дата: 12.12.21 18:59
Оценка:
Здравствуйте, Shmj, Вы писали:

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


Kotlin не более функционален, чем, например, Java.

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


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

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


Приёмы функционального программирования помогают:

1. Записывать некоторые участки кода короче и ясней. В основном это касается манипуляций с коллекциями.

2. Чистые функции можно невозбранно запускать в отдельных потоках. Т.е. порой можно переписав определённый участок кода на функциях без побочных эффектов, запускать эти функции в отдельных потоках, тем самым получив ускорение выполнения этого участка кода за счёт многопоточности. Это сделать легко, быстро, не требует особенного понимания многопоточности и это чаще всего не привносит багов. Переписать императивный код на многопоточный, с разделяемой памятью, ручными синхронизациями и прочим: требует высокой квалификации; довольно сложно; могут быть трудновоспроизводимые баги. А уж про всякие свободные от блокировок алгоритмы я вообще молчу, это удел гуру.

3. Упростить иерархию объектов, упростить некоторые паттерны проектирования. Например там, где в традиционном ООП нужно создавать родительский абстрактный метод с несколькими наследниками-реализациями, с ФП достаточно передать лямбду и никакой иерархии уже не нужно.

Это те места, в которых я вижу применение функционального подхода в классических императивных языках (к которым, безусловно, относится Kotlin, равно как и большинство коммерчески применяемых языков).
Отредактировано 12.12.2021 19:01 vsb . Предыдущая версия .
Re[3]: Про Kotlin
От: Shtole  
Дата: 12.12.21 19:12
Оценка:
Здравствуйте, T4r4sB, Вы писали:

scf>>И его код будет проще и понятнее.


TB>Не будет. Вместо простого цикла на 10 строк будет портянка из кучи шаблонов с перегрузками и рекурсией.


Без примеров дискуссия обречена зайти в тупик

А то ведь вполне можно сказать, что вместо простого декларативный запроса, по которому сразу видно, что он делает, будет портянка со вложенными циклами и, скорее всего, с ошибками. Я тут читал (боюсь, человек и так на меня обиделся, поэтому без имён и ссылок, хотя мы все ошибаемся и это не обидно), как некто налетел на исчерпание места на диске. Вскрытие показало, что про одну из явно вызываемых функций он не дочитал, что у неё есть побочный эффект в виде логгинга, местами — значительного. Когда он это выяснил (кажется, кто-то процитировал маны), он негодовал, что разрабы — утырки, ну как можно делать такие опасные для жизни сайд-эффекты, мол?! А я вот считаю, надо или крестик снять (и читать супервнимательно про каждую долбанную императивную функцию), или трусишки надеть и переходить на новый декларативный API, если уж хочется писать в духе 'сделайХорошо(самЗнаешьКак)'. Мне кажется, когда пишут FP-style API, авторы вынуждены думать о таких вещах.

Но, ещё раз, без примеров это пустой разговор.
Do you want to develop an app?
Re[4]: Про Kotlin
От: T4r4sB Россия  
Дата: 12.12.21 19:21
Оценка: :))
Здравствуйте, Shtole, Вы писали:


S>Без примеров дискуссия обречена зайти в тупик


По ФП примером не вспомню.
Но я точно помню, как человек, только что писавший на Расте, на С++ вместо

unique_ptr<T>


написал
Option<unique_ptr<T>>

подазумевая что внутри T точно не зануляющийся

Стал ли от этого код проще для понимания? Да нихрена!
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[5]: Про Kotlin
От: Shtole  
Дата: 12.12.21 19:27
Оценка:
Здравствуйте, T4r4sB, Вы писали:

Не, вы говорили про простой цикл на 10 строк и сложную ФП-портянку вместо него. Я так понял, что подразумевался один код, написанный по-разному, и у вас есть готовый пример.
Do you want to develop an app?
Re[6]: Про Kotlin
От: T4r4sB Россия  
Дата: 12.12.21 19:31
Оценка:
Здравствуйте, Shtole, Вы писали:

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


S>Не, вы говорили про простой цикл на 10 строк и сложную ФП-портянку вместо него. Я так понял, что подразумевался один код, написанный по-разному, и у вас есть готовый пример.


Я привёл пример, правда не из ФП, но тоже про то, как после более "правильного" языка код якобы становится лучше.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[3]: Про Kotlin
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 13.12.21 04:03
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Они иногда помогают решать проблемы быстрее и проще. Иногда на них дольше и сложнее. А в большинстве случаев — разницы нет.


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

А вот в случае с приложениями без состояния (со слабо выраженным состоянием) уже сильно иначе. Так как количество данных которые нужно обновлять сводится к минимуму, функциональная парадигма позволяет сильно ускорить разработку, т.к. убирает большой пласт логических ошибок связанных с неверным использованием разделяемых данных, синхронизациями, сложностями с написанием модульных тестов и т.д.

Б>Поэтому ФП языки до сих пор не сильно распространены. И поэтому ФП по чуть-чуть все же добавляют в "обычные" языки.


Как мне кажется причина в косности мышления разработчиков и управленцев. Всегда страшно взять новый, не знакомый инструмент, потом думать где и как искать людей. Плюс возрастает требование к квалификации, т.к. функциональный подход требует несколько иного мышления и как следствие людей которые в состоянии мыслить не только в императивном, но и функциональном ключе.
Re[4]: Про Kotlin
От: CreatorCray  
Дата: 13.12.21 04:26
Оценка: +3
Здравствуйте, kaa.python, Вы писали:

KP>Как мне кажется причина в косности мышления разработчиков и управленцев.

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

KP> Всегда страшно взять новый, не знакомый инструмент, потом думать где и как искать людей.

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

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

И это тоже рациональное мышление.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Отредактировано 13.12.2021 5:52 CreatorCray . Предыдущая версия .
Re[5]: Про Kotlin
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 13.12.21 04:47
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>И это тоже рациональное мышление.


Да, я знаю что парадокс Блаба не миф. Может быть ты ещё что-то попытался сказать, но я не очень понял
Re[6]: Про Kotlin
От: Аноним931 Германия  
Дата: 13.12.21 08:48
Оценка: -2
S>Не, вы говорили про простой цикл на 10 строк и сложную ФП-портянку вместо него. Я так понял, что подразумевался один код, написанный по-разному, и у вас есть готовый пример.

Хмм... интересный у Вас ход мысли! Значит, Вы предполагаете — нет, в данном случае даже требуете! — чтобы T4r4sB, встретив когда-то лет 7 назад в чьем-то коде некую ФП-портянку, не просто ругнулся и пошел бы дальше по своим программистким делам, а бережно сохранил бы данный код на локальный жесткий диск, гуглдрайв, и ленточный накопитель. А в идеале еще и распечатал и повесил бы в рамочке на стену перед монитором, чтобы уж точно не потерять. Ведь иначе жеж пацаны не поверят, что такое бывает, и ответ держать придется перед самим Shtole!
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Re[7]: Про Kotlin
От: Shtole  
Дата: 13.12.21 08:57
Оценка: +2
Здравствуйте, Аноним931, Вы писали:

А>Хмм... интересный у Вас ход мысли! Значит, Вы предполагаете — нет, в данном случае даже требуете! — чтобы T4r4sB, встретив когда-то лет 7 назад в чьем-то коде некую ФП-портянку, не просто ругнулся и пошел бы дальше по своим программистким делам, а бережно сохранил бы данный код на локальный жесткий диск, гуглдрайв, и ленточный накопитель. А в идеале еще и распечатал и повесил бы в рамочке на стену перед монитором, чтобы уж точно не потерять. Ведь иначе жеж пацаны не поверят, что такое бывает, и ответ держать придется перед самим Shtole!


Зачем юродствовать? Человек написал: «Вместо простого цикла на 10 строк будет портянка из кучи шаблонов с перегрузками и рекурсией». Я попросил пример. Вообще, это азбука продуктивного обсуждения: не переливать из пустого в порожнее, делая глобальные утверждения, а объяснять на примерах. Человек отказался. Ну, его дело.
Do you want to develop an app?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.