Для начала, позвольте уточнить, что я являюсь большим любителем и сторонником 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, Вы далеко не средний, и даже не пытайтесь!
UPD. Был бы очень признателен за обоснование минусов в комментариях. Их повлекли мои безуспешные потуги начать улучшать свой английский? Бессмысленность поста? Несогласие с автором оригинала (я сам в определенных вопросах не разделяю его позиции)?
