авторЯ однозначно отвергаю аргумент “отлично, тогда мы найдем более профессиональных разработчиков”. Нам стоит решать проблему “Scala is hard”, работая над улучшением компетентности разработчиков вцелом (одни, кто сможет читать сигнатуры типов, другие — выражать свои программы используя математические подходы и т.д.), но мы отдаляемся от сути. А суть в том, что Scala не так хорошо подходит для начала революции в обучении , образовании или найме, как подходит для повышения профессионализма среднего разработчика, с целью перестать быть для него сложной.


+1. не понимаю как можно начинать обучение скалы с обучения скалы ))
нужно начать с хаскеля, а лишь потом использовать скалу в качестве более практичного инструмента.

Clojure vs Scala - anecdote

авторВ связи с моим предстоящим выступлением на встрече разработчиков Scala решил накинуть говна на вентилятор перевести появившийся недавно Clojure use case. Оригинал появился сегодня рано утром и взят отсюда.

"Хотелось бы немного поделиться нашим опытом из World Singles...
В ноябре 2009-го мы начали разрабатывать на Scala. Нам нужен был очень длительный процесс, который публиковал бы большие тома изменений из нашей БД пользователей в виде XML-пакетов, опубликованных в кастомном поисковом движке. Отобразить пол дюжины таблиц из БД на XML было довольно сложно, и компания уже перепробовала несколько решений с разным успехом. Я предложил Scala, основываясь на производительности, конкурентности, типобезопасности и краткости (особенно учитывая, что XML -- родная структура данных в Scala).
Мы использовали публикующие демоны на Scala в продакшене больше двух лет. В основном, они работали неплохо, однако при высокой нагрузке часто выкидывали исключения Out of Memory. После длительного ковыряния в коде, мы пришли к выводу, что это происходило благодаря (по крайней мере, частично) дефолтной реализации акторов в Scala. Scala должна скоро объединиться с Akka, и, так или иначе, мы раздумывали о миграции на Akka...
Но после того, как мы начали использовать Clojure в этом году (после экспериментов с Clojure с мая этого года) выяснилось, что довольно просто реализовать Clojure-версию нашего Scala-кода.
Чтобы по-новой создать публикующего демона, потребовалось около 15-ти часов работы, после которых стали проходить все наши функциональные тесты. Теперь мы запускаем полный тест, публикующий более 300 000 профайлов за раз. Scala-код вылетает с OoM-исключением уже на 50 000 профайлов (иногда даже меньше). А Clojure-код вышел сухим из воды и спокойно работает на таких нагрузках. Теперь мы собираемся заменить наш Scala-код на Clojure-код в следующем продакшен-билде.
Другая интересная особенность заключается в том, что Scala-код занял около 1000 строк (примерно 31k символов). Аналог на Clojure занял всего 260 строк и 11.5к символов. Ни тот, ни другой исходник не содержит большого числа комментариев (кгмм... я не горжусь этим, конечно, а просто показываю, что ни в одном из исходников нету лишнего текста, мещающего сравнивать их по объему). В сравнении также не учитывается код юнит-тестов, так что мы сравниваем чистый продакшен-код. Clojure-код написан по тем же принципам, что и Scala-код, в основном с теми же самыми функциями (Scala-код был написан в функциональном стиле), с небольшим рефакторингом для извлечения helper-функций и повышения модульности и упрощения поддержки.
В результате, понятное дело, мы берем в продакшен Clojure-код и полностью отказываемся от Scala.
Слава Ричу Хикки и Сlojure/core-команде за разработку такого великолепного языка общего назначения, решающего большие задачи! Спасибо вам!"


мне кстати кложурка очень нравится.

mikkriZyK_BotaN,

не уверен, поняли вы или нет из перевода, но автор оригинала статьи просто стебется.

в каждой шутке есть доля шутки, а остальное правда.

ZyK_BotaNmikkriZyK_BotaN,

не уверен, поняли вы или нет из перевода, но автор оригинала статьи просто стебется.

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

LeonidvmikkriZyK_BotaN,

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

к той где говорится, что скала - сложна.

Petro123VoDA,
я бы развил ещё дальше.
Программировать на ФП не рационально.
Футурологи говорят, к 2050 году на носитель будет перезаписан интеллект с нейронов.
Так что мы перескочим через ФП на какой-нить КП.
______________________________________________
"Сложнее всего в мире достигнуть простоты — это крайняя граница опыта и последнее усилие гения". © George Sand.
AutoPOI.ru — ГИС-технологии для Oracle

NixicPetro123Так что мы перескочим через ФП на какой-нить КП.

Что за КП ?

квантовое, не?

ходя для квантовых вычислений хорошо подойдет уже существующая парадигма логического программирования.

Kenny FartmanZyK_BotaN Система типов в Scala является чрезвычайно мощной, но, с Вашей точки зрения, возможно, даже чересчур. В ScalaDocs некоторые сигнатуры могут выглядеть очень устрашающе. Гляньте на

flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That


и теперь попробуйте мне сказать, что это не взорвало Ваш мозг. Этот метод новички используют каждый день, а, возможно раз 20 за день. Документация Scala нуждается в библиотеке, которая бы скрывала всю эту сложность. Сложность, делающую метод flatMap невероятно мощным. Для системы типов и сопутствующей документации необходим более простой и понятный пользователю режим отображения.такая надуманная феерическая мура. новичек будет втыкать с примеры и екзамплы и бэст практики взятые с интернета и разберется за месяц-полгода и ему пофиг какая на самом деле сигнатура у метода flatMap, будет копи-пастить примеры и перекраивать под себя как делают и джависты и сишарпщики. Никто код "из головы" вслепую не пишет
И потом, кто не разберется в таких сигнатурах, займут место кобольщиков, отойдут в историю программирования. в конце концов есть инженеры разрабатывающие станки с чпу, а есть те у кого хватает ума только подносить в эти станки болванки и нажимать кнопку, запуская программу обработки болванки. И те и другие люди нужны и если вторые не могут асилить чертежи станка с ЧПУ то это не значит что инженерам нужно срочно побросать свои CADы и CAMы и стать на место подносчиков болванок. "ниасилил- метлу в руки и дворником работай". А то эти стоны "Нам нужен вижуал бэйсик. Но чтобы сцуко мощный! Но сцуко при этом простой такой как HTML и эффективный как C++" уже подзадостали

вот здесь я с тобой соглашусь полностью. дурной пример с типами он привел. нефиг разрабов за придурков держать.

zeehondмне кажется, лет через 10 Scala будет *повсеместно* используемым языком для разработки бизнес-приложений, таким же, как сейчас Java


а почему именно скала? че не хаскель например? или если рассматривать жавовскую платформу, то почему не кложур?

zeehond
так что не желающие изучать новые парадигмы (ФП и синтаксис Scala) - через 10 лет вам придётся конкурировать с огромными толпами пишущих на Java индусов

вот сегодня скала никому не уперлась, дак почему изучать фп парадигму на примере скалы?
не будет ли проще изучать фп на примере хацкеля, а "лет через 10 Scala будет *повсеместно* используемым языком для разработки бизнес-приложений, таким же, как сейчас Java"(с) изучить скалу и использовать себе ее во благо?

BlazkowiczZyK_BotaN"лет через 10 Scala будет *повсеместно* используемым языком для разработки бизнес-приложений, таким же, как сейчас Java"(с)
Зачем на глупость ещё и копирайт ставить?
что-бы не подумали что я сам такое мог ляпнуть.

VoDAИМО высокая гибкость языка это плюс для малых команд и жирный минус для больших,
согласен.
надо фп - бери хаскель, там есть единые подходы решения проблем и единый стиль.

а в скале намешана куча парадигм, а что с ними делать - хз.
каждый пишет по своему.