Дискуссия вокруг 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)
stalkerg
13.09.2016 18:43Не Java разработчикам (или которые только иногда на нём пишут) всё это кажется странным...
JuniorIL
13.09.2016 19:09+9ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Работал в двух фирмах, которые используют Скалу и ещё в одной на ней пишет супруга. Пока это предположение не подтвердилось.
sshikov
13.09.2016 19:30+2Совершенно согласен. Я даже думаю, что "они" могут быть кем угодно, в том числе упертыми маньяками. И дело вовсе не в scala, это для любой технологии возможно.
helions8
13.09.2016 19:29+2ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Это утверждение и следующий за ней абзац откровенно повеселили. Я так познакомился с Erlang'ом, просто потому, что архитектору был выдан карт-бланш и очень хотелось попробовать Erlang, а тут такая возможность. Медленно переписываем теперь. Со Scala забавные ситуации, когда вместо того, чтобы взять Спринг или Джангу для того, чтобы по-быстрому написать несложный рест-сервис, разработчики воротят нос и два месяца втыкают в сликовские транзакции и пишут тот код, который для Джавы уже есть готовый. К сожалению, я отмечаю то, что людям важнее писать на Скале, чем выпустить продукт.
Хотя я согласен, что Скала может пробивать лед для тех языков, которые придут за ней и будут более удобны в работе, особенно для среднего уровня программиста.
solver
13.09.2016 21:08+6> Со Scala забавные ситуации, когда вместо того, чтобы взять Спринг или Джангу для того, чтобы по-быстрому написать несложный рест-сервис, разработчики воротят нос и два месяца втыкают в сликовские транзакции…
Такие высказывания веселят не меньше. Какая разница, втыкать 2 месяца в джангу или в слик?
Мне вот писать рест сервис на Akka сейчас будет быстрее чем на Спринге или тем более на джанге, например)
andy128k
13.09.2016 22:09+2Такие высказывания веселят не меньше. Какая разница, втыкать 2 месяца в джангу или в слик?
Лично знаком с приведённой ситуацией. И ваш довод никак не противоречит. Разработчики знали и спринг, и джангу, но очень желали сделать с помощью скалы и слика.
bormotov
14.09.2016 00:05+2И причем тут скала как таковая? Это же разработчики хотели?
А кто им разрешил? Тот, кому тоже не очень важно то продукт выпускать?
bigfatbrowncat
14.09.2016 20:44+2Может быть, разработчики, зная Джангу и Спринг, настолько их ненавидели, что хотели попробовать что-то другое?
andy128k
15.09.2016 00:12+1… ненавидели...
Очень профессионально :)bigfatbrowncat
15.09.2016 01:25+3То есть вы утверждаете, что разработчик обязан относиться с пиететом и уважением к любой освоенной им технологии?
Напротив, именно разобравшись в чем-то достаточно глубоко, вы обретаете моральное право на личное отношение.
Я, например, лично знаю человека, который очень глубоко знает C++.- вплоть до понимания различий между разными версиями gcc и различий в имплементации шаблонов в нем, clang и msvc++.
Так вот, этот товарищ мрачнеет, когда ему приходится заниматься разработкой/поддержкой кода на C++. Он предпочитает Java, Objective C… А «кресты» именно не любит. И причины своей неприязни легко может изложить, пересказав пару «очаровательных» историй, в которые влипал из-за неудобства их синтаксиса и компиляции.
А что — профессионалы обязаны любить любой инструмент?helions8
15.09.2016 16:11Профессионалы должны выбирать инструмент по задаче, а не пользоваться критериями из разряда вкусовщины. Нет ничего профессионального в том, чтобы потратить дополнительные деньги заказчика на новую технологию, которая не дает заказчику и его бизнесу никаких преимуществ. Это я вам конкретно по этому случаю говорю – никаких преимуществ Скала не принесла, но напротив – увеличила стоимость поддержки.
bigfatbrowncat
15.09.2016 21:34Дает преимущества, если на самом деле технология хреновая, а учат они хорошую.
«Вкусовщина» профессионала всегда имеет под собой основания. Когда вам опытный человек говорит «X — дрянь», он имеет в виду отнюдь не то, что при изучении X от него ушла подружка, а то, что в X присутствует плохой код, неудобный API, много ошибок или еще что-то, что делает X плохим.
Я выше уже написал, что фраза «я ненавижу C++» может означать, например, что для того, чтобы собрать программу из двух частей, собранных разными компиляторами и использующих шаблоны, нужно убить кучу сил и времени. Как вариант.
Я не понимаю, почему эмоциональная оценка не может быть результатом рациональных убеждений. Мы, вроде, люди, так?helions8
15.09.2016 21:43+1Дает преимущества, если на самом деле технология хреновая, а учат они хорошую.
Как определяется степень хорошести? Джанго — плохая технология, потому что в ней плохой код, неудобный АПИ и много ошибок? А Play хороший потому, что в нем хороший код, кдобный АПИ и нет ошибок? Я правильно понял ваш подход?
Нет хреновых технологий, есть те, которые лучше подходят для задачи и есть те, которые хуже.solver
15.09.2016 23:24Проблема только в одном сейчас.
Процентов наверно 70, если не больше, проектов сейчас пишутся с одинаковой степенью эффективности (для заказчика) на практически любом популярном языке. Под эффективностью я тут понимаю решение бизнесзадач заказчика.
Т.е. условный бизнеспроект можно без серьезных преимуществ со стороны этих технологий написать на: PHP, Go, Python, Java, Scala, Clojure, С# и что там я еще забыл.
Такие важные составляющие решения как: скорость разработки, надежность, достаточная производительность. Будут определяться на 99% людьми участвующими в проекте.
И вот тут проявляется интересный факт. Различность технологий позволяет разным людям, с разными (но работающими естественно) решениями работать вместе эффективно.
Разность этих технологий позволяет людям объединяться по интересам и работать вместе не перегрызая друг другу горло) И это хорошо.
Бизнесу надо сделать правильно ровно одну вещь. Это нанять хорошего техдира, который сможет не мешать группе людей, на удобной им технологии сделать хорошо бизнесу. Ему надо только сдерживать совсем уж безудержные порывы разработчиков. Ну чтобы они начали проект на коболе в 2016 году, или на брейнфаке ))helions8
16.09.2016 10:54Не знаю насчет процентов, может для веб-разработки в большинстве случаев и не важно на чем писать, но кроме скорости самой разработки, есть еще и стоимость поддержки и внесения изменений. Я смотрю на это изнутри продуктовой компании, для нас это важно. И вот в случае не нагруженного рест-сервиса, о котором я писал выше, стоимость владения кодовой базой на Скале гораздо выше, чем на питоне, хоты бы потому, что скалисты стоят дороже. Хотя, есть другие части системы, где эта же самая Скала подходит отлично и вообще best-fit.
bigfatbrowncat
16.09.2016 17:05Я, на всякий случай, уточню, что я не про конкретную технологию говорю, тем более, что конкретно Джанго не знаю вовсе.
Я говорю об оценке в целом.
Специалист взял в руку инструмент, поработал им день и на вопрос, «насколько хорош этот инструмент», выругался матом.
Это была эмоциональная оценка.
Вместо нее он мог бы выдать список, в котором было бы две запоротые детали, вывернутое запястие, отдавленная нога и стружка, попавшая в глаз из-за кривой защиты резца.
Но специалист просто вам ответил «эта вещь мне не нравится». А потом, как в анекдоте, грязно выругался.
Вам кажется, что он непрофессионален? Или профессионал не имеет права на точку зрения относительно инструмента?
Рискну предположить, что, возможно, лично вы хорошо знаете этот фреймворк, любите и недоумеваете, почему кто-то другой может его не любить. Спешу вас заверить, что даже если есть объективные критерии любить или не любить инструмент, у всех они разные (значимость разная). И вовсе необязательно все крутые спецы обязаны любить что-то одно, а кто не любит — «вон из профессии».helions8
16.09.2016 19:04-1«Специалист взял в руки микроскоп и попытался им целый день забивать гвозди, и на вопрос, «насколько хорош этот инструмент», выругался матом. Это была эмоциональная оценка.» Думаю, моя мысль понятна.
«Оценка в целом» это такое размытое понятие, что я бы не стал им оперировать. Если, например, задача относится к сфере высокочастотного трейдинга, то наверняка в первую очередь подумают о С++ и Java, как бы к ним не относились. Но это лучшие инструменты для решения задачи построения приложения подобного рода и выбирать надо их, несмотря на эмоциональную оценку, любовь и личную привязанность.
Если надо нарисовать простенькую интернет-витрину для магазина шапок, то более подходящими будут какие-то CMS на PHP или Рельсы или еще что-то подобное. И если для решения задачи подобного рода выбирается С++, то тут у меня возникают вопросы. И дело не в том, что на плюсах нельзя написать такое, дело в том, что это не подходящий инструмент, который удорожает разработку и поддержку. Именно об этом я и писал, но не в такой утрированной форме.
А технологий без недостатков нет и я не знаю ничего, к чему не было бы претензий. Если технология живет и занимает нишу, то это означает ровно то, что лучшего инструмента по заданному набору критериев просто нет (не рассматривая граничные случаи типа Кобола в фин.сфере, конечно же).
Ну и да, если вместо внятных аргументов я слышу «фу-фу-фу, я не буду на этом говне писать», то я отношу это как раз к непрофессионализму. Мое личное мнение.
Рискну предположить, что, возможно, лично вы хорошо знаете этот фреймворк, любите и недоумеваете, почему кто-то другой может его не любить.
Я не пользуюсь вашей системой ценностей, основанной на эмоциональной привязанности, это для меня не имеет никакого значения.bigfatbrowncat
16.09.2016 23:47+2Я вам привел простой пример, вы обобщили его до абсурда. Зачем?
Речь шла о ситуации, когда:
1. Инструмент был использован на основании того, что подходил к поставленной задаче (во всяком случае, предназначался для нее)
2. Инструмент был выбран сознательно
Оценка в целом — действительно размытое понятие, но я говорю о случае, когда вполне конкретный человек решает вполне конкретный класс задач.
Человек оценивает инструмент не «в целом». Он его оценивает в контексте поставленной задачи.
Суммирую:
Если специалист, занимающийся некоторой задачей с помощью некоторого инструмента, говорит, что инструмент — дрянь, он имеет в виду, что инструмент, по его мнению, не подходит для данной задачи.
Напомню, что изначально в дискуссии речь шла о конкретных примерах. Я сказал, что, возможно, специалисты выкинули из рассмотрения некий фреймворк, потому что он им не нравился. Из чего, скажите на милость, вы сделали вывод, что он им не нравился «как сферический в вакууме»? Он им не нравился конкретно — для их целей. Здесь и сейчас.
taujavarob
15.09.2016 14:40+1Может быть, разработчики, зная Джангу и Спринг, настолько их ненавидели, что хотели попробовать что-то другое?
Вряд ли. Просто скучно стало им поди.
helions8
13.09.2016 23:56Я не писал про 2 месяца на джанге, я писал «по-быстрому на джанге», а это неделя-две. То, что вам лично быстрее на Акке я не оспариваю. Мне больше интересно то, на чем будет быстрее широкому кругу разработчиков.
bormotov
14.09.2016 00:07Широкому кругу быстрее на bottle или flask (питон)
Но что это меняет в контексте данной статьи?
понятно, что использование знакомого инструмента даст результат быстрее и лучше. Вопрос то не в это.helions8
14.09.2016 00:20О, а в чем же тогда?
bormotov
14.09.2016 07:41в людях?
цитата из этой статьи
Сегодня мы поговорим о том, нужна ли Scala разработчику для саморазвития
Разработчики из вашего примера со сликом, так и не выпустили ничего работающее?
Может быть, напрасно они сразу за слик схватились?helions8
14.09.2016 13:34Выпустили, но несколько позже, чем можно было бы. Хотя это скалисты с опытом. Ну и если они, по вашему выражению, напрасно сразу за слик схватились, то как это сочетается с «если выбрали скалу, то это серьезно»?
bormotov
14.09.2016 14:39+1очень легко сочетается
Пример из нашей жизни, как раз вот один из разработчиков интересовался, сколько проекту лет — 6 лет. от первого коммита. Можно ли сказать, что проект, который компании прибыль — это несерьезно? Вполне серьезно. Никаких проблем из за того, что «скала» мы не испытывали. Да, лет пять назад, были некие сложности с поиском людей, но наша практика показала, что человек который умеет использовать Java, под руководством нашего тимлда, вливается в проект примерно за пару недель. За пару месяцев за ним вообще уже не нужно приглядывать.
Что-то мне подсказывает, что если взять другие инструменты и посмотреть на аналогичные метрики, разницы на порядок точно не будет, и скорее всего не будет отличий даже «в разы».
То есть суть отличий будет
— в сложности проекта как такового
— в людях
Сделал wc -l в src/main/scala — всего 65602 строк. Никакого слика или другого ОРМ у нас нет. В оракл и постгрес ходить умеем, но нужно не часто. Основное хранилище — монга.
andy128k
13.09.2016 22:18+3… пробивать лед… для среднего уровня...
Это самое грустное. Средний уровень должен расти, а не привыкать десять лет к «новинкам» (из 60-ых) типа анонимных функций.
Скала должна «пробивать лёд» НЕ ДЛЯ котлина, а К хаскелю, агде, идрису…
senia
15.09.2016 17:01+3Во что там втыкать? Джуны за месяц в состоянии освоить слик и akka-http. И scala, впервые ее увидев в начале месяца.
helions8
15.09.2016 17:11Без иронии – я очень завидую уровню ваших джунов. Во что втыкать я не сильно понимаю, но я вижу результат.
senia
15.09.2016 17:27Осваивали «by example». С активной помощью, конечно, но в итоге вполне адекватно использовали. Показать пример, отвечать на вопросы, проводить review. Хотя может это джуны такие хорошие были — выборка пока маленькая.
fogone
13.09.2016 19:51+7ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Вот на этом невысказанном предположении и держится весь хрупкий механизм нашего молодого народовластия.
unabl4
13.09.2016 20:11+12Используем Скалу в одном из наших под-проектов.
Скажу так, что сколько бы я не пытался начать изучать Java — синтаксис и портянки кода просто убивают всякое желание в этом всём разбираться. За Java 8 ничего не скажу — не пробовал. ИМХО.
Скала в этом плане действительно лаконичнее и проще читается. Но это с одной стороны. С другой стороны, если начать выкручивать Скалу на полную катушку, т.е начать использовать все функциональные возможности: view bounds, higher kinded types, монады, вариативность и ещё бог знает что, то в проекте вы, скорее всего, быстро останетесь одни, потому что этот лес нагромождений мало кто захочет разгребать, чтобы разобраться и понять саму бизнес-логику, которую вы в этом всём закопали. Вот пока не пишешь сложного (овер-функционального) кода на Скале — всё хорошо. Как только осознал, что написал сложно (через месяц сам не сразу понимаешь, как оно работает) — очень хочется какой-нибудь более простой и однозначный язык.
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.bigfatbrowncat
14.09.2016 21:07+3(немного старческого брюзжания)
Молодые люди желают свободы. Везде и всегда. Я в 20 тоже полагал, что чем больше свободы предлагает мне компилятор, тем круче язык.
А потом, в процессе переламывания очередного копья о завитушки собственного очередного «красивого программного решения» начал осознавать, что главное в нашем деле — не супервозможности, а удобство разработки/отладки/поддержки.
Я, например, до сих пор недоумеваю, за что людям так нравится Питон, в котором принято, чуть что, хвататься за рефлексию, а инкапсуляция отсутствует как таковая.taujavarob
15.09.2016 14:44Я, например, до сих пор недоумеваю, за что людям так нравится Питон
Скобок нет. Отступы поди им нравятся.bigfatbrowncat
15.09.2016 21:37+1Это отсутствие скобок меня обескуражило первым же делом. Особенно когда я начал задавать себе неудобные вопросы типа:
1. А что будет, если нечаянно ткнуть лишний пробел?
2. А что будет, если в куске кода использовать табуляции, а в другом — скобки?
3. А что будет, если в одной строке сперва отбивать табами, а потом — пробелами? (я так люблю делать, например)
Все эти вопросы не имеют значительного смысла в языках, где операторные скобки видны даже людям с сильным астигматизмом.stokker
16.09.2016 02:22-3Скобки — это:
— дополнительное пустое место на экране (обычно целая строка);
— лишняя информация (так как отступы обычно есть).
Borz
16.09.2016 08:17+2скобки это не только визуальная отбивка. Например в Java фигурные скобки обеспечивают ещё дополнительную локальную область видимости переменных внутри метода
bigfatbrowncat
16.09.2016 17:11+3Во-первых, «пустое» место бывает не всегда, а только если скобки выносить на отдельную строку. Я, например, приучен Джавой писать так:
void someFunction(int arg) { if (something) { foo(); } else { anotherFoo(); } }
Давайте найдем в моем коде лишние пустые строки.
А во-вторых, я сам иногда НАМЕРЕННО (представьте себе) отделяю блоки кода пустыми строками друг от друга, чтобы улучшить их читабельность. Мне мало имеющихся фигурных скобочек, я хочу больше пустоты.
Что касается лишней информации, я уже написал (полушутя) про астигматизм. Теперь уточню серьезно.
Умение четко видеть вертикальную границу текста — навык, требующий не только тренировки, но и хорошего глазомера.
При этом скобки помогают четко видеть, где блок кода заканчивается.
Я, кстати, часто в IDE ставлю курсор на открывающуюся скобочку, чтобы увидеть закрывающуюся. Куда прикажете в питоне курсор ставить?
Optik
13.09.2016 20:34+2Субъективно, всех скалистов уже задолбал этот холивар, так что дискуссия/срач вряд ли получится.
По поводу популярности и вакансий — растет, за год существенно прибавилось, хотя заманухи также хватает.
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 медленно загибается" :)
23derevo
14.09.2016 00:05+4Scala медленно растет. Медленнее, чем лично мне хотелось бы, например. Потому что Java тоже растет, и растет быстрее. И доля Scala, соответственно, не особо увеличивается.
p1l1gr1m
14.09.2016 15:44Абсолютно согласен.
Возможно Scala вообще никогда не станет мейнстримом как Java или JS.
Короче говоря, говорить о какой стагнации преждевременно, мне кажется следующие пару лет будут решающими — или рост или Scala просто основательно займет свои некоторые ниши (и это тоже неплохо).stokker
15.09.2016 09:45> Возможно Scala в
ообщеникогда не станет мейнстримом как Java или JS.
Точно, что никогда не станет, так как мейнстриму необходим легкий поиск сотрудников даже в небольшом городке. А это означает низкий порог вхождения и т.д.
Вопрос только в том, займет ли Scala какую-то нишу или лет через 5, когда ФП будет внедрено повсеместно, просто засохнет.
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 как язык за последний год?
4lex1v
14.09.2016 07:40+3А что Scala, на Ваш взгляд, должна приобрести? В языке много чего есть, чего нет добавят / поправят в Dotty, которую собираются зарелизить в какой-то форме (доклад Одерски на ScalaWorld) в обозримом будущем, лишнее уберут. Коммьюнити развивается, работы тоже предостаточно, как для убежденных джавистов, так и для тех кто предпочитает функциональный подход. В чем проблема?
solver
14.09.2016 10:34+1> что нового приобрела Scala как язык за последний год?
Быстро можно расти только с нуля. Язык, у которого серьезные новшества появляются каждый год, это очень молодой язык.
Scala к таковым не относится.
leventov
14.09.2016 00:38+2Взгляд неофита в Скале:
Мне важно понимать, во что и как компилируется код, когда я его читаю, какие там есть аллокации. В Java это довольно просто, в этом смысле Java на самом деле недалеко ушла от Си (для кого-то это может звучать дико, но в моем видении это так.) То есть Java это такой Си с хорошей IDE, билд тулами, библиотеками и т. д.
Скала — с ее implicits, mixins, хитрыми коллекциями и магическими фреймворками — уже все совсем непонятно. То есть приближается к динамическим языкам, где проще забить на всякую производительность, расслабиться и радоваться сахарку.
Котлин, как мне кажется, еще сохраняет необходимую прозрачность, при том что фактически весь необходимый скаловский сахар там есть. Очень кстати что JetBrains взялись активно проговаривать эту тему, как компилируется Котлин: https://youtu.be/yYG12qaxWO4?list=PLVe-2wcL84b-Waky1nkWVSNHPg6eOQWU9
К сожалению, пока Котлин очень сырой, но буду ковырять на нем pet проекты и следить.
lani
14.09.2016 16:44-2Не все ли равно как Котлин компилируется, если он это делает быстрее скалы?
А так используешь его в продакшене на Андроиде и чувствуш себя белым человеком (+ ценность как девелопера повышается)
alexeyrom
14.09.2016 22:37+1Скала — с ее implicits, mixins, хитрыми коллекциями и магическими фреймворками — уже все совсем непонятно.
Если интересно, во что скомпилировался конкретный код, всегда можно использовать -Xprint: желаемая-фаза-компилятора. А по сравнению со Spring, JPA и т.д. магии в скаловских фреймворках много меньше (ПМСМ).
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. Ну просто мир движется вперёд, технологии развиваются, появляются новые идеи и концепции. Пора это уже наконец понять, закопать стюардессу и идти дальше!
fogone
14.09.2016 10:56+3Достаточно небольшой, но компетентной команды профессионалов. Спецназ одним словом.
Это высказывание намекает нам, что небольшая команда профессиональных скала-разработчиков чем-то отличается от такой же команды разработчиков java. И как «спецназ» может сделать какую-то задачу особенно хорошо или быстро (не знаю, что здесь имеется ввиду). Но это умозаключение не только ничем не подтверждено, но и вполне вероятно может оказаться просто ложным.
Уровень докладов, в среднем, на порядок глубже и сильнее чем то, что я, опять же, в среднем, видел на любых конференциях по java.
Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?
имея в распоряжении миллиарды долларов и огромный штат инженеров, не смогла добавить в язык многострадальные value types и ahead of time compiler. Как такое вообще возможно???
Зато от версии к версии они почти абсолютную совместимость сохраняют, что видимо для бизнеса приоритетнее, чем новые фичи языка, которые (к слову) медленно но в языке появляются.
Нет ничего плохого в том, что java рано или поздно уйдёт со сцены
Вероятно уйдет, да, но скала этого скорее всего не увидит. Думаю, на опыте скалы будут появляться новые языки, которые будут более подходить более широкой аудитории и решать те же задачи.eXTreMeHawk
14.09.2016 12:33> Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?
Квалификация требуется на уровне первого курса любого технического универа + умение читать. Но сейчас вроде везде так…
Да, действительно, есть некоторые баги компилятора scala, при попытке «обойти» которые рождается не самый простой код. Это правда. Но такой код, как правило, сосредоточен в библиотеках + в той же грядущей Scala 2.12 уже многое пофикшено. В целом, я бы назвал это болезнями роста.
> Зато от версии к версии они почти абсолютную совместимость сохраняют, что видимо для бизнеса приоритетнее, чем новые фичи языка, которые (к слову) медленно но в языке появляются.
Абсолютная совместимость бывает только на кладбище. Давайте посмотрим на параллельный мир JavaScript / Frontend Side. Да там в месяц 20 новых фреймворков появляется :-), а совместимость ломается каждые пару лет (см ng1 vs ng2) и почему-то бизнес это не сильно парит…wing_pin
14.09.2016 16:44+1> Квалификация требуется на уровне первого курса любого технического универа + умение читать
Скажите название того вуза, где на первом курсе проходят функциональное программирование со всеми этими вашими функторами и монадами, модель акторов и разные радости ООП в полном объеме.
>… почему-то бизнес это не сильно парит
Вы видели хоть одну банковскую систему полностью на JavaScript?taujavarob
14.09.2016 17:14Нет. Но бухгалтерских на 1C полно. ;-)
Вообще-то можно, наверное, написать и банковский опер-день на JavaScript. Писали же раньше на Clipper.
Но нужно ли, если есть Java? — По крайней мере на сервере.
Scf
14.09.2016 18:08Вот что касается функторов и монад — сначала ими активно пользуются, а уже потом какой-нибудь гуру объясняет, что это функторы и монады.
taujavarob
14.09.2016 18:12а уже потом какой-нибудь гуру объясняет, что это функторы и монады.
«Он с удивлением узнал, что говорил прозой» (С)
fogone
14.09.2016 22:10+1Квалификация требуется на уровне первого курса любого технического универа + умение читать.
Я согласился бы с вами, если бы вы написали, что для того, чтобы писать на скала как на джаве (т.е. без особых изощрений) достаточно средней квалификации. Но, боюсь, уровня первого курса а тем более любого технического универа сейчас недостаточно, чтобы писать почти ни на каком языке.
да, действительно, есть некоторые баги компилятора scala
про баги и болезнь роста — это ответ на какой вопрос?
Давайте посмотрим на параллельный мир JavaScript
вы уж меня простите, но причем тут JavaScript? От безысходности чтоли? Кстати, в JavaScript-е обратную совместимость блюдут достаточно строго — в современной реализации до сих пор можно найти интересные «особенности» ранних версий.
20 новых фреймворков появляется
хорошо, про языки поговорили, давайте теперь за фреймворки возьмемся — ок.
почему-то бизнес это не сильно парит
во-первых, откуда такая уверенность, что бизнес это не парит? во-вторых, напомню, мы говорим не о javascript-овых фреймворках, а потере скалой совместимости между версиями, вы считаете это ок?taujavarob
15.09.2016 14:46во-вторых, напомню, мы говорим не о javascript-овых фреймворках, а потере скалой совместимости между версиями, вы считаете это ок?
Как? — только не это!
alexeyrom
14.09.2016 22:46-1Но это умозаключение не только ничем не подтверждено, но и вполне вероятно может оказаться просто ложным.
Только в следующем абзаце вы его как раз и подтверждаете:
Возможно, это связано с тем, что язык сложноват и требует квалификацию выше средней?
Да, именно более высокой квалификацией небольшая команда разработчиков на Scala будет отличаться от аналогичной команды разработчиков на Java (в среднем, конечно).
Вероятно уйдет, да, но скала этого скорее всего не увидит.
Вероятно, нет (по крайней мере в обозримом будущем).fogone
15.09.2016 11:18+1Только в следующем абзаце вы его как раз и подтверждаете
То, что язык требует более высокой квалификации для входа совершенно не означает, что он позволяет сделать какую-то задачу особенно хорошо или быстро (я так и не понял, что именно тут имелось ввиду).
Да, именно более высокой квалификацией небольшая команда разработчиков на Scala будет отличаться от аналогичной команды разработчиков на Java
Тут получается вот что: требования к квалификации выше, но очевидного профита от этого не видно — ведь единственная очевидно повешенная квалификация скалиста — это опыт борьбы с самим языком — о других навыках этих людей мы наверняка не знаем — что вероятно в какой-то степени влияет на результаты его деятельности, но умение решать задачи от этого навыка серьезно не зависят. По крайней мере никакими доказательствами обратного я не владею.
Scf
14.09.2016 13:10+6Все недоразумения из-за того, что Scala — фактически три разных языка
- Сильно улучшенная джава (за это все так любят скалу)
- Функциональный язык (применять аккуратно)
- Академический/экспериментальный язык (хороший способ писать совершенно нечитабельный код)
taujavarob
14.09.2016 18:14+4Сильно улучшенная джава (за это все так любят скалу)
Это замануха для привлечения Java программистов. :-)
Функциональный язык (применять аккуратно)
Это мода на функциональщину. :-)
Академический/экспериментальный язык (хороший способ писать совершенно нечитабельный код)
А вот это суть Scala и есть. ;-)jukkagrao
14.09.2016 19:19+1Scala в первую очередь это промышленный язык, сложно его назвать академическим. Крупнейшие европейские компании используют его в продакшене.
taujavarob
14.09.2016 19:55Крупнейшие европейские компании используют его в продакшене.
хороший способ писать совершенно нечитабельный код
Шифруются?
Scf
15.09.2016 11:19+2Кому что. Никто же не заставляет прикручивать scalaz и активно использовать имплиситы в промышленном проекте, не так ли? Scala в этом отношении немного похожа на C++ — нужно знать, какими фичами языка можно пользоваться, а какими — не стоит.
potan
14.09.2016 15:30+1А что такого в Kotlin функционального? Pattern matching есть? С типом Option как с монадой он работает? Может еще и функция значение последнего выражения возвращает бeз необходимости писать return?
lani
14.09.2016 18:33- функции вне классов
- лямбды
- функции высших порядков
- замыкания (с возможностью модификации)
- хвостовая рекурсия
- библиотека https://github.com/MarioAriasC/funKTionale которая использует возможности языка, позволяет делать:
Function composition, Currying, Partial Application, Option, Either/Disjunction, Memoization
potan
14.09.2016 18:41Этим сейчас редкий язык не модет похвастаться. Ну кроме TCO, но она конфликтует с моделью безопасности jvm, так что я не уверен, что Kotlin ее везде поддерживает.
В функциональной парадигме главное — поощрение иммутабельности и испрользованию возвращаемого значения из функций. Этого я в Kotlin не вижу.
nerumb
14.09.2016 18:43+1В функциональной парадигме главное — поощрение иммутабельности и испрользованию возвращаемого значения из функций. Этого я в Kotlin не вижу.
Это как раз в Kotlin есть
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))potan
14.09.2016 18:58+2Это, конечно, шаг в сторону ФП.
То почему бы в классе не сделать val по умолчанию, а var требовать явно, как это сделано в Scala?
Kotlin тут чуть лучше Java, но до ориентированных на ФП языков, все-таки не дотягивает.lani
14.09.2016 19:551) Потому что Котлин прагматичный мультипарадигменный язык, а не чисто функциональный.
2) Все равно придется каждый раз выбирать между var и val (а не как в Java все без final изменяемое).nehaev
15.09.2016 11:01+2Все равно придется каждый раз выбирать между var и val (а не как в Java все без final изменяемое).
Но ведь Java тоже всерьез рассматривает переход на val/var, судя по недавнему голосованию. Может так получиться, что через n лет, когда котлин станет менее сырым, все его фичи не будут стоить того, чтобы соскакивать с джавы.lani
15.09.2016 14:48-1Java тоже всерьез рассматривает переход на 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.
nehaev
15.09.2016 16:06+2properties, extension-functions, nullability, readonly collection, first class functions, primary constructors, data class и тд — этого в Java придется ждать очень долго (ведь совместимость для нее важнее).
Если бы вопрос был только в количестве фич, то скала уже давно была бы мейнстримовым мейнстримом. Похоже джава просто ждет, какие из фич новых языков лучше всего выстреливают, перенимает их себе и делает (условно) 95% JVM-программистов вполне удовлетворенными, снимая при этом с их менеджмента огромные риски от перехода на новый язык.
в JB заявили что они начали разработку компилятора Kotlin->LLVM и возможно в следующем году, можно будет «соскочить» но только уже с JVM
Вряд ли, потому что вся огромная Java-экосистема заточена под JVM, а еще один LLVM-язык без экосистемы едва ли кому-то нужен. А вот если джава таки осилит AOT-компиляцию, которую они уже давно обещают, многим уже существующим LLVM-поделушкам может прийти внезапный конец.taujavarob
15.09.2016 16:58+1Похоже джава просто ждет, какие из фич новых языков лучше всего выстреливают
Можно и так сказать, а можно сказать — Похоже джава просто отстаёт от всех, пытаясь хоть как-то ещё плестись в конце.
jukkagrao
14.09.2016 19:11+1А как насчет других структур данных, в Скале их довольно много, а чем может похвастаться Kotlin? Есть ли там immutable списки, туплы и тп?
lani
14.09.2016 19:44Вот тут хорошо объясняется https://youtu.be/CX_K1r0Vklg
Вкраце: все коллекции по умолчанию immutable (List, Map), от них уже наслаждаются MuttableList, MuttableSet и тд. (от них уже ArrayList). Плюс если некая магия, для превращения их рантайме в стандартные Java коллекции.
Туплов больше 3 нет (тк они не нужны), вместо них есть data class
jukkagrao
14.09.2016 20:22+2Эти коллекции не immutable, а readonly, то есть никто не может гарантировать что они не изменятся, отсюда и все сопутствующие им недостатки.
fogone
14.09.2016 21:48никто не мешает использовать иммутабельные сторонние коллекции. А вот интероперабельность со стандартной библиотекой java — бесценно. К тому же ультрамаленький размер стандартной библиотеки — так же бесценно, когда речь об андроиде, например.
vba
15.09.2016 18:42-1ЗА: Если компания использует Scala, можно быть уверенным в их серьезном подходе к разработке
Поверьте мне это далеко не так, встречаются компании, это конечно редкость, которые использують скалу, только потому что они модные стратапы. А на самом деле там такой ужас понаписан, который на джаве редко встретишь.
23derevo
Я помню прекрасный разговор в Киеве, который состоялся у меня с местными ****-овцами три года назад. Дискуссия шла вокруг языков для JVM, и барышня сказала, что вот, мол, у них открыты первые вакансии на Scala. Я спросил у нее подробностей и выяснил, что
После этого скеписиса к скале у меня прибавилось. И, к слову сказать, за эти три года вроде как Scala не стала сильно популярнее.
Ну а про то, что Scala-программиста днем с огнем не найти, в отличие от приличных джавистов, я и говорить не буду. Вон, как Тинькофф мучаются.
jukkagrao
Мне кажется правильной реакцией было бы если бы у вас скепсиса к той самой барышне прибавилось. Scala тут не виновата.
senia
Мучается он… Был я когда-то у них (люксофт питерский, но отдел полностью под Тинькофф) на собеседовании: запомнилось ощущение абсолютной неадекватности интервьюверов. Вместо собеседования по scala — tricky questions по темам, в которых сами плавают. Они так долго искать будут людей если не организуют процесс собеседования кандидатов.