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

Аргументы за Scala известны:

1. Scala лаконичная;
2. Scala функциональная;
3. Scala крутая и современная;

В ответ на то, что Scala медленно загибается, Мартин Одерски заявил следующее: «В 2015-м было затишье, но вот в 2016-м развитие Scala должно ускориться».

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

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

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

Переехав на Java 8 и освоив Optional и стримы, я начинаю понимать привлекательность функционального подхода. Когда я вижу, как вложенный цикл for выполняет итерации по коллекции или пачку проверок на null в иерархии класса, меня немного передергивает… Не столько из-за того, что такой код попросту уродлив, сколько из-за того, что до недавнего времени я и сам не знал ничего лучше.

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

ЗА: Scala – один из немногих функциональных языков, за разработку на котором вам будут платить


Если бегло пройтись по вакансиям Scala, можно увидеть, что коммерческие проекты начинают использовать этот ЯП. Это при том, что вакансии по Clojure и OCaml не находятся в моем городе вовсе, а Erlang, Kotlin и Haskell возвращают по одной вакансии каждый (обычно как дополнительный скилл). Тут стоит отметить, что Scala, во всяком случае, востребована как первичная компетенция.

(прим. пер.: В Санкт-Петербурге на момент перевода статьи 61 вакансия Scala, Erlang и Kotlin – 22 и 11 соответственно, а другие приведенные языки действительно выдают минимум вакансий).



ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке


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

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

ЗА: Даже если вы останетесь на Java, вы станете лучшим разработчиком


Почему эта переменная не final? Может быть лучше возвращать новый объект, а не модифицировать существующий? Является ли этот return Optional или нет? Все эти вопросы я задавал себе, когда писал на Java из-за моего слабого понимания функционального программирования. Ответив на эти вопросы, я улучшил свой код.

Даже если я не смогу писать на Scala, знание Scala повлияет на мой код только положитедбно, даже если этот код будет написан на Java.

ПРОТИВ: Scala – это один вариант из бесконечного множества вещей, которые можно изучить


Станет ли изучение Scala наилучшим вложением моего времени, учитывая, что у разработчика список возможных компетенций стремится к бесконечности? Я могу потратить время на изучение Scala, а может быть лучше заняться изучить все подводные камни работы с облачными платформами наподобие AWS? Или стоит изучить логику процессинга Big Data? А может стоит посмотреть в сторону OWASP Top-10 или администрирования Linux-систем? Или заняться этой новенькой JavaScript бибилиотечкой?

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

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

ПРОТИВ: Scala может просто «пробивать лед» для языков, подобных Kotlin


Kotlin еще предстоит взлететь (на май 2016 он даже не вошел в ТОП-50 индекса TIOBE), но я готов поспорить, что Kotlin станет ключевым языком функционального программирования на JVM в ближайшие несколько лет.

Язык разрабатывается JetBrains, так что tooling для него будет убойным в любом случае. Kotlin развивается из требований отрасли, а не из академических измышлений. К концу этого года, я думаю, Kotlin сравняется со Scala по количеству доступных вакансий.

ПРОТИВ: Возможно, функциональная Java достаточно хороша?


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

Да, это не будет чистым функциональным подходом, и у вас не будет права хвастаться Higher Kinded Types. А может вы просто получите 80% преимуществ от использования 20% функциональных coding features?

Простых ответов не бывает


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



Если вы когда-либо думали о переходе на Scala, но не знали, с чего начать, приходите на двухдневный тренинг по Scala для Java-разработчиков от разработчика Scala плагина из JetBrains Александра Подхалюзина, который пройдет 12-13 октября в Петербурге, накануне Joker 2016.

Вкратце о тренинге


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

И полезные ссылки для холивара Java vs Scala:

1. Как перейти с Java на Scala;
2. Scala хуже, чем Java;
3. Да, Вирджиния, Scala сложна!
4. Как будучи Java-программистом перестать сомневаться и перейти на Scala.
Поделиться с друзьями
-->

Комментарии (92)


  1. 23derevo
    13.09.2016 17:56
    +5

    Я помню прекрасный разговор в Киеве, который состоялся у меня с местными ****-овцами три года назад. Дискуссия шла вокруг языков для JVM, и барышня сказала, что вот, мол, у них открыты первые вакансии на Scala. Я спросил у нее подробностей и выяснил, что

    • в одном из проектов — это не прод, а тесты
    • в другом — это эксперимент
    • в третьем скалы вообще нет, а в вакансии — это просто замануха, чтобы умных ребят заманить (мол, знает скалу, значит умный и надо его брать)


    После этого скеписиса к скале у меня прибавилось. И, к слову сказать, за эти три года вроде как Scala не стала сильно популярнее.

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


    1. jukkagrao
      13.09.2016 18:23
      +6

      Мне кажется правильной реакцией было бы если бы у вас скепсиса к той самой барышне прибавилось. Scala тут не виновата.


    1. senia
      15.09.2016 16:56
      +1

      Мучается он… Был я когда-то у них (люксофт питерский, но отдел полностью под Тинькофф) на собеседовании: запомнилось ощущение абсолютной неадекватности интервьюверов. Вместо собеседования по scala — tricky questions по темам, в которых сами плавают. Они так долго искать будут людей если не организуют процесс собеседования кандидатов.


  1. iamironz
    13.09.2016 18:17
    +15

    Так как же всё-таки переводится аббревиатура «Scala»?
    ответ
    А разгадка вот в чём:
    ответ


    1. senia
      15.09.2016 16:58

      Еще вариант — переименовать в hascalator.


  1. Borz
    13.09.2016 18:20
    +1

    "Я нахожу меня порванным между очевидными преимуществами" — это точно вручную переводилось?


    1. ARG89
      13.09.2016 18:28
      +2

      Вручную, и эта ошибка — доказательство! Человеческий фактор вмешался и помешал переводчику сделать все идеально с первой попытки:)


  1. stalkerg
    13.09.2016 18:43

    Не Java разработчикам (или которые только иногда на нём пишут) всё это кажется странным...


  1. JuniorIL
    13.09.2016 19:09
    +9

    ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке

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


    1. sshikov
      13.09.2016 19:30
      +2

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


  1. helions8
    13.09.2016 19:29
    +2

    ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке


    Это утверждение и следующий за ней абзац откровенно повеселили. Я так познакомился с Erlang'ом, просто потому, что архитектору был выдан карт-бланш и очень хотелось попробовать Erlang, а тут такая возможность. Медленно переписываем теперь. Со Scala забавные ситуации, когда вместо того, чтобы взять Спринг или Джангу для того, чтобы по-быстрому написать несложный рест-сервис, разработчики воротят нос и два месяца втыкают в сликовские транзакции и пишут тот код, который для Джавы уже есть готовый. К сожалению, я отмечаю то, что людям важнее писать на Скале, чем выпустить продукт.

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


    1. solver
      13.09.2016 21:08
      +6

      > Со Scala забавные ситуации, когда вместо того, чтобы взять Спринг или Джангу для того, чтобы по-быстрому написать несложный рест-сервис, разработчики воротят нос и два месяца втыкают в сликовские транзакции…

      Такие высказывания веселят не меньше. Какая разница, втыкать 2 месяца в джангу или в слик?
      Мне вот писать рест сервис на Akka сейчас будет быстрее чем на Спринге или тем более на джанге, например)


      1. andy128k
        13.09.2016 22:09
        +2

        Такие высказывания веселят не меньше. Какая разница, втыкать 2 месяца в джангу или в слик?
        Лично знаком с приведённой ситуацией. И ваш довод никак не противоречит. Разработчики знали и спринг, и джангу, но очень желали сделать с помощью скалы и слика.


        1. bormotov
          14.09.2016 00:05
          +2

          И причем тут скала как таковая? Это же разработчики хотели?
          А кто им разрешил? Тот, кому тоже не очень важно то продукт выпускать?


        1. bigfatbrowncat
          14.09.2016 20:44
          +2

          Может быть, разработчики, зная Джангу и Спринг, настолько их ненавидели, что хотели попробовать что-то другое?


          1. andy128k
            15.09.2016 00:12
            +1

            … ненавидели...
            Очень профессионально :)


            1. bigfatbrowncat
              15.09.2016 01:25
              +3

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

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

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

              Так вот, этот товарищ мрачнеет, когда ему приходится заниматься разработкой/поддержкой кода на C++. Он предпочитает Java, Objective C… А «кресты» именно не любит. И причины своей неприязни легко может изложить, пересказав пару «очаровательных» историй, в которые влипал из-за неудобства их синтаксиса и компиляции.

              А что — профессионалы обязаны любить любой инструмент?


              1. helions8
                15.09.2016 16:11

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


                1. bigfatbrowncat
                  15.09.2016 21:34

                  Дает преимущества, если на самом деле технология хреновая, а учат они хорошую.

                  «Вкусовщина» профессионала всегда имеет под собой основания. Когда вам опытный человек говорит «X — дрянь», он имеет в виду отнюдь не то, что при изучении X от него ушла подружка, а то, что в X присутствует плохой код, неудобный API, много ошибок или еще что-то, что делает X плохим.

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

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


                  1. helions8
                    15.09.2016 21:43
                    +1

                    Дает преимущества, если на самом деле технология хреновая, а учат они хорошую.


                    Как определяется степень хорошести? Джанго — плохая технология, потому что в ней плохой код, неудобный АПИ и много ошибок? А Play хороший потому, что в нем хороший код, кдобный АПИ и нет ошибок? Я правильно понял ваш подход?

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


                    1. solver
                      15.09.2016 23:24

                      Проблема только в одном сейчас.
                      Процентов наверно 70, если не больше, проектов сейчас пишутся с одинаковой степенью эффективности (для заказчика) на практически любом популярном языке. Под эффективностью я тут понимаю решение бизнесзадач заказчика.
                      Т.е. условный бизнеспроект можно без серьезных преимуществ со стороны этих технологий написать на: PHP, Go, Python, Java, Scala, Clojure, С# и что там я еще забыл.
                      Такие важные составляющие решения как: скорость разработки, надежность, достаточная производительность. Будут определяться на 99% людьми участвующими в проекте.
                      И вот тут проявляется интересный факт. Различность технологий позволяет разным людям, с разными (но работающими естественно) решениями работать вместе эффективно.
                      Разность этих технологий позволяет людям объединяться по интересам и работать вместе не перегрызая друг другу горло) И это хорошо.
                      Бизнесу надо сделать правильно ровно одну вещь. Это нанять хорошего техдира, который сможет не мешать группе людей, на удобной им технологии сделать хорошо бизнесу. Ему надо только сдерживать совсем уж безудержные порывы разработчиков. Ну чтобы они начали проект на коболе в 2016 году, или на брейнфаке ))


                      1. helions8
                        16.09.2016 10:54

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


                    1. bigfatbrowncat
                      16.09.2016 17:05

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

                      Я говорю об оценке в целом.

                      Специалист взял в руку инструмент, поработал им день и на вопрос, «насколько хорош этот инструмент», выругался матом.

                      Это была эмоциональная оценка.

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

                      Но специалист просто вам ответил «эта вещь мне не нравится». А потом, как в анекдоте, грязно выругался.

                      Вам кажется, что он непрофессионален? Или профессионал не имеет права на точку зрения относительно инструмента?

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


                      1. helions8
                        16.09.2016 19:04
                        -1

                        «Специалист взял в руки микроскоп и попытался им целый день забивать гвозди, и на вопрос, «насколько хорош этот инструмент», выругался матом. Это была эмоциональная оценка.» Думаю, моя мысль понятна.

                        «Оценка в целом» это такое размытое понятие, что я бы не стал им оперировать. Если, например, задача относится к сфере высокочастотного трейдинга, то наверняка в первую очередь подумают о С++ и Java, как бы к ним не относились. Но это лучшие инструменты для решения задачи построения приложения подобного рода и выбирать надо их, несмотря на эмоциональную оценку, любовь и личную привязанность.

                        Если надо нарисовать простенькую интернет-витрину для магазина шапок, то более подходящими будут какие-то CMS на PHP или Рельсы или еще что-то подобное. И если для решения задачи подобного рода выбирается С++, то тут у меня возникают вопросы. И дело не в том, что на плюсах нельзя написать такое, дело в том, что это не подходящий инструмент, который удорожает разработку и поддержку. Именно об этом я и писал, но не в такой утрированной форме.

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

                        Ну и да, если вместо внятных аргументов я слышу «фу-фу-фу, я не буду на этом говне писать», то я отношу это как раз к непрофессионализму. Мое личное мнение.

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

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


                        1. bigfatbrowncat
                          16.09.2016 23:47
                          +2

                          Я вам привел простой пример, вы обобщили его до абсурда. Зачем?

                          Речь шла о ситуации, когда:
                          1. Инструмент был использован на основании того, что подходил к поставленной задаче (во всяком случае, предназначался для нее)
                          2. Инструмент был выбран сознательно

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

                          Человек оценивает инструмент не «в целом». Он его оценивает в контексте поставленной задачи.

                          Суммирую:

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

                          Напомню, что изначально в дискуссии речь шла о конкретных примерах. Я сказал, что, возможно, специалисты выкинули из рассмотрения некий фреймворк, потому что он им не нравился. Из чего, скажите на милость, вы сделали вывод, что он им не нравился «как сферический в вакууме»? Он им не нравился конкретно — для их целей. Здесь и сейчас.


          1. taujavarob
            15.09.2016 14:40
            +1

            Может быть, разработчики, зная Джангу и Спринг, настолько их ненавидели, что хотели попробовать что-то другое?

            Вряд ли. Просто скучно стало им поди.


      1. helions8
        13.09.2016 23:56

        Я не писал про 2 месяца на джанге, я писал «по-быстрому на джанге», а это неделя-две. То, что вам лично быстрее на Акке я не оспариваю. Мне больше интересно то, на чем будет быстрее широкому кругу разработчиков.


        1. bormotov
          14.09.2016 00:07

          Широкому кругу быстрее на bottle или flask (питон)
          Но что это меняет в контексте данной статьи?

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


          1. helions8
            14.09.2016 00:20

            О, а в чем же тогда?


            1. bormotov
              14.09.2016 07:41

              в людях?

              цитата из этой статьи

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


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


              1. helions8
                14.09.2016 13:34

                Выпустили, но несколько позже, чем можно было бы. Хотя это скалисты с опытом. Ну и если они, по вашему выражению, напрасно сразу за слик схватились, то как это сочетается с «если выбрали скалу, то это серьезно»?


                1. bormotov
                  14.09.2016 14:39
                  +1

                  очень легко сочетается

                  Пример из нашей жизни, как раз вот один из разработчиков интересовался, сколько проекту лет — 6 лет. от первого коммита. Можно ли сказать, что проект, который компании прибыль — это несерьезно? Вполне серьезно. Никаких проблем из за того, что «скала» мы не испытывали. Да, лет пять назад, были некие сложности с поиском людей, но наша практика показала, что человек который умеет использовать Java, под руководством нашего тимлда, вливается в проект примерно за пару недель. За пару месяцев за ним вообще уже не нужно приглядывать.

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

                  То есть суть отличий будет
                  — в сложности проекта как такового
                  — в людях

                  Сделал wc -l в src/main/scala — всего 65602 строк. Никакого слика или другого ОРМ у нас нет. В оракл и постгрес ходить умеем, но нужно не часто. Основное хранилище — монга.


                  1. helions8
                    14.09.2016 14:41

                    Слово против слова. Я вам тоже привел пример из жизни.


    1. andy128k
      13.09.2016 22:18
      +3

      … пробивать лед… для среднего уровня...
      Это самое грустное. Средний уровень должен расти, а не привыкать десять лет к «новинкам» (из 60-ых) типа анонимных функций.

      Скала должна «пробивать лёд» НЕ ДЛЯ котлина, а К хаскелю, агде, идрису…


    1. senia
      15.09.2016 17:01
      +3

      Во что там втыкать? Джуны за месяц в состоянии освоить слик и akka-http. И scala, впервые ее увидев в начале месяца.


      1. helions8
        15.09.2016 17:11

        Без иронии – я очень завидую уровню ваших джунов. Во что втыкать я не сильно понимаю, но я вижу результат.


        1. senia
          15.09.2016 17:27

          Осваивали «by example». С активной помощью, конечно, но в итоге вполне адекватно использовали. Показать пример, отвечать на вопросы, проводить review. Хотя может это джуны такие хорошие были — выборка пока маленькая.


  1. fogone
    13.09.2016 19:51
    +7

    ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке

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


  1. unabl4
    13.09.2016 20:11
    +12

    Используем Скалу в одном из наших под-проектов.
    Скажу так, что сколько бы я не пытался начать изучать Java — синтаксис и портянки кода просто убивают всякое желание в этом всём разбираться. За Java 8 ничего не скажу — не пробовал. ИМХО.
    Скала в этом плане действительно лаконичнее и проще читается. Но это с одной стороны. С другой стороны, если начать выкручивать Скалу на полную катушку, т.е начать использовать все функциональные возможности: view bounds, higher kinded types, монады, вариативность и ещё бог знает что, то в проекте вы, скорее всего, быстро останетесь одни, потому что этот лес нагромождений мало кто захочет разгребать, чтобы разобраться и понять саму бизнес-логику, которую вы в этом всём закопали. Вот пока не пишешь сложного (овер-функционального) кода на Скале — всё хорошо. Как только осознал, что написал сложно (через месяц сам не сразу понимаешь, как оно работает) — очень хочется какой-нибудь более простой и однозначный язык.


    1. fediq
      13.09.2016 22:40
      +7

      Ситуация дополнительно усугубляется следующим. Синтаксис Java ограничивает разработчика и заставляет его делать вещи Java-way, начиная от code style и заканчивая паттернами. В результате, хороший код на Java везде выглядит примерно одинаково.

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

      Дедушки помнят девиз одного популярного некогда языка "There’s More Than One Way To Do It". Вспомните, где он теперь? =)

      P.S. Несмотря на это, большую часть промышленного кода пишем на Scala.


      1. bormotov
        14.09.2016 00:09
        -5

        а еще больше порядка в программах на Go, и растет он быстрее


      1. bigfatbrowncat
        14.09.2016 21:07
        +3

        (немного старческого брюзжания)

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

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

        Я, например, до сих пор недоумеваю, за что людям так нравится Питон, в котором принято, чуть что, хвататься за рефлексию, а инкапсуляция отсутствует как таковая.


        1. taujavarob
          15.09.2016 14:44

          Я, например, до сих пор недоумеваю, за что людям так нравится Питон

          Скобок нет. Отступы поди им нравятся.


          1. bigfatbrowncat
            15.09.2016 21:37
            +1

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

            1. А что будет, если нечаянно ткнуть лишний пробел?
            2. А что будет, если в куске кода использовать табуляции, а в другом — скобки?
            3. А что будет, если в одной строке сперва отбивать табами, а потом — пробелами? (я так люблю делать, например)

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


            1. stokker
              16.09.2016 02:22
              -3

              Скобки — это:
              — дополнительное пустое место на экране (обычно целая строка);
              — лишняя информация (так как отступы обычно есть).


              1. Borz
                16.09.2016 08:17
                +2

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


              1. bigfatbrowncat
                16.09.2016 17:11
                +3

                Во-первых, «пустое» место бывает не всегда, а только если скобки выносить на отдельную строку. Я, например, приучен Джавой писать так:

                void someFunction(int arg) {
                    if (something) {
                        foo();
                    } else {
                        anotherFoo();
                    }
                }
                


                Давайте найдем в моем коде лишние пустые строки.

                А во-вторых, я сам иногда НАМЕРЕННО (представьте себе) отделяю блоки кода пустыми строками друг от друга, чтобы улучшить их читабельность. Мне мало имеющихся фигурных скобочек, я хочу больше пустоты.

                Что касается лишней информации, я уже написал (полушутя) про астигматизм. Теперь уточню серьезно.

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

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

                Я, кстати, часто в IDE ставлю курсор на открывающуюся скобочку, чтобы увидеть закрывающуюся. Куда прикажете в питоне курсор ставить?


  1. Optik
    13.09.2016 20:34
    +2

    Субъективно, всех скалистов уже задолбал этот холивар, так что дискуссия/срач вряд ли получится.

    По поводу популярности и вакансий — растет, за год существенно прибавилось, хотя заманухи также хватает.


  1. p1l1gr1m
    13.09.2016 21:29
    +13

    Мда, на дворе 2016-й год, Scala:

    • практически lingua franca в сфере Big Data
    • множество больших компаний используют Scala в production (Akka, Play)
    • в активной разработке Dotty
    • при EPFL открывается Scala Center
    • один из самых популярных MOOC на Coursera — новая специализация по Scala (всем советую)
    • и прочее и прочее


    … а в Виллорибо все ещё думают что "Scala медленно загибается" :)


    1. 23derevo
      14.09.2016 00:05
      +4

      Scala медленно растет. Медленнее, чем лично мне хотелось бы, например. Потому что Java тоже растет, и растет быстрее. И доля Scala, соответственно, не особо увеличивается.


      1. p1l1gr1m
        14.09.2016 15:44

        Абсолютно согласен.

        Возможно Scala вообще никогда не станет мейнстримом как Java или JS.

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


        1. stokker
          15.09.2016 09:45

          > Возможно Scala вообще никогда не станет мейнстримом как Java или JS.

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

          Вопрос только в том, займет ли Scala какую-то нишу или лет через 5, когда ФП будет внедрено повсеместно, просто засохнет.


    1. dedyshka
      14.09.2016 00:13
      -1

      • практически lingua franca в сфере Big Data — это вы про Spark? Ну, дак и на Java под него нормально пишется.
      • множество больших компаний используют Scala в production — сможете привести это «множество» списком?
      • в активной разработке Dotty — и, что?
      • при EPFL открывается Scala Center — и, что?
      • один из самых популярных MOOC на Coursera — новая специализация по Scala — ну, дак маркетинг же… всем поют, что Scala это круто, Scala это для умных и продвинутых (так было одно время с Haskell).

      что нового приобрела Scala как язык за последний год?


      1. 4lex1v
        14.09.2016 07:40
        +3

        А что Scala, на Ваш взгляд, должна приобрести? В языке много чего есть, чего нет добавят / поправят в Dotty, которую собираются зарелизить в какой-то форме (доклад Одерски на ScalaWorld) в обозримом будущем, лишнее уберут. Коммьюнити развивается, работы тоже предостаточно, как для убежденных джавистов, так и для тех кто предпочитает функциональный подход. В чем проблема?


      1. solver
        14.09.2016 10:34
        +1

        > что нового приобрела Scala как язык за последний год?

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


    1. potan
      14.09.2016 15:33
      -3

      Все-таки в бигдате доминирует питон. Почему-то Scala многих пугает.


  1. leventov
    14.09.2016 00:38
    +2

    Взгляд неофита в Скале:


    Мне важно понимать, во что и как компилируется код, когда я его читаю, какие там есть аллокации. В Java это довольно просто, в этом смысле Java на самом деле недалеко ушла от Си (для кого-то это может звучать дико, но в моем видении это так.) То есть Java это такой Си с хорошей IDE, билд тулами, библиотеками и т. д.


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


    Котлин, как мне кажется, еще сохраняет необходимую прозрачность, при том что фактически весь необходимый скаловский сахар там есть. Очень кстати что JetBrains взялись активно проговаривать эту тему, как компилируется Котлин: https://youtu.be/yYG12qaxWO4?list=PLVe-2wcL84b-Waky1nkWVSNHPg6eOQWU9


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


    1. lani
      14.09.2016 16:44
      -2

      Не все ли равно как Котлин компилируется, если он это делает быстрее скалы?

      А так используешь его в продакшене на Андроиде и чувствуш себя белым человеком (+ ценность как девелопера повышается)


    1. alexeyrom
      14.09.2016 22:37
      +1

      Скала — с ее implicits, mixins, хитрыми коллекциями и магическими фреймворками — уже все совсем непонятно.

      Если интересно, во что скомпилировался конкретный код, всегда можно использовать -Xprint: желаемая-фаза-компилятора. А по сравнению со Spring, JPA и т.д. магии в скаловских фреймворках много меньше (ПМСМ).


  1. eXTreMeHawk
    14.09.2016 09:54
    +3

    Блин, честно, работал в Москве, — пол этажа скала программистов… Сейчас работаю в SF, аналогично, — недостатка в scala разработчиках нет. Scala — это другая ветка эволюции. Здесь не надо сгонять 1000 орков-программистов на один проект. Достаточно небольшой, но компетентной команды профессионалов. Спецназ одним словом. И эта тенденция будет только расти. Посмотрите доклады с любой scala конференции. Уровень докладов, в среднем, на порядок глубже и сильнее чем то, что я, опять же, в среднем, видел на любых конференциях по java. Oracle за 10 лет, имея в распоряжении миллиарды долларов и огромный штат инженеров, не смогла добавить в язык многострадальные value types и ahead of time compiler. Как такое вообще возможно??? И я не говорю уже про type erasure в generics и т. п. баги… Сome on guys, вы всё ещё верите, что в java когда-нибудь появятся идеи, описанные здесь? Это просто невозможно с точки зрения её дизайна, да и Oracle в этом не заинтересована. Нет ничего плохого в том, что java рано или поздно уйдёт со сцены, как это было в своё время с COBOL. Ну просто мир движется вперёд, технологии развиваются, появляются новые идеи и концепции. Пора это уже наконец понять, закопать стюардессу и идти дальше!


    1. fogone
      14.09.2016 10:56
      +3

      Достаточно небольшой, но компетентной команды профессионалов. Спецназ одним словом.

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

      Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?
      имея в распоряжении миллиарды долларов и огромный штат инженеров, не смогла добавить в язык многострадальные value types и ahead of time compiler. Как такое вообще возможно???

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

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


      1. eXTreMeHawk
        14.09.2016 12:33

        > Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?

        Квалификация требуется на уровне первого курса любого технического универа + умение читать. Но сейчас вроде везде так…
        Да, действительно, есть некоторые баги компилятора scala, при попытке «обойти» которые рождается не самый простой код. Это правда. Но такой код, как правило, сосредоточен в библиотеках + в той же грядущей Scala 2.12 уже многое пофикшено. В целом, я бы назвал это болезнями роста.

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

        Абсолютная совместимость бывает только на кладбище. Давайте посмотрим на параллельный мир JavaScript / Frontend Side. Да там в месяц 20 новых фреймворков появляется :-), а совместимость ломается каждые пару лет (см ng1 vs ng2) и почему-то бизнес это не сильно парит…


        1. wing_pin
          14.09.2016 16:44
          +1

          > Квалификация требуется на уровне первого курса любого технического универа + умение читать

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

          >… почему-то бизнес это не сильно парит

          Вы видели хоть одну банковскую систему полностью на JavaScript?


          1. taujavarob
            14.09.2016 17:14

            Нет. Но бухгалтерских на 1C полно. ;-)

            Вообще-то можно, наверное, написать и банковский опер-день на JavaScript. Писали же раньше на Clipper.

            Но нужно ли, если есть Java? — По крайней мере на сервере.


          1. Scf
            14.09.2016 18:08

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


            1. taujavarob
              14.09.2016 18:12

              а уже потом какой-нибудь гуру объясняет, что это функторы и монады.


              «Он с удивлением узнал, что говорил прозой» (С)


        1. fogone
          14.09.2016 22:10
          +1

          Квалификация требуется на уровне первого курса любого технического универа + умение читать.

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

          про баги и болезнь роста — это ответ на какой вопрос?
          Давайте посмотрим на параллельный мир JavaScript

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

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

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


          1. taujavarob
            15.09.2016 14:46

            во-вторых, напомню, мы говорим не о javascript-овых фреймворках, а потере скалой совместимости между версиями, вы считаете это ок?

            Как? — только не это!


      1. alexeyrom
        14.09.2016 22:46
        -1

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


        Только в следующем абзаце вы его как раз и подтверждаете:

        Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?


        Да, именно более высокой квалификацией небольшая команда разработчиков на Scala будет отличаться от аналогичной команды разработчиков на Java (в среднем, конечно).

        Вероятно уйдет, да, но скала этого скорее всего не увидит.


        Вероятно, нет (по крайней мере в обозримом будущем).


        1. fogone
          15.09.2016 11:18
          +1

          Только в следующем абзаце вы его как раз и подтверждаете

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

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


  1. Scf
    14.09.2016 13:10
    +6

    Все недоразумения из-за того, что Scala — фактически три разных языка


    • Сильно улучшенная джава (за это все так любят скалу)
    • Функциональный язык (применять аккуратно)
    • Академический/экспериментальный язык (хороший способ писать совершенно нечитабельный код)


    1. taujavarob
      14.09.2016 18:14
      +4

      Сильно улучшенная джава (за это все так любят скалу)

      Это замануха для привлечения Java программистов. :-)

      Функциональный язык (применять аккуратно)

      Это мода на функциональщину. :-)

      Академический/экспериментальный язык (хороший способ писать совершенно нечитабельный код)

      А вот это суть Scala и есть. ;-)


      1. jukkagrao
        14.09.2016 19:19
        +1

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


        1. taujavarob
          14.09.2016 19:55

          Крупнейшие европейские компании используют его в продакшене.

          хороший способ писать совершенно нечитабельный код

          Шифруются?


      1. Scf
        15.09.2016 11:19
        +2

        Кому что. Никто же не заставляет прикручивать scalaz и активно использовать имплиситы в промышленном проекте, не так ли? Scala в этом отношении немного похожа на C++ — нужно знать, какими фичами языка можно пользоваться, а какими — не стоит.


  1. potan
    14.09.2016 15:30
    +1

    А что такого в Kotlin функционального? Pattern matching есть? С типом Option как с монадой он работает? Может еще и функция значение последнего выражения возвращает бeз необходимости писать return?


    1. lani
      14.09.2016 18:33

      • функции вне классов
      • лямбды
      • функции высших порядков
      • замыкания (с возможностью модификации)
      • хвостовая рекурсия
      • библиотека https://github.com/MarioAriasC/funKTionale которая использует возможности языка, позволяет делать:
        Function composition, Currying, Partial Application, Option, Either/Disjunction, Memoization


      1. potan
        14.09.2016 18:41

        Этим сейчас редкий язык не модет похвастаться. Ну кроме TCO, но она конфликтует с моделью безопасности jvm, так что я не уверен, что Kotlin ее везде поддерживает.
        В функциональной парадигме главное — поощрение иммутабельности и испрользованию возвращаемого значения из функций. Этого я в Kotlin не вижу.


        1. nerumb
          14.09.2016 18:43
          +1

          В функциональной парадигме главное — поощрение иммутабельности и испрользованию возвращаемого значения из функций. Этого я в Kotlin не вижу.

          Это как раз в Kotlin есть


        1. lani
          14.09.2016 18:46

          Ну а как же val (знаю что это readonly, но все таки) и primary-consturctors.
          Очень легко создавать неизменяемые класс


          data class User(val name:String, val birthday: Date)
          
          val me = User("lani", Date(17, 2, 3))


          1. potan
            14.09.2016 18:58
            +2

            Это, конечно, шаг в сторону ФП.
            То почему бы в классе не сделать val по умолчанию, а var требовать явно, как это сделано в Scala?
            Kotlin тут чуть лучше Java, но до ориентированных на ФП языков, все-таки не дотягивает.


            1. lani
              14.09.2016 19:55

              1) Потому что Котлин прагматичный мультипарадигменный язык, а не чисто функциональный.
              2) Все равно придется каждый раз выбирать между var и val (а не как в Java все без final изменяемое).


              1. nehaev
                15.09.2016 11:01
                +2

                Все равно придется каждый раз выбирать между var и val (а не как в Java все без final изменяемое).

                Но ведь Java тоже всерьез рассматривает переход на val/var, судя по недавнему голосованию. Может так получиться, что через n лет, когда котлин станет менее сырым, все его фичи не будут стоить того, чтобы соскакивать с джавы.


                1. lani
                  15.09.2016 14:48
                  -1

                  Java тоже всерьез рассматривает переход на val/var

                  Это хорошо, но в JEP-286 говорится только про локальные переменные, да и будет это минимум в 10.
                  Не говоря уже о том что var/val это такая мелочь в различие языков.


                  все его фичи не будут стоить того, чтобы соскакивать с джавы.

                  properties, extension-functions, nullability, readonly collection, first class functions, primary constructors, data class и тд — этого в Java придется ждать очень долго (ведь совместимость для нее важнее).
                  А уже через полгода после релиза, в Kotlin 1.1 добавили async/await и yeild (в тестовом режиме пока).


                  Также в JB заявили что они начали разработку компилятора Kotlin->LLVM и возможно в следующем году, можно будет "соскочить" но только уже с JVM.


                  1. nehaev
                    15.09.2016 16:06
                    +2

                    properties, extension-functions, nullability, readonly collection, first class functions, primary constructors, data class и тд — этого в Java придется ждать очень долго (ведь совместимость для нее важнее).

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

                    в JB заявили что они начали разработку компилятора Kotlin->LLVM и возможно в следующем году, можно будет «соскочить» но только уже с JVM


                    Вряд ли, потому что вся огромная Java-экосистема заточена под JVM, а еще один LLVM-язык без экосистемы едва ли кому-то нужен. А вот если джава таки осилит AOT-компиляцию, которую они уже давно обещают, многим уже существующим LLVM-поделушкам может прийти внезапный конец.


                    1. taujavarob
                      15.09.2016 16:58
                      +1

                      Похоже джава просто ждет, какие из фич новых языков лучше всего выстреливают

                      Можно и так сказать, а можно сказать — Похоже джава просто отстаёт от всех, пытаясь хоть как-то ещё плестись в конце.


          1. jukkagrao
            14.09.2016 19:11
            +1

            А как насчет других структур данных, в Скале их довольно много, а чем может похвастаться Kotlin? Есть ли там immutable списки, туплы и тп?


            1. lani
              14.09.2016 19:44

              Вот тут хорошо объясняется https://youtu.be/CX_K1r0Vklg


              Вкраце: все коллекции по умолчанию immutable (List, Map), от них уже наслаждаются MuttableList, MuttableSet и тд. (от них уже ArrayList). Плюс если некая магия, для превращения их рантайме в стандартные Java коллекции.


              Туплов больше 3 нет (тк они не нужны), вместо них есть data class


              1. jukkagrao
                14.09.2016 20:22
                +2

                Эти коллекции не immutable, а readonly, то есть никто не может гарантировать что они не изменятся, отсюда и все сопутствующие им недостатки.


                1. fogone
                  14.09.2016 21:48

                  никто не мешает использовать иммутабельные сторонние коллекции. А вот интероперабельность со стандартной библиотекой java — бесценно. К тому же ультрамаленький размер стандартной библиотеки — так же бесценно, когда речь об андроиде, например.


    1. nerumb
      14.09.2016 18:42

      Вот неплохая статья по поводу ФП в Kotlin


  1. vba
    15.09.2016 18:42
    -1

    ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке

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