Слегка разочаровался в Scala

Когда-то, довольно давно, я взялся за поиск альтернативы для C++, который во все времена был и, как мне думается на данный момент, будет моим основным рабочим инструментом. Само собой, эта альтернатива мне была нужна не для того, что бы перейти в какую-то иную сферу, а для тех случаев, когда либо хочется написать что-то свое, либо нужно быстро создать какой-то прототип, проверить ту или иную концепцию. В такой ситуации JVM-based язык очень удобен и, по большому счету, безальтернативен, конкуренцию может составить разве что Python со своим простым синтаксисом и безграничным набором библиотек.
В итоге, я довольно плотно сел за изучение Scala, прочел пару книг и некоторое время прибывал в полнейшем восторге. Но, как и все хорошее, восторг закончился с первым тестовым проектом который был написан на Scala как раз с целью “попробовать”. На данный момент у меня остались крайне противоречивые ощущения.

Хорошее:

  1. Язык очень мощный, обладающей замечательной стандартной библиотекой и не менее замечательной библиотекой AKKA;
  2. Код пишется быстро и просто. Аналогичное приложение на C++, при условии наличия необходимых библиотек, привело бы к написанию, в лучшем случае, двукратного количества кода;
  3. Благодаря тому, что под JVM существует огромное количество библиотек, разработка существенно упрощается, так как вероятность найти уже готовый фрагмент функционала велика;
  4. Большое сообщество разработчиков и относительная простота поиска решения возникшей проблемы.

Плохое:

  1. Язык провоцирует писать write-only код, это просто какой-то Perl XXI века;
  2. Язык провоцирует писать не эффективный код: различные алгоритмы “хотят” получить на вход коллекции разных типов, а преобразования между типами коллекций чрезвычайно простое для написания; многие функции разворачиваются в достаточно неожиданный код;
  3. Совершенно не понятные интуитивно операторы типа :+, ++=, :::. Да что там говорить об интуитивной не очевидности этих конструкций, достаточно попробовать их нагуглить!

В итоге, я пришел к довольно неожиданному выводу:

  1. Scala – очень хороший язык, с богатыми возможностями, позволяющий разрабатывать приложения довольно быстро.
  2. При этом, я бы не хотел работать в команде, которая пишет код на Scala, так написать на этом языке “шедевр” даже проще чем на C++.
  3. В качестве языка для прототипов класса “попробовал и сразу в морг” язык подходит просто великолепно, главное, что бы кому-то не пришло в голову из прототипа сделать приложение для конечного пользователя.

К сожалению, этот замечательный язык не подходит для моих целей, так как , во-первых, прототипы, очень часто начинают жить своей жизнью, а собственные проекты, иногда, приходится и поддерживать. Единственная потенциальная альтернатива C++ только одна – это Rust, а язык для прототипов и собственных “поделий” надо искать дальше, наверное, следующее что я попробую, будет Clojure…

14 Comments Слегка разочаровался в Scala

    1. Alexander Stavonin

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

      Reply
  1. Yury Schkatula

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

    Вот и выходит, что джуниоров лучше пускать пастись на DSL-полянке, а “под капот” пускать лишь сеньоров, причём обкладывая их тестами, статический анализатором и прочими изобретениями софтверной инквизиции, ибо иначе начинается такая ересь в коде…

    Reply
    1. Alexander Stavonin

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

      Reply
    2. eao197

      Страуструп на эту тему когда-то сказал, что есть всего два типа языков программирования: языки первого типа все ругают, на языках второго типа никто пишет

      Reply
  2. NN

    А что насчет Kotlin от jetBrains ? Он конечно не так силен как Scala но код вполне можно читать

    P.S.
    Ну конечно еще есть Nemerle который на мой взгляд и легко читать и легко писать и не провоцирует стиль “только для записи”, но он пока не для JVM увы

    Reply
    1. Alexander Stavonin

      Мне кажется, у Kotlin достаточно мутные перспективы, а связываться с языком, знание которого почти наверняка никогда не принесет никаких бенефитов не мой вариант. Ну а Nemerle, он как был скорее мертв, так и остается по сей день, .NET делает свое черное дело.

      Reply
      1. NN

        Ну осталось дождаться Nemerle в JVM и жизнь удалась.
        Или Kotlin с макросами , что тоже также вероятно

        Reply
  3. Arc

    — Я не люблю кошек.
    — Вы просто не умеете их готовить.

    Позвольте не согласиться с позицией автора.

    Плохое: Язык провоцирует писать write-only код, это просто какой-то Perl XXI века;

    Любым инструментом надо уметь пользоваться. По мере изучения, разработчик (1) научится писать доброкачественный код; (2) научится читать типовые конструкции языка, которые вначале были непривычны.

    Язык весьма глубокий по уровню концепций и если код непонятен, то скорее всего, концепции, лежащие в его основе, не знакомы разработчику. “Многие вещи нам непонятны не потому, что наши понятия слабы, а потому, что сии вещи не входят в круг наших понятий.” © К.Прутков.

    Плохое: Язык провоцирует писать не эффективный код: различные алгоритмы “хотят” получить на вход коллекции разных типов, а преобразования между типами коллекций чрезвычайно простое для написания; многие функции разворачиваются в достаточно неожиданный код;

    Неэффективный код можно написать на любом языке. Знание — сила! В Scala всегда есть возможность написать код, столь же эффективный, как на Java.

    Эффективность бывает разная. Есть эффективность разработки, а есть эффективность runtime-исполнения. Если учесть trend’ы: производительность компьютеров растёт экспоненциально, а производительность программистов — не поспевает. Scala даёт возможность повысить именно производительность программистов. Причём в 10-100 раз! А если какой-то код при определённых условиях будет работать медленнее, чем хотелось бы, то именно этот код можно отдельно прооптимизировать.

    Плохое: Совершенно не понятные интуитивно операторы типа :+, ++=, :::. Да что там говорить об интуитивной не очевидности этих конструкций, достаточно попробовать их нагуглить!

    Для поиска символов используйте symbolhound.

    А неочевидность, очевидно, связана с тем, что разработчик не осилил tutorial и introduction. Часто используемых символов в Scala не так уж много, для некоторых есть синонимы в виде обычных методов, для многих символов есть хорошее интуитивное обоснование. Символы в стандартной библиотеке используются последовательно и везде означают одно и тоже. Один раз прочитал, после — используешь везде легко и непринуждённо.

    Reply
    1. Alexander Stavonin

      Спасибо за развернутый ответ, не часто такое увидишь.

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

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

      Т.е. Scala – восхитительный язык, но использоваться его в разнородной команде, т.е. команде состоящей из людей с разными уровнями, опасно.

      Reply
      1. Arc

        Да, Scala в этом плане несколько похожа на C++. И там и там можно писать как читабельный код, так и непонятный.

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

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

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

        Если сравнить код на Scala и код на других языках, то можно обнаружить, что простые алгоритмы выглядят достаточно похоже, без явного преимущества Scala. Преимущества начитают блистать при построении сложных систем. Scala позволяет легко оперировать классами (один класс — одна строка), создавая конструкции, гораздо более содержательные, чем кусочки скриптового кода. Что означает содержательность? Значит конструкция, созданная несколькими строками кода, будет выполнять требуемые функции с учётом требуемых ограничений, причём эти требования и ограничения далеко не тривиальны. Это как современные смартфоны и старые проводные телефоны. Содержание смартфонов, очевидно, несколько больше…

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

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

        Reply

Leave a Reply to NN Cancel reply