5 сентября 2011 в 08:23

Да, Вирджиния, Scala сложна! перевод

Для начала, позвольте уточнить, что я являюсь большим любителем и сторонником Scala вот уже 5 лет. Мною были написаны книги и статьи о Scala. Также я работал со множеством компаний, начавших использование Scala и Lift и проводил code review огромного количества Scala — проектов. Раньше я думал, что Scala — это просто. Она была и продолжает быть лекарством от многих проблем Java. С точки зрения “сложные или вообще невыполнимые вещи в Java довольно просты в Scala”, Scala — довольно простой язык. Работа с коллекциями очень проста. Изоляция бизнес-логики делает программы гораздо более поддерживаемыми и невероятно простыми, чем если бы они писались на Java.
Так почему же Scala сложна? Вот лучшее, что я смог придумать:

  • Scala пытается взять на себя слишком много. Это означает — Вы можете продолжать писать код в стиле Java, что одновременно является проклятьем и благословением. Но в долгосрочной перспективе, я думаю, это все же проклятье. Сейчас слишком много дебатов о противопоставлении OO и FP. Такого рода дискуссии являются допустимыми, если вы — небольшая команда, но они чертовски плохи, когда вы пытаетесь учить писать на Scala Java — разработчиков, которые на самом деле не хотят учиться или меняться. Потрясающие преимущества Scala, в действительности, начинают проявляться, когда вы пишете в стиле FP, но почти невозможно привлечь OO разработчиков, пока они сами не захотят писать в непривычном им стиле. В этом случае меньшие языковые возможности, как в Java или Ruby, более просты для адаптации, сужая круг потенциальных решений.
  • плохая поддержка со стороны IDE (и всегда такой будет). Eclipse плагин для Scala (или как еще он там называется на этой неделе) — отстойный. Он продолжает быть таким вот уже в течение 5ти лет моей работы со Scala. Постоянно я слышу “вот вот будет лучше”, и все же отстойный! Поддержка Scala со стороны IntelliJ приемлема для меня. Но тем, кому нужны шаблоны в их IDE, не найдут поддержку Scala достаточно хорошей. Во-первых, шаблоны/паттерны в Scala настолько разнообразные и разобщенные (OO через микшины — путь ScalaZ), что их, действительно, невероятно много. Если вы успешно пишете код в Emacs, Vi или TextMate — все в порядке, и переход к IntelliJ будет казаться неплохим. Но в случае ожидания “доброжелательности”, подобной получаемой от Java IDEs — мечты будут разбиты и никогда не воплотятся из-за всеобъемлющей мощи Scala, которая будет сложна в реализации, требуя огромного количества вложений. И даже Typesafe с их 3мя миллионами на счете не смогут этого гарантировать.
  • Система типов в Scala является чрезвычайно мощной, но, с Вашей точки зрения, возможно, даже чересчур. В ScalaDocs некоторые сигнатуры могут выглядеть очень устрашающе. Гляньте на
    flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

    и теперь попробуйте мне сказать, что это не взорвало Ваш мозг. Этот метод новички используют каждый день, а, возможно раз 20 за день. Документация Scala нуждается в библиотеке, которая бы скрывала всю эту сложность. Сложность, делающую метод flatMap невероятно мощным. Для системы типов и сопутствующей документации необходим более простой и понятный пользователю режим отображения.
  • Начинающим разработчикам, которым необходимо поддерживать программы более опытных, следует понимать идиомы и паттерны в коде. Несмотря на то, что в Scala бизнес-логика выносится на передние позиции (а не разносится через кучу циклов for и сложные if — выражения), в зависимости от используемых идиом, код все равно не является очевидным и легкочитаемым. И в конце дня хорошо бы было вам объединиться командой, чтобы обсудить написанный Scala код вместе со всеми используемыми методиками. Это также верно для Ruby on Rails, где hashmaps виртуально могут заменить все парадигмы программирования. Но в мире Rails, парадигма единообразна (хотя и не основывается на проверке типов) и проста для восприятия. В Java же паттерны уже заложены в IDE, поэтому разработчики во время своего “взросления” учатся и становятся способными их определять. Но, к сожалению, такой подход не имеет места быть в Scala, со своими слишком разнообразными идиомами, зависящими от команды или используемого фреймворка.

Есть несколько типов команд, для которых Scala, определенно, является более лучшим вариантом, чем Java, Ruby или какой-нибудь другой язык. Twitter — отличное тому доказательство. Им необходим четкий, типобезопасный, высокопроизводительные язык и среда. И Scala предоставила им все это. Foursquare использует сложность Scala для своего механизма фильтрации. Вы должны быть достаточно хороши, чтобы суметь освоить Scala и иметь успех в Foursquare.
Но если у вас команда с навыками, близкими к средним, выбор Scala может и не быть оптимальным (это зависит от управления… требуется ли использование challenging-черт Scala для фильтрации и улучшения команды?) Будучи средненькой компанией, с точки зрения обучения, Scala будет стоить вам отказа от уже существующих разработчиков, отсутствия паттернов. Вам понадобится сильный технический директор или архитектор для выработки паттернов, а не выделения их из книг или IDE. И количество таких средних компаний с довольно сильными техническими директорами или архитекторами, мягко скажем, невелико.
Итак, как же выяснить будет ли Scala простой для адаптации в вашей организации:
  • В вашей компании есть докладчики на JavaOne, OSCON, Strange Loop, QCon — Scala будет проста
  • Заобеденные дискуссии содержат в себе критерии для перехода от обычного разработчика к старшему — Scala будет сложна
  • Если придется, ваши разработчики смогут писать код в NotePad — проста
  • Ваши разработчики безучастны или говорят 3 “Hail Marys” когда слышат имя “Zed Shaw”: Scala == Hard
  • Разработчики поголовно следят на Dean Wampler’ом в Твиттере: Scala — проста
  • Ваши разработчики приходят на работу в 9.15 и уходят до 6ти, не проверяя свой email — Сложна

Конечно, у вас могут быть свои мысли на это счет. Но я, определенно, согласен с утверждением, что Scala для средней команды сложна. И не только сложна, но еще может и не принести ни в ближайшем, ни в дальнейшем будущем каких-либо преимуществ. Тех, что могла бы принести командам, состоящих из участников с 95% мастерства.
И еще несколько мыслей:
  • Да, система типов в Scala очень мощная и может привести к отличной красоте кода, как в Scala collections.
    Посмотрите stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-histo и www.scala-lang.org/docu/files/collections-api/collections-impl.html
    Но существует разница между потребностями дизайнеров языков/библиотек и разработчиков средних компаний. И отсутствие подобного разделения в Scala влечет трудности для последних. Лично я не думаю, что смог бы выразить идеи в Lift настолько четко и мощно на каком-либо другом языке. Поэтому, будучи дизайнером библиотеки, я люблю Scala. Но как я, так и многие люди, не считающие Scala сложной — не середнячки. И 11-летний пацан, пишущий на Scala также находится не на середине.
  • Да, улучшение ScalaDocs, обеспечивающее “простой” и “архитектурный” просмотр может явиться большой победой. Но это все равно всего лишь точка старта, но никак не конечная.
  • Я однозначно отвергаю аргумент “отлично, тогда мы найдем более профессиональных разработчиков”. Нам стоит решать проблему “Scala is hard”, работая над улучшением компетентности разработчиков вцелом (одни, кто сможет читать сигнатуры типов, другие — выражать свои программы используя математические подходы и т.д.), но мы отдаляемся от сути. А суть в том, что Scala не так хорошо подходит для начала революции в обучении, образовании или найме, как подходит для повышения профессионализма среднего разработчика, с целью перестать быть для него сложной.
  • Я сомневаюсь, что тот, кто читает это или мой Твиттер является среднестатистическим разработчиком и Paul Snively, Вы далеко не средний, и даже не пытайтесь!
Перевод: David Pollak
Viktor Taranenko @sndl
карма
26,0
рейтинг 0,0
Похожие публикации
Самое читаемое Разработка

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

  • +6
    Читал на днях в оригинале, понравился список «будет ли Scala простой для адаптации в вашей организации». И да, теперь я слежу в Твиттере за Dean Wampler’ом =)
  • –2
    Сплошное нытье, смешанное с обидой непонятно на что. В скале куча инструментов, которые не обязательно использовать одновременно. Очень странно слышать такое от человека с пятилетним стажем, который сам может приложить руку к улучшению языка/документации/IDE, и не один, а с командой.
    • +3
      Он как бы и не ноет. Наоборот говорит, что скала хороша. Но вот большинство команд имеют средний уровень и потому выбор скалы для них может привести не более чем к необоснованным разочарованиям.

      Он не говорит о сложности языка, а говорит о сложности восприятия для определенных личностей. И зачастую это непонимание связано больше с нежеланием, чем со способностями.
    • +2
      Неверно. Критика вполне конструктивна, и основывается на том, что читать код Scala нормально может только программист-эксперт.
      • 0
        Да не критикует он читабельность кода. В силу специфики и мощи языка, сложность эта неизбежна. Тем более, что бОльшая сложность возникает в большей степени при реализации библиотечных функций, о чем и говорит на примере метода flatMap. Он всем доволен — и Scala, и собой.
        Критику же я разглядел только в упоминании про IDE, но там же он и поясняет, что очень сложно создать средство разработки для подобного языка.
  • +2
    «Им необходим четкий, типобезопасный, высокопроизводительные язык и среда.» — чОткий язык это как раз то, что нужно твиттеру :)
    • +3
      Ладно, немного эмоционально получилось, добавлю конструктива:
      1. Не надо переводить идиомы дословно. Лучше выкинуть кусок, чем оставлять заведомо непонятный никому оборот.
      2. Не надо переводить слова по словарю не поискав их в гугле и не проверив что такая семантика и контекст имеют место хотя бы в нескольких других документах.
      3. Ну давайте тексты на вычитку другим людям. Ну если уже совсем никак и друзей владеющих техническим языком нет, то хотя бы паре авторов из этого блога можно написать с просьбой сделать ревью — хоть один да согласиться.
  • –3
    После прочтения статьи стало интересно, что же это за книги написанные автором и насколько они востребованы…
    Удалось найти только одну и с достаточно негативными отзывами на Amazon.com; почему-то не удивило.
    • +2
      Это автор Лифта, кстати. В сообществе Скалы это на сегодняшний день один из самых известных проектов.
      • +1
        В таком случае извиняюсь за пренебрежительный тон.
        Тем не менее, всё же кажется несколько странным использование множественного числа в отношении написанных книг.
    • +1
      Полак человек неоднозначный. С одной стороны он кажется один из наиболее продуктивных разработчиков в мире. С другой стороны его взгляды и, хм… стиль программирования скажем так спорны.

      Не стоит все отзывы на его работы принимать за абсолютную истину. Но и его идеи стоит примерять на себя с осторожностью.
  • 0
    >Изоляция бизнес-логики делает программы гораздо более поддерживаемыми и невероятно простыми, чем если бы они писались на Java.

    А кто-нибудь может мне рассказать что это за изоляция такая?
    • 0
      Полагаю, что речь идёт о «high cohesion».
      • 0
        А по-подробней можно? Как это достигается в Scala и почему не достигается в Java?
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            На самом деле вы немного преувеличиваете с «сотни дёргающих друг друга в разном порядке объектов, меняющих при этом внутреннее состояние», в java-мире практикуется разделение логики и состояния (Anemic Domain Model), подразумевающее создание statless-сервисов. Другое дело, как мне уже ответили ниже, достигается такое разделение более естественно.
            • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              ага, ага, расскажите это авторам wicket, hibernate и им сочувствующим
              • НЛО прилетело и опубликовало эту надпись здесь
                • +1
                  image
              • 0
                Иногда хибер прячут в DAO-шки, которые отдают immutable DTO-шки и логику уже пишут на них. В общем вопрос реализации.

                Что касается Wicket, JSF и прочего, то да, такой подход есть. И опять де есть stateless-подоход. Я не говорю, что ООП не используют. Но довольно распространены не то процедурные, не то функциональные практики.
        • +1
          Достижимо что угодно и где угодно, вопрос в сложности и стабильности этих достижений.

          Ну вот пара первых приходящих в голову особенностей Scala в сравнении в Java:
          1. Удобство создания неизменяемых структур данных и их обилие в стандартных библиотеках.
          2. Удобство создания чистых функций.
          3. Удобство создания маленьких и простых классов и функций.
          4. Возможность ухода от использования null и исключений (Option и Either).
          5. Более простое делегирование операций благодаря наличию замыканий.
          6. Поддержка множественного наследования не только интерфейса но и поведения (trait).
          7. Возможность более точной спецификации сигнатур функций благодаря развитой системе типов.
  • 0
    Полагаю, что речь идёт о «high cohesion».
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      В котором «средний программист» не будет _более_ продуктивным. Т.е. плюсов переходить нет.
      • +1
        Если говорить прямо, то в статье сказано, что плюсов переходить не будет у ленивых, слабеньких и ничего не хотящих добиться в этой жизни программистов…

        Работа с функциональными языками реально переворачивает мозги. Я после Scala даже на Java стал по другому писать…
    • 0
      Аргументы за «Scala сложна» таковы:
      — Заобеденные дискуссии содержат в себе критерии для перехода от обычного разработчика к старшему
      — Ваши разработчики приходят на работу в 9.15 и уходят до 6ти, не проверяя свой email

      Мне кажется, что в таких условиях проекту недолго осталось и без Scala.
  • +2
    Кстати, если кому интересно что за Вирджиния в заголовке.

    Я думаю, более стилистически точный перевод на русский звучал бы… "Удивительное рядом — Scala сложна!" или вообще, Внезапно.
    • 0
      Спасибо! Ломал голову, искал имя в его семье, смотрел не было ли докладов в этом одноименном штате за последнее время. Думал над «Scala сложна, детка!», но не решился, так и не определив что за Virginia :)
  • +1
    Возможно это мое imho, но основную проблему Scala я вижу в излишней математичности. Язык кажется сложным, потому что он пестрит математическими выражениями. Практически каждый элемент требует знаний и навыков теоретико-множественного исчисления, тогда как программисты больше склонны к алгоритмическому мышлению и далеко не все имеют математическое образование. А основные понятия языка и методы определены в его API, поэтому учить Scala — это не только учить язык, но и все, что идет под scala._. В итоге язык становится оторванным от реальности и представляющим исключительно академический интерес теоретикам программирования, использующим его как площадку для своих паттернов.

    Проблема резко усугубляется перегрузкой операторов. Разработчики языка не могут жить спокойно, чтобы лишний раз не наполнить какую-нибудь закорючку сакральным смыслом, вместо того, чтобы написать имя метода на христианском английском. Тем же самым грешат писатели библиотек. В итоге смысл кода становится абсолютно не ясным, если перед глазами нет соответствующего ScalaDoc. Апогей подобного маразма — это тот самый знаменитый Lift.

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

    Еще одна особенность — это повсеместное использование DSL в библиотеках. Хорошо это или плохо — тема отдельного разговора.

    Если сравнивать Scala с Groovy, то последний, обладая схожими возможностями, при этом являясь динамическим, т.е. «недоязыком», покрывает Scala в удобстве использования, потому как более-менее пытается следовать Java-way. Сравните, например, внешне скрипт на Gradle и на т.н. «Simple Build Tool»… ;)))
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Народ жаждет подробностей.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Ой да ладно. Твиттер со своим standard-project и в 0.7 страх наводил, которым тут и не пахнет. Научиться читать (и со скрипом писать) такие билды — это два вечера (сам вот только недавно осваивал).
            • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Грэдл это пипец на марше. Во-первых время запуска, на прокте из 6 модулей в сумме секунд 40. Мавен xthtp 'nj время уже зипует архивы, если проект на джаве. Во-вторых мания авторов делать из всего DSL и рассказывать в документации про этот DSL, а не про стоящую за ним модель. Как результат простейшее действие для своего выполнения требует залезания в исходники самого грэдла или вопроса в рассылку (благодаря чему по потоку сообщений она ещё зимой делала scala-user).

      Извините, накипело.
    • 0
      По теме комента: а можно пример элемента _требующего_ знаний теории множеств.

      Чем лучше имя на христианском набора символов? Если не понимаешь что оно делает — непонятно в любом случае. Если понимаешь — всё ок. Единственна реальная проблема — это именование таких операторов в устной речи. Но если не увлекаться и граничиваться операторами вроде << или ++ — проблем вообще не видно.
  • 0
    Очень интересный пост, спасибо за перевод.
    Это ведь необычно, когда адепт языка/технологии открыто говорит о его минусах.
  • +1
    Очень многие жалуются на сложный код Lift, и выбирают Play второй веб фремворк по удобству для Scala и не нативный для Scala. Так что вполне вероятно что сложность языка(его внутрених библиотек) умноженная на сложность библиотеки(аля lift) — очень сложное нечто. Сам я достаточно просто пишу средние проекты на Scala, но переиспользовать чужие библиотеки не решаюсь.
    Одна возможность создавать почти нативный DSL говорит о том что язык выучить невозможно т.к. это бесконечное число языков…
    Что тут можно сказать. Scala нужно знать, писать на ней, и внедрять )
  • 0
    Изучаю Scala в данный момент. Многое непривычно и приходится менять стереотипы сложившиеся при кодинге на Java. Scala может показаться сложнее просто потому, что там больше возможностей. Я уверен, сложность освоения окупится скоростью разработки.
    • 0
      От Java я пришел к Scala через Groovy и Python. Некоторые функциональные особенности языка были уже знакомы, но, безусловно было огромное количество всего нового. Полность. с Вами согласен: после определенного момента скорость разработки непременно повысится — кода получается гораааздо меньше. Очень доволен переходом на Lift.

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