Конец хайпа: Что ждёт язык Scala дальше

Original author: Li Haoyi


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


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


В ответ на это один из очень активных членов сообщества (Li Haoyi) описал своё видение дальнейшего пути языка Scala.


Статья у него получилась интересной, посему решил перевести её.


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

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


Этот пост был вдохновлен следующим твитом:


Обидно смотреть, как увольняют друзей из Typesafe/Lightbend, но, как я всегда говорил, бесплатные вещи продавать тяжело.

Я действительно задаюсь вопросом об использовании Scala сейчас. Это конечно не "конец Clojure", но, похоже, Scala достигла пика примерно в 2016 году. Хотя у меня нет данных, подтверждающих это.

Jamie Allen


Джейми отмечает, что общественный интерес к языку программирования Scala, похоже, уменьшился: меньше интереса к встречам, меньше интереса к конференциям и т.д. Я вижу примерно то же самое. Несмотря на то, что конференции, посвященные Scala, ориентированные на энтузиастов, по-прежнему актуальны (или были, пока COVID19 не закрыл мировую экономику), я думаю, что нет сомнений, в инженерном сообществе сейчас гораздо меньше разговоров о Scala.


Думаю, что это снижение интереса не только реально, но также ожидаемо, учитывая типичный «Hype Cycle», который следует за любой новой технологией:



Вначале Scala накрыла волна хайпа, которая откровенно удивила даже меня: хайп вокруг расширения синтаксиса, вокруг реактивной архитектуры, вокруг функционального программирования, вокруг проекта Apache Spark. Потом большая часть этой шумихи сошла, и в сообществе и за его пределами был период негатива. С тех пор все утихло и остался разумный, скучный язык, который постоянно развивается и предоставляет отличную платформу для общей разработки программного обеспечения.


Прошлое: пик завышенных ожиданий


Хотя язык Scala был создан в 2004 году, он начал активно развиваться только в начале 2010-х годов:


~2009: Twitter начал использовать язык в продакшене


~2010: Первый релиз библиотеки функционального программирования Scalaz


~2011: Была основана компания Lightbend, продвигающая Scala и связанные с ней технологии


~2014: Apache Spark был написан на языке Scala


~2015: Первый релиз библиотеки функционального программирования Cats


Хотя до этого в сообществе Scala не было никаких сомнений, это были основные вехи, которые пробудили интерес к языку. Неудивительно, что благодаря широкому коммерческому внедрению, коммерческой поддержке и таким убийственным продуктам по работе с большими данными, как Apache Spark, общественный интерес возрос. Многие из этих усилий были направлены на следующие области:


Раздвигая границы синтаксиса


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


В качестве примера можно привести ряд проектов, таких как HTTP-клиент Databinder Dispatch, библиотека структуры данных Scala-Graph или средство сборки SBT:


// Making a HTTP request and processing the output in Databinder Dispatch
executer(:/(host, port) / target << reqBody >- { fromRespStr })

// Constructing a simple directed graph with labelled edges in Scala Graph
val flights = Graph(
    (jfc ~+#> fra)(Flight("LH 400" ,10 o 25, 8 h 20)),
    (fra ~+#> dme)(Flight("LH 1444", 7 o 50, 3 h 10))

// Append the contents of a URL to a File after filtering through grep using SBT
url("http://databinder.net/dispatch/About") #> "grep JSON" #>> file("About_JSON") !

// Search for uses of null in the source directory using SBT
"find src -name *.scala -exec grep null {} ;"  #|  "xargs test -z"  #&&  "echo null-free"  #||  "echo null detected"  !

Многие из этих библиотек развивались с первых релизов Scala и с тех пор перешли к более простым API на основе методов. Оказалось, что именование операторов >- ~+#> или #&& хотя и было возможно, не всегда было мудрым решением. Тем не менее, нет никаких сомнений в том, что расширение границ синтаксиса Scala с использованием операторов и предметно-ориентированных языков было одной из главных достопримечательностей раннего Scala.


Реактивная Архитектура


Реактивная архитектура, проталкиваемая Lightbend через их среду Akka Actor, была еще одним большим усилием. Это способ написания кода, сильно отличающийся от «нормального» кода, который обычно изучают в школе, но позволяющий получить более высокий уровень параллелизма и производительности чем при написании кода в традиционном стиле.


В начале Akka Actors пожертвовали многим из того, чем является Scala: полным отсутствием типобезопасности между акторами, запретом блокировок API и многими другими особенностями. Работа с акторами Akka была в основном их собственным языком, встроенным в Scala, но со своими собственными соглашениями, синтаксисом и семантикой.


Совсем недавно, с релизом Typed Actors и Reactive Streams, разработчики получили больше типобезопасности, которой обычно ожидают в программах на Scala. Я думаю, что также произошел сдвиг в настроении сообщества: вместо того, чтобы относиться к реактивным архитектурам как к универсальному решению всех проблем, теперь они рассматриваются как один из возможных подходов для одного конкретного класса проблем. Это в основном соответствует моему опыту использования этих методов в моих собственных приложениях.


Функциональное программирование


Функциональное программирование в Scala лучше всего иллюстрируется проектами Scalaz и Cats. Эти две библиотеки пытаются перенести большую часть методов функционального программирования с языка Haskell на язык Scala: большое внимание уделяется таким понятиям, как монады или аппликативы, избегая объектно-ориентированной стороны языка для более чистого функционального стиля.


Две библиотеки имеют разные стили, и обе они активно используются сегодня в сообществе. Религии стало меньше, и все признают функциональное программирование как один из возможных стилей написания приложений для Scala.


Apache Spark


Последним крупным проектом, вызвавшим ранний ажиотаж в Scala, был Apache Spark. Распределенная среда обработки больших данных, Apache Spark использовала функциональный стиль Scala и сериализуемые лямбды для сбора общих коллекций, таких как map, filter и reduce, распределенных по вычислительному кластеру, обрабатывающему огромные объемы данных. Apache Spark позволяющий писать на порядки меньшие объёмы кода для конвейерной обработки больших данных и работающий на порядки быстрее раннего API Hadoop — мгновенно стал хитом.


Apache Spark был киллер фичей Scala. Огромная часть сообщества Scala использует Scala только потому, что им нужно каким-то образом взаимодействовать со Spark.


Apache Spark теперь поддерживает API-интерфейсы для разработчиков на многих языках: SQL, R, Python. Причем Python является самым популярным вариантом. Исходный API, построенный на API из коллекций, был в основном заменён на API более похожий на SQL, который лучше оптимизируется, что является важным фактором при работе с огромными наборами данных, для которых часто используется Apache Spark. Тем не менее, кодовая база Apache Spark по сей день остается в основном на Scala.


Дно разочарования


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


Трудно понять точно когда прошел хайп, возможно, в 2016-2018 годах.


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


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


Меня совсем не удивляет, что в результате люди оказались со мной на «Дне разочарования».


Настоящее: на склоне просветления


Scala получила свой хайп в начале 2010-х, после чего последовал спад в середине-конце 2010-х. Куда же теперь двигается Скала?


Стабильно растущее сообщество



Несмотря на очевидный спад интереса, использование Scala продолжает расти. Я поддерживаю большое количество библиотек с открытым исходным кодом, и количество уникальных IP-адресов, загружающих эти библиотеки из репозитория пакетов Maven Central, выросло чуть более чем в 2 раза за последний год. Несмотря на некоторые различия в количестве загрузок или показателях для каждого отдельного пакета, в целом они достаточно близко соответствуют этой тенденции.


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


Если вы посмотрите на самые последние рейтинги Redmonk или Tiobe, они оба показывают, что Scala стабильно колеблется в непосредственной близости от основных языков, заняв 13 и 28 места соответственно. Не очень популярный, но не малоизвестный язык.


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


Надежная платформа для использования в производстве


Несмотря на снижение хайпа, язык Scala чувствует себя лучше, чем раньше:


  • За последние несколько лет инструмент для сборки SBT сильно развился, стал значительно быстрее и проще в использовании.
  • Если вам не нравится SBT, у вас есть выбор: многие организации используют Bazel или Pants со Scala, в то время как мой собственный инструмент для сборки Mill стабилен и широко используется.
  • Новые инструменты, такие как Coursier, формируют новую основу для экосистемы: используются инструментами от Ammonite до SBT и Mill
  • Проект Metals даёт поддержку Scala для VSCode, Sublime Text и любого другого редактора с поддержкой языкового сервера.
  • Собственный плагин Intellij для Scala продолжает совершенствоваться: быстрее, точнее и с поддержкой новых инструментов, таких как скрипты Ammonite или инструмент сборки Mill.
  • Новая библиотека коллекций в Scala 2.13 хорошо почистила API и значительно повысила производительность во многих случаях (например, ускорение на 25-40% в Sjsonnet)
  • «Полировочные» функции, такие как сопоставление с образцом в строках или подавление предупреждений, продолжают улучшать жизнь каждого.
  • Компилятор значительно ускорился, код компилируется буквально в два раза быстрее, чем всего три года назад.


Хотя спецификация языка, за последние несколько лет, почти не изменилась, количество качественных улучшений в целом трудно переоценить. В 2017 году, любая инженерная организация, использующая Scala, за сокращение времени компиляции вдвое осыпала бы вас деньгами!


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


Широкая и разнообразная экосистема


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


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


Множество стилей в Scala можно рассматривать как благо: вместо того, чтобы рассматривать его как способ разделения сообщества, это способ объединения сообществ, которые иначе никогда бы не взаимодействовали друг с другом. Без Scala эти сообщества могут работать независимо друг от друга в системах на Haskell, Python, Java и Go. Сконцентрировавшись на общих чертах, а не отличиях, Scala позволяет сообществам совместно работать над тем, что им выгодно, при этом сохраняя всё то, что делает каждое суб-сообщество уникальным.


Я не делаю сразу архитектуру своего кода реактивной с использованием Actors, но я создавал продакшен код активно использующий акторы, когда это было надо. Я не всегда использую чисто функциональные методы программирования, но я использовал довольно эзотерические конструкции, такие как Free Applicatives, когда они полезны. Я думаю, что сообщество в целом развивалось аналогичным образом: ценило различные стили и использовало их, где это уместно, без догматизма, который отравлял первые дни Scala.


Будущее


Итак, что интересного, как я думаю, нас ждёт в будущем Scala?


Для меня сам язык Scala находится в относительно хорошем состоянии. Дня написания современного Java-кода достаточно, чтобы избавить меня от иллюзий, которые «догнали» другие языки, равно как и потратить дни, пытаясь (безуспешно) упаковать проект Python в отдельный исполняемый файл (Здравствуйте, Azure-CLI!).


Где самый большой потенциал, для представления Scala новым людям или новым вариантам использования, которые до этого момента были полностью вне границ. Я думаю, что есть две основные вещи:


Удобство использования

В самом начале Scala не хватало одного: возможности новому программисту быстро начать работу с кодовой базой и быстро стать продуктивным. Неважно, использовали ли вы императивный стиль, реактивный стиль с акторами или чистый функциональный стиль с FP-Cats / Scalaz: кому-то придется нелегко.


Почему так должно происходить?


В качестве контр-примера разработчики обычно приводят Python как простой язык для начала: «исполняемый псевдокод», который они называют. Новые программисты изучают Python. Непрограммисты изучают Python. Когда люди пишут код на доске с маркером, они часто пишут на Python. Хотя производительность, параллелизм или масштабируемость в Python сомнительны, его простота, в начале, не имеет себе равных.


Почему Scala не может быть так же легка на старте, как Python?


Ответ на этот вопрос — цель всего набора библиотек, который я поддерживаю. Многие из моих библиотек являются копиями, бесстыдными клонами их эквивалентов на Python. Например:


  • Ammonite, клон IPython REPL
  • uPickle, клон Python json module
  • PPrint, клон Python pprint module
  • Requests-Scala, клон Kenneth Rietz' Requests module
  • OS-Lib, клон Python os, sys, и shutil modules
  • Cask, клон Armin Ronacher's Flask library

Оказывается, вы можете сделать Scala таким же простым на старте, как и Python. Со всеми слабостями Python — производительностью, параллелизмом, удобством обслуживания — Scala уже отлично справляется. Scala обладает потенциалом языка с удобством и гибкостью Python, производительностью и масштабируемостью Java или Go, а также типо-безопасностью, выходящей далеко за пределы любого из этих вариантов. В буквальном смысле лучшее из обоих миров!


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


Scala Native


Scala.js продемонстрировал целесообразность использования Scala на альтернативной платформе: он скомпилирован для Javascript, а не для JVM, имеет популярную экосистему, сообщество и переносит язык Scala в браузер, где его нельзя было использовать ранее.


Scala-Native обещает еще большую революцию: компилируя Scala в автономные бинарные исполняемые файлы. Это позволит использовать язык Scala в сценариях, где время запуска и оверхед JVM или Javascript недопустимы.
Как Scala.js принес Scala в браузер, так Scala-Native обещает привести Scala к множеству новых окружений:


  • Инструменты командной строки, такие как git, ls, rsync и т.д., которым критично время запуска JVM.
  • Фоновые процессы или демоны, где из-за значительных накладных расходов памяти JVM использование Scala проблематично.
  • Разработка мобильных приложений для iOS на iPhone и iPad, одном из самых распространенных в мире потребительских вычислительных устройств.
  • Десктопные приложения, в которых запуск JVM слишком медленный или сборка JVM слишком громоздкая.
  • Глубокая интеграция с нативными библиотеками, такими как библиотека машинного обучения Tensorflow.

Программы такого рода традиционно написаны на небезопасных языках, таких как C или C ++. Более поздние реализации часто пишутся на Rust или Go, и существует целая индустрия не-C языков программирования, таких как Nim, Zig или Crystal, которые также пытаются занять эту нишу. Scala-Native обещает занять нишу не новым языком, а уже популярным языком с богатой экосистемой библиотек и инструментов.


Scala-Native будет намного сложнее добиться успеха, чем Scala.js. В частности, Scala.js может сосредоточиться на компиляторе, а затем делегировать его существующей среде исполнения Javascript, в то время как Scala-Native должен построить свою собственную среду исполнения с самых основ: многопоточность, сборка мусора, циклы событий и так далее. Это добавляет огромное количество необходимой работы компилятору. Тем не менее, в случае успеха это будет огромным благом для расширения вариантов использования языка Scala.


Заключение


В то время как хайп вокруг языка Scala утих за эти годы, его использование, похоже, постоянно растет, и качество использования языка быстро улучшается. Это именно то, что вы ожидаете по мере того, как язык продвигается через цикл рекламы и переходит от сообщества, ориентированного на причуду, к сообществу, ориентированному на ценность. Разработчики Scala используют язык не как самоцель, а как надежный инструмент, который они могут использовать для решения своих технических или бизнес-задач, не связанных со Scala.


По сути, это означает зрелость сообщества.


В будущем, я надеюсь, мы сможем увидеть больше этого. Больше внимания на результатах и ценности, а не на рекламе. Больше взвешенных компромиссов, нежели догматизма. Больше искать общее, чем спорить о различиях. И еще 2х кратного ускорения компилятора!


Я думаю, что сообщество Scala не должно тратить много усилий на изучение существующего синтаксиса языка, много усилий на обсуждение функционального и объектно-ориентированного программирования или много усилий на то, чтобы сделать наш и без того очень типобезопасный код еще более типобезопасным. Вместо этого усилия должны идти на расширение языка, чтобы охватить тех разработчиков, которых мы не могли вовлечь: новичков, непрограммистов, людей с инструментами командной строки, разработчиков iOS и так далее. Если мы посмотрим на Опрос разработчиков Jetbrains 2019 для Python, мы увидим множество различных областей, в которых используется язык Python:


В настоящее время Scala в подавляющем большинстве случаев используется для серверных служб и/или конвейеров данных Spark, но нет никаких причин, по которым Scala также не могла удовлетворить вышеупомянутые варианты использования. Сообщество должно сделать применение Scala простым и широким настолько, чтобы любой, а не только многоопытный бэкенд/инженер данных, мог выбрать Scala и использовать его, наслаждаясь лаконичностью, производительностью и безопасностью типов, которые в сообществе Scala уже знают и любят.


Об авторе: Хаойи (Haoyi) — инженер-программист, один из первых разработчиков Scala.js и автор многих инструментов Scala с открытым исходным кодом, таких как Ammonite REPL и FastParse.


Если вам понравился этот блог, или вам нравилось использовать другие библиотеки с открытым исходным кодом Haoyi, пожалуйста, подключитесь (или сделайте так, чтобы ваша компания включилась!) Через Patreon, чтобы он мог продолжить свою работу с открытым исходным кодом.

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 110

    +5
    Текст о будущем Scala без единого упоминания Dotty / Scala 3… интересно.
      0
      Просто статья не про развитие внутренностей скалы, а про движуху вокруг языка в целом.
      Dotty / Scala 3 конечно интересны. Но до их адаптации в производство не один год пройдёт.
      Когда там еще релиз будет, когда еще библиотеки подтянутся, когда еще вся экосистема подтянется. И надо еще чтобы отгремели холивары по поводу их внедрения )
      Питон гораздо популярнее и сколько лет прошло преждем чем значимое количество проектов на 3ю версию перешли?
      Другими словами, это отдалёное будущее скалы, которое еще не факт, что настанет. Комьюнити у скалы не такое большое как у питона, неизвестно как оно переживёт этот раскол.
        +2
        Так вот как раз об этом и речь. Что предстоящий «раскол» с потерей обратной совместимости может для кого-то стать значимым фактором в выборе или невыборе языка ужé сейчас. И на эту тему уже много холиваров было — а тут в статье данный аспект в упор игнорируется.
          0

          Так обратная совместимость есть. Почти всё, кроме макросов, будет работать.

            0
            Я так понимаю, что ещё с implicits там всё плотно переделали. Да и вообще список dropped features в документации dotty довольно большой. Хоть о большей части этих фич я только из этого списка и узнал :) — но я-то Скалу так пока, только щупаю, а у кого-то на них может быть многое завязано.
            В любом случае, даже если в своём коде всю эту экзотику не использовать — она с высокой степенью вероятности есть в используемых сторонних библиотеках. И пока их судьба в рамках новой версии языка окончательно не ясна — сохраняются и сомнения, есть ли смысл сейчас связываться с тем, что придётся через пару лет переписывать.
              +1

              Да откуда у вас это мнение? Компилятор дотти уже сейчас кросс компилирует библиотеки из скалы 2. Авторы либ уже сейчас начинают переписывать части либ, где используются макросы. К релизу это всё уже будет. Имплиситов никуда не деваются. Всё старое на месте, и будет удаляться потом, через deprecation цикл.

                0
                У меня какого-то устоявшегося мнения по этому поводу нет. Просто присматриваясь к Скале, дискуссий по поводу того, не повредит ли перспективам языка новая версия, прочитал изрядно. И даже в отсутствие объективных причин для раскола сыграть могут совершенно субъективные факторы (даже и без Dotty демарши в стиле «я обиделся, я ухожу» среди ключевых разработчиков библиотек были).

                Я со своей дилетантской точки зрения (ибо пока не разобрался в нюансах использования всех продвинутых фич, которые меняются) тоже склоняюсь к тому, что всё в итоге пройдёт гладко и языку с библиотеками суждена долгая и счастливая жизнь, — но отсутствие какой-то оценки этого вопроса в статье удивило. Не более.
        +1
        Посмотрите на это с другой стороны. Вы видите тут Spark? Ну так вот, я как раз из тех, у кого Scala — средство доступа к спарку.

        Смотрим, какая у нас версия Spark: 2.2.0_cloudera4, смотрим, какая версия Scala: 2.11. Dotty (так же, как впрочем и Hadoop 3, и Spark 3.0, и Java 14) нам в ближайшее время либо вообще не светит, либо грозит огромными трудозатратами, чтобы на них мигрировать. Вот такое, оно, будущее Scala в одном отдельно взятом банке. Скушно, но жизненно.
          0

          Спарк уже сейчас работает под дотти.

            0
            Спарк какой версии?
              +2

              Все версии, в которых поддерживается скала 2.12.
              Спарк 2.2.0 вышел в июле 17 года. 3 года назад! То, что вы используете такие старых версии инструментов — не проблема инструментов или языка. Обновитесь уже на актуальную версию

                +1
                >Обновитесь уже…
                А вы давно пробовали обновить кластер, работающий 24х7? В котором порядка 300 узлов, и петабайты данных? Поверьте, это далеко не так просто. Мы уже трижды пробовали обновиться на 2.3, и трижды откатывались обратно. Потому что несовместимости. Сейчас вот новый кластер собирают, на новой cloudera, и там все будет в виде спарка 2.4. Но когда мы на него переедем — вопрос очень интересный.
                  +3

                  Но это ведь всё равно никак не связано с языком, правда? А по оригинальному сообщению прослеживается именно такая мысль.

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

                    Я скорее имел в виду, что значительному числу пользователей скалы типа меня (на самом деле пользователям спарка) — им на дотти пока приходится облизываться в лучшем случае. Мы бы и рады, и пробуем — но тяжело это идет.
                    0
                    А вы кластер не обновляете и изучите как Спарк работает вообще, можно хоть 7 разных Спарков иметь в одном кластере, Спарк работает как обычное ярн приложение и умеет поставлять свои бинари той версии которой вам нужно. Что касается питона для Спарк, ну для простой аналитики оно подходит: для etc или датаинженерии никак нет, кастомные вещи часто приходится писать на таких объемах данных. Складывается впечатление, что вы даже не проверяли возможности и сидите едите кактус на проходной версии Спарка без норм стриминга и нормального каталиста
                      +2
                      Про питон я вообще не писал не слова — откуда вы выдумали эту чушь? Вот такое у меня складывается впечатление от вашего коммента.
              +1
              Автор статьи пишет же не про Вас, для кого Скала — довесок к Спарку. А скорее про тех, кто как я — рассматривает Скалу как основной язык для нового проекта. «Better Java» плюс возможность внедрять ФП без фанатизма. Для них он и свои библиотеки пишет и пр.
              И вот тут и могут сыграть опасения, что у Скалы что-то глобальное скоро будет меняться. Поэтому непонятно, насколько это (а) скажется на популярности языка и доступности разработчиков на оном на рынке и (б) на судьбе фреймворков/библиотек, которые будешь использовать. И поэтому не взять ли вместо Скалы какой-нибудь Котлин — возможностей, конечно, меньше, но поддержка Гугла, стабильность и все дела.
                +1
                Не, ну конечно не только про меня. Просто таких кому нужен спарк — их много.
            +3
            Зав типы вот будущее ФП. Это если о будущем ФП вообще. Статья какая-то аля все хорошо мы не идем на дно.
              +2

              Интересно, чего быстрее дождёмся — готового к продакшену идриса или -XDependentHaskell плюс выпиливание неконсистентностей типа TypeInType.

                0
                А как в dependent haskell собираются формализовывать Double и тому подобное? Есть какие-нибудь идеи на этот счёт?
                  0

                  Так же, как и в каком-нибудь Idris: никак. Но это не задача языка, это библиотечный уровень.

                    0
                    А как с уровня библиотеки и индуктивных определений для double (как в Coq сейчас делают) протащить это всё до уровня машинного кода? Скриптиком на Bash править в извлечённом коде типы? А где гарантии, что эта правка будет именно такой, которая ничего не сломает? Много-много вопросов. Нужен какой-то технологичный ответ на чаяния тех, кому важна скорость.

                    Вот. Например, где-нибудь можно посмотреть пример доказательства, что алгоритм умножения блочных float-матриц корректен?
                      0
                      А как с уровня библиотеки и индуктивных определений для double (как в Coq сейчас делают) протащить это всё до уровня машинного кода? Скриптиком на Bash править в извлечённом коде типы?

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


                      А где гарантии, что эта правка будет именно такой, которая ничего не сломает?

                      Там же, где гарантии, что ваш процессор правильно обрабатывает mov и add. Это внешние относительно языка вещи.


                      Например, где-нибудь можно посмотреть пример доказательства, что алгоритм умножения блочных float-матриц корректен?

                      Причём float'ов, нативных для железа? См. выше, можно рассуждать и доказывать что-то только в рамках модели железа.

                        0
                        Не обязательно нативных. Просто float-ов. Я сам пытался искать такие примеры, наткнулся только на certigrad, но в нём вся интересная мне арифметическая часть просто аксиоматизирована и реализована на Си++.
                          0

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

                  –1
                    0

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

                      0
                      Ну кмк там довольно инетресная система, в частности оптимальная редукция. А оптимальное выполнение ФП кода на императивной железке это довольно интересный результат, имзо.

                      Выдержка из одного поста:

                      Hi everyone. We have great news on the ultimate λ-calculus which will possibly lead to a next-gen compiler for Formality.

                      Long history: initially, we compiled Formality to interaction combinators, the Levy-optimal system everyone here knows. Sadly, inets, while asymptotically fast, are slightly inefficient in practice due to pointer gloat. A few months ago, I noticed a way to represent a subset interaction combinators in a more compact format that resembled terms, except «ill-scoped» (i.e., a lambda-bound variable can appear outside of its body). I called it the ultimate λ-calculus. It had 4 main constructors:

                      LAM(name, body)
                      APP(func, argm)
                      PAR(val0, val1)
                      LET(name0, name1, expr, body)


                      Afterwards, I found a very efficient way to evaluate a subset of the ultimate λ-calculus, by representing variables as pointers on LAM nodes (i.e., lambdas point to variables, not the other way around). This, together with a leftmost-innermost reduction, allowed beta-reduction to become a single array write! It is, ridiculously, 40x faster than interaction nets. It is the «fast-mode» on Formality v0.1.253. Sadly, this mode didn't allow duplications at all, only affine terms. The problem was that the order let redexes were found didn't match the leftmost-innermost reduction. This resulted in errors, since pointers would become invalid when the terms they pointed to moved. Today, I noticed that a small change on the ultimate λ-calculus could solve that issue. Instead of a let with two variables, we use a cpy with only one. That is, instead of:

                      let [a, b] = 42 in [a, b]
                      We have:

                      [cpy a = 42, a]
                      The cpy constructor injects a copy of something into another location, and then returns that thing. The result of this is that 1. the let constructor becomes smaller (from 3 to 2 fields), 2. the order it is found matches the innermost-leftmost reduction strategy, solving the problem mentioned.

                      I'll start immediately working in a C runtime for that new calculus and benchmark. If it works well, I'll proceed with the addition of native numbers and mutable arrays (which can be detected from types as I mentioned previously). If all turns ok, we'll have a functional runtime that is very CPU efficient, levy-optimal, non-garbage collected and with actual mutable arrays that don't need to live inside ST or other monad.
                        0

                        Это действительно интересно с точки зрения рантайм-поведения, стоит почитать, да.


                        Так-то ФП-шников рантайм-эффекты традиционно не волнуют, слишком скучно.

                    +1
                    ИМХО в Хаскель только если Haskell 2 завести и параллельно поддержку старого без зав типов оставить. Хотя, тут и ресурсов нет и Idris, F* (Ф Стар от майкрософт. Прикольная вешь) уже есть.
                      0

                      А зачем? Ну просто у вас будет ещё одно расширение, дающее возможность делать понятно что. Добавление кусочков вроде DataKinds, TypeFamilies и тому подобного не потребовало же форкать язык.


                      F* (Ф Стар от майкрософт. Прикольная вешь)

                      В соседней ветке спрашивал у кого-то ещё, но спрошу ещё раз и тут, так как сейчас ковыряю что-то очень похожее. Как там устроено взаимодействие завтипов и refinement types?

                    0
                    Вот когда в завтипы завезут native арифметику, тогда можно и будет говорить о будущем. На современном уровне завтипы стоят очень много усилий, а для реального кода, который (сюрприз-сюрприз) должен ещё умножать, складывать и делить, да ещё и в петабайтных масштабах, как тут некоторые указывают выше, выгоды никакой по корректности не дают. Видел я, конечно, работы по переносу доказательств из Nat в Zpos, но пока как-то совсем не впечатляет. А ещё же нужны float-ы. С ними совсем беда.
                      +1

                      А в чём проблема с Nat? Тот же идрис компилирует Nat-like-типы (у которых конструкторы вида C1 : Ty и C2 : Ty -> Ty) в обычную gmp'шную длинную арифметику, стопицот конструкторов там никто не таскает. Аналогично можно и с другими кольцами жить.


                      А вообще знакомые делали какой-то блокчейн на идрисе с доказуемо корректными бинарными числами, и там всё достаточно шустро работало.

                        0
                        А вообще знакомые делали какой-то блокчейн на идрисе с доказуемо корректными бинарными числами, и там всё достаточно шустро работало.


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

                        О natlike компиляции мне известно, но этого «маловато будет» для производительных приложений. Ну, вот, например, речь же идёт всегда об ответственных приложениях, типа управления оборудованием, а там по техническим причинам применяются микроконтроллеры. Нужно, чтобы модель устройства влезала в маленькую память. GMP-арифметика не особо подходит для этого.
                          0
                          Верно ли я предполагаю, что, как и всегда в таких случаях, код посмотреть невозможно?

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


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

                          Поэтому берёте другие кольца. Например, вместо ℤ берёте ℤ/nℤ для вашего любимого n. Возьмёте n = 2³² — получите свой обычный uint32_t. Никаких теоретических преград этому нет.

                            0
                            Теоретических, конечно, нет никаких преград. Но, ведь, этот тип будет индуктивным, то есть, представленным в виде дерева конструкторов. Как потом это представление переводить в машинный код? Узнавать структуры, как делается с Nat-ами в Idris? А их точно можно узнать? Кодировка Z(n) в, например, CompCert довольно сложная. Есть ли что об этом почитать? Ну, просто животрепещущий вопрос.
                              0

                              Не обязательно узнавать, можно просто постулировать, что такие-то операции над типом должны компилироваться в такую-то операцию. Ну там, Zxor reg, reg, Sinc reg, add : Nat -> Nat -> Natadd reg1, reg2.


                              Как конкретно кодируются ℤ/nℤ — хрен его знает, я до этой задачи не доходил. Когда-нибудь дойдут руки — можно поглядеть.

                    +1
                    Спасибо за перевод!
                      +1
                      Что ждёт язык Scala дальше

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

                      Сегодня из всех языков будущее есть лишь у пошлого Го и у шарпованного Си, потому что за них готовы платить. А вот у остальных — будущего нет. Даже у Java, как не печально, но Оракл похоже остался один из тех, кто её хоть как-то поддерживает. И ему она не нужна. Поэтому лет через 10 ландшафт используемых языков сместится в сторону гугло-недо-языков с примесью мелкософтовых изысков.

                      Миром правит финансирование рекламы, а не какие-то там пристрастия разработчиков и удобства языка. Будут платить з/п выше рынка за пошлый Го — будет рост. Не будут платить — всё умрёт.

                      Хотя «умрёт» здесь не совсем точно отражающее реальность слово. Жизнь будет, но в летаргическом сне, как у кучи давно забытых языков, которыми на всей земле пользуется тысяча-другая человек.
                        0
                        Тогда следуя Вашей логике почему же Питон растёт огромными темпами?
                          0

                          А вы посмотрите список спонсоров PSF.

                          +4
                          Вы таки в самом деле думаете, что популярность C# или Go вызвана обилием рекламы, а не низким порогом входа, в том числе и инструментальным, в эти языки? Скажите, чему будут больше учить всякие разные ютуберы и онлайн-академии, более сложному в использовании языку или более простому, когда обучение можно поставить на поток, и когда для того, чтобы стать учителем, не нужно затрачивать больших усилий?

                          Отсюда и популярность, ну, и, соответственно, сообщения об этих языках из всех сокетов всея интернета.

                          Если в большинстве случаев простой язык позволяет решать задачу, люди будут использовать более простой язык и рационализировать свой отказ от изучения более сложного. Мозг — ленивая штука. А в большинстве случаев простых и «пошлых» языков хватает.

                          Собственно, как-то так, мне кажется. Большие компании просто понимают, как это всё устроено и работает, и умеют пользоваться, иначе, они бы не смогли бы стать такими большими. У «не пошлых» языков (я так понимаю, Scala и Haskell?) стратегии захода на массовый рынок просто нету. О чём, собственно, автор статьи и пишет. Организовали бы какой-нибудь Scala Game Jam, народ бы и потянулся.

                          Но тут, конечно, возникает ещё один интересный вопрос: насколько велика когнитивная нагрузка Scala на программирующего? Может ли он одновременно продумывать хорошую игру и хорошую архитектуру кода на Scala? Интересный, мне кажется, вопрос. Вдвойне поэтому интересно было бы посмотреть на Scala/Haskell Game Jam.
                            +2
                            Ох уж прохладные истории про популярность Golang.
                            Скрытый текст


                            И это при том что это вообще рандомная выборка куда попали любые вакансии где есть слово Go а таки слово Java намного больше фильтрует. Если поставить фильтры IT телеком и в названии вакансии то вообще получается 77 против 884 в пользу Java.
                              0
                              Но тут, конечно, возникает ещё один интересный вопрос: насколько велика когнитивная нагрузка Scala на программирующего? Может ли он одновременно продумывать хорошую игру и хорошую архитектуру кода на Scala? Интересный, мне кажется, вопрос. Вдвойне поэтому интересно было бы посмотреть на Scala/Haskell Game Jam.

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

                              +1
                              БТВ, мелкософт помимо C# сейчас начала в сторону FP (F#), зав типов (F*) и системшины (Verona) копать. Пока по ощущениям они им не нужны и это все ресерч. Увидим что дальше будет. Надеюсь они таки всерьез завтипами займутся.
                              +4

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


                              Spark застрял со старой версией (всем миром ему помогали на 2.12 выкатываться), некоторые библиотеки еще не смогли (например, elasticsearch-hadoop). Ну и как выше писали в комментах, мигрировать не очень просто. И все больше скалу в спарке вытесняет питон.


                              Из ниши «better java» скалу со свистом вышвырнул котлин — а в статье про него ноль упоминаний. И у того же котлина уже есть плюс-минус рабочее решение с js и native. У скалы вроде как тоже, но котлин в этих направлениях развивается гораздо активнее. Scala-js по маргинальности примерно одинакова с хаскеллем на фронте. Native там же примерно. Да и graalvm тоже маячит.


                              Akka уже теснят всякие корутины и project loom. Реактивным программированием сейчас тоже никого не удивишь.


                              Dotty вроде как дает надежду и уже почти готов, но опять же в статье про него тоже ни слова.


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

                                0
                                «Akka уже теснят всякие корутины и project loom» — кто тут кого может теснить когда это совершенно разные вещи?
                                  –1

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

                                    +2
                                    Зависит от проекта, разумеется. Акторы это не про континуации.
                                      0

                                      Ок, перефразирую вопрос — при каких условиях для нового проекта будет использоваться Akka? Эти условия те же, что были до появления котлина с корутинами?


                                      Disclaimer: я не фанат котлина, но мне кажется, что он неплохо отжирает долю ниш скалы.

                                        0
                                        Опять же, из того, что я вижу на практике — нисколько. Был котлин, да весь вышел. Уже вышел. Занял немного места в тестировании — и этим все ограничилось. Обобщать не готов — это всего-лишь частный случай.
                                          0

                                          В тестах? Весьма странно — имхо, у scala test больше возможностей и гибкости, чем у любой котлиновской библиотеки тестов или junit того же самого.

                                            0
                                            Ну, так исторически сложилось. Я бы тоже скорее scala test прикручивал.

                                            Это были Java разработчики, не скалисты. Решили попробовать с тестов. Ничего особо не дало. Впрочем, я как раз это вполне готов объяснить тем, что у нас на первом месте спарк, а тесты для спарка — это по большей части интеграционные, не юнит, тесты.

                                            Собственно язык написания тестов и фреймворк — это такая мелкая фигня во всем этом целом получается. Не в плане объема мелкая — по объему это как раз много выходит, а в плане сложности достижения эффекта, чтобы реально что-то протестировать.
                                          0
                                          Akka нужна, если нужен стейт в рантайме. И если нужен кластер, что бы этот стейт не проворонить
                                            0
                                            Вы таки попали в точку. Например у меня друг на Акторах делал сервер пиратский корейской гриндилки. Не помню как называется. Игра похожая на WoW. Насколько я у него узнал акторы популярны при разработке таких стейтфул игровых серверов.
                                    0
                                    Руки так и не дошли скалу попробовать, а она уже удел маргиналов. Однако.
                                    С Котлином тоже, пожалуй, подожду пару лет, а то он тоже, вдруг…
                                      –4

                                      Котлин гугл признал официальным языком на Андроид, так что вряд ли он повторит судьбу Скалы

                                        0
                                        У гугла свои дети есть — Go и Dart. Яб не стал в этом плане на него надеяться. Кто реально за Kotlin стоит так это JB.
                                          0
                                          Так у Котлина вроде основная ниша Андроид…
                                          UPD

                                          JediPhilosopher Вот почему Гугл на Котлин подсел — вообще не пойму. Ведь они могли любой свой ЯП туда присобачить (да хоть новый с нуля разработать). Теория заговоров какая-то…
                                            +2

                                            Насколько я знаю, там была история в духе "мы для вас бесплатно делаем клевую IDE под андроид, а вы пиарите наш язык". win-win такой.
                                            go и dart сто лет в обед, но чет вроде на андроиде никто их не пиарит особо. А на котлин, например, уже и большую часть документации гугловой переписали.

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

                                        У нас модели тоже любят делать в Jupiter и на питоне. А потом когда в пром нужно, берут, и переписывают. На Java, как правило.

                                        Завтра из интереса спрошу, есть ли у нас хоть какой-то питон в проме. И если есть, сколько его в процентах. Моя оценка — порядка 1%.
                                          0

                                          Вот вы сами сказали что модели пишут на питоне, а потом в проде на java переписывают. Если на скале удобнее — чего ж на ней-то не пишут?
                                          В спарке в том то и прикол, что очень многим от него начинает быть нужен только spark sql. А там без разницы практически на чем писать. Вот и пишут дата сайентисты на питоне спарковские джобы. Т.е. основной язык, где разрабатывается что-то новое, уже не факт, что scala.

                                            0
                                            >скале удобнее — чего ж на ней-то не пишут?
                                            Простой ответ — это разные люди. Мне было бы на питоне неудобно, но я это не они.

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

                                            Ну а совсем точного ответа у меня нет.
                                              0

                                              Так про то и речь. Раньше дата-анализ на спарке был либо на голых rdd, либо на java-либах. Сейчас эту нишу отъел питон.

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

                                                  Для действительно тяжелых задач — да, на скале будет быстрее. Для того, чтобы проверять гипотезы — вряд ли. Тут уже разница есть, когда нужно реальная оптимизация, недостижимая сменой алгоритма. Но api pyspark предоставляет почти полностью идентичный скале, выполняется все на экзекуторах. Если большая часть обработки — на spark sql или через стандартные методы, то питон там будет проседать в основном только из-за боксинга/анбоксинга. По сетке гонять все равно дороже.


                                                  В любом случае порог входа ниже для питониста. Если даже взять среднюю температуру по больнице в виде запросов “spark scala” и “spark python” на hh, то получим 134 против 211.

                                                    0
                                                    >В любом случае порог входа ниже для питониста.
                                                    У нас есть живой пример, когда нужно было сделать проект, переваривающий терабайты в сутки. Причем было много неясностей, и мы решили делать прототип на spark-shell, который в итоге и остался (на скале).

                                                    В результате его сделали двое — один аналитик, и один Java-разработчик примерно middle-уровня (примерно — потому что на самом деле он довольно опытный, но немного в другой области — в области баз данных и SQL). Два месяца примерно. Нулевой уровень скалы в начале, у обоих.

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

                                                    На всякий случай, чтоб было понятнее — это не ML, это скорее ETL. То есть, я не к тому, что порог у питона высокий, или что-то в этом духе, а что порог входа у скалы тоже низкий.
                                                      0

                                                      Я не говорю, что для скалы порог входа высокий. Я тоже могу рассказать несколько историй про то, как быстро люди начинают на ней писать.
                                                      Я про то, что у питона он ниже. Еще раз — я ни в коем случае не против скалы. Просто говорю, что питон начал отъедать ее аудиторию для спарка. Я уже не знаю, как вам еще доказать, что это не «сказки» — зайдите что ли в чат русского сообщества apache spark в телеге или посмотрите программу Spark AI Summit — там есть чисто питонячий трек.

                                      • UFO just landed and posted this here
                                          +1
                                          Как я понял смысл, то автор говорит, мол надо думать о удобстве использования языка тех, кто не сильно шарит во всех этих ФП наворотах. Т.е. не надо концентрироваться на библиотеках типа Cats, а делать библиотеки простыми для более широкого круга, как в питоне. Тогда потянутся люди и кто захочет, тот будет котов использовтаь, а кто не захочет, может делать более простые вещи. Но самое главное комьюнити будет расти, а это очень важно для развития языка в целом.
                                          Что автор и делает в своих библиотеках. Они действительно простые и понятные.
                                          Я вот их использую)
                                          • UFO just landed and posted this here
                                          0
                                          Scala проигрывает по всем фронтам, и даже Хаскель уже хайповее. Очень жаль, ведь именно она понесла ФП в массы. Я думаю ей надо развиваться не во всех направлениях (как это предлагается в статье), а выбрать те ниши, где ФП подход однозначно выгоднее простого ООП и процедурного. Возможно, ей надо в новой версии сделать полностью асинхронное ядро (ну или какую-то другую киллер-фичу).
                                            0
                                            те ниши, где ФП подход однозначно выгоднее простого ООП и процедурного

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


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

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

                                              А вот как «better java» (ответ на ваш нижний комментарий) — это вопрос интересный.
                                              Если делать better_java для простых задач, то это не ниша Скалы (и там уже укрепился Котлин). А вот для сложных задач (чтобы их можно было делать легко и быстро) может и взлететь. Хотя здесь ее уже тоже подпирают не-jvm-ские Haskell и Rust. Но это по-любому означает необходимость кардинальной переработки Скалы, чтобы она перестала быть всем для всех.
                                                +1
                                                ФП хорошо работает там, где идут потоки информации, которые надо обрабатывать в реальном режиме времени, а стейты некритичны. Думаю, такие ниши есть.

                                                Да и где стейты критичны, тоже. Там как раз хорошо, стейт сразу видно, он везде явный, а не «вот если у этого объекта дёрнуть это, а потом у того то, то первый будет в нужном стейте, но при этом вот этот метод дёргать нельзя, а то всё сломается».


                                                Хотя здесь ее уже тоже подпирают не-jvm-ские Haskell и Rust.

                                                Есть, кстати, jvm-ский хаскель (даже два): eta и чуть более дохлый frege.

                                                  0
                                                  Да и где стейты критичны, тоже. Там как раз хорошо, стейт сразу видно, он везде явный, а не «вот если у этого объекта дёрнуть это, а потом у того то, то первый будет в нужном стейте, но при этом вот этот метод дёргать нельзя, а то всё сломается».
                                                  Согласен, нынешние дизайны ООЯП подталкивают к «макаронной» архитектуре.
                                                +5
                                                Людям удобно мыслить императивно или объектно

                                                Это очень спорное утверждение, на котором много копий сломано.
                                                Каким именно людям? Тем, кто в институте, на курсах и на первых работах писал императивно?
                                                Да, привычки играют очень большую роль. Но есть люди, кто с самого начала изучал только функциональщину, они вот непонимают, как можно писать ПО с этой кашей ООП объектов.
                                                Я хочу сказать, что нет хорошей, объективной статистики для таких утверждений.
                                                А что касается "это соответствует тому, как мы ощущаем окружающий мир", то его удобство очень хорошо отображает вот эта классическая картинка.

                                                  0

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

                                                    0

                                                    Даже в OOP Claims brains:true смущает, и неабстрактный legs который возвращает 0 для всех животных которые не догадались его переопределить.

                                                      0
                                                      А brains:true-то почему смущает? ;)
                                                        +1

                                                        Потому что я бы ожидал brains: Brains или что-то такое. А признак это IsBrain/HasBrains/… Уже настолько привык к гайдлайнам именования что немного рвет шаблон когда у людей переменная brains внезапно не типа Brains.

                                                          0

                                                          А brains: Brain[] смущает?

                                                            0

                                                            Нет, это тоже логично, ведь вполне возможно что type Brains = Brain[], или, возможно, чуть более сложная структура. А вот bool уже никак, извините.

                                                    +2
                                                    Сколько лет пытаются людей убедить что ФП это круто, но нет, не ложится оно на мозги.

                                                    На деле, ФП вполне проникает в мейнстрим, просто кусками и медленно. Но и ООП зашло в мейнстрим не через Smalltalk, а через более близкие к процедурным языкам C++ и Java.

                                                      0
                                                      Возьмем, к примеру, классические rest-API: если рассуждать с точки зрения программирования в большинстве случаев там ООП ну никак не заходит, единственная причина, по которой оно (ООП) занимает нишу — «ну, так все делают!».

                                                      На моей практике, университетов в России которые нормально преподают ФП, (5 лет назад), было очень мало, по сравнению с университетами где хоть как-то преподавали программирование. Но ООП есть везде. Вкупе с тем, что концепции довольно сильно отличаются, мы получаем эффект, что на выходе разработчики не могут «с ходу» понять абстракции ФП и не спешат развиваться в эту сторону.
                                                        –1

                                                        И почему же оно не подходит? Есть объекты бизнес-логики, есть эндпоинты апи, которые что-то с ними делают.


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

                                                          +2
                                                          И почему же оно не подходит?

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

                                                          res = handle(req)


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

                                                          объекты бизнес-логики

                                                          Объекты никуда не деваются и в ФП. Только вместо классов появляются типы, вместо интерфейсов — тайпклассы и т.д…

                                                          «ну есть юзеры, группы, роли, проекты, и все это связано кучей зависимостей»

                                                          Это все прекрасно описывается теорией категорий. (И да — ее не обязательно знать, достаточно понимать довольно небольшое кол-во базовых понятий). Оперируя продуктами\ко-продуктами можно добиться выдающихся результатов, при этом получая мощные гарантии. А ООП код не дает никаких гарантий. Наследуясь от базового класса — можно переопределить его поведение до неузнаваемости. И программисту, который, скажем, рефакторит такой код чтобы быть уверенным, что он ничего не поломал необходимо изучить всю иерархию классов… если обобщить, то ты не знаешь что делает программа, пока не прочитаешь ее полностью (в худшем случае). Если брать ФП, то там программа сводится к значению. Т.е. это просто функция, а что бы понять что делает функция — достаточно взглянуть на ее сигнатуру. И если вам когда либо приходилось рефакторить код на Java (ООП) и Scala (ФП), то очевидно, что последнее требовало на порядки меньше трудозатрат.

                                                          Как-то так.

                                                          т.е. какая-то там часть функциональщины может там работать под капотом в виде всяких акторов

                                                          Часто как раз таки поступают наоборот. Возвращаясь к скале — рантайм JVM очевидно более заточен под Java, поэтому в скале даже в чисто функциональных частях кода используют ООП под капотом, чтобы добиться оптимальной производительности.
                                                          Пример: Map — если конструировать ее из списка, то под капотом создается MutableBuilder, который собирает структуру данных, а на выход она уже возвращается как immutable.Map. Это не ломает никаких абстракций, но прокачивает производительность в реалиях JVM.
                                                            0
                                                            Это все прекрасно описывается теорией категорий. (И да — ее не обязательно знать, достаточно понимать довольно небольшое кол-во базовых понятий).

                                                            Вспомнил статью «Формальный аксиоматический подход к аспектно-ориентированному расширению технологий программирования» (с. 55 здесь).

                                                        0

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


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

                                                          0
                                                          Я тут относительно недавно поймал себя на мысли, что давно не встречал задачи, куда хорошо ложится ООП


                                                          Полностью поддерживаю! Сам прошел путь от процедурного программирования к ФП и теперь ясно осознаю, что, действительно, там, где раньше вместо ООП и ничего нельзя было представить — теперь очевидно (мне), что его использование выливается в кучу костылей.

                                                          не пишу гуи (и никогда не писал фронтенд)


                                                          С некоторыми оговорками — ФП тоже хорошо заходит (что на нижнем слое все же прослойка из ООП для производительности).

                                                          Ну, вот gamedev на мой взгляд довольно хорош в рамках ООП.
                                                            0

                                                            Ну, те вещи, которые я писал с высокими требованиями к производительности (наносекунды там, на плюсах и всё такое), там ООП бы не зашло. А вот к ФП там было очень близко, и гипотетический ФП-язык с иммутабельностью, но линейными типами, там был бы очень хорош.

                                                            0

                                                            А давно вы занимались автоматизацией документооборота, электронной коммерцией, учётом различным, задачами где суть в управлении состоянием огромных систем?

                                                              0

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

                                                                0

                                                                Вот для работы с потоками событий ФП в среднем подходит лучше.

                                                        +5

                                                        Пытался одно время перелезть на скалу, как на better java — не взлетело. Да, были какие-то приятные фишки, ради которых очень хотелось перейти, но:


                                                        1) Запутанность и неочевидность многих вещей. В последний раз такую фрустрацию от непонимания переусложненных языковых конструкций я в С++ ощущал. И НЕТ, вы не сможете пользоваться только каким-то понятным и приятным вам лично подмножеством языка. Потому что авторы популярных библиотек обожают нахреначить туда всех этих имплиситов и прочей мутной хренотени, и волей-неволей приходится пытаться это все понять.


                                                        2) Фиг найдешь разработчиков. Тут замкнутый круг — нет популярности языка — нет разработчиков — нет проектов. Я сделал один небольшой сервер в продакшене на скале и уже успел проклясть все на свете — другие члены команды в скале не разбираются, учить смысла не видят, кроме меня ковырять его некому. На хабре была когда-то хорошая статья на эту тему — почему для бизнеса скала плохой вариант.


                                                        При этом начиная с 8 джавы для меня лично почти все критичные фишки появились и в самой джаве — лямбды и стримы. Если добавить ломбок — то и дата-классы и еще что-то там. По сути единственное по чему я скучал в джаве по сравнению со скалой — это подход "все является выражением" и паттерн-патчинг. Но это вроде тоже в джаву потихоньку перетаскивают.


                                                        А потом появился Котлин. Который во-первых еще более better java, во-вторых не содержит такой кучи мозговзрывающих концепций, превращающих код в write-only, а в-третьих благодаря поддержке гугла на андроиде он сумел разорвать замкнутый круг и резко начал набирать популярность.


                                                        Итог: как better java Скала, на мой взгляд, смысла больше не имеет. И ждет ее дальше только тихое загнивание и стагнация, подпитываемое по чуть-чуть любителями ФП, так как на хаскелле вакансий вообще нет, а на скале хоть чуть-чуть да есть.

                                                          +2
                                                          Вот у меня похожие мысли. Но только лично мне самому Скала очень хорошо зашла. А вот насколько пихать её в проекты, к которым потом привлекать наёмных программистов — большой вопрос… Да, рынок «скалистов» узкий и специфический (шанс нарваться на ФП-фаната, который напишет код, достойный диссертации по математике, но непонятный никому, кроме него самого).

                                                          На чистую Java после Скалы откатываться не хочется. А вот Котлин?.. Да, поддержка Google. Но, с другой стороны, на Котлине пишут 90% под Андроид. И толку мне от обилия мобильных разработчиков, если мне надо пилить не мобильное приложение, а бекенд, шустренько и зело распаралеленно ворочающий гигабайты данных.
                                                            0

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

                                                              0
                                                              Я не сомневаюсь, что на Котлине можно написать бэкенд.

                                                              Я про то, что преимущество Котлина над Скалой в части наличия на рынке бóльшего количества разработчиков в случае с бэкендом не столь очевидно. Пишущих на Котлине вообще — да, больше, чем на Скале, и перспективы роста этого количества лучше. А пишущих на Котлине бэк — вот не факт…
                                                                0

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

                                                            +2
                                                            Запутанность и неочевидность многих вещей

                                                            Справедливости ради, популярные Java-стеки тоже сложно назвать простыми и очевидными. Программирование на аннотациях и на classpath в спринг-буте имхо гораздо большая магия, чем имплиситы, или макросы, или что угодно еще в скале. Взять какой-нибудь хибернейт или тот же ломбок — в них реально проще разобраться, изменить поведение или найти баг, чем в скала-либах?


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


                                                            Но вот когда в спринг-буте что-то ломается на ровном месте из-за неправильного порядка загрузки конфигов, а птичьего языка аннотаций не хватает, чтобы запрограммировать нужное поведение — вот тут я ощущаю нешуточную фрустрацию. Правильность аннотаций не проверяется компилятором. Все это добро работает в рантайме через рефлексию. Весь современный java стек программируется не на уровне языка джава, а мета-уровнях, будь то имена методов (как в JPA), аннотации, classpath, генерация кода, генерация байткода.


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

                                                              0
                                                              Насчет Java/Spring — нельзя не согласиться, хотя это свойственно и .NET и другим средам. Rails тот же — имел «радость» писать на нем довольно большой командой, помню ощущение счастья когда исполнение запущенного проекта таки доходит до первой строчки вашего кода — а не падает по дороге в одном из многочисленных mixin-ов.
                                                                0
                                                                BTW, миксины проще тестить поотдельности, и получить в итоге точно работающий проект. То что вы не писали тестов — разве это аргумент в пользу «метапрограммирование — это плохо»?

                                                                Rails был первым блином (комом), и таким достаточно долго и оставался (да что там, и остается до сих пор)). Но затем появились более правильные подходы к проектированию таких больших систем. Как хороший образец кода можно посмотреть Sequel и Shrine. Затем появился Dry и Hanami. Отсуствие метапрограммирования в современном мире — это дичайше неудобно.
                                                              0
                                                              >1) Запутанность и неочевидность многих вещей.
                                                              Ну, этому нужно правильно учить. Я пытался учить этому аналитиков. В принципе, в рамках приложенных усилий (примерно в пределах 10 часов занятий) результат более чем неплохой.

                                                              Возможно, это объясняется тем, что библиотек у нас как раз одна — спарк. Но я бы сказал — частично объясняет.
                                                              –2
                                                              Личное мнение:
                                                              Тоже, что и котлин и прочее java+ like. Java перенимает положительные аспекты и опыт. Старается избегать отрицательные. Идёт дальше. А scala\kotlin\назовите свой остаётся с редеющей аудиторией из фанатиков и малочисленных экспертов.
                                                                0
                                                                На мой субъективный взгляд джава перенимает несвязную фигню. То оттуда кусочек, то отсюда, а полной картинки нет. Это в отличии от Котлина.
                                                                  +1
                                                                  Время рассудит нас.
                                                                    0

                                                                    В смысле время? Последних 6 лет недостаточно что ли? Примерно все добавленные синтаксические фичи джавы, имеющие аналог в скале, во-первых сделаны более убого по сравнению со скалой, во-вторых, неслабо корежат исходный синтаксис джавы, делая его все менее консистентным и более мозаичным.


                                                                    Хорошая иллюстрация, как дизайнерам джавы приходится идти на компромиссы и выбирать из нескольких зол — спич Тагира Валеева про паттерн-матчинг https://www.youtube.com/watch?v=qurG_J81_Cs

                                                                      0
                                                                      Изначально отвечал развёрнуто. О том, что согласен с большего о
                                                                      перенимает несвязную фигню

                                                                      Были вопросы о
                                                                      полной картинки нет
                                                                      .
                                                                      Позже показалось, что резюмировать фразой о времени после того как высказался не очень красиво.
                                                                      Посему и писал, что «старается» избегать в изначальном комметарии.
                                                                      Моё высказывание о времени было скорее о том, что же будет с java+ языками.
                                                                0
                                                                Автор, спасибо за статью!
                                                                Можете, пожалуйста, исправить перевод (перевод «Польские» здесь неправильно использован для слова «polish»):
                                                                «Польские» функции, такие как сопоставление с образцом в строках или подавление предупреждений, продолжают улучшать жизнь каждого.

                                                                Only users with full accounts can post comments. Log in, please.