Зачем человеку Scala?

https://blog.softwaremill.com/why-scala-a6ac8c98c541
  • Перевод
Здравствуйте, коллеги.

Не так давно мы допечатали книгу Одерски, Спуна и Веннерса о Scala 2.12. Ведь до Scala 3 еще далеко.


Автор сегодняшней статьи — Адам Уорски, сооснователь компании «SoftwareMill» и опытный Scala-разработчик. У него получилось интересное резюме сильных сторон современного языка Scala, которое мы и предлагаем вашему вниманию.


После пленарной лекции Мартина Одерски на ScalaDays, где он изложил планы на Scala 3 и пленарной лекции Джона де Гоуса на конференции Scalapeño о будущем Scala в сообществе Scala продолжаются оживленные дискуссии. Не считая обсуждения этих пленарных выступлений, многочисленные дискуссии идут в twitter, в сообществах Slack, а также на reddit (см. напр. 1, 2).



Вот в чем вопрос!

Все это очень интересно и познавательно для специалистов, уже работающих в экосистеме Scala. Однако, значительная часть споров связана с различными интуитивно ощутимыми или фактическими недостатками Scala как языка. Эти моменты могут отпугивать людей «со стороны», вызывая у них вопросы: «А зачем мне вообще пользоваться Scala?», «А вдруг это тупиковый путь?», «Повторит ли Scala 3 успех Python 3?» и т.д. Как и в большинстве дискуссий, внимание приковывают самые слабые и эмоциональные тезисы, и эти дебаты — не исключение.

Поэтому сделаем шаг назад: зачем вам вообще мог бы потребоваться язык Scala? Каковы технические и деловые доводы в пользу работы с эти языком?

Предметная область проекта

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

Таким образом, Scala отлично вам подойдет, если требуется сориентироваться в сложной предметной области. Например, речь может идти о распределенном или конкурентном программировании. Наладить параллелизм очень сложно, а в Scala есть ряд библиотек, упрощающих эту задачу путем построения абстракций. Для этого существует два основных подхода: акторный, реализуемый при помощи Akka, и в духе FP, представленный Monix/cats-effect и Scalaz/ZIO (если бы вы хотели подробнее почитать о сравнении этих инструментов – я написал серию статей как раз на эту тему).

Однако, разумеется, речь может идти и о других предметных областях. Возможности Scala также позволяют вывести на новый уровень моделирование типичных бизнес-приложений. Но в данном случае речь уже о сложности другого порядка. В случае с распределенными системами мы сталкиваемся с технической сложностью. При программировании бизнес-логики в приложениях речь идет уже о сложности предметной области как таковой. Например, в книге Дебасиша Гхоша (Debasish Ghosh) “Functional and reactive domain modeling” объясняется, как совместить DDD с функциональным и реактивным программированием.

Сложность языка

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

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

Таким образом, при относительно небольшом количестве базовых возможностей (по размеру грамматики Scala проще Kotlin, Java или Swift!) — что, в свою очередь, облегчает обучение – варианты комбинаций гораздо многочисленнее.

Не слишком ли широкий выбор? Не думаю. Программист, как компетентный и ответственный профессионал, более чем в состоянии выбрать наилучший вариант, чтобы решить конкретную задачу. Подробнее об этом см. в статье “Простой стек Scala”.

Java, только лучше

Сейчас много говорят, что Kotlin вытеснил Scala в качестве “как Java, только лучше”. Но я считаю, что именно Scala, а не Kotlin, по-прежнему заслуживает такого звания. На то есть две основные причины:

Во-первых, неизменяемость в языке Scala первостепенна. Это связано с природой Scala как таковой: писать на нем код удобно прежде всего при помощи неизменяемых данных. К таким данным относятся, в частности: val (как единицы первого класса), case-классы, функции высшего порядка, т.д. Но дело и в том, как спроектирована и написана стандартная библиотека языка Scala; неизменяемы все структуры данных, используемые «по умолчанию». Благодаря неизменяемости упрощается целый ряд вещей, особенно в нашем мире высокой конкуренции, где выигрывают именно те языки, где предпочитается неизменяемость.

Во-вторых, в Scala поддерживаются конструкторы типов, типы высшего порядка и типы классов (объявляемые неявно), что серьезно упрощает работу с оборачивающими/контейнерными типами, например, с Promise, Future или Task. Такие обертки преобладают при программировании в асинхронном или реактивном стиле, и наличие языковых конструкций, упрощающих работу, скажем, с такой базой кода, где активно используются Future – еще один аргумент в пользу Scala.

Что такое типы классов? Роль их примерно такова, как у паттернов проектирования в Java, однако, они более гибкие и простые в использовании, как только вы крепко усвоите их смысл. По этому поводу есть несколько отличных руководств, например, 1, 2.

Что насчет конструкторов типов? Это такие типы как Future или Option, служащие “контейнерами” или “обертками” для других типов. Так, у вас может быть Option[String] или Future[Int]. Типы высшего порядка позволяют писать код, обеспечивающий абстрагирование любой обертки. См. например. 1, 2.

Вдруг вам интересно, зачем вообще прибегать к Future/Task? Дело не только в том, что большинство высокопроизводительных «реактивных» вычислений с минимальными задержками выполняются с применением асинхронного ввода/вывода, для которого просто просятся именно такие конструкции. Другие причины приводятся в этой дискуссии на reddit и в моей статье “Зачем возиться с обертками?”.

Работа в преимущественно неизменяемой среде, а также возможность с удобством обращаться с такими конструкциями как Future, Promise или Task (и абстрагировать их!) радикально преображает ваш код. На первый взгляд это может быть неочевидно: если у вас за плечами опыт Java или Ruby, то осознать эти аспекты Scala вы сможете не сразу. Но, даже с образовательной точки зрения полезно разобраться, как устроен «функциональный» подход и, что гораздо важнее, почему он может оказаться весьма достойной альтернативой.

Естественно, и у Scala, и у Kotlin есть ряд общих преимуществ по сравнению с Java, например:

  • Более компактный синтаксис
  • Меньше стереотипного кода
  • Более насыщенная система типов
  • Отсутствие языкового балласта


В то же время, оба языка открывают доступ к экосистеме библиотек и фреймворков JVM.
Чем насыщеннее система типов (в Scala она богаче, чем в Kotlin, а в Kotlin – богаче чем в Java), тем больше работы по верификации выполняется компилятором, а не человеком. Именно для этого и созданы компьютеры: выполнять скучные, рутинные повторяющиеся задачи. Проверка применимости типов – определенно, как раз одна из таких задач.

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

ФП vs OOП

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

ФП – это программирование при помощи функций, правда, не любых, а референциально прозрачных (см. этот ответ на reddit в более раннем треде, где превосходно объясняется референциальная прозрачность). В ООП коммуникация с объектами организована при помощи “сообщений” или, в нашей терминологии, вызовов виртуальных методов. Нет ни одной причины, по которой два этих подхода не могли бы сосуществовать, и Scala это уже продемонстрировал!

В твите о достоинствах Scala Джон де Гоус упоминает некоторые черты ООП, полезные и при чисто функциональном подходе, в частности, модули первого класса (получаемые путем композиции объектов), точечный синтаксис (вызов методов в объектах) и классы/экземпляры типов как конструкции первого класса. Все это – элементы успешной комбинации двух парадигм. Может быть, еще какие-то не за горами?

Проект «синтеза» еще не закончен, здесь определенно остается поле для обсуждения. Один из незавершенных аспектов – это предлагаемый синтаксис методов расширения, который должен прийти на смену гораздо более путаным неявным преобразованиям. Другой – оптимизация синтаксиса классов типов; предложение по этому поводу, высказанное некоторое время назад, явно сырое и не охватывает некоторые из наиболее распространенных случаев использования монад в Scala. Некоторые предложения лучше, другие требуют доработки, но хорошо, что они поступают, и о них идут дискуссии; благодаря ним язык живет и, в конечном счете, в нем закрепляется наилучшее решение.

Scala 3

Scala 3 выйдет через два года. В нем появится ряд интересных возможностей, в частности, непрозрачные типы, параметры типажей, новый подход, связанный с метапрограммированием, типы объединения и & пересечения, неявные типы функций – вот всего несколько примеров. Конечно, здесь возникает (обоснованная) обеспокоенность по поводу миграции.

Уже известно, что будет представлен специальный инструмент для автоматической миграции кода со Scala 2 на Scala 3 при помощи scalafix. Поскольку Scala – статически типизированный язык, такая задача решаема в больших масштабах и гораздо проще, чем, например, на Python. Но, разумеется, никакой магии тут нет: даже если этот инструмент на 99% обеспечит правильное покрытие кода, все равно останется 1% наиболее проблемных случаев. Поскольку на магию рассчитывать не приходится, миграцию этих фрагментов нужно будет выполнить вручную.

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

Обнадеживает тот факт, что команда Scala всерьез подходит к миграции. Тогда как ранее миграция между старшими версиями Scala (напр. с 2.8 на 2.9) была довольно обременительна, последние миграции прошли гораздо лучше. В них участвуют три основных стороны: EPFL, ScalaCenter и Lightbend все они (зачастую вместе) работают на облегчение миграции. Например, существует двоично-совместимый инструмент MIMA, а также в сообществе постоянно создаются многочисленные новые библиотеки, призванные обеспечить удобную работу с новыми версиями Scala.

Наконец, пока не законченный инструмент TASTY (который, соответственно, пока нельзя оценить) должен обеспечить использование двоичных файлов из Scala 2 в Scala 3.

Итак, зачем же использовать Scala?

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

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

Резюме

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

Scala позволяет вам развивать свой стиль программирования, каким бы языком вы раньше ни занимались: Java, Ruby или только пробуете себя в программировании. Не существует однозначно выигрышного подхода к Scala; можно придерживаться или более императивного подхода Akka, или более функционального подхода Cats и Scalaz.

Вот где можно усмотреть проблему: в сообществе Scala есть фракции, придерживающиеся “реактивного”, “синтетического” OOП/ФП подхода и чистого ФП. Однако, на самом деле в этом заключается огромное преимущество. Благодаря такому разнообразию ведутся дискуссии, высказывается множество различных мнений с разных точек зрения. На этом, в свою очередь, отлично можно выучиться нестандартному решению задач и обогатить собственный инструментарий.

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

Издательский дом «Питер»

246,46

Компания

Поделиться публикацией
Комментарии 48
    +9

    Имхо, Scala хорошо развивает мозг и позволяет обогатить себя как профессионала за счет изучения новых подходов и принципов.
    Но как язык промышленного программирования я бы не стал его использовать. Когда работаешь в команде понимание кода других участников может быть затруднительно, даже если вы более менее согласились с тем что и как будете применять. Разработка на Scala даёт много вольностей и возможности написать сложный для понимания код. Чем любят заниматься люди с целью повышения своего ЧСВ.
    Сама Scala мотивирует активно думать над тем что бы писать выского абстрактный код и постоянно планировать абстрактную архитектуру. Что ни как не помогает быстро и качественно решать задачу а скорее подобно творчеству. А когда эта абстрактная архитектура написана кем то другим понять её зачастую затруднительно, хотя задачи которые она решает могут быть достаточно простыми.
    Так же такую сильносвязанную абстрактную архитектуру сложно рефакторить. Потому что хоть она и должна быть отстранена от прикладной задачи(суть абстракции), в реальности основана на решаемой задаче, а новые задачи(бизнес требования) могут требовать существенных измений в коде для поддержки его согласованности или костыля, что обычно и происходит, со временем сильно ухудшая понимание кода.
    По этому я начал искать другие языки которые позволяют писать быстро и качественно. Остановился на Clojure и очень доволен, язык соответствует тому что я хотел найти — быстро писать качественный код.

      0

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

        0

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

        +2
        Я соглашусь, Scala позволяет писать высоабстрактный и «совершенный» код и этим притягивает определенный круг разработчиков, но дальше все зависит от индивидуальности разработчиков и культуры команды.

        У нас, например, поощряется писать более простой код, хоть иногда и чуть больше, а иногда и чуть продублировать.

        Apache Spark со своим style guide пример как огромное количество котрибьютеров с разным бэкгроундом может работать над одной большой кодовой базой

        Twitter — отличный пример из индустрии, избегающий все упомянутые высокоабстрактные архитектуры и продолжающий с успехом использовать Scala
          0
          А вам не кажется, что язык программирования — крайне слабый и не уместный способ enforcement of policies (как это по русски — навзязываение политик, хз)?

          Если в команде анархия и нет ни ревью, ни guidlines, нет способа рассмотрения и принятия архитектурных решения, то что-то не так в царстве датском.
          0

          Очень странная метаморфоза произошла с Typesafe.


          Вообще, по моим ощущениям, примерно с того же времени в Scala начался какой-то застой. Если тогда появление Kotlin выглядело забавным, то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin. Потому что действительно better java, а не wannabe haskell, со всеми вытекающими.

            0
            то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin

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

              Согласен.


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

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

                0

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

                  0

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

            0
            ph_piter ну и где скидка для хабра? :)
            уже нашел на habr.com/company/piter/blog/341808
              +1
              Но я считаю, что именно Scala, а не Kotlin, по-прежнему заслуживает такого звания. На то есть две основные причины:

              Во-первых, неизменяемость в языке Scala первостепенна. Это связано с природой Scala как таковой: писать на нем код удобно прежде всего при помощи неизменяемых данных.

              А чем иммутабельность в Scala отличается иммутабельности в Kotlin?
                0
                При этом насыщенная система типов полезна не только при написании кода, но и, в гораздо большей степени при чтении кода. Когда тебе легко сориентироваться в базе кода, понять, что он делает, а, к тому же, не страшно (или не так страшно) браться за его рефакторинг, это очень положительно характеризует язык как с технической, так и с прикладной точки зрения.

                Вот! Идеально объясняет почему C# у меня вызывает такое чувство обескураженности при подходе к любому проекту где уже потрачены сотни человекочасов, а с F# все проходит легко.

                  0
                  как-то низко не упоминать цейлон, из которого через джва года скала допиз… дозаимствует систему типов
                    0

                    Не могли бы вы раскрыть мысль? Я правильно понял что Scala которую разрабатывают с 2004 года украла систему типов у Цейлона который разрабатывают с 2011? Или украдет в Scala 3.0?
                    У меня плохая память и даты я взял из википедии.

                      +2
                      да, в скала 3.
                      в математических аспектах того, как поженить типы-пересечения и -объединения с наследованием, дженериками, и прочими, существовавшими до того, фичами систем типов разбирался конкретный человек — член команды цейлона. он же запилил систему типов котлина, о чем чуваки из джетбрэйнса тоже не любят распространяться. а теперь эти же фичи переползают в тайпскрипт и вот в скалу.
                      чем они 14 лет занимались — хз, пытались убедить народ, какой у них прагматичный язык получился со спейсшип операторами и встроенными html-тэгами, наверное
                        +2
                        Спасибо, что объяснили основновные исторические пробелы создания скалы.
                        Не знал, что Одерски 14 лет пилил встроенные html-тэги, в ожидании пока освободится единственный на планете человек, который знает что такое типы-пересечения и -объединения с наследованием… Но слава богу, что через 14 лет ожидания он наконец освободился и смог запилить все необходимое для скалы.
                          0
                          а что конкретно Одерски сделал по теории языков программирования?
                          такие вещи не появляются из воздуха, у них есть конкретные авторы. это потом становится странно, а что же раньше никто так не делал, когда уже всё придумано и проработано
                            0
                            lampwww.epfl.ch/~odersky/papers/#Scala

                            Вся информация тут. Не надо выставлять человека уж совсем идиотом.
                              0
                              я не считаю его идиотом, он выдающийся инженер
                              но всякий ли выдающийся инженер сделает хороший прагматичный язык программирования — думаю, скорее, не всякий
                              а еще мне не нравятся попытки со стороны комьюнити скалы объяснить окружающим программистам, какая скала на самом деле практичная, и замести под ковер тот факт, что это всегда был исследовательский проект. переубедить, а не исправить косяки.
                              возможно, в этом плане что-то поменяется в третьей версии как раз, посмотрим
                                0
                                Каждый понимает «прагматичность» по своему.
                                Я не могу себя причислить к скала сообществу, потому что я не работаю с этим языком на постоянной основе. Но приходилось писать несколько проектов в прошлом на базе Play Framework. Перед этим я прошёл вводный курс по скале на курсере (который опять же ведёт Мартин). От этого языка всегда веяло какой-то академичностью — такое ощущение, как-будто его с интересом и любовью препарировали в стенах университетских лабораторий :) Я, кстати, не припомню, чтобы это кто-то скрывал.
                                И вот появился этот монстр, в основе которого JVM с своими возможностями и ограниченями, на которое сумели взгромоздить и FP и OOP, подружив их друг с другом, и доселе невиданную систему типов (я честно не знаю, украли ли они её у кого-то или сами придумали) и ещё бог пойми чего и всё это ещё и под соусом обещаний интероперабилити с java, type-safety, иммутабельности и т.д и т.п. Иронически, получился швейцарский нож. Университет EPFL, в котором преподает Мартин, так же находится в Швейцарии (Лозанна) :)

                                И вот тут уже конечному разработчику решать, как с этим многофункциональным ножом играться. Если юзать его аккуратно, как better java, оно, на мой взгляд, довольно хорошо работает. Писать на скале, как на улучшенной джаве действительно удобно и приятно. Прагматично? Ну, возможно.
                                Но можно заиграться и перерезать себе все руки (прежде, чем отстрелишь ноги) — любой обфускатор позавидует. Концов не соберёшь — в какой-то момент сдавался даже IntelliJ Idea для скалы. Отдельно радует SBT, в котором есть операторы, которые даже загуглить нельзя. :)

                                P.S. Я потом ещё прошёл курс по реактивному программированию на базе скалы — это просто взорвало мой мозг.
                                  0
                                  ну как «по-своему»?..
                                  не раз видел, как разные команды приходят к примерно одному списку критериев прагматичности: починить косяки предшественников, при этом не трогать то, что и так было нормально; чтоб тулинг был возможен; и чтоб компилялось быстро. это навскидку самое основное
                                    0
                                    У всех команд разный опыт, разная экспертиза и, как следствие, может быть совершенно иное видение того языка, который бы больше подходил под их конкретные задачи и требования. Для кого-то динамическая типизация = прагматичность — тогда не надо беспокоиться о системе типов (которая может быть очень даже непросто для понимания) или о скорости компиляции. Кто-то исходит из «модности», «хайповости», трендовости, размера и/или активности сообщества — как быстро можно загуглить ту или иную проблему или как быстро можно получить ответ на stackoverflow. Скала уже давно прошла свой пик популярности. Тот, кто с ней остался, вполне отдаёт себе отчёт — что, зачем и почему.
                                      0
                                      я имел в виду команды разработчиков языков программирования и то, что они хотят заложить в свой продукт
                                        0
                                        А, прошу прощения — неправильно понял о ком речь.

                                        www.artima.com/scalazine/articles/origins_of_scala.html
                                        Тут есть некоторые пояснения :)
                                        Интересно, насколько корнями Scala уходит в самую первую Java и ранее. И как сама Scala, которая частично «базировалась» на малоизвестных Funnel, Pizza, в каком-то даже смысле опережала развитие Java на тот момент.
                                    0

                                    Вот кстати из моего наскального опыта, использовать scala как better java — это в самом деле дорога в никуда. Язык действительно достаточно хорошо заточен на то, чтобы возлюбить FP, FRP, иммутабельность. Правда в какой-то момент надо научиться понимать во что это всё хотя бы примерно компилируется, но тем не менее.

                                    0

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

                                  0
                                  Ну как минимум вот столько — lampwww.epfl.ch/~odersky/papers
                                +1
                                А можно чуток подробностей? Просто я например до этого бы уверен, что и первые и вторые и третьи просто взяли систему типов Ocaml.
                                  0
                                  безусловно, ноги растут еще из ml и ocaml.
                                  я их не знаю в должной мере, чтобы составить исчерпывающий список отличий, но очевидно, если бы там всё уже было в том же самом виде, не надо было бы ждать больше десяти лет, чтобы начать это повторять в скале, можно было еще в первой скале позаимствовать.
                                  какие-то намёки на типы-пересечения и -объединения есть даже в яве. в catch(FooException | BarException e) у нас практически тип-объединение. или вот так можно: void printAndClose<T extends Printable & Closeable>(T arg)
                                  в недрах компиляторов эти вещи тоже были до того, дело оставалось за малым — понять, что за частными случаями скрывается более общая красивая математика, которая упростит работу с типами, сообразить дать этот инструмент программисту, придумать синтаксис, попробовать кучу вариантов совмещения новой фичи с имеющимися.
                                  а так да, всё уже было :)
                                  0

                                  А можно подробнее про этого человека? Возможно у него есть имя? Было бы интересно узнать.

                                    +1
                                    Росс Тэйт
                                    вообще, рекомендую сайт посетить ceylon-lang.org
                                    там не только система типов крутая, но и много чего еще. доки хорошие, и что мне больше всего нравится, не только описано, что сделано, но и почему сделано именно так. и на гитхабе обсуждения фичей интересно почитать
                                  0

                                  Вы по всей видимости говорите о Ross Tate который ведёт свою научную деятельность с 2010-го года. Его работа наверняка повлияла на Цейлон, Скалу и Котлин,


                                  Однако Intersection и Union Types были изобретены (открыты?) и изучались задолго (эта статья 1995-й года и есть ещё более ранние) до работ Росса, и появлялись во многих экспериментальных языках. Изучать эту тему мог кто угодно, в том числе и Росс, и Мартин, и другие учёные.


                                  Сама же Scala 3 базируется на компиляторе Dotty, основой которого является исчисление Dependent Object Types. Обоснование этой системы типов выполнено в-основном аспирантами Мартина (Nada Amin, Samuel Grütter, Tiark Rompf и Sandro Stucki). Intersection и Union типы являются частью DOT и используются для описания наименьшей верхней границы (least upper bound) для if- и match- выражений.


                                  Так что 14 лет для построения компилятора, поддержки и развития ветки Scala 2, переосмысления ошибок, создания новой системы типов и доказательства её корректности, построения нового компилятора Dotty и использование его как бэкенда для языка Scala — вот для всей этой работы 14 лет для меня не выглядит сильно уж большим временем.

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

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

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

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

                                            Раз мы так далеко отошли от темы, я позволю себе задать вопрос, который может показаться провокационным, но мне интересна ваша точка зрения. Почему на stackoverflow по поиску работы с ключевым словом Ceylon 0 результатов, а Scala — 115. И где мне начать писать за деньги, если я решу бросить Scala\Java\Kotlin и переползти на Ceylon ?


                                            Приведу ссылки дабы не казаться голословным.
                                            https://stackoverflow.com/jobs?q=Ceylon
                                            https://stackoverflow.com/jobs?q=scala

                                              0
                                              думаю, потому же, почему вакансий по яве еще на порядок больше :) им лет больше.
                                              а про котлин такой вопрос года полтора назад тоже еще был «провокационным», ничего, как-то появились вакансии.
                                              начинать юзать новый язык можно с изолированных частей имеющегося проекта или на каких-то поделках поиграться.
                                +1

                                Зачем человеку Скала? Повыпендриваться и поразминать мозг — да, но уж точно не упростить себе жизнь.
                                Имею опыт внедрения скалы в продакшене (чего, как мне кажется, нет у большей части горячих фанатов этого языка). Начиналось это как небольшой вебсервис почти без бизнес-логики (перекладывал объекты из одного апи в другое), поэтому решил немного поэкспериментировать, так как это казалось безопасным. Разумеется пару лет спустя оно переросло в здоровенный сервис и обросло кучей фич. Никогда такого не было и вот опять, да. И началась боль.


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


                                Ковыряться в библиотеках — то еще удовольствие. Тут не работает вариант "использовать то что нравится, а всякую сложную хаскеллеобразную муть не использовать, если не хочется". Потому что разработчики библиотек зачастую придерживаются другого мнения, и их апи представляет густо замешанную смесь из монад, функторов, имплиситов, присыпанных всякими scalaz-штуками, от которых у меня глаза кровоточат когда я пытаюсь понять, что это все значит.


                                В итоге столкнулся с тем, что:


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

                                В общем никому не порекомендую повторить это. Если у вас нет команды звезд ФП, то никакого профита с переезда на скалу не получите, только боль.
                                На хабре уже когда-то был перевод статьи на эту тему https://habr.com/post/273535/, могу в целом подтвердить со своего опыта что так оно и получается.


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

                                  +1
                                  Имею опыт внедрения скалы в продакшене (чего, как мне кажется, нет у большей части горячих фанатов этого языка).<
                                  Интереса ради, не споров для — а где Вы с фанатами Scala общаетесь ?

                                  P.S.
                                  Был перевод на хабре, о том что сам Одерски считает успехом не 1000 сервисов на Scala а Spark и Kafka.

                                    +1
                                    Да вот тут в комментариях на хабре. Практически к каждому такому посту (в том числе и к тому, на который я ссылку дал), набегает в комментарии куча народу с криками МОНАДЫ! ТАЙПКЛАССЫ! и закидывает какашками тех, кто пытается объяснить что для успешного внедрения языка нужны не такие фичи, а простота разработки, который в скале с точки зрения среднего разработчика нет. А на все рассказы о сложности поддержки скала-программ они начинают кричать что мол это те кто внедрял — дураки.
                                    Плюс пару раз общался с адептами ФП (не скалы) в реальности, там примерно то же самое — яростная концентрация на инструменте, а не на решаемых задачах.

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

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


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


                                      https://www.youtube.com/watch?v=dWyGM3MnN0A

                                        +1

                                        Если инересна тема, то можно почитать книгу Paul Chiusano and Runar Bjarnason, Functional Programming in Scala. Сам я ее еще не прочитал, только собираюсь, но слышал пложительные отзывы, как о хорошем введении в ФП. Она не является учебником по Scala, там лишь присутсвуют минимальные уточнения к коду и отсылки к документации, чтобы примеры были хоть как-то понятны и тем, кто Scala не знает, так что лучше ее читать будучи уже знакомым со Scala.

                                          0

                                          Красноая книга топ !

                                            0
                                            +1.
                                            Мы очень надеялись и продолжаем надеяться, что Пол обновит эту книгу

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

                                Самое читаемое