Pull to refresh

Comments 59

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


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

Может быть, имеет место просто ошибка выжившего, потому что можно написать плохой код, пытаясь сделать программу в ООП или структурном стиле, но в функциональном стиле просто ничего не заработает (например, пока ты не поймёшь что такое map, filter и reduce и как они работают, ты даже написать компилирующуюся программу с ними не сможешь, в этом плане ФП проще, а ООП — easy to «learn», hard to master). Или потому что ООП — до сих пор мейнстрим, то до ФП доходят лишь немногие, т.е. люди уже опытные, люди занимающиеся профессиональным развитием, т.е. по определению лучшие программисты.

Я почему-то не сомневаюсь, что если Рича Хики попросить написать программу на Java (очень попросить), а Скотта Влашина — на C#, а Джеральда Сассмана — на C, то они напишут просто отличный код. Точно также мне кажется, что человек, который ушёл с Java на Clojure, или с C# на F#, или с C++ на Haskell, лучше знает Java/C#/C++, чем человек, который ни о чём больше не слышал/ничего больше даже не пробовал/ничего больше даже не искал.
Утверждение
Функциональное программирование помогает сделать код более понятным, предсказуемым и легким для чтения

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

В общем-то стоит это расценивать так — ФП помогает сделать код более понятным, предсказуемым и лёгким для чтения, так как предоставляет мощные средства для абстрагирования. С другой стороны из-за этого появляются две проблемы, одна минорная, другая мажорная:


  • минорная — больше способов написать излишне абстрактный код
  • мажорная — люди, которые не изучили какие-то фичи/либы, в связи с чем считают код с их использованием нечитаемым, а так же транслируют это мнение в массы

Прекрасный пример второго явления — линзы. Есть кто не понимают их и поэтому считают код с ними нечитаемым, а есть те, кто не поленился таки прочитать по ним туториал.

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

Отвечу пастой:


Я много раз пытался объяснить людям положительные стороны функций, но все бестолку. Они ждут что им на пальцах, за пару часов расскажут о целой парадигме. Хотя никто не ожидает что ООП можно объяснить в тот же срок. Люди годами его изучают, придумывают принципы, мнемоники и паттерны. Причем основная масса так никогда его и не осиливает. Но вот функции обязательно надо раскрыть в одной статье. Почти каждый кто стал на них писать не может нарадоваться и всячески толкает и в мир, но для вас это не показатель. Притом что им уже 60 лет. А вот очередное хайповое говно от очередного Гугла учите только так.
Ассемблер умиляет 60 летних.
Вся эта байда с ФП не стоит ни чего. Все из-за стогнации сегмента программирования в последнее время. Библиотеки не поддерживаются, языки меняются. Даже в MIT перестали читать курс о LISP. В свое время читал книгу по LISP. Но скоро понял, что работадателям не интересно ФП. Можно даже сказать, что ФП очень спорная ветвь развития языков программирования. Может комуто и нравится думать как программист функциональщик. Но это всего на пару лет. Потом все выветривается из головы, т.к. мало поддерживается. Книги по ФП очень обстрактные. Не хватает примеров в интернете. А жести и без ФП хватает в ООП.
На счет хайпа могу сказать, что отрасль программирования сама по себе хайповая штука. С ФП хайповый подход не работает. Т.к. за ФП не платят денег, то ФП ни стоит ни чего. Можно только в институте рассказывать как хорошо программировать на ФП и то не весь семестр. Да и функциональщики — народ ленивый. Вместо того, чтобы писать примеры в интернете работающих кейсов они пишут водянистые статьи на хабре.

Вы по-русски-то плохо пишете («обстрактные», «ни чего», «стогнации», «комуто», — всё это не единичные описки, это стиль программирования письма, показатель отношения к потенциальному читателю), но так «авторитетно» пишете, будто всё обо всём знаете. Спорная ветвь! Ничего не стоит! Ха-ха. Именно поэтому в C# продолжают добавлять сопоставление с паттерном, именно поэтому так много проектов на Scala, из-за спорности, конечно.

Существует огромное количество книг по функциональному программированию. Выберите по ближайшему к Вашему стеку ФП-языку и начинайте читать системно. Или не приставайте к авторам ненавистных Вам «водянистых» статей.
UFO just landed and posted this here
Например, хотя где-то была статья с разбором утверждающая что больша часть этих примеров не очень корректна.

RSS агрегатор bazqux.com написан на хаскеле.

Scala считаем функциональным? :) Тогда например Spark, чем вам не пример?
Хмм…
Никакого ООП… Только процедуры и функции, вызываемые в определенной последовательности…
Неужто это
Тот самый стиль, которым [почти]все мы писали в школе на паскале/дельфях, это самый стиль — сейчас в тренде? )))

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

Нет, вы полностью не поняли о чём речь, ФП это не отказ от ООП, это другой подход, данные неизменяемы, циклов нет и т.п.
В Паскале функция — всего лишь процедура, которая может вернуть значение.
Да, можно на Паскале написать все на функциях, но…
Это не функкциональное программирование в широком смысле слова — это процедурное.
Основное, чего не хватает в Паскале (чтобы быть функциональным) — это функций как объекта первого класса и функций высшего порядка, но это будет уже не Паскаль.
Сделал прототип идеи интуитивного способа программирования, похоже ли такое на функциональное программирование?:

А есть какие-нибудь актуальные данные о производительности, потреблении ресурсов и возможностях оптимизации в ФП?
Как-то интуитивно всё это удовольствие выглядит сильно оторваным от реального железа и происходящих там процессов.
На сколько свободно функциональщих может контролировать итоговый код который будет выполняться? Рекурсии, лямбды, линзы это не бесплатно ж всё.
Обычно покупателя в итоге интересует скорость и стабильность работы готовой программы, а не абстрактная «красота кода»/
тыц, хотя пример специфический, но в целом насколько я помню хаскелл один из самых производительных языков, но подводные камни есть — из-за ленивости иногда могут быть большие проблемы с памятью и нужно об этом помнить.
Спасибо. Пример, конечно, спорный :) но пока копался в поисках опровержений пришло таки осознание того что ФП — это таки парадигма, а не конкретный компилятор/среда разработки. И, если не учитывать «набирающий популярность js», действительно может лучше работать на каких-то задачах. Что-то оно действительно позволяет оптимизировать и улучшать, что-то усложняет. Как минимум, для общего развития разобраться будет не лишним.
Haskell, как изначально функциональный язык имеет специально оптимизированную виртуальную машину. Функциональным языкам, к примеру на JVM (Scala) или на .Net (F#), приходится использовать то, что есть в этих, изначально императивных VM. Поэтому в них некоторые сугубо функциональные вещи будут работать медленнее.
Тут было недавно два замечательных поста. Первый — про написание кода на хаскеле, второй — про оптимизацию. В принципе, они отвечают на ваш вопрос. Начать можно со второго из них.

Почему НЕ стоит использовать функциональное программирование (в бизнес-приложениях)?


  • менталитет людей не поменять, зачастую описание (и понимание) задачи приводится императивно ввиде линейного бизнес-процесса или алгоритма
  • многие ФП-языки не типизированные со всеми вытекающими проблемами
  • устаревший и непривычный синтаксис (и понятия) более близкий к математике, нежели к бизнесу
  • система типов базируется на сложных для понимания абстрактных понятиях
  • невозможность привычного дебага
  • отсутствие стейта и сложность мониторинга
  • параллельный мир: сложно интегрировать с уже существующими не ФП-технологиями (коих чуть менее, чем все), особенно там, где появляется state или IO и функции перестают быть чистыми.

Поэтому реально ФП имеет смысл использовать в отдельных законченных модулях типа разбора выражений и rules engine, но писать все приложение на ФП не имеет большого смысла.

Ниже я буду говорить в первую очередь о Haskell


менталитет людей не поменять, зачастую описание (и понимание) задачи приводится императивно ввиде линейного бизнес-процесса или алгоритма

Так оно работает разве что с программистами. Обычно люди разговаривают и объясняют задачи на языке вообще не предназначенном для программирования, часто смешивая императивное "как" и декларативное "что". Более того, обычно объяснения настолько высокоуровневые, что полностью абстрагированны не то что от императивного потока исполнения обычного языка программирования, а даже от жизненного цикла программы.


многие ФП-языки не типизированные со всеми вытекающими проблемами

Наиболее развитые системы типов встречаются именно в ФП, кроме того, типизация в императивных языках развивается только на основе прогресса в области ФП.


устаревший и непривычный синтаксис (и понятия) более близкий к математике, нежели к бизнесу

Был уже как-то язык, который был "близок к бизнесу", COBOL назывался, и что в итоге? При этом наиболее популярные нынче C-подобные языки близки к бизнесу примерно никак. "Математичность" же синтаксиса — это реализация вполне разумного стремления сделать код читаемее человеческой речи, которая плохо структурированна, не имеет ни операционной, ни денотационной семантики и вообще слабо подходит для описания вычислений. Попробуйте заменить все формулы в учебниках по математике, физике, химии и инженерному делу на словесные описания — да люди потом замучаются это всё читать.


система типов базируется на сложных для понимания абстрактных понятиях

Любая система типов базируется на одном и том же. Разве что если в системе типов фич больше, то и теория под ней, вероятнее всего, обширней. Но фичи, знаете ли, вводятся не затем, чтобы сделать что-то сложнее и элитарнее.


невозможность привычного дебага

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


отсутствие стейта и сложность мониторинга

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


параллельный мир: сложно интегрировать с уже существующими не ФП-технологиями (коих чуть менее, чем все), особенно там, где появляется state или IO и функции перестают быть чистыми.

Да, действительно, проблема есть. Так же как и проблема того, что существующих не-ФП технологий не так много. Именно поэтому тот же Haskell обычно используют там, где готовых решений не так уж и много, а большую часть кода придётся писать самостоятельно независимо от выбора языка.


В общем-то все эти претензии вместе взятые выглядят как "это не императивное программирование, меня этому не учили, мой опыт императивного программиста на этот глобус не натягивается, мне это не нравится, да и тратить своё время на то, чтобы этому учится, я не хочу".

Обычно люди разговаривают и объясняют задачи на языке вообще не предназначенном для программирования, часто смешивая императивное "как" и декларативное "что".

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


Был уже как-то язык, который был "близок к бизнесу", COBOL назывался, и что в итоге?

До сих пор индустриальный стандарт в банковской системе, а специалисты по нему наиболее высокооплачиваемые. Но не суть.


"Математичность" же синтаксиса — это реализация вполне разумного стремления сделать код читаемее человеческой речи, которая плохо структурированна, не имеет ни операционной, ни денотационной семантики и вообще слабо подходит для описания вычислений.

То есть вас не смущают в Scala идентификаторы, составленные из символов !\$%&/|, которые к тому же могут оказаться вообще всем чем угодно. То есть любой человек, взглянув на код "a! b" без детального анализа контекста сразу же поймет, что это эквивалентно a.sendMessage(b), только гораздо лаконичнее и математичнее. Императивные языки используют минимальный набор простых и понятных управляющих статичных конструкций (в минимуме — условие и цикл), в то время в функциональном языке вся логика — это композиция вычислений, к тому же динамически связанная.


Но фичи, знаете ли, вводятся не затем, чтобы сделать что-то сложнее и элитарнее.

Этим и отличаются академические языки от промышленных. В академических (таких как Хаскель или Скала) фичи вводятся просто чтобы было, например на основе чьей-то научной работы. Затем некоторые из них мигрируют в той или иной форме в промышленные, и только когда доказана их полезность.


В общем-то все эти претензии вместе взятые выглядят как "это не императивное программирование

Точно также можно сказать в ответ, "я выучил ФП, и теперь все, кто его не умеет или не хочет — говно".
Мои претензии — это не стоит рекламировать ФП как универсальную парадигму для всего (впрочем как и любую другугю). Количество задач там, где ее применение оправдано, достаточно ограниченно (посмотрите: сейчас это в основном потоковая обработка данных и распределенные вычисления). Для остальных задач проще и дешевле использовать традиционный подход.

Как раз человеку очень хорошо понятна последовательности действий, которая интуитивно связана с концепцей времени. И на этом языке можно вести диалог с заказчиком: сходи туда, получи такие-то данные, вызови этот интерфейс, затем вычисли то, и сохрани там и т.д…

Да, а ещё человек вместо скажет "возьми все записи повявившиеся после T времени", что уже вполне себе декларативно. Судя по вашему высказыванию — моё вы даже не пытались читать. Я говорю, что человек говорит не на языке программирования, это раз. Два это то, что на функциональных языках тоже можно писать императивные сценарии, но, в отличии от императивных языков, это можно делать на достаточно высоком уровне абстракции, чтобы приблизиться к человеческому описанию.


До сих пор индустриальный стандарт в банковской системе, а специалисты по нему наиболее высокооплачиваемые. Но не суть.

Интересное у вас отношение к дремучему легаси.


То есть вас не смущают в Scala идентификаторы, составленные из символов !$%&/|, которые к тому же могут оказаться вообще всем чем угодно.

В хаскеле они меня точно не смущают потому-что:


  • как правило это часто используемые стандартные операции
  • чем угодно они оказаться могут лишь настолько же, насколько чем угодно может оказаться функция, имя которой написано латинскими буквами

То есть любой человек, взглянув на код "a! b" без детального анализа контекста сразу же поймет, что это эквивалентно a.sendMessage(b), только гораздо лаконичнее и математичнее.

Не поймёт, но, во первых, не разу не видел, чтобы операторы для таких штук использовали, а во вторых, и a.sendMessage(b) много информации человеку не даст.


Императивные языки используют минимальный набор простых и понятных управляющих статичных конструкций (в минимуме — условие и цикл)

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


в то время в функциональном языке вся логика — это композиция вычислений, к тому же динамически связанная

Что подразумевается под динамическим связыванием? Это вроде как в джавах всяких активно используют полиморфизм подтипов, тайпкастинг и null-reference, не? Да и что плохого в композиции вычислений? Считаете, что использование каждый раз новых велосипедов вместо переиспользования один раз написанного кода лучше?


Этим и отличаются академические языки от промышленных. В академических (таких как Хаскель или Скала) фичи вводятся просто чтобы было, например на основе чьей-то научной работы. Затем некоторые из них мигрируют в той или иной форме в промышленные, и только когда доказана их полезность.

А доказанной полезность фичи является видимо тогда, когда какой-нибудь старый сумасшедший (но очень уважаемый в IT) дед скажет, что она нужна, да?
Мне вот лично совершенно непонятно как можно объективно доказать пользу/вред фичи без введения её в какой-то популярный язык и последующего подробного исследования её использования. Субъективно же обычно те, кто освоил фичи из ФП на должном уровне, уже не хочет от них отказываться.


"я выучил ФП, и теперь все, кто его не умеет или не хочет — говно"

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


Мои претензии — это не стоит рекламировать ФП как универсальную парадигму для всего (впрочем как и любую другугю). Количество задач там, где ее применение оправдано, достаточно ограниченно (посмотрите: сейчас это в основном потоковая обработка данных и распределенные вычисления).

Вообще-то стоит, ибо почти все ограничения применения с ФП связанны лишь с его непопулярностью.


Для остальных задач проще и дешевле использовать традиционный подход.

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

Хорошо, я вас понял. Зайдем с другой стороны. Ответьте тогда на вопрос, почему на сегодняшний день при всех своих очевидных преимуществах ФП-языки так не популярны? Более того, за всю историю они никогда не были особо популярными? И тенденция к их популяризации в будущем тоже не радует. О них внезапно всмопнили десять лет назад, когда понадобилось масштабировать параллельные вычисления. Какой вы можете назвать общеизвестный проект, который написан на вашем любимом Хаскеле? У какого ФП-языка экосистема хотя бы приблизилась к объему C/C++/Java/JS? И какие будут соображения о причинах этого? Можете даже выбрать:


  • ФП сложны для понимания. Большинство людей обходится более простыми и понятными методами.
  • ФП не обучают в ВУЗах. На рынке мало специалистов по ФП, а соответственно возрастают риски и стоимость проекта.
  • ФП эффективны в решении определенного круга задач, но не подходят в качестве универсального инструмента.
  • ФП не подходят для больших проектов и не совместимы с используемыми там методологиями.
  • На ФП плохо моделировать предметную область, например сущности и отношения.
Ответьте тогда на вопрос, почему на сегодняшний день при всех своих очевидных преимуществах ФП-языки так не популярны?

Исторически так сложилось. Процитирую одного умного человека: "Одно из характерных качеств хаcкеля как языка и сообщества в том, что они вместе не стремились стать популярными, дав простой ответ на популярные вопросы.
Вместо этого выстраивали логичный principled путь решения реальных проблем, а не быстрого проникновения в сердце прохожего интересующегося."


Так вот, для того, чтобы выстроить логичный principled путь решения реальных проблем в PLT требовались многие годы, так же как и Haskell для того, чтобы стать production ready языком требовалось 15 лет. Это очень сильно отличает его от того же JS, который задизайнили за неделю, выпустили на свет как есть, а дальше строго берегли обратную совместимость. Но именно поэтому JS сейчас на коне, а Haskell есть там, где он есть. JS вышел на рынок и пусть крайне посредственно, но дал инструмент для решения задачи, которая без него никак до этого не решалась. Haskell стал production языком только через 15 лет после своего появления, когда все ниши уже заняты, а проблемы хоть и крайне отвратно и хрупко, но решены.


Ещё одной проблемой является то, что он другой. От программиста, который уже сносно программирует на языках надёжно занявших свои нишы, он требует учиться заного. Его предыдущий опыт ему тут не помогает, а даже наоборот мешает, от чего многие наверняка даже не освоив основы бросают язык, называют его сложным, перемудрёным и не нужным. Это наверное самая большая проблема, переучить кучу людей очень дорого, особенно когда они сами не хотят переучиваться.


Какой вы можете назвать общеизвестный проект, который написан на вашем любимом Хаскеле? У какого ФП-языка экосистема хотя бы приблизилась к объему C/C++/Java/JS?

Мы уже кажется выяснили, что ФП не популярен. Что вы этим хотели сказать совершенно непонятно.

>Зайдем с другой стороны.

Ну давайте. Еще с одной, если не против.

А что у нас вообще популярно? Отвечаю не думая — web у нас популярен. А что такое web? Это javascript, так как де-факто на сегодня писать на чем-то другом уже можно, но пока еще сильно неудобно.

>ФП-языки так не популярны
Ну вот а теперь, попробуйте мне ответить, почему вы думаете, что ФП не популярно в среде javascript-еров? Да, это язык не чисто функциональный, побочные эффекты налицо, но в тоже время, функция есть сущность первого класса, функции высшего порядка возможны, и если чего нет — так это по большому счету системы типов.

При этом многие части функциональной парадигмы не просто популярны, а давно популярны. Тот же пресловутый jquery с его $ — это в значительной степени функциональная идея (я видел как утверждения, что это монада, так и опровержения). И таких библиотек, в которых некоторые части ФП давно и успешно применяются — их полно. map, fold, reduce — так просто на каждом углу.

И это не 10 лет назад было, наоборот, это прямо сейчас такая тенденция.

Это не значит, что в них все хорошо. Скажем, undescore аргументировано ругали за то, что в исходном виде API таков, что не удобно применять каррирование, было бы лучше поменять порядок аргументов некоторых функций. Но это уже частности.

Вам видится, что ФП не популярно? Мне пока видится ровно наоборот, как и тенденции.

То, что стало можно передать функцию в качестве параметра — это еще не ФП, а лишь элементы ФП. Да, многие языки переняли некоторые идеи ФП для удобства использования в определенных операциях, но при этом весь основной дизайн приложения остается в ООП и императивной парадигме. В частности, упомянутый filter/map/fold используется теперь как инструмент работы с коллекциями, и на нем в большинстве случаев и заканчивается весь перенятый ФП. И это нормально, когда в языки портируют наиболее интересные идеи, использование которых будет оправдано в определенных кейсах. Но ФП далеко не серебряная пуля, как заявляет автор и другие приверженцы, и сильно усложняет дизайн приложения например там, где появляется мутабельный стейт (например база данных — здесь ФП наполняется императивными хаками ввиде IO/do), или там, где необходимо моделирование сущностей/свойств и их отношений.


Вам видится, что ФП не популярно? Мне пока видится ровно наоборот, как и тенденции.

Если следовать всем тенденциям, то и блокчейн непременно должен быть в каждом пылесосе и утюге. :) О причинах непопулярности pure-ФП языков сказал предыдущий оратор в треде.

Если бы ФП было в javascript везде — я бы так и сказал, что оно уже захватило мир :) Да, пока это фрагменты.

И я вам так скажу — на мой взгляд, ФП именно таким образом станет популярным — путем интеграции интересных идей туда, где они приносят пользу. И этот процесс мне кажется как раз и идет.
>До сих пор индустриальный стандарт в банковской системе, а специалисты по нему наиболее высокооплачиваемые. Но не суть.

Эх. Люблю я эту тему. Знаете, я уже 10 лет в этой самой «банковской системе», и что характерно — ни разу не видел кобола. Как впрочем и хаскеля. Может про кобол — это уже давно легенда?

Я тоже думал легенда, но вот нет. Американские и некоторые европейские банки до сих пор используют процессинг на коболе, и вроде как менять не собираются. У нас в компании в банковском департаменте до сих пор сидят коболисты и что-то делают. Рынок, конечно, ограниченный, но время от времени всплывают предложения для кобола.

Знаете, я не могу считать скалу академическим языком. Вот раньше мог, а сегодня после Spark — не могу, и все. Может когда-то и был, а сегодня это чистой воды промышленное программирование, вполне себе ежедневное. Даже при том, что в нашем отделе, например, любители скалы и сторонники Java 8 делятся где-то пополам, в лучшем случае, т.е. позиции Java на сегодня более сильны. Но при этом и те и другие пользуются Spark, из которого уши скалы торчат буквально там и тут ;)

К скале у меня особое отношение — я ее вообще не считаю ее за язык, мне жалко людей, которые на ней пишут, и также жалко тех, которые потом будут поддерживать этот код.


Скала — это именно академический язык, помойка, в которую Одерски жадно набросал все, что только можно из других языков программирования в надежде, что это привлечет рыбех всевозможного калибра. Во времена застоя джавы он начал сильно форсить скалу как улучшенную джаву (потом, правда диаметрально поменял свое мнение, говоря, что скала — это совершенно другой язык), и на этот крючок попалось много компаний и разрабов (в т.ч. и я). Основным профитом заявлялась возможность при помощи системы типов писать DSL-и для предметной области. Но что-то как-то не сильно взлетело. Язык оказался сложным, громоздким, медленным в компиляции, трудночитаемым, не таким интероперабельным с Java, а также проблемным в совместимости с собственными версиями. Код зачастую превращался в мультипарадигменное месиво, которое было сложно контролировать (причем парадокс: те, кто только осваивал скалу писали лучший код, чем те, кто уже что-то на ней умел). Early-adopters вцелом оставались недовольными и зачастую переписывали свой стек обратно на Java. А тут еще Java 8 с лямбдами подоспела, что вызвало массовый обратный отток разрабов. Те же, кого не устраивала Java уже активно смотрели в сторону Котлина, который ехидно заявлял, что не ставит целью соперничать со скалой. В конце-концов, Одерски понял свою ошибку, но время уже было упущено.


Фактически единственной областью, где скала зарекомендовала себя — это потоковая обработка данных, и то во-многом благодаря сложившимся обстоятельствам в виде Akka. Чувствуя долгожданный профит, Одерски с друзьями запиливает Typesafe (ныне Lightbend), куда сваливает все необходимое для законченного решения.


Ну и как бы что Spark? У него есть удобоваримый Java-интерфейс. Да, написан на скале. С таким же успехом он мог бы быть написан на Java/Kotlin/Groovy.

А можно цифры? Сколько вот это вот «массовый отток»? 2? 3 человека? Просто так цифрами кидаться — быть Львом Толстым. Чувствуется ваша личная неприязнь (которая имеет место быть, мы живем в мире, где каждый имеет свое мнение), которая выдается за мнение большой группы людей, при этом пруфоф нет. И спасибо за вашу жалость =)
>Ну и как бы что Spark?
Да ничего спарк. Вот представьте себе, совершенно реальный ежедневный use case: аналитики, а не программисты, лезут в Spark Shell, и пишут там скрипты. Не, они не сами это придумали, это я их научил, если честно. Но: Spark Shell это Scala Repl, просто в чистом незамутненном виде, с двумя или тремя переменными в контексте от спарка.

То есть, люди ежедневно пишут на скале, при этом не испытывая каких-либо неудобств. И им совершенно пофиг, что вам их жалко :)

Ну то есть, что описанные вами недостатки имеют место — я соглашусь без вопросов. Но однако же спарк меняет все дело, потому что это рабочая лошадь современной BigData, и он попутно делает скалу вполне промышленным языком, а не академическим экспериментом.

>С таким же успехом он мог бы быть написан на Java/Kotlin/Groovy.
Вот когда напишут — тогда и поговорим. Что на груви большого написали? gradle? Я так подозреваю (хоть я и не измерял, конечно), что он в разы меньше спарка по размеру кода. И в те же разы проще.
>многие ФП-языки не типизированные со всеми вытекающими проблемами
Не, ну вы что, серьезно? Ну да, кложа не типизирована. Но система типов хаскеля одна из наиболее развитых вообще, скала типизирована, ML и F# тоже.

И я бы на сегодня скорее сказал, что широко распространенный не-ФП язык Java скорее имеет «все вытекающие проблемы» из-за некоторых исторически сложившихся слабостей системы типов.
В бизнес приложениях фукциональный подход нисколько не хуже императивного. А насчёт простоты — есть пример 1С. Они сделали систему, которую должен может (по-идее) настраивать каждый бухгалтер. Там и язык русский, и уровень входа низкий… Но, таких бухгалтеров всё равно нашлось считанные единицы. И появились 1С-программисты, как жизненно необходимый для предприятия ресурс. Со временем, система усложнялась, бухгалтера уже отреклись от программирования, но язык остался таким же. Да, в 1С можно быстро создать бизнес приложение, но сопровождение типовых конфигураций превратилось в ад. Как вам процедуры/функции на тысячи строк?

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

UFO just landed and posted this here
Джойстик на последнем фото судя по всему BMW, очень глючный на практике оказался, т.е. показывать его как пример хорошего решения не очень правильно.
У меня есть большая и сложная модель из десятков тысяч объектов. Я хочу внести в нее некие пробные изменения и узнать как эти изменения повлияют на целевую функцию, потом новую порцию изменений и так далее. В функциональном стиле функция, которая вносит пробные изменения должна возвращать новую версию этой модели, но с изменениями. Учитывая что модель очень сложная (еще и формируется лениво), это задача невероятно сложная и в любом случае очень тормозящая работу.
Конкретно в этой задаче заменил на чистые максимально возможное количество функций. Код стал понятнее, это правда.

Даже если бы я действительно был "должен" думать о ФП, я мог бы думать так: "Оно мне надо?"
Как религия — точно нет. Как увлечение — не зацепило то, что о нём знаю. Как инструмент — не вижу столько пользы, сколько затратится на смену парадигмы. Время-то утекает, и мне больше нравится расти в глубину, чем в ширину, утилизируя освоенное, а не отбрасывая.
Я выбрал путь и стою на нём. А ФП? Забавная штука, полезная к месту… Но вот не должен я ему ничего, и всё тут.

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

Всё-таки, это относится к ФВП, а композиция, это применение функции к результату выполнения другой функции.
А статья нужная, хоть и несколько сумбурная :)
Ну, а что же еще? Текст да, страдает местами.
UFO just landed and posted this here
Вопрос к фанатам ФП:
есть ли полноценный язык реализующий концепцию языка UnLambda?

А что вы имеете в виду под концепцией? Насколько я могу судить, Unlambda — это базовые примитивы ФП, которые есть что в Хаскеле, что в Scheme.

Спасибо большое, очень познавательная статья. Скажите, а есть какая литература по функциональному программированию?
Как пример:
Scala
Профессиональное
программирование З-е издание
ISBN 978-5-496-02951-3

Книги по Java 8 +…

Спасибо большое за сведения
Спасибо большое за сведения
Sign up to leave a comment.

Articles