Зря вы так про Scala-то. «Programming in Scala» от Одерски и Ко. одна из лучших официальных книг-введений в язык программирования, сайт и документация отличные, да и в сети уже куча материалов в виде различных статей и бложиков. Не засчитывается.
P.S. С утра пораньше разговариваем-с с переводом, да.
Официальная документация довольно сумбурная, содержит мало хороших примеров решения типичных задач и вообще пока еще явно сыровата. Ну и даже для введения это слишком, слишком мало. Никакого обзора sbt, ни сравнения с другими task-runner'ами, не рассказано, почему именно такая структура проекта принята итд итп etc etc.
Мне кажется лучше было бы постараться изложить основы sbt в менее фрагментированном формате и больше ориентироваться на решение практических задач.
Для меня понятие «чистая» автоматически подразумевает и включает в себя «непротиворечивая» (:
Даже не могу представить примера, когда может быть одно без другого. Есть идеи?
Потому что если процесс разработки фичи длится долго, в какой-то момент вы можете оказатся у одного толстого коммита, которые перестал работать, а откатиться на последнее стабильное изменение в пределах этой фичи вы уже не сможете (если не лазать по reflog'у с факелом и слезами на глазах).
Я понимаю вашу точку зрения, но это создает плохую практику «рубки дерева бензопилой». Да, бензопилу в руках держать приятнее — красиво, технологично, но не надо показывать это другим в пример. Пока Scala-коммьюнити преимущественно состоит из «хипстеров» (работающих в крупных интернет компаниях и сильнейших CS-вузах мира, ага (: ) она может позволить себе быстрый рост и изменяемость (хотя уже сейчас начался переход к большей стабильности API и совместимости версий). А если в нее ломанутся Java-разработчики и начнут пытаться руководить балом — язык ожидает стагнация, из-за давнего существования которой в Java разработчики изначально и начинают смотреть в сторону Scala.
И вы в каждый проект, где вам понадобится парсить CSV, вместо использования готовой библиотеки будете вставлять этот милый «сниппет» на 170 строк? Или, не дай бог, писать каждый раз с нуля?
Чтобы его выкинуть, надо сначала понять как он работает, чтобы не задеть поведение использующих его частей, в которых уже возможно тоже заковнокожены костыли, ожидающие костыльного поведения. Понять говнокод — половина беда. Понять его правильно со всеми нюансами костылей, когда git log выглядит как череда из коммитов с локоничным сообщением «fix» или «fix of a last fix» — вообще невозможно. А если при этом «опытные разработчики» еще и на тесты забили, потому что «нет времени, надо пилить фичи», то даже пытаться практически бесполезно.
Суть не в «функциональщина/императивщина». Scala даже более чистый ООП язык чем Java, а ее система типов и такие конструкции как трейты и кейс классы позволяют писать супер-лаконичный и переиспользуемый ООП-код. Разумеется, когда есть необходимость в проихводительности лучше отбросить все сомнения и flatMap'ы, взяться за изменяемые структуры данных и погрузится по локоть в ручное перемешивание битов.
Я же говорю про идеоматичность, как с точки зрения кода, так и используемых библиотек. Вокруг Scala уже успело собраться отличное коммьюнити, которое активно занимается разработкой огромного числа отличных инструментов и библиотек. Все изложенное в статье можно сделать в пару десятков строк кода без единого XML файла'а и Java EE Bean'а на коком-нибудь Play framework, либо даже самостоятельно с помощью связки Spray + Akka.
P.S. С утра пораньше разговариваем-с с переводом, да.
Мне кажется лучше было бы постараться изложить основы sbt в менее фрагментированном формате и больше ориентироваться на решение практических задач.
Даже не могу представить примера, когда может быть одно без другого. Есть идеи?
rebase переносит коммиты из ветки на другую ветку.
Я же говорю про идеоматичность, как с точки зрения кода, так и используемых библиотек. Вокруг Scala уже успело собраться отличное коммьюнити, которое активно занимается разработкой огромного числа отличных инструментов и библиотек. Все изложенное в статье можно сделать в пару десятков строк кода без единого XML файла'а и Java EE Bean'а на коком-нибудь Play framework, либо даже самостоятельно с помощью связки Spray + Akka.