Прощальная записка языку программирования

Такие записки выглядят для меня примерно так:
«Я долгие годы пользовался плоской отверткой. Но пришло время и я узнал о крестовых… это был прорыв. Но прошло время и я узнал торксах… Все, больше я обычные отвертки не могу использовать..»

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

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

Советую прочитать эту статью — Элитные языки программирования.

I found that to be particularly gruesome when working with seasoned Java developers. Yeah, sure, they have been doing OOP for a long time, for whatever that’s worth. But that doesn’t mean that it’s a good idea to recreate Java in Scala with just a little bit less of boilerplate. In well over a year of working in Scala teams there hasn’t been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem.

С одной стороны, он не первый, кто пересел со Scala на Clojure и говорит о том, что разработка на последнем намного более прямолинейна. Но с другой стороны, простите, если ситуация в стиле лебедь рак и щука, то почему винить язык? Скорее это проблема в том, что команда не может договориться внутри себя.
Но если правду сказать, наш проект страдает от тех же проблем. Отсутствие однозначной политики разработки + тонна возможностей + неправильный выбор библиотек + команда в 12 человек = далеко не гладкий код.

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

Например:

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

Для меня это оказалось ужасным открытием, когда стал работать в команде с опытными Java разработчиками. Знаешь, в течение долгого времени они занимались ООП, и как бы то ни было, это того стоит. Только не значит, что это хорошая идея воссоздать Java в Scala, где будет всего лишь чуть меньше шаблонов. В течение более чем одного года работы в командах Scala не было ни одного дня, когда я бы не чувствовал командного духа, направленного на то, чтобы разработать систему или приблизиться к решению проблемы.

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

Исходник

At first, I took it as a compliment that you tried to please me by offering me to work the way I liked. But then I noticed that it wasn’t something you did for me in particular. Instead, you try to be everybody’s darling by offering every software development paradigm known to man.

I found that to be particularly gruesome when working with seasoned Java developers. Yeah, sure, they have been doing OOP for a long time, for whatever that’s worth. But that doesn’t mean that it’s a good idea to recreate Java in Scala with just a little bit less of boilerplate. In well over a year of working in Scala teams there hasn’t been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem.

Смысл

Поначалу мне показалось очень приятным то, что ты предлагаешь мне выполнять задачи именно тем способом, который мне нравится. Но спустя некоторое время я заметил, что ты предлагаешь это не только мне. Вместо этого ты хочешь понравится всем, одновременно предлагая все известные человечеству парадигмы программирования.

Ужаснее всего это было при работе с опытными Java-разработчиками. Да, конечно, они очень долго занимались ООП и наверное это того стоило. Но это вовсе не означает, что попытка воссоздать Java на Scala с несколько меньшим количеством шаблонного кода, является хорошей идеей. В течение более чем года работы в использующих Scala командах не было ни одного дня, когда я бы чувствал, что у нас есть общее понимание того, как надо разрабатывать систему или хотя бы единый подход к решению проблем.

Часть предложений у вас поменяло смысл на прямо противоположный

В течение более чем одного года работы в командах Scala не было ни одного дня, когда я бы не чувствовал командного духа, направленного на то, чтобы разработать систему или приблизиться к решению проблемы

В исходнике наоборот «не было ни одного дня, когда я бы чувствовал командного духа», в вашем переводе получилось что он чувствовал этот командный дух постоянно и это еще не учитывая того, что в исходнике речь шла не совсем о командном духе и было точно описано в несколько словосочетаний о чем именно.

Или

У меня перерыв; я нашел замену лучше.

В исходнике прямо противоположное

I don’t need to take a break; I have found a better match.

Если буквально, то: «Мне не нужен прерыв» если художественно то «Речь вовсе не о перерыве, я нашел партнера получше.»

Заранее оговорюсь, что не хочу спровозировать конфликт на почве религиозных разногласий, все это мое персональное мнение.
Scala изначально позиционировался как универсальный язык для всего. Основными целями было:
1. Создать гибкий инструмент, который бы позволил использовать вместе различные парадигмы.
2. Совместимость с Java.
3. Максимальная лаконичность записи. Ничего лишнего.
4. Создание новых синтаксических конструкций через DSL.
5. Наиболее полная система типов.
6. Стать новым IT стандартом.

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

1. Различные парадигмы плохо сочетаются друг с другом. Кроме того, использовать в коде сразу несколько парадигм делает код запутанным, а сам язык увеличивает свой «порог вхождения». В 95% случаев функциональный подход используют для лямбд и работе с коллекциями: это модная фича, а программеры уже приучены. Функциональный подход при проектировании приложения встречается крайне редко. В итоге язык становится неким монстром Франкенштейна из плохо сшитых частей разных тел.

2. С дополнительными костылями. Коллекции несовместимы, структуры другие. Постоянно нужно держать в уме во что это будет компилиться. Учитывая что 99% библиотек и фреймворков написаны на Java, это дополнительная сложность.

3. Вообще странно. С одной стороны в Scala есть длинные ключевые слова, которые можно было бы сократить, с другой стороны, вся стардартная библиотека изобилует злоупотреблениями ввиде операторов. Вместо английского названия метода, объясняющего операцию, стоит одна или несколько закорючек, интуитивно не понятных без документации. В угоду DSL был окончательно испорчен синтаксис, позволяющий записывать одно и то же разными способами. Многие называют это гибкостью, когда это больше похоже на отсутствие костей. Сомнительная идея выражений через вызовы методов порождают сложные правила применения операций. В итоге, чем короче хочется написать, тем больше приходится нагружать язык синтаксической магией. Многие конструкции, типа XML, совершенно рудиментарные и искусственно внесены в язык, чтобы где-то сократить написание.

4. Удобство DSL — спорная идея, т.к. привносит магию. Обычно DSL используются для создания builder-а для сложного объекта по типу конфигурации. Попытка расширять конструкции языка через DSL сильно искусственна. Поэтому создатели Scala в последнее время смотрят в сторону макросов Nemerle.

5. А реальный смысл делать систему типов 100% type-safe и настолько сложной? Обычно в редких случаях, где появляется unchecked type casting, программист сам неплохо контролирует это. Как-то же программируют и на языках с динамической типизацией.

6. Несмотря на рекламу, Scala слабо адаптируется в среде программистов. Каждый обязан ее попробовать, но очень скоро вау-эффект пройдет. Создатели Scala ориентированы на совершенно других задачах, нежели требуется в реальных проектах. Скоро это поняли и создали инициативу typesafe.com. Однако покрываемая typesafe.com предметная область сильно ограничена. То есть, либо ты должен использовать Java фреймворк, что только усложняет ситуацию, либо шлепать функционал самому.

P.S. Если цитировать гения «Make it as simple as possible but not simpler», то Scala не может считаться гениальным языком :)

У меня есть положительный опыт командной разработке на Scala. Не смотря на сложные концепции, код получается компактным и легко исправляется. Бывает сложно провести рефакторинг из-за вывода типов и имплиситов, но все проблемы разрешимы. Возможно, здесь поможет IDE, просто я не умею ими пользоваться — даже под виндой пользуюсь vim.

Что интересно в статье — он перешел на Clojure. То есть к Java, JavaScript или Python уже точно не вернется ;-).