Comments 40
Чтобы сделать этот аргумент автора еще более абсурдным, можно переделать так:
Не всегда язык программирования и парадигма определяет качество продукта. Гораздо чаще все зависит от проработки бизнес-требований и техзадания. Поэтому к черту программирование вообще, давайте лучше переучиваться на аналитика.
Вполне возможно. Но из этого никак не следует, что тем кто пишет код этих микросервисов теперь не обязательно изучать парадигмы программирования.
Не поверите сколько есть людей, которые все ещё пишут на Java 5, J2EE Легаси проекты и не планируют менять что-то. Мне кажется, что в таком случае следует выбирать в изучении и применении что-то отличное от Haskell. Не согласны?
Скоро людей, которые пишут на C++/C#/Java, вообще не останется.
Эммм… Сильное заявление.
Писал 2 года на Scala в Spark'e. Писал, писал, всё здорово. Начал менять работу после слов: «Зачем нам один дорогой Scala разработчик, если можно взять 2-3 Java разработчиков и научить работать со Spark?».
Смотрел конференцию когда-то давно (наверное в 2017 году) Евгения Борисова на JPoint, где как раз таки наоборот говорят о закате Scala.
Скоро людей, которые пишут на C++/C#/Java, вообще не останется. Так ли это? Не думаю
У меня вокруг по большей части Spark разработчики. Большая часть из них пишет на Java. Но при этом, насколько я знаю, ни для кого не составляет особого труда между делом наваять сотню-другую строк в Spark Shell, который есть scala в чистом виде.
- не понимаю тех, кто разделяет эти понятия. Разработчик — он либо разработчик, либо не.
- с выходом Java 8 произошел сильный сдвиг в применимости ФП в Java. На сегодня они скорее сближаются, чем отдаляются.
- 2017 это очень давно по меркам развития языков. Все уже тогда ждали scala 3, и сейчас ждут. То что там обещано — выглядит хорошо. И это будет вероятно упрощение.
Именно на этот вопрос — ответ однозначно положительный. Лично я не готов пока переходить на ФП (хм… в основном потому, что никто особо и не предлагает — так бы было неплохо сменить парадигму для освежения мозгов), но его понимание помогает лучше писать и на нынешних императивных языках. Не говоря уж о том, что это лично мне просто интересно (возможно, в силу полученного образования или из-за чтения в детстве развлекательных книжек по математике типа Гарднера/Ллойда/Дьюдени).
Я тоже люблю ФП и тоже считаю, что он не везде применим. Но агрументация, приведенная в статье, кажется мне крайне слабой.
ФП далеко не везде применимо — и это "далеко не везде" в итоге сводится к программированию железа. Но вот если что и есть "далеко не везде", так это программирование железа на низком уровне. Большинство популярных языков программирования (Java, C#, Python, JavaScript и т.п.) отделены от железа виртуальными машинами и интерпретаторами и вполне себе высокоуровневые для использования ФП.
Приносит головную боль при интеграции с готовыми решениями — это да, но прогресс не стоит на месте. В той же скале множество задач можно решить без использования джава-фреймворков. Ну и да, если бы люди всегда предпочитали "старые-добрые" EJB всему "новому и непонятному", то Spring никогда не стал бы "хорошо протестированным и отлично детерминированным решением".
Тратить время на ФП не всегда разумно — здесь все сводится к абсурдному тезису, что кроме кода есть еще архитектура. Кроме кода есть еще много чего, но если мы все-таки говорим про именно код, изучение ФП еще как имеет смысл.
2) Готовые решения — второй случай когда вы не всегда можете пользоваться ФП. Это факт.
3) Предположим ФП позволяет писать идеальные программы. Все, что я хочу сказать — это будет не столь важно со слабой архитурой. Если выбирать между кодом и архитектурой, то выбор должен падать на второе. Это же тоже понятно?
Таким образом, я показал, что, во-первых, есть низкоуровневый слой, где ФП мало применим. Во-вторых, есть моменты и на более высоких уровнях, в которых ФП себя хорошо не проявит. Вы же согласны с этим? Почему тогда это не соответствует теме статьи? Приведите свои аргументы. Мне правда интересно.
Если выбирать между кодом и архитектурой, то выбор должен падать на второе. Это же тоже понятно?
Перед кем может стоять такой выбор?
Вы же согласны с этим? Почему тогда это не соответствует теме статьи?
Я согласен с введением и заключением, но приведенная аргументация меня не убеждает, поскольку каждый тезис можно опровергнуть, используя ту же логику.
Приведите свои аргументы. Мне правда интересно.
Аргументы против ФП? Даже не знаю. Я всегда использую ФП по умолчанию и отступаю от него только при наличии веских причин это сделать, причем происходит это настолько редко, что с трудом поддается какому-то обобщению.
Я согласен с введением и заключением, но приведенная аргументация меня не убеждает, поскольку каждый тезис можно опровергнуть, используя ту же логику.
Приведите пример использования той же логики в утвержднии, что ФП мало применимо на низком уровне и плохо сочетается с большинством готовых решений на многих языках. Я не совсем понимаю, что здесь противоречивого.
Аргументы против ФП?
Вообще не понял к чему вы это написали. Мы вроде обсуждали ограничения ФП, а не отказ от него…
Даже не знаю. Я всегда использую ФП по умолчанию и отступаю от него только при наличии веских причин это сделать, причем происходит это настолько редко, что с трудом поддается какому-то обобщению.
Вы согласны с введением и заключением, но не можете объяснить почему?
Хм… То есть вы действительно не понимаете разницу между "ФП мало применимо на низком уровне" и "ФП далеко не везде применимо"? С первым мало кто будет спорить, но сводить второе к первому — весьма смелое преувеличение.
Про "головную боль при интеграции с готовыми решениями", опять-таки неверно для скалы, которую вы приводите в пример. И в целом аргументация не учитывает прогресс в софтостроении, "старое" не всегда значит "хорошее".
Про "выбор между архитектурой и кодом" — просто абсурд.
И естественно я согласен с вещами типа "инженер не должен мыслить категориями нравится/не нравится", это вроде достаточно очевидно. Каких еще объяснений вы от меня хотите?
И как показывает жизнь, он отодвигается все дальше и дальше. Так что это практически не аргумент.
Контрпример — вполне себе пример глубокого проникновения ФП в "программирование железа". Да, это не читсяй ФП язык, но уж ФП там побольше чем во многих мейнстримовых языках.
это не оно http://www.clash-lang.org/ ?
У одного физика видел интересное наблюдение: «Математики любят упорядочивать свои аргументы порой до степени полной непостижимости для непосвящённых». Когда я пытаюсь писать в функциональном стиле, у меня ощущение, что я занимаюсь чем-то похожим. Возможно с опытом это прошло бы.
Очень интересная заметка, спасибо автору за публицкаю своих мыслей.
Недавно выходила на хабре статья со статистикой по зарплатам и она утверждала что медиана и максимальная зп у Scala программистов выше чем у Java программистов.
Как профессиональный Scala программист я полностью согласен с автором.
Почему же так происходит? Дело в том, что все вышеперечисленное работает напрямую с железом. Железо не знает никаких функций высшего порядка.
Интересно, что вы скажете на тот факт, что иногда вполне себе функциональный (ну ладно, мультипарадигменный) Common Lisp позволяет писать оптимизированный высокопроизводительный код, вполне себе работающий с низкоуровневыми примитивами железа (SSE) и обгоняющий по производительности аналогичный код на C++?
Простите, причем тут С++? Обычно код для операционок, высопроизводительных движков и микроконтроллеров пишут на приемущественно на c, asm. Ни разу не видел прошивку на лиспе. Возможно я слишком молод для такого.
Не могли бы вы назвать игровой движок или какой-нибудь военный/космический проект с микроконтроллером на лиспе? Мне действительно интересно стало. Не особо представляю как там происходит жёсткий контроль управления памятью.
Хотел бы я поглядеть, где автор в Spring нашел изменяемые состояния, которые мешают работать с ФП. На мой взгляд — это фигня какая-то, ничем не подтвержденная.
Что касается «готовых решений» — ну, если вы фреймоврк под Java вы попытаетесь подключить к Haskell, то результат будет точно такой же как и подключение к PHP или JavaScript.
Для ФП языков создаются свои фреймворки, которые удобны для использования
Сумбур какой-то.
Уже почти не важно на чем вы пишете: Python, Java, Scala. Код на любом из этих языков можно обернуть в образ и поставлять контейнером.
С одной стороны вы говорите, что не важно на чем писать, с другой стороны говорите, что ФП может быть помехой. Если вы уже используете JVM или .net, вся экосистема вам уже доступна, все фреймворки и библиотеки к вашим услугам. Разница только в сложности поддержки кода, и для многих задач ФП обеспечит более легкий в поддержке код, особенно если речь идет про потоковую обработку данных и/или конкарренси.
В С# — это, например, Entity Framework и .Net. В Java — это Hibernate и Spring. И почти каждый фреймворк нацелен на работу в привычном нам ООП стиле. Почти всегда эти решения имеют изменяемые состояния и совершенно не пригодны для работы с чистым ФП.
То, что, например, EF работает с мутацией наших моделей, все еще не означает, что мы не можем его использовать из F#. Популярное решение — impure/pure/impure sandwich. Сделайте модели, которые будет мутировать EF, они все равно даже в ООП обычно сразу мапятся в другие модели, и наш собственный код их никак не мутирует. Собственно, конкретно в F# вы можете использовать рекорды с аттрибутом [<CLIMutable>], который позволит десериализацию, но ваш код мутировать эти объекты не сможет.
вы действительно уверены, что ваше время стоит вкладывать в изучение ФП с его теорией категорий? Возможно стоит вложиться в развитие общей архитектуры системы.
Представьте себе, теория категорий в ФП тесно связана с построением архитектуры.
Остается всего одна проблема. Что с ним делать дальше? Как настроить процесс автоматизации? Как настроить “умную” балансировку? Как другим сервисом найти ваш? На эти вопросы ответа у вас может просто не быть!
Я не понял, как это связано с тем, на каком языке написан сервис. С момента, как вы его захостили и выставили публичный апи, всему остальному миру плевать, на чем внутри написан сервис, он использует его как черный ящик со стандартным протоколом коммуникации. Проблемы балансировки и service discovery тоже непонятно какое отношение имеют к парадигме программирования. Если уж на то пошло, есть Azure, который предоставляет автоскейлинг, например, для Azure Functions. И можно писать AF хоть на С#, хоть на F#, хоть на JS, не побоюсь этого слова.
Что касается вывода — да, любой инструмент хорош для подходящей задачи, спасибо. Но ничего нового вы нам тут не сказали.
Функциональное программирование: семь раз отмерь, один раз отрежь