Инструмент как часть личности

Возьмем типичную ситуацию: переход на новый стек или поддержка старой базы. Допустим, команда третью неделю (а иногда и третий месяц!) обсуждает, оставить Scala или перейти на Kotlin. Аргументы обеих сторон озвучиваются на первой же встрече, а затем просто повторяются от созвона к созвону. Кто-то говорит об экосистеме, кто-то — о кривой обучения. Внешне это выглядит как техническая дискуссия, но решение не принимается.

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

Программист, который пять лет пишет на Scala, не просто использует инструмент. Язык стал частью его мышления: как он декомпозирует задачи и выстраивает архитектуру. И когда кто-то предлагает перейти на Kotlin, человек слышит: «То, что ты умеешь, больше не нужно». Отсюда и высокий градус эмоций. Годы практики делают стек частью профессиональной идентичности. Оспорить выбор инструмента — значит задеть человека лично.

Ловушка единомышленников

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

Однако со временем команда перестает замечать собственные слепые пятна. Любой «человек со стороны» с его новым взглядом воспринимается как дилетант, пытающийся найти изъяны в идеальной системе. Холивары в таких коллективах особенно вязкие: все одинаково уверены, что «очевидное очевидно», а любое альтернативное мнение априори ошибочно или упоминается лишь в контексте «идея хорошая, но делать ее мы не будем».

Скульптура против Lego: конфликт ценностей

В инженерной культуре сложность часто путают с качеством. Из-за этого возникают одни из самых затяжных конфликтов: когда один разработчик ратует за лаконичность и скорость, а другой — за «высокую архитектуру». Scala появилась именно из этой логики: язык создавался людьми, которые хотели объединить объектно-ориентированное и функциональное программирование в одном инструменте. Получилось мощно и академически красиво, но взаправду сложно. И вопрос, а всегда ли нужно вот настолько сложно, тоже порождает споры.

Хорошая аналогия — скульптура из мрамора против фигурки из Lego. Когда мы видим работы Страцца и Бернини, которые смогли передать в камне эффект тончайшей вуали, мы застываем в восхищении посреди музея. Но создание таких статуй требовало времени, а внести “правки от заказчика” означало бы подвергнуть риску всю работу: попробуйте исправить скол на мраморной статуе, которую ваяли сильно дольше, чем планировалось. В случае с конструкцией из Lego все намного проще: вынул блок, вставил другой, и вот из фигурки кошки уже получился «Тысячелетний сокол».

Чем сложнее язык или технология, тем глубже оказываются ошибки и тем труднее их потом найти. Причем платит за это не только тот, кто писал. Автор ошибки как раз легко может к этому моменту уже уйти на повышение. Но каждый следующий человек, который начнет взаимодействовать с этим кодом, заплатит ту же цену. Технический долг в командах почти всегда описывают одинаково: «это то, что написали до меня». Мы сильно реже склонны упоминать его, имея в виду собственный код и свои планы. Сложные решения, выбранные ради красоты концепции, — один из самых надежных способов создать именно такой долг.

Сложный инструмент — не приговор. Но когда его выбирают ради престижа, а не задачи, споры вокруг него становятся особенно изматывающими.

Конфликт как трудности перевода

Важная вещь, которую часто пропускают: разные люди воспринимают одно и то же взаимодействие по-разному. Для одних горячий спор — нормальный способ думать вслух и нащупывать решение. Для других тот же разговор выглядит как конфликт, который нужно срочно разрядить или который надо зарепортить, тимлиду или сразу в HR.

Представьте, что два инженера увлеченно спорят об архитектуре: перебивают друг друга, говорят громко, каждый настаивает на своем. Третий коллега идет к руководителю и взволнованно сообщает, что в команде глубокий конфликт. Двое из начала абзаца искренне удивляются: какой конфликт, мы просто разговаривали. Но наблюдатель снаружи видит драку.

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

Молчание как последствие конфликтофобии

Если порыться в памяти, мы вспомним истории, когда инженер предлагал идею, но получил отказ — причем без объяснений, просто нет. Инженер предлагает снова, и снова получает неаргументированный отказ. В такой ситуации мало кто предложит инициативу в третий раз. Психологи называют это выученной беспомощностью — человек перестает пробовать, потому что система не воспринимает предложения. А объяснять детали система не обучена или не планирует, ведь чем больше информации она даст участникам системы, тем больше поводов для споров может возникнуть.

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

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

Маленькое трение, умноженное на количество людей и рабочих дней, становится реальной проблемой производительности. Разница в том, что не всегда можно четко измерить, когда человек не доволен. Это не видно на графиках, и поэтому проще игнорировать, но трение точно ощущается человеком изо дня в день.

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

Новый стандарт 3.0 уже поддерживается большинством современных браузеров и приносит сразу несколько ключевых нововведений.

Главное из нововведений

• 64-битная адресация: теперь Wasm может использовать i64 вместо i32, что расширяет лимит адресуемой памяти с 4 ГБ до 16 ЭБ (в реальности — до 16 ГБ в браузерах).
• Несколько областей памяти: модули теперь могут напрямую использовать и копировать данные между разной памятью, без обходных трюков с импортом других модулей.
• Сборка мусора (GC): добавлена поддержка управляемой памяти для языков с автоматическим управлением памятью (например, Java, Scala, Kotlin, Dart).
• Типизированные ссылки: улучшенная типизация ссылок и функций позволяет избежать лишних проверок в рантайме.
• Исключения: наконец-то появилась полноценная система обработки исключений — с try, throw и catch, как в других языках.
• Хвостовые вызовы: позволяют не занимать стек при возврате через вызов, что критично для функциональных языков и оптимизаций.
• Расслабленные SIMD-инструкции: добавлены быстрые, но менее детерминированные версии векторных инструкций для повышения производительности.
• Детерминированный профиль: теперь для задач с требованием полной воспроизводимости (например, блокчейны) можно включить строго определенное поведение операций.
• Аннотации в тексте: появилась возможность вставлять пользовательские аннотации прямо в текстовый формат .wat.

Что это значит

WebAssembly становится всё ближе к полноценной виртуальной машине для высокоуровневых языков. В новой версии уже появляются компиляторы для Java, OCaml, Scala и прочих ЯП — благодаря поддержке GC и исключений.

Новый стандарт уже поддерживается в основных браузерах, включая Chrome и Firefox. Независимые движки, такие как Wasmtime, тоже догоняют.

Репозиторий уже собрал почти 65 000 звезд на GitHub. Разбираемся, как он устроен и какие интересные модули лежат внутри.

Что делает этот алгоритм

Алгоритм отвечает за то, какие посты и аккаунты вы видите на всех основных страницах в X: от рекомендаций и трендов до пушей. Внутри — десятки сервисов и моделей, взаимодействующих между собой.

Например, компонент home-mixer собирает кандидатные твиты из разных источников (например, через search-index, tweet-mixer, user-tweet-entity-graph) и ранжирует их при помощи легкой и тяжелой нейросети (light-ranker, heavy-ranker).

После этого подключаются фильтры (например, visibility-filters), которые убирают нежелательный контент и скрытые посты.

Из чего это все собрано

Проект построен на Scala (66%), Java (20%) и Rust. Некоторые модули используют Python и даже TensorFlow v1 (например, twml). Базовые компоненты включают:

• Данные — tweepypie, unified-user-actions, user-signal-service
• Модели — SimClusters, TwHIN, real-graph, tweepcred, trust-and-safety-models
• Фреймворки — navi (на Rust), product-mixer, representation-scorer, representation-manager

Также присутствуют специфические компоненты для пушей — сервис pushservice, ранжирующие модели pushservice-light-ranker и pushservice-heavy-ranker, предсказывающие, откроет ли пользователь уведомление.

Почему это важно

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

Во-вторых, открытый код — это редкость в мире коммерческих рекомендаций, особенно на таком масштабе.

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

Что это значит для разработчиков

Этот проект — хорошее поле для изучения реального промышленного машинного обучения. Особенно интересны:

• плотные графовые эмбеддинги в TwHIN
• модели репутации и социальной близости в real-graph и tweepcred
• многозадачные модели в pushservice-heavy-ranker

Проект можно собрать с помощью Bazel, хотя полноценной инфраструктуры для тестов пока нет.

Есть одна задача, которую программисты терпеть не могут — но именно она отличает хорошего инженера от посредственного: как они документируют свой проект? Несколько лет назад я отвечал за запуск финтех-проекта. Мы выбрали стратегию быстрого старта, поэтому масштабируемость не стала для нас приоритетом. Главной целью было проверить гипотезу — и мы двигались вперёд, разрабатывая API, архитектуру и системы — с упором на простоту, не особенно задумываясь о будущем.

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

Во время работы я наткнулся на подход, который мне очень понравился: ADR — Architectural Decision Record, или «протокол архитектурных решений».

По сути, это документ, в котором фиксируются все изменения, внесённые в архитектуру: само решение, его влияние и полученные уроки.

Проще говоря, это как личный дневник — только для всей команды.

Почему это важно?

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

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

Будущие разработчики скажут вам спасибо. Подумайте о человеке, который через пять лет будет разбираться в вашем коде. Если вы не оставили объяснений, он, скорее всего, будет мучиться, пытаясь понять, зачем было сделано то или иное изменение. А теперь представьте другого разработчика в другой компании, который находит ADR-документ с чётким объяснением принятого решения. Он, без сомнения, будет вам благодарен.

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Ценность ADR я впервые осознала в 2019 году. В команду, где работала, активно набирали новых ребят, и приблизительно раз в неделю кто-нибудь из новых разработчиков спрашивал "а почему это сделано так, а не иначе?" Приходилось постоянно давать ответы на одни и те же вопросы, и тогда-то я и поняла, насколько будет удобно записывать ответы где-нибудь в документацию в confluence и просто кидать ссылку новичкам.

В 2019 году я еще не знала сам термин ADR и говорила "документация". С термином я познакомилась совсем недавно — этим летом, на курсе по архитектуре монолитных приложений. Тогда я поняла, насколько эффективно можно использовать ADR для ускорения разработки и уменьшения TTM. Дело в том, что начиная разрабатывать новый проект, разработчик первое время (от месяца до полугода! всё зависит от размера проекта) погружается в проект — разбирается, как всё устроено, чтобы вносить изменения соответственно архитектуре. В этот период разработчик, по сути, составляет собственные adr — обычно в виде мыслеобразов в своей голове :) Если записать основные решения, разработчик сможет намного быстрее погрузиться в проект.

Как писать ADR?

Существует несколько общепринятых правил, но вы всегда можете адаптировать их под себя.

Вдохновившее меня соглашение можно найти на GitHub . Вы также можете ознакомиться с процессом ADR на Amazon.

Вот пример шаблона, который вы можете использовать.

Такой тип документа может находиться прямо в репозитории проекта, в Confluence или, например, в JIRA.

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Многие руководители хотят видеть на своём проекте разработчиков, которые "сразу, без раскачки" начнут перформить. Совсем избежать периода погружения невозможно, но можно ускорить его в десятки раз за счёт ADR

Рекурсия: что это такое и зачем нужна

Рекурсия — функция, которая вызывает саму себя. Ее базовое применение — разбить большую задачу на несколько мелких, что делает код проще и понятнее, или когда нужно повторить какое-то действие несколько раз. Второй случай похож на русскую матрешку — вы достаете куклу за куклой, пока не дойдете до самой маленькой.

А теперь давайте разберемся на простом примере из математики: представим, что у нас есть функция F, которая выполняет определенное действие. В нашем случае — вычисляет факториал числа (это самый классический пример). Внутри этой функции F в качестве одного из значений используем вызов этой же функции F, но с уменьшенным аргументом. Так функция будет вызывать саму себя до тех пор, пока не достигнет базового случая (о нем расскажем ниже), после чего начнет возвращать результаты.

В виде кода это выглядит так:

Здесь функция F вычисляет факториал числа n, умножая его на факториал n-1, и так до тех пор, пока не дойдёт до 1, после чего начнёт возвращать результаты вверх по цепочке вызовов. Этот пример как раз о том, что нужно выполнить несколько одинаковых действий.

А вот пример из жизни: вы листаете ленту в известной социальной сети, а новые посты обновляются автоматически — это рекурсия в действии.

Принципы работы рекурсии

Рекурсия строится на двух ключевых принципах: базовый случай и рекурсивный вызов. Они позволяют функции вызывать саму себя, пока она не завершится.

Базовый случай

Базовый случай рекурсии — условие, при котором рекурсивный вызов прекращается. Без него функция будет вызывать саму себя бесконечно, а значит, стек переполнится.

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

Так это выглядит в виде кода:

То есть, базовый случай — если exponent == 0, то возвращаем 1.

Рекурсивный вызов

Рекурсивный вызов — шаг, на котором функция вызывает саму себя, но с измененными параметрами, чтобы задача стала проще. Один из еще одних классических примеров — задача с числами Фибоначчи.

Числа Фибоначчи — это последовательность, где каждое число равно сумме двух предыдущих: 0, 1, 1, 2, 3, 5, 8, 13, 21, …

Если вызвать fibonacci(5), то увидите следующее:

После этого функция возвращает результаты обратно вверх по стеку вызовов. Обычно этот метод используется в криптографии и алгосах.

Кстати, на примере чисел Фибоначчи можно разобрать одну из проблем рекурсии — плохая производительность при отсутствии мемоизации.

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

Так, функция в задаче с числами Фибоначчи имеет экспоненциальную сложность O(2^n), так как она многократно вычисляет одни и те же значения. Например, чтобы вычислить fibonacci(5), функция вызывает сама себя 15 раз, хотя уникальных вычислений всего 6.

Чтобы улучшить производительность, нужно использовать мемоизацию, чтобы сохранить результаты:

Здесь сложность уменьшается до O(n), так как каждое значение вычисляется только один раз.

Стек вызовов и управление памятью

Каждый рекурсивный вызов функции добавляет новый элемент в стек вызовов. Это значит, что вызовы складывается в стеке до тех пор, пока не будет достигнут базовый случай. После этого стек начинает разворачиваться, возвращая результаты на каждом уровне.

Например:

Так, когда мы вызываем сountdows(3), в стеке появляются новые вызовы:

call countdown(3) # → печатает 3

call countdown(2) # → печатает 2

call countdown(1) # → печатает 1

call countdown(0) # → печатает "Старт" и выходит

Затем стек начинает разворачиваться:

• countdown(0) завершился → удаляется из стека
• countdown(1) завершился → удаляется из стека
• countdown(2) завершился → удаляется из стека
• countdown(3) завершился → удаляется из стека

Если же в рекурсии нет базового случая, то стек вызовов никогда не освободится, и программа (в нашем случае на Питоне) выдаст ошибку RecursionError.

Вот пример бесконечной рекурсии:

В Питоне есть ограничения до 1000 вызовов, чтобы не перегружать стек, но этот лимит можно увеличить:

Рекурсия на реальных задачах

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

Обход структуры данных

Рекурсия часто используется для обхода деревьев и графов. Например, бинарного дерева — в нем не более двух дочерних узлов (левый и правый). Вот три основных способа обхода:

1. Прямой обход (Pre-order): Корень → Левый узел → Правый узел.
2. Симметричный обход (In-order): Левый узел → Корень → Правый узел.
3. Обратный обход (Post-order): Левый узел → Правый узел → Корень.

Запишем в виде кода:

Дерево будет выглядеть так:

1

/ \

2 3

/ \

4 5

• Прямой обход: 1 → 2 → 4 → 5 → 3.
• Симметричный обход: 4 → 2 → 5 → 1 → 3.
• Обратный обход: 4 → 5 → 2 → 3 → 1.

Обходить можно и графы, особенно в глубине (DFS). Вот пример:

Сам граф:

Результат обхода: A → B → D → E → F → C.

Разбиение

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

Что такое хвостовая рекурсия

Хвостовая (оконечная) рекурсия — частный случай рекурсии. Главное отличие от обычной в том, что единственный рекурсивный вызов находится в конце перед выходом функции. В традиционной же рекурсии после рекурсивного вызова могут быть дополнительные вычисления.

Вот пример:

Кстати, с помощью хвостовой рекурсии тоже можно решать задачи с числами Фибоначчи:

Некоторые языки программирования (например, Haskell и Scala) поддерживают оптимизацию хвостовой рекурсии. Это означает, что компилятор или интерпретатор преобразует хвостовую рекурсию в итерацию — это помогает избежать переполнение стека.

Давайте посмотрим, как это работает в Scala. Вот обычная рекурсия, чтобы понять принцип:

А вот рекурсия с оптимизацией:

К сожалению, наш любимый Питон такую функцию не поддерживает, но всегда можно преобразовать «хвостика» в итерацию вручную:

Это пример итеративного решения факториала.

Рекурсия vs. итерация

Основные различия между рекурсией и итерацией заключаются в следующем:

• В рекурсии функция вызывает саму себя, а в итерации используются циклы.
• Интеграция требует меньше памяти, потому что нет стека вызовов.
• Рекурсия медленнее без оптимизации.
• С рекурсией легко переполнить хранилище при большой глубине.
• Рекурсия обычно более читаемая и лаконичная, но подходит для меньшего количества задач.

Итерацию лучше использовать в следующих случаях:

• Задачи, где нужна производительность. Как, например, с итеративным вычислением чисел Фибоначчи.
• Обработка больших данных, например, поиск или сортировка. Вот пример пузырьковой сортировки:

• Задачи с большой глубиной рекурсии, чтобы стек не переполнялся. Вот как итеративно обойти дерево:

Еще один пример: задача «Ханойские башни»

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

Есть три стержня: A, B и C. На стержень A нанизано несколько дисков разного размера, причем диски упорядочены по размеру в виде пирамидки — вниз от маленького к большому. Суть в том, чтобы переместить все диски со стержня А на С, при этом: за один раз можно перемещать только один диск, нельзя класть больший диск на меньший, можно использовать стержень B как вспомогательный.

Рекурсивное решение задачи «Ханойские башни» основано на следующей идее:

1. Переместить (n−1) дисков с A на B, используя C как промежуточный.
2. Переместить оставшийся самый большой диск с A на C.
3. Переместить (n−1) дисков с B) на C, теперь используя A как промежуточный.

Следовательно, если количество дисков n=1, просто переместите его с А на С (базовый случай). В остальных случаях при n–1 повторить то, что указано выше.

А теперь решение с помощью кода:

Вывод:

Поздравляем, вы великолепны. А если хотите еще потренироваться в рекурсии, то можно написать код для поиска пути в лабиринте (кстати, это чем-то напоминает онлайн-карты и навигаторы) или обратного вывода строки.

Множество людей советовали мне изучить Haskell, Scala, Clojure, Erlang или Lisp, потому что они помогут хорошо понять функциональное программирование. Но я не уверен, за какой стоит взяться в первую очередь. У меня есть опыт работы с Python и JS, но я ни разу не сталкивался с функциональными языками программирования, поэтому также хочется знать, какие языки для чего используются: приложения, сайты, игры, машинное обучение и так далее.

В ответ HistoricalAccess9501 получил несколько дельных советов.

UdPropheticCatgirl

Я думаю, что любой из потомков и диалектов Lisp подойдет, например, SBCL или Clojure (и, возможно, Racket).

Можно взяться за Elixir, Erlang и Gleam, особенно чтобы разобраться в BEAM. Если вы хорошо знакомы с акторами и IPC. Scala великолепен, но многим отличается от большинства функциональных языков, поэтому не стоит учить его в первую очередь. Еще я бы не брался за Haskell и вместо него учил OCaml.

Что касается сфер применения:

• Scala используется для построения дата-пайплайнов, и для бэкенда на Java.
• Clojure — оптимальный Lisp, для работы в 2024, в основном если пишете бэкенд на Java.
• SBCL сегодня встречается редко, я сталкивался с ним только во время работы с HFT, еще в какой-то момент его часто использовали в сфере ИИ, но не уверен, продолжают ли сейчас.
• Elixir — снова бэкенд, особенно если работаете с распределенными системами.
• Erlang — король распределенных систем, часто используется в телекоме.
• Haskell подходит, только если вам не о чем поговорить с курьером и перед партией в D&D.
• OCaml используется примерно в двух финтех-компаниях и некоторыми небольшими анализаторами в Meta, вот и все.

VicariousAthlete

F# просто замечательный — мой лучший опыт в этой сфере. Сейчас мы используем его в создании масштабных систем (заказ еды онлайн).

nandryshak

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

• Функции первого класса, составные функции и прочее? — Javascript, Racket.
• Все вышеперечисленное плюс неизменяемые объекты? — Clojure.
• Все вышеперечисленное плюс хорошая система типов? Typescript.
• Все вышеперечисленное плюс, Хиндли-Милнер и математика? — Haskell.

<…>

Joewoof

Сложно выбрать. Самый простой и популярный — Scala, но это мультипарадигмальный язык. Haskell слишком редкий. Что-то среднее?

Наверное, OCaml. Он преподается как первый в Кембридже, у него хорошая репутация. Если хотите что-то более практичное, то выбирайте Elixir.

0xAERG

Если вы знакомы с JS и хотите что-то похожее, советую попробовать изучить ReScript. Он функциональный, компилируется в JavaScript, а синтаксис похож на смесь OCalm и JS. <…>

davadds0

В университете я изучал Erlang и Scheme.

Рекомендую сначала изучить Erlang (сначала хорошо освоить vanilla Erlang), а затем — OTP, что-то вроде библиотеки/фреймворка Erlang, это спасет вас от монотонной работы. А еще будет удобно создавать сложные распределенные системы с помощью Erlang/OTP. <…>

Peiple

Из необычного — R, который полезен на практике. Он не такой хардкорный, как Haskell, но содержит большинство концепций функционального программирования. В основном используется в Data Science. <…>

Frenchslumbe

Самый легкий в освоении — Lips.

Простой и последовательный синтаксис (но при этом очень выразительный). К тому же, изучив Lips, будет проще с его диалектами и языками-потомками. <…>

Также советую ClojureScript. Это реализация Clojure, с компиляцией в JavaScript.

А что бы вы посоветовали, начинающим изучать функциональное программирование?

Вместе с разработчиками технологической и научно-исследовательской компании «Криптонит» мы составили дорожную карту по изучению Scala. Этот роадмап подойдёт Java-разработчикам, которые хотят освоить больше связанных технологий.

1. Зачем переходить на Scala
2. Задачи и возможности Scala
3. Чем занимается Scala-программист
4. Общие инструменты
5. Полезные материалы для изучения Scala

Зачем переходить на Scala

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

Scala создавался как преемник Java. Он унаследовал лучшее от предшественника и стал технически совершеннее. Scala более объектно-ориентирован, чем Java, а также обладает возможностями функционального языка. Сочетание двух подходов делает программирование на Scala гибким, повышает эффективность кода и позволяет реализовывать нестандартные решения.

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

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

Задачи и возможности Scala

Scala — многофункциональный язык программирования, который применяется для решения различных задач. Сегодня возможности Scala используют для разработки распределённых систем, научных вычислений, мобильных и веб-приложений и приложений для анализа данных.

Писать на Scala сложнее, чем на Java. Язык требует совершенно другого подхода к архитектуре и логике построения кода. Но вместе с этим Scala имеет ряд преимуществ:

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

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

— Интероперабельность с Java. Язык полностью совместим с Java, поэтому Scala-разработчики могут использовать библиотеки Java и легко взаимодействовать с Java-кодом.

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

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

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

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

Чем занимается Scala-программист

Согласно исследованию Stack Overflow, доля Scala-разработчиков среди профессиональных программистов — около 3%. И компании активно ищут таких специалистов: в марте 2023 года только на карьерной площадке Linkedin размещено почти 34 тысячи соответствующих вакансий.

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

Бэкендеры занимаются разработкой сервисов, связанных с бизнес-логикой системы. Например, в «Криптоните» ищут Scala-разработчиков, которые возьмутся за реализацию серверной части веб-приложений, связанных с обработкой и отображением больших данных, а также начинающих «скалистов», которые будут разрабатывать отдельные компоненты приложений и проводить их автоматическое тестирование.

До того, как стал писать на Scala коммерческие проекты, я уже знал Java, JavaScript и C. Примерно в 2012 году стали много говорить о том, что Java скоро умрёт и будут новые языки. Scala назывался как один из них, и я решил попробовать. Оказалось, это интереснее, чем писать на Java. Однако у «скалистов» более высокий порог входа. Чтобы начать писать на этом языке, нужно чуть больше знаний, чем для программирования на Java. На Scala я пишу почти 10 лет. Сначала делал небольшие программы для себя. Они выполняли какие-то рутинные действия, помогая мне в основной работе. Например, я сделал редактор protobuf’а (формата сериализации структурированных данных Protocol Buffers, который по сравнению с XML обеспечивает более компактное хранение и повышает скорость обработки данных). Особенно понравилось, что в среде разработки Scala есть консоль (среда программирования REPL с интерфейсом командной строки). В ней можно писать код в интерактивном режиме и тут же его выполнять. В «Криптоните» я занимаюсь бэкендом для клиента интеллектуальной системы транскрибации голоса. Это очень перспективная тема, и её интересно реализовать на Scala. Ещё я сейчас работаю над сервисами для платформы обработки больших данных. Я выполнил оптимизацию кода и потребления вычислительных ресурсов, используя принцип разделения функционала. Получились отдельные лёгкие микросервисы.

Кроме backend-разработки, у Scala-программистов есть карьерные перспективы в обработке данных. Это направление требует широкого кругозора и понимания того, по каким принципам строятся распределённые системы. Также для работы понадобятся сильные технические навыки, знание тонкостей работы платформы JVM и облачной инфраструктуры.

Впервые о языке Scala я узнал в 2015 году. Я уже знал Java, а также успел поучаствовать на проектах с Python, Ruby и немного — с JavaScript. Мой первый проект на Scala был связан с обработкой результатов тестов в генетической лаборатории. Он состоял из двух отдельных частей: ETL (извлечение, преобразование и загрузка) огромного потока данных и backend для отображения статистики. В «Криптоните» я занимаюсь разработкой ПО для наших заказчиков: поиском и обработкой больших массивов данных, транскрибацией голосовых сообщений, а также участвую в разработке внутренних проектов — например, сервисом доступа и хранения данных.

Ещё одно направление для развития — анализ данных. На этой позиции от кандидатов требуют знание Scala, Python, SQL, умение декомпозировать сложные структуры данных на отдельные компоненты, выстраивать гипотезы на основе этих компонент и проводить математические исследования с целью доказательства или опровержения выработанных гипотез.

Scala-программисты описывают алгоритмы приведения неструктурированных данных к структурированным, находят зависимости и противоречия. Например, в «Криптоните» разрабатывают аналитические системы на базе единой платформы, которые позволяют безопасно работать с данными независимо от их формата, метода хранения и эксплуатации. Сейчас компания ищет тимлида на этот проект.

По образованию я физик. В университете для научной работы использовал Си и MatLab. Затем на работе нужно было использовать OpenText (OScript) и писать на JavaScript, а для хобби-проектов использовал Java. Программировать на Scala предложили на собеседовании, так как вся команда писала на этом языке. Моей первой задачей, реализованной на Scala, было написание коннектора к чат-серверу. В нём использовался публичный API социальной сети «Одноклассники», чтобы передавать сообщения к чат-серверу и обратно. Требования были такими: максимально быстрая передача сообщений, возможность для масштабирования и отказоустойчивость. В итоге коннектор был реализован мной с использованием набора библиотек Akka для разработки распределённых приложений и параллельных вычислений. В «Криптоните» я занимаюсь конструктором запросов для анализа большого количества данных. У нас в компании все продукты разрабатываются в рамках единой экосистемы, поэтому необходим сервис, который может их связывать. Конечная цель этого сервиса — возможность выстраивать компоненты для анализа различного типа данных (текст, изображение, аудио) в единую цепочку для их обработки. Коллеги из лаборатории больших данных и статистики приносят нам готовые ML-модели, а мы пишем на Scala сервис для конструктора запросов, который склеивает всё это в единый продукт.

Общие инструменты

Напомним, что Scala-разработчику доступны все JVM-библиотеки, написанные на Java, Kotlin и других. Поэтому в статье разберём только те инструменты, которые написаны на Scala или имеющие соответствующий API.

Основы языка

Изучение Scala с нуля стоит начать со стандартной библиотеки языка. Она сочетает в себе изменяемые и неизменяемые структуры данных, а предоставляемые ей интерфейсы используются во всех сторонних библиотеках.

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

Компиляция проектов

Несмотря на возможность сборки Scala-проектов с помощью gradle и maven, рекомендуем освоить работу Scala Build Tool. С помощью этого инструмента можно настраивать параметры компиляции проектов: выставлять необходимые флаги компилятора языка, разбивать проект на подмодули, осуществлять кросс-компиляцию с разными версиями библиотек и даже самого языка Scala.

Плагины компилятора

Scala позволяет не только гибко изменять и комбинировать программы, но и модифицировать этап компиляции проектов при помощи API для создания плагинов.

Предназначение плагинов компилятора может быть крайне разным. Например, плагины WartRemover и Scapegoat предоставляют инструменты для статического анализа кода, better-tostring изменяет поведение генерируемых по умолчанию функций, а Scala.js и Scala Native позволяют компилировать Scala-код для платформ, отличных от JVM.

Работа с консолью

Взаимодействовать со Scala-проектами можно не только путём их компиляции и последующего запуска, но и в интерактивном режиме при помощи Scala REPL. Эта консольная оболочка позволяет выполнять команды пользователя построчно. Использовать Scala REPL можно и на основе полноценных компилируемых проектов, и для интерпретации отдельных файлов.

Для работы с консолью также подходит Ammonite REPL. Это сторонний инструмент с бо́льшим числом возможностей по сравнению с оболочкой по умолчанию. Среди них — подсветка синтаксиса и динамическое подключение зависимостей.

Сериализация данных

Библиотеки для сериализации и десериализации данных применяются при синхронном взаимодействии сервисов с помощью API, при асинхронном взаимодействии с использованием очередей сообщений и при записи в файл или хранилище данных.

Хотя самый популярный формат сообщений для межсервисного взаимодействия — JSON, также активно используются Parquet, protobuf, Avro и CSV. Собрали наиболее крупные библиотеки для работы с этими форматами на Scala:

• avro4s — библиотека для взаимодействия с форматом Avro;
• ScalaPB — библиотека для генерации protobuf-сообщений;
• parquet4s — библиотека для работы с форматом Parquet;
• circe — одна из самых популярных библиотек для работы с JSON в функциональном стиле;
• uJson — минималистичная библиотека для работы с JSON;
• json4s — корневая библиотека, предоставляющая интерфейсы для работы с различными JSON-парсерами и сериализаторами.

Тестирование

Библиотеки для тестирования фокусируются на читаемости тестов и имеют синтаксис, близкий к обычному английскому языку.

Пример теста, написанного при помощи scalatest:

Основные фреймворки и библиотеки для тестирования:

• scalatest — фреймворк для тестирования кода, позволяющий гибко выбирать синтаксис написания тестов;
• specs2 — альтернатива scalatest с фокусом на behavior-driven тестах;
• scalacheck — обособленная библиотека тестирования кода путём случайной генерации входных данных. Имеет интеграции с основными фреймворками для тестирования;
• munit — библиотека для тестирования с акцентом на читаемости ошибок в тестах;
• uTest — минималистичная библиотека для тестирования.
• weaver test — библиотека для тестирования с использованием cats-effect.

Логирование и конфигурация

Конфигурация проектов в Scala зачастую осуществляется на основе файла application.conf, аналогично языку Java. Наиболее популярный формат конфигурации — HOCON. Он позволяет использовать переменные окружения и ссылки на другие элементы конфигурации при её описании. Для чтения конфигурации используют эти библиотеки:

• lightbend/config — библиотека без сторонних зависимостей, реализованная на языке Java;
• pureconfig — Scala-библиотека с возможностью автоматической конвертации конфигурации в классы приложения.

Библиотеки для логирования в основном базируются на Java-интерфейсах. Выбирать библиотеку стоит исходя из совместимости с фреймворком и уменьшения числа зависимостей, используемых в проекте. Основные библиотеки:

• scala-logging — высокопроизводительная библиотека-обёртка над slf4j интерфейсами;
• log4cats — библиотека для логирования в функциональном стиле с интеграцией с cats-effec;
• LogStage — оптимизированная библиотека для структурного логирования.

Полезные материалы для изучения Scala

Чтобы обучение языку Scala было максимально эффективным, следует запастись полезными ресурсами.

Списки Scala-библиотек:

• Scaladex
• Awesome Scala libraries

Telegram-каналы:

• Scala User Group — крупнейший русскоязычный чат для обсуждения языка Scala.
• Scala Learning & Education: Ask for Review & Noob questions — чат для начинающих изучать Scala.
• Scala Nishtyaki Channel — канал от создателей сообщества Scala_ru с публикациями статей, докладов и новостей из мира функционального программирования и Scala.

Книги:

Курсы и упражнения:

• Специализация Functional Programming in Scala
• Scala on Exercism
• Effective Programming in Scala
• Онлайн-книги с упражнениями от Underscore

Работа для Scala-программистов

Если вы готовы перейти с Java на Scala, держите подборку вакансий в «Криптоните». Компания занимается разработкой платформы частного облака с ML-технологиями для аналитики и бизнес-решений. Основной стек технологий компании: Scala, Typescript, Rust, Python, K8S, Spark, Kafka, ClickHouse, Scylla, Postgres, Vue.

Прямо сейчас «Криптонит» ищет:

• Developer
• Team Lead
• Стажёр-разработчик (Серверная разработка)
• Стажёр-разработчик (Data Engineering)

Переходите по ссылке и станьте частью команды!

Реклама АО «Научно-производственная компания «Криптонит» LjN8KWavY

Давайте рассмотрим, какой же рынок грузоперевозок сейчас в России. Официальные источники утверждают, что объем рынка в 2019 году достиг 900 млрд руб., они, конечно же не учитывают объем «серого» рынка, когда оплата происходит наличными. Хотя, введение самозанятости у водителей сильно обеляет рынок, но оплата «переводом на карту водителю» остается существенной и достигает 30%-40% от всего рынка.

Запуская свой стартап, мы ориентировались на рынок last mile, который, считается, что занимает до 70% от рынка грузоперевозок. Как принято говорить, это большой красный океан, в котором хотелось найти голубой ручеек.

Особенности запуска проекта

Для начала пришлось разобраться, как работает логистика на стороне клиента. Оговорюсь сразу, мы пошли в сегмент b2b и не хотели заниматься квартирными переездами, где пришлось бы конкурировать с небезызвестными крупными игроками, которые имеют огромные бюджеты на продвижение.

Итак, как же работали логисты в крупных и не очень компаниях. Мы назвали это «метод коленки», когда каждый вечер, в 18-00 садятся два менеджера-логиста и начинают раскидывать адреса доставки в excel так, чтобы успеть развести всем клиентам. Это упражнение они делают исходя из своего опыта, ни о каких технологиях и речи нет. Уверена, часть компаний так и остались в этой мезозойской эре.

На то есть причины: невозможно внедрять что-то новое в логистике, когда у тебя складская программа/бухгалтерия/crm написаны 10 лет назад группой программистов на аутсорсе, которых уже нет. И никто уже не знает, как работает их API, а программист на саппорте уныло разводит руками.

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

Выбор солвера для маршрутизации

Сейчас на рынке существует множество универсальных опенсорсных солверов Google OR-Tools, Choco-solver. В каждом есть функционал, который можно настроить для применения различных бизнес правил: вместимость авто, время подачи/загрузки, в нашем случае, даже была задача от клиента, что точку в Кремле можно было давать только одному водителю, т.к он уже прошел миллион проверок и по понятным причинам менять каждый день водителя никто не хотел. Ограничения от клиентов могут быть абсолютно не типовые.

Итак, свой выбор мы остановили на Google OR-tools, хотя был большой интерес еще к платному Gurobi, но на этапе стартапа сначала ты экономишь и тестируешь. Нам не хотелось лезть в промышленные солверы за большие деньги, тк был план разобраться сначала с тем, что дают бесплатно.

Чтобы «приготовить» OR-tools так, как нужно, пришлось разбить первоначальную задачу на подзадачи, чтобы соответствовать опциям и ограничениям от заказчиков. Процесс был не супер быстрый, солвер частенько тупил и выдавал «решение не найдено».  Как мы с этим справлялись?

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

В конечном счете мы смогли докрутить все параметры так, чтобы работало как часы.

Упаковка в продукт

Маршрутизация отдельно от всего, может быть прекрасным продуктом, но, если клиент не может это «поженить» со своими внутренними программами, если водители игнорируют использование приложения, нужно придумывать кастомные интеграции или делать продукт настолько полезным, что клиент сам побежит менять свою внутрянку так, чтобы можно было нормально синхронизироваться со всем остальным. Даже если это будет болезненно.

Как заставить клиента менять привычный метод «на коленке»? Мы добавили водителей.

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

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

Какие технологии мы использовали для создания такого продукта?

UI построили с помощью Typescript и кастомного UI фреймворка; этот подход упростил разработку мобильного приложения для водителей с использованием Apache Cordova. Бэкэнд реализовали на Scala и NodeJS (последний для более микросервисного подхода).

У нас используется множество внешних сервисов, такие как Firebase (для отправки push-уведомлений в Android-приложение); Контур помогает надежно обмениваться юридическими документами с B2B клиентами, Voximplant для организации управления звонками и подмены телефонных номеров; Smsaero для отправки уведомлений о выполнении заказов, с Банком 131 сделана API интеграция по массовым автоматическим выплатам исполнителям.

Все это позволяет нам к минимуму сводить человеческий труд.

Про водителей или без чего не будет успеха

Бизнесы по модели маркетплейса это всегда весы, когда нужно искать баланс. Мало заказов — водители моментально уходят и перестают использовать предложение, много заказов- водители находят в других приложения более выгодные/удобные по геолокации заказы и могут в последний момент отказываться от уже взятого.

Работа с водителями это большой продукт, которым нужно заниматься, продумывать систему обучения, мотивации и штрафов для водителей. Срыв поставки для B2B клиента это, как правило, потеря денег, репутации и клиент скорее всего к вам не вернется. Поэтому, от того, насколько лояльные водители будут работать в вашем сервисе зависит 80% успеха.

В завершении хочется сказать, что, собирая команду на логистический стартап, важно, чтобы у вас были не только айтишники, но и ребята с опытом в хардкорных классических ТК (транспортных компаниях).

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

В грузоперевозках работа с автопарками ГАЗелей в нашей модели, была несущественная, мы работаем с водителями напрямую. Это стратегическое решение, которое помогает держать цены ниже рынка. Когда у тебя 2000 водителей важно найти ключик, который поможет выяснить мотивацию, и, она, у ГАЗелистов не только денежная.

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

Мы — IT-вендор, разрабатывающий собственные продукты на базе Open Source проектов (Greenplum, Hadoop, Apache Kafka, Apache NiFi, ClickHouse и др.). В этом кратком обзоре речь пойдёт об инструментах и технологиях, которые используются в нашей компании для создания утилит и интеграционных решений на Java/Scala.

Технологический ландшафт

• Apache ZooKeeper — сервер для высоконадёжной распределённой координации приложений;
• Apache Spark — фреймворк с открытым исходным кодом для реализации распределённой обработки неструктурированных и слабоструктурированных данных, входящий в экосистему проектов Hadoop;
• Apache Kafka — распределённый программный брокер сообщений;
• Apache NiFi — ETL-инструмент с открытым исходным кодом;
• ClickHouse — колоночная аналитическая СУБД (Яндекс);
• Tarantool — система управления in-memory БД (база данных) с неблокирующим сервером (Mail.ru Group);
• Greenplum — массивно-параллельная СУБД для хранилищ данных на основе PostgreSQL.

Инструменты

• YourKit Java Profiler — для профилирования процессора и памяти Java;
• SonarQube — для анализа качества программного кода;
• Git — система управления версиями;
• SBT — система автоматической сборки для Java и Scala;
• Apache Maven и Gradle — для автоматизации сборки проектов;
• Jenkins — для обеспечения процесса непрерывной интеграции программного обеспечения;
• Portainer — для управления Docker-контейнерами;
• Docker — программа для автоматизации развёртывания и управления приложениями и контейнеризации приложений;
• Docker Compose — для запуска и управления Docker-контейнерами.

Библиотеки и фреймворки

• Spring Framework — универсальный фреймворк как основа для наших Java-приложений;
• Lombok — проект по добавлению дополнительной функциональности в Java c помощью изменения исходного кода перед компиляцией;
• Vert.x — фреймворк для реализаций реактивных сервисов;
• Apache Calcite — фреймворк для синтаксического анализа и построения SQL-выражений, а также для планирования запросов;
• JUnit — фреймворк для написания юнит-тестов;
• Akka, Akka HTTP, Akka Streams — набор инструментов для создания параллельных, распределённых и отказоустойчивых приложений для Java и Scala;
• Finagle — расширяемая RPC-система от компании Twitter для построения высоконагруженных систем;
• ScalikeJDBC — библиотека для доступа к БД с помощью JDBC;
• ScalaTest, TestContainers — для написания unit и интеграционных тестов;
• Spark (Core, Streaming, SQL) — для реализации коннекторов к различным источникам данных.

Для работы с фреймворком Spring также может быть полезен Spring Boot. Это проект, который упрощает создание приложений на основе Spring.

У нас есть статья, которая знакомит со Spring Boot на примере разработки простого веб-приложения.

Рассмотрим классический пример наследования, когда требуется реализовать два класса типа «Прямоугольник» и «Квадрат». Известно, что у каждой фигуры есть периметр и площадь. Будем считать, что объект мутабельный (mutable ― изменчивый) и имеет соответствующие методы (свойства) для изменения размеров. Достаточно легко обобщить формулу для вычисления площади и периметра таких фигур, и, кажется, логично будет использовать наследование. Кто в такой модели должен быть родительским классом, а кто ― потомком?

Казалось бы, со школы мы помним, что квадрат ― частный случай прямоугольника, а значит, квадрат наследует от прямоугольника.

Пока все просто. Но что же произойдёт, если мы попытаемся создать «частный случай прямоугольника»? Ведь у квадрата по определению width == height. Конечно же, можно использовать приватную переменную, и при модификации ширины менять и высоту фигуры соответственно, но, если задуматься ― а насколько это ожидаемо? Если квадрат ― наследник прямоугольника, то пользователь должен иметь возможность использовать квадрат точно так же, как и прямоугольник. Может ли пользователь предположить, что при установке ширины прямоугольника автоматически поменяется и его длина?

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

Пока выглядит неплохо. Однако, пользователь знает, что площадь квадрата ― квадрат его стороны. Может ли пользователь ожидать, что, установив сторону квадрата в 5, например, он не получит 25 только потому, что его квадрат на самом деле прямоугольник?

Хорошим дизайном вашей модели будет являться такая, в которой не будет исключений и подводных камней. По идее, только посмотрев на сигнатуру интерфейса, вы должны иметь возможность сказать, как экземпляр этого класса себя будет вести и что от него стоит ожидать. Эта идея носит гордое название «принципа замещения Барбары Лисков» или LSP. Можно грубо сказать, что LSP — это такой ad hoc полиморфизм, при котором класс-потомок никогда не врет.

Когда полиморфизм может сделать больно

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

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

Подчеркну, что страшно не само по себе нарушение принципа, в конце концов программирование — это раздел инженерии, и вся наша работа состоит в выборе подходящего компромисса — а то, что такое поведение крайне трудно предсказать: откуда разработчику знать, что метод, который он вызовет, выбросит Exception? Обратите внимание, что такое исключение неожиданно и не может быть предсказано исходя из здравого смысла — ведь рядом может лежать другая имплементация, которая не имеет подобной проблемы. Некоторые ЯП имеют checked exception, но практика показывает, что их проще завернуть в unchecked, чем пытаться поддерживать. Как следствие, логическая сложность программы с подобным code smell растет неоправданно, и становится все сложнее понять, какая из N имплементаций сервиса будет работать как ожидается, а какая ― нет.

При проектировании модели можно услышать советы вроде «придерживайся tell-don’t-ask», «используй null-object-pattern», или даже «prefer composition over inheritance», которые в целом могут помочь увернуться от описанной проблемы. Последний совет, кстати, вообще несколько неочевиден — не использовать наследование в ООП специфичном языке.

Я предлагаю посмотреть в корень — и он в том, что данные хранятся вместе с поведением. В нашей жизни мы часто думаем об окружающих вещах как об объектах, поэтому такое положение дел кажется более или менее естественным. С другой стороны, при достаточно большой и сложной доменной области наследование может начать нести некоторую опасность ― ведь описать формальным языком поведение, не нарушая LSP, бывает очень сложно. На мой взгляд, эта проблема возникает в первую очередь из-за того, что в реальной жизни мы, скорее, создаем свою иерархию наследований под каждый конкретный случай, тогда как при проектировании доменной области зачастую стараемся сделать из объекта некий «швейцарский нож», обладающий разным и порой никак не связанным друг с другом поведением — потому что чем меньше вспомогательных сущностей мы имеем, тем проще понять модель.

«Не узнаю вас в гриме»

Вторая проблема более характерна для строго типизированных языков, где, имея список каких-то объектов, приведенных в базовому типу, нужно проверять тип каждого элемента, чтобы вызвать специфическое поведение. Например:

Такое часто можно встретить при вызове сторонних библиотек, или если у вас legacy. Некоторые языки программирования даже имеют более или менее стандартную функциональность, чтобы работать с базовыми типами, проверяя их конкретную реализацию в рантайме, что ломает сразу двух из трех китов ООП ― и полиморфизм, и инкапсуляцию. Например, если вы счастливый программист на Scala ― у вас есть pattern matching. С другой стороны, никто не мешает сделать своего китоломателя на минималках, и это и есть — Visitor.

Идиоматичный Visitor

Идея достаточно простая — вместо того, чтобы объявлять поведение внутри класса, мы делегируем это поведение некоторому внешнему объекту. При этом объект-делегат называется посетителем (Visitor), и в нем должны быть объявлены методы посещения для каждого конкретного типа из иерархии. Экземпляр такого объекта мне нравится называть глаголом, описывающим нужный эффект, тем самым подчеркивая, что визитор — скорее поведение, отделенное от данных, чем полноценный объект (makeSomething vs somethingMaker).

Пора посмотреть, как могла бы выглядеть реализация паттерна:

Приведенный пример легко можно переделать, чтобы собирать только фастфуд (Sausage) или сериализовать в json, или добавлять любое другое поведение в существующую иерархию объектов. В этом самое большое преимущество паттерна.

А вот недостатком будет многословность и не слишком большая очевидность. Для каждого потомка Tasty придется делать реализацию visit, а в самом TastyVisitor ― сделать соответствующий метод.

К тому же этот шаблон не получится использовать, если нет контроля над существующим деревом объектов ― то есть если нельзя внести соответствующие изменения в существующую иерархию.

Рекомендация

Если у вас уже есть не слишком большая цепочка доменных классов, которые могут использовать в разных сценариях — задумайтесь о том, а не нарушите ли вы принцип единичной ответственности уже сейчас, и не выйдет ли так, что полиморфное поведение будет больше мешать, чем помогать? И если все-таки не хочется иметь разные доменные модели под каждый конкретный сценарий использования, например, потому что они будут на 99% совпадать, то может быть имеет смысл отделить данные от поведения — и Visitor в таком случае может сослужить хорошую службу. Ценой одного дополнительного интерфейса на этапе проектирования и изменением привычного способа взаимодействия с классом модели вы сможете добавлять любое необходимое поведение в типобезопасной манере, и каждый такой метод будет изолирован от других. Получается, что соблюдается и принцип единичной ответственности, и LSP не нарушается.

Кроме того, мы привели базовое введение в Scala, мультипарадигменный язык программирования с широкой поддержкой функционального подхода. В предыдущей статье вы можете ознакомиться с базовыми понятиями языка и узнать, как настроить окружение.

В этой части мы расскажем об ООП-модели Scala и о некотором синтаксическом сахаре, специфичном для языка Scala.

Основы модели ООП

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

Класс в Scala объявляется следующим образом:

и инстанцируется при помощи конструкции new ClassName(field1, field2, … , fieldN).

Параметры, введенные скобках после имени класса, являются private полями класса, однако можно изменить их область видимости: если нужно иметь доступ на чтение извне, перед именем поля нужно поставить модификатор val, а если нужно чтение и запись — модификатор var. Классы являются ссылочными типами и неявно наследуют базовый класс AnyRef. Поэтому присваивание объекта с мутирующими (var) полями другой переменной только копирует ссылку.

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

Внутри класса можно вводить многие вложенные структуры для внутреннего использования. По умолчанию все переменные, постоянные и методы, объявленные в теле класса, — публичные. Их можно защитить при помощи модификаторов private и protected. С другой стороны, вложенные классы недоступны извне.

Другой ООП-сущностью является trait. В отличие от класса, trait не может иметь конструктора и не может быть инстанцирован. Кроме того, он может содержать абстрактные методы, в то время как класс — только если помечен модификатором abstract.

Синтаксис трейта таков:

Ещё одна ООП-сущность, с которой вы столкнулись в предыдущей статье, — object.

Его отличительной чертой является то, что он имеет единственный экземпляр, создаваемый автоматически, иначе говоря, является синглтоном. Только обжект может быть точкой входа в программу. Кроме того, вы можете импортировать его вложенные типы, методы, значения в область видимости другого файла. Это позволяет использовать обжект как средство структурной организации программы, давая возможность группировать константы и статические методы.

Наследование в Scala имеет некоторые особенности. Во-первых, практически всё может наследовать от нескольких trait при помощи синтаксиса extends trait1 with trait2 with trait3 ... with traitN.

Именно это явление вы видели в начале статьи:

Здесь App — предопределённый трейт, оборачивающий содержимое внутрь метода main.

Зачем нужен синтаксис extends … with … with …? Разве нельзя обойтись одним ключевым словом? Увы, нет. Если же разрешить множественное наследование (с наследованием реализации), то появляется проблема ромбовидного наследования. В Scala эта проблема решена определением главного трейта, реализация которого и наследуется. Этот главный трейт идёт первым после слова extends (к слову, это может быть вовсе не трейт, а класс или абстрактный класс).

Кроме того, вы не можете наследовать типы от объекта.

На самом деле, вы можете создать анонимный класс-наследник трейта, реализовав все его абстрактные методы используя функционал анонимных классов, и далее создать его экземпляр:

Но писать такой код бывает достаточно громоздко. Для этого были введены обжекты-компаньоны (companion object). Для них нет специального ключевого слова, поэтому, чтобы их определить, вам нужно создать в файле с классом (или трейтом) обжект с таким же именем, как у класса. У обжекта-комапньона вы можете определить метод apply:

Тогда вы можете создавать «экземпляры» трейта при помощи синтаксиса Foo.apply(1).

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

Foo(1)

Подобное можно делать и с классами. Отметим, что семантика метода apply может значительно отличаться от приведённого примера, ведь никто вас не ограничивает в том, что будет делать этот метод. Эта особенность активно используется как в стандартных библиотеках, так и в сторонних.

Параметрические типы

В Scala есть возможность параметризовать трейт, класс или его метод некоторым количеством типов. Делается это при помощи такого синтаксиса:

Вы можете использовать параметры типа внутри тела метода/класса/трейта разными способами. Например, вы можете написать функцию, которая будет вычислять композицию 2 функций:

def compose[U, V, W](f: U => V, g: V => W): W = (x :U) => g(f(x))

На этом примере мы можем продемонстрировать ещё одну особенность системы типов Scala — она может выводить параметры-типы шаблонов. Например, если мы введём две функции

то мы можем вычислить их композицию, не указывая цепочку типов:

val f = compose(fromIntToDouble, fromIntToString)

Что на самом деле эквивалентно:

val f: Int => String = compose[Int, Double, String](fromIntToDouble, fromIntToString)

Параметрические типы — мощное средство доказательства свойств программы — в том числе типобезопасности. Например, у вас в базе данных хранятся объекты двух типов A и B. Вы не хотите, чтобы кто-то мог добавить объект типа А в коллекцию элементов B (допустим, ваша БД нереляционная, например, MongoDB, и позволяет такое) или же не пытался записать элемент в несуществующую коллекцию. Вы можете написать метод добавления в коллекцию вот таким образом:

В этом примере вы сможете добавить элемент в коллекцию соответствующего типа. Попытка добавить элемент типа А в коллекцию элементов типа B вызовет ошибку компиляции, и, скорее всего, IDE предупредит вас об этом ещё на этапе написания кода.

Вы можете создавать псевдонимы для параметрических типов, если вы задали в них все или несколько параметров. К примеру, вы можете ввести список строк:

type String = List[String]

Или же, например, кортеж, один из параметров которого — целое:

type TypInt[T] = (T, Int)

Хотя на этом возможности системы типов Scala и не завершаются, дальнейшее повествование выходит за рамки нашего введения.

Кейс-классы и сопоставление с шаблоном

Оператор switch во многих языках воплощает задумку классификации данных на несколько категорий. Но большинство реализаций не могут поддерживать классификацию объектов, и поэтому редко используются в программах. В Scala есть очень мощная система сопоставления объекта с образцом. Однако экземпляр далеко не каждого класса можно сопоставлять с образцом без лишних телодвижений. Для упрощения этого процесса были введены два специальных вида сущностей: кейс-классы (case classes) и кейс-обжэкты (case objects). Кейс-классы подобны именованным кортежам, используемым для хранения данных. Часто они могут не иметь своих методов, выступая пассивными контейнерами, ведь Scala предоставляет великое множество других методов взаимодействия. Итак, синтаксис кейс-класса таков:

case class CaseClasName(parameterList) { /*опциональное тело класса*/ }

Все поля кейс-класса немутирующие и публичные. Это не является нарушением принципа инкапсуляции, поскольку он неприменим к публичным параметрам кейс-класса. Инкапсуляция полей имеет место, когда поля класса должны меняться некоторым сложным взаимосвязанным образом, и поэтому изменение полей должно производиться через методы класса. Здесь же нет никакого изменяемого состояния (мы крайне не рекомендуем его вводить в теле класса, чревато неожиданными последствиями), и инкапсулировать нечего. Инстанцировать экземпляр кейс-класса можно удобным синтаксисом:

CaseClasName(parameter1, parameter2, … , parameterN)

Примечание Здесь «под капотом» находится автоматически сгенерированный метод apply для этого класса, позволяющий пользоваться таким синтаксисом.

Пример:

Второй тип сущностей, case object, похож на case class, но не имеет полей. Зачем же он тогда нужен? Для создания строго типизированных перечислений.

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

Каким образом работает сопоставление с шаблоном (pattern matching)? При помощи следующего синтаксиса:

Шаблоны могут быть очень разнообразными в зависимости от используемого типа данных.

Кейс-класс в сопоставлении с шаблоном можно разложить на его параметры при помощи «вызова конструктора» этого кейс-класса. Например, приведенному выше классу User будет соответствовать шаблон User(name, email). Здесь переменные name и user извлекаются из объекта класса User и после этого становятся доступны блоку value, следующему за =>. Кроме того, вы можете ввести переменную для обозначения объекта, сопоставляемого с образцом, при помощи символа @. Например, такой шаблон введёт переменную user для блока value:

user @ User(name, email)

Ещё одной полезной особенностью сопоставления с образцом является возможность зафиксировать некоторые поля класса или же, наоборот, игнорировать некоторые из них.

Например, мы можем выбирать пользователя только с именем «dave» шаблоном User("dave", email). Если же нам безразличен email пользователя, мы можем не вводить переменную для этого поля шаблоном User(name, _).

Стоит отметить, что сопоставление с образцами происходит в порядке их расположения. Если шаблон User(name, email) находится выше шаблона User("dave", email), то сопоставления с последним никогда не произойдет, потому что первому из шаблонов соответствует любой экземпляр класса User.

Если же вам не нужны поля класса, а нужно просто соответствие по типу, используйте шаблон вида valName: TypeName.

Кроме того, существует шаблон «_», которому удовлетворяет любой объект.

Результат сопоставления с образцом — значение, возвращённое из value, приведенное к общему надтипу всех блоков value1, … valueN.

Если ни одному из шаблонов значение не соответствует, выбрасывается исключение PatternMatchingException.

Приведем пример, объединяющий написанное выше:

На самом деле, сопоставление с образцом можно применять не только на кейс-классах. На всех типах-примитивах (числа, строки, символы, …), и типов, для которых определён метод-экстрактор. Например, вы можете сопоставлять строку с регулярным выражением. Просто создайте несколько регулярных выражений и применяйте сопоставление с шаблоном:

Такие действия можно осуществлять, определяя метод unapply и объект-экстрактор. Подробнее об этом можно прочитать в документации. Экстрактор имеет ещё одно полезное применение: с помощью него можно распаковывать кейс-классы и другие классы, имеющие экстрактор, используя точно такой же синтаксис, как вид шаблона в сопоставлении с образцом:

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

Сахар, сахар и ещё раз сахар

В этой части мы опишем дополнительный синтаксический сахар, относящийся к функциям.

Многие функции стандартной библиотеки Scala принимают в качестве параметра другие функции. Например, у списка (List) есть функция map, которая совершает преобразование над каждым его элементом, сигнатура которой упрощенно выглядит так:

def map[B](f: A=>B): List[B]

Допустим, у нас есть список целых чисел и нам нужно прибавить к каждому из элементов единицу. Мы могли бы сделать это при помощи лямбда-выражения:

И получили бы список:

List(2, 3, 4, 5, 6)

Но Scala для подобных случаев имеет более лаконичный синтаксис:

list.map {_ + 1}

Здесь на место подчёркивания будет подставлен элемент списка. Сокращение в виде подчёркивания может использоваться в самых неожиданных местах, но общая идея его использования — исключение имени переменной там, где можно восстановить однозначным образом манипуляцию над данными, которую вы хотите описать. Например, там, где требуется функция типа (Int, Int) => Int, вы можете передать суммирование при помощи синтаксиса _ + _. Однако, не всюду такой сахар будет работать, и тогда нужно будет пользоваться обычными лямбда-выражениями. Лямбда-выражения хорошо работают, когда у функции аргументы не запакованы ни в какие обёртки. Если же мы рассмотрим функцию, принимающую функцию из кортежа целых чисел в целое:

def f(g: Tuple[Int, Int] => Int) = ???

То мы не сможем сделать вызов при помощи удобного синтаксиса:

f { (i1, i2) => i1 + i2 } // ошибка компиляции

Функция должна переводить из одного параметра кортежа в целое:

f { t => t._1 + t._2 } // верно

Но такой синтаксис недостаточно выразителен, поэтому для этих целей существует некоторого вида сопоставление с шаблоном. Вообще, синтаксис case <шаблон> if => value задает частично определённую функцию (partial function). Частично определённая функция, действующая из некоторого набора данных A в набор данных B, отличается от обычной функции тем, что она может быть определена не для всех возможных значений из A. Например, функция извлечения арифметического квадратного корня является частично определённой для всех вещественных чисел от 0 до +∞. Компилятор Scala умеет определять, является ли частичная функция обычной. Если же он обнаружит, что в сопоставлении с шаблоном вы описали не все случаи, он выдаст вам предупреждение с примером входных данных, которые могут выбросить PatternMatchingException.

Следующая порция синтаксического сахара Scala — ассоциативность операторов. Оператором в Scala называется нестатический метод, который принимает один параметр. Существует два типа операторов: правоассоциативные и левоассоциативные, если вызывать их через точку, то различия нет, но зато, при использовании сокращенного синтаксиса без точки, семантика записи a op b меняется. Правоассоциативные операторы можно вызывать подобным образом:

a1 op1 a2 op2 a3 … opN-1 aN

Что эквивалентно записи:

( ... ((a1.op1(a2)).op2(a3)) …).opN-1(aN)

Что вполне неплохо сокращает количество скобок. К примеру, мы можем последовательно вызывать метод преобразования элементов списка:

List(1, 2, 3) map { _ + 1 } map { _ * 2 } map { _ - 1 }

И это будет эквивалентно записи:

((List(1, 2, 3).map { _ + 1 }).map { _ * 2 }).map { _ - 1 }

Левоассоциативные операторы можно вызывать похожим способом:

a1 op1 a2 op2 a3 … opN-1 aN

Но это будет эквивалентно совсем другой записи:

(...((aN.opN-1(aN-1)).opN-2(aN-2))...).op1(a1)

Левоассоциативные операторы отличаются от правоассоциативных наличием символа «:» на конце. Например, вы можете создавать список, вызывая метод пустого списка (Nil) :::

1 :: 2 :: 3 :: 4 :: 5 :: Nil,

что будет эквивалентно:

((((Nil.::(5)).::(4)).::(3)).::(2)).::(1)

И создаст список:

List(1, 2, 3, 4, 5)

Для унарных и некоторых бинарных операторов существует постфиксная нотация, например, когда у вас нет никаких параметров к методу, вы можете написать value methodName вместо value.methodName.

Так, например, в стандартной библиотеке в пакете scala.concurrent.duration устроены конструкторы промежутков времени. Вы можете написать:

На самом деле, вы будете вызывать методы:

Другое дело, что у обычного Int нет методов second, minutes и milis. Эти методы добавлены к нему при помощи специального механизма методов расширения, о которых мы поговорим в следующей части.

Некоторые разработчики критикуют возможность создания DSL (Domain Specific Language) прямо внутри языка. Один из основных пунктов критики — код становится непонятным и нечитаемым, разобраться в стрелочках и прочих закорючках становится довольно сложно.

На самом деле эта критика происходит из неправильного использования DSL: разработчики пытаются создавать предметно-специфический язык, чётко не выделив предметную область.

Для того чтобы строить полезные и понятные DSL, нужно строго определить область, для которой создаётся язык. Например, стандартная библиотека предоставляет DSL для работы с последовательностями. Далее нужно использовать отличимые и интуитивно понятные символы, и если таких нет, не стесняться использовать слова. Например, использовать -~> и ~-> в одном языке — не самая хорошая идея.

На самом деле, правильно написанные DSL позволяют сильно сокращать количество написанного кода и делать его более идиоматическим.

Заключение

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

Большинство приложений в мире написано в традициях ООП (объектно-ориентированного программирования) и использует императивный код. Несмотря на то, что объектно-ориентированный подход очень популярен и прост для понимания, он не лишён своих недостатков.

Недостатки ООП

Во-первых, в большинстве языков высокого уровня обработка ошибок реализована с помощью механизма исключений. Идея о том, что выполнение кода нужно прерывать, как только достигнуто некорректное состояние, хороша, но её реализация в виде выброса исключения и перехвата его в другом месте требует от коллектива программистов железной дисциплины. Иначе простая линейная цепочка вычислений превратится в древообразную, а то и в запутанный граф. Функциональная парадигма предоставляет абстракции для простой и прозрачной обработки ошибок.

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

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

Функциональный подход

В функциональном программировании решили подойти с другой стороны. Во-первых, решили отказаться от возможности изменять переменные настолько, насколько это возможно (существуют фундаментальные ограничения, не позволяющие сделать это полностью). Функция в смысле информатики не является функцией в смысле математики: например, функция датчика случайных чисел (на основе физического датчика) не является математической функцией — она не принимает параметров, и потому, с точки зрения математики, должна быть константой, но каждый раз эта функция выдаёт разный результат. Такого в математике не бывает. Если же мы запретим переменным изменяться, то есть уничтожим глобальное изменяемое состояние, то функции станут действительно математическими, и можно будет построить строгую математическую теорию. Такая теория была построена и ныне носит название λ-исчисления. Эта теория описывает типы и полиморфизм.

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

Монады бывают двух видов. Первый вид — «чистая» монада, она представляет корректные данные. Второй вид — некорректная монада, она нужна для представления некорректных данных. Над этими двумя типами данных определены операции:

1. pure — функция создания «чистой» монады.
2. flatMap — применение преобразования, которое может привести к некорректному результату. К примеру, операция деления целых чисел будет корректно обрабатывать все данные, кроме деления на 0. В этом случае будет создана некорректная монада и применение к ней операции flatMap её не изменит.
3. map — применение к данным операции, которая не может вызвать исключений по своей природе, например, операции сложения.

Важно понимать, что функциональное программирование занимает нишу в середине между низкоуровневыми операциями и очень высокими уровнями абстракции — например, такими, как уровень сервисов или приложений. Исходя из этого был создан объектно-функциональный стиль, позволяющий использовать императивный код для низкоуровневых функций, чистый функциональный код в середине приложения и паттерны проектирования и прочие ООП-технологии на наивысшем уровне абстракции. Таким образом, функциональный подход лучше применять не для создания замкнутых систем, а скорее для слоёв приложений и описания бизнес-логики. Именно в таком ключе функциональное программирование и применяется на сегодняшний день — построенное над низкоуровневым императивным кодом, внутри объектных абстракций.

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

В этой статье будут описаны фундаментальные языковые конструкции и некоторые средства сокращения кода.

О Scala

Изначально язык Scala был разработан Мартином Одерски (который также работал над Generics в Java и над компилятором Javac) в EPFL. Первая версия языка была выпущена в мир в 2004 году на платформе Java. Нынешняя версия языка (2-я) имеет версии для платформ JavaScript (Scala-js) и под LLVM (Scala Native).

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

Язык был оценен по достоинству крупными корпорациями: например, он активно используется в Twitter, LinkedIn, Netflix, Sony и других.

Установка IDE и SBT

Чтобы использовать Scala под платформу Java, вам понадобятся установленные JRE и JDK. Для знакомства с языком разумно использовать IDE IntelliJ IDEA Community Edition со специальным плагином Scala Plugin (доступен прямо при установке IDE) и систему построения проектов SBT (есть под большинство ОС, скачивается при создании проекта).

Примеры из статьи можно запускать, используя онлайн-компилятор Scalastie.

Для того чтобы создать ваш первый проект, нужно сделать следующее:

new project → scala → sbt

В меню создания проекта нужно выбрать версию SBT и Scala, последними на момент написания статьи являются 1.2.1 и 2.12.6 соответственно.

После нажатия кнопки создания проекта IDEA отдаст указание о создании проекта SBT (это можно понять по надписи dump project structure from SBT), поэтому структура папок проекта появится не сразу.

После формирования проекта вы можете увидеть подобную структуру папок:

Нас в основном будут интересовать папка src и её подпапки main/scala и test/scala, а также файл build.sbt. Файл build.sbt описывает всю структуру проекта и используется для определения модулей, подмодулей, управления зависимостями и версиями библиотек. Сюда же стоит дописывать импорты сторонних библиотек.

В папке main/scala нужно создать new scala class и выбрать там object (о том, что это такое и какую роль он играет в Scala, будет сказано ниже). Обратите внимание, что имя обджекта должно совпадать с именем файла, в котором он расположен, иначе вы можете столкнуться с ошибками при попытке запустить вашу первую программу.

После создания обджекта вы увидите следующий код:

В теле обджекта нужно создать точку входа в программу, а именно метод main() (в Scala методы объявляются ключевым словом def), автодополнение IDEA предложит вам сгенерировать метод как только вы начнёте набирать def main. В итоге должен получиться такой код:

Если же вам не нужны параметры командной строки args, вы можете сократить свой код до:

Отметим несколько отличительных особенностей: во-первых, в списке параметров сначала идут имена параметров, а потом их типы после двоеточия, во-вторых, тип возвращаемого значения указывается через двоеточие после списка параметров (в Scala все функции всегда возвращают значение, но когда необходимости в этом нет, используется тип Unit — это аналог ключевого слова void, указывающий на отсутствие какого-либо возвращаемого значения).

Добавив строчку println("Hello world"), вы сможете запустить эту программу, нажав на зелёный треугольник напротив метода main. Если всё сделано правильно, в консоли должна появиться строка «Hello world».

Мы настоятельно рекомендуем всем любителям чистых текстовых редакторов на этапе знакомства с языком пользоваться IDEA (пусть это и противоречит философии Unix). Scala содержит большое количество достаточно хитрых конструкций, поддержку которых редко когда можно встретить в редакторе. Кроме того, у IDEA есть много полезных языко-специфических функций. С их помощью IDEA может спасти вас от некоторых глупых ошибок ещё во время написания кода.

Переменные

В языке Scala есть 2 типа переменных — val и var.

val — это неизменяемая переменная, ей можно присвоить значение только при инициализации. Синтаксис введения постоянной выглядит так:

val valueName: TypeName = value

Опять же, как и у параметров функции, имя постоянной находится сначала, а имя типа — после двоеточия, за именем постоянной. В Scala существует продвинутая система типов, поэтому в большинстве случаев вы можете опускать имя типа, компилятор выведет его за вас (IDEA тоже это умеет, поставьте курсор на имя переменной и нажмите Ctrl+Q).

Для того чтобы объявить переменную, вам нужно использовать ключевое слово var:

var valueName: TypeName = value

Как и в случае постоянной, тип в большинстве случаев можно опускать.

Переменные можно объединять в кортежи при помощи удобного синтаксиса запаковки в кортеж:

val tuple: (Type1, Type2, ... , TypeN) = (val1, val2, … , valN )

И распаковки из кортежа:

val (val1: Type1, … valN: TypeN) = tuple

Здесь типы тоже можно опускать, сокращая код до:

val tuple = (val1, val2, … , valN )val (val1, … val2) = tuple

Методы

Для определения методов используется ключевое слово def. Синтаксис для определения метода выглядит так:

В определении вы наверняка не увидели слово return. Это потому, что последнее значение в функции является возвращаемым. То же самое касается и оператора if: вопреки принятой в императивных языках логике, оператор if (condition) value_if_true else value_if_false имеет возвращаемое значение, имеющее тип, общий над value_if_true/value_if_false и значение, в зависимости от условия равное value_if_true/value_if_false.

В функциях не обошлось без синтаксического сахара. Если функция не принимает параметров, то вы можете не писать скобки. Кроме того, можно не указывать тип возвращаемого значения. Как и в случае с переменными, тип будет выведен (в IDEA этот тип будет напечатан фантомным текстом). Ещё одна «сахарная» особенность — если тело метода достаточно короткое и содержит всего лишь одну инструкцию, вы можете не писать фигурных скобок. Например, такой код будет абсолютно корректен:

def five = 5

Хотелось бы отметить, что функция может быть значением и при этом будет иметь функциональный тип, который записывается как SourceType => ResultType.

К примеру, функция, которая увеличивает число на 1 (здесь num + 1 — возвращаемое значение, а Int — его тип):

def inc (num: Int) = num +1

будет иметь тип Int => Int.

Тогда мы можем ввести постоянные, значениями которых будут наши функции:

val incFunc: Int=>Int = inc

В чём же разница между val и def? Дело в том, что значение val вычисляется однажды и дальше используется при каждом упоминании, а значение типа def вычисляется каждый раз при упоминании. Проверить это можно следующим фрагментом кода:

Первые две строчки вывода будут совпадать, а вторые две — различаться.

Если же у функции много входных параметров, тип можно записать так:

(Type1, Type2, … TypeN) => ResultType

К примеру, функция сложения двух чисел:

def add(a: Int, b: Int) = a+b

будет иметь тип: (Int, Int) => Int.

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

Для функций существует синтаксический сахар, позволяющий создать функцию, не вводя для неё отдельного метода. Он может быть вам знаком, потому как присутствует в других языках:

(argument_list) => value

value вполне может быть блоком, в котором вы можете вводить дополнительные переменные и совершать некоторые действия. Примеры:

Поскольку для функций существует тип, мы можем создавать функции от функций, то есть функции высшего порядка. Для этого достаточно просто дописать параметру функциональный тип. К примеру, можно написать функцию, которая к двум числам применяет заданное преобразование:

def transform (a: Int, b: Int, f: (int, Int) => Int): Int = f(a,b)

Есть ещё один нюанс, связанный с функциями. Существует 2 семантики передачи параметров: call by name и call by value. Call by value используется по умолчанию: значение сначала вычисляется, а потом передаётся в функцию. Call by name, наоборот, сначала передаётся в функцию, а потом вычисляется в каждом месте упоминания. Для указания этой семантики перед типом ставится знак =>. Продемонстрировать это можно следующим примером:

Вы должны получить следующий вывод: 1 1 1 2 3 4. Таким образом, если вы хотите передать в функцию генератор случайных чисел, вы должны использовать семантику callByName.

Заключение

Мы познакомились с основами языка программирования Scala: рассмотрели, как настроить окружение, как вводить переменные, функции. Мы также рассмотрели два вида семантики методов — callByName и callByValue.

В следующей статье мы рассмотрим объектную модель языка Scala и некоторые особенности, связанные с синтаксическим сахаром.

Неявные преобразования и использование аргументов

В новой версии редактор кода обзавелся удобными функциями работы с неявными действиями:

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

Включить встроенные подсказки в Windows можно по сочетанию клавиш Ctrl + Alt + Shift + «+».

Кроме того, разработчики также добавили информацию о неявных преобразованиях в действие Parameter Info Tooltip (Ctrl/Cmd + P) и научили команду Implicit Arguments Popup (Ctrl/Cmd + Shift + P) показывать тип, структуру и местоположение аргументов.

Автозаполнение

Обновленный плагин IntelliJ Scala генерирует исчерпывающее соответствие для закрытых типов с наследниками, Java Enums и Scala Enumerators. Более того, список автозаполнения теперь содержит шаблон unapply(...):

Семантическое подсвечивание

Новую функцию можно подключить и изменить под свои нужды в настройках редактора IDE. Раскраске подверглись параметры функций и различные типы переменных. Подсвечивание помогает отслеживать определенную переменную или ее изоляции:

Scalafmt

Разработчики объединили модуль форматирования Scalafmt, существовавший как отдельный плагин, с IntelliJ Scala. Он может использоваться вместо стандартного модуля IntelliJ, и, в отличие от него, не имеет множества вкладок с настройками, а передает их в файле .conf. Определить, какой из этих файлов будет являться активным файлом конфигурации, можно в настройках редактора:

Другие изменения

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

Scala развивается и становится популярнее в том числе из-за того, что он похож на Java и может использоваться в качестве его замены. По результатам майского рейтинга ЯП TIOBE Scala вернулся в топ-20 спустя несколько лет отсутствия.

У этого инструмента единственная цель — максимально сократить время сборки без ущерба для корректности исполнения. При изменении исходного кода Zinc анализирует все зависимости и компилирует подмножество исходных файлов, на которые оказали влияние внесённые правки. Таким образом сгенерированный код получается абсолютно идентичным выходу чистой компиляции.

3 ноября разработчики представили новую, усовершенствованную версию компилятора — Zinc 1.0.

Ключевая особенность v1.0 — анализ зависимостей на основе классов. Этот механизм был разработан для более рафинированной обработки зависимостей, исключающей общие случаи излишней компиляции. Сравнительные тесты показали, что новый механизм сокращает процесс сборки до 40 раз.

Пример семикратного увеличения скорости

И что же в ней такого особенного? Для сравнения были взяты две версии Zinc: 0.13.x и 0.1.x.

Исходные данные: ScalaTest, основной модуль которой состоит из 40 377 строк кода на Scala (не считая комментариев и пустых строк).

Испытание: обычная операция в любой кодовой базе — добавление метода.

В данном случае стоит задача добавить новый метод к классу с большим числом зависимостей (вроде AndHaveWord в Matcher.scala) после корректного «разогрева» компилятора и компиляции проекта.

Насколько быстро с этим справится v0.13.x?

Инкрементальная компиляция заняла у нее 21 секунду. Настала очередь нового алгоритма.

Эта версия завершила перекомпиляцию всего лишь за 3 секунды. В данном примере Zinc 1.0.0 оказался быстрее своего предшественника в 7 раз.

Подобные эксперименты дают совершенно разные результаты, зависящие от особенностей Scala и используемой архитектуры. Но главная идея в здесь том, что разработчикам можно смело ожидать увеличения скорости компиляции при решении ежедневных задач. Больше всего от этого выигрывают проекты Scala на основе cake pattern или интенсивного type-level программирования. По словам тестировавших алгоритм программистов, в некоторых проектах скорость компиляции в Zinc 1.0 превосходила скорость старой версии в 22 раза.

Краткий список нововведений

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

• Усовершенствован инкрементальный алгоритм: устранены «узкие места», которые раньше не удавалось скомпилировать до конца;
• Исправлены баги в инкрементальной компиляции Scala bridge и Java;
• Улучшена обработка type-level программ;
• Усовершенствованы старые Zinc API и созданы дружественные API для дополнения недостающего функционала общего доступа;
• Закончена миграция к Scala 2.12. Zinc подготовлен для JDK8;
• Добавлен анализ на основе протокола передачи данных с долгосрочной бинарной поддержкой.

С полным списком улучшений можно ознакомиться здесь.

Новая версия Zinc уже доступна в sbt 1.0.

Вот самые важные нововведения:

• Java 9: теперь поддерживаются последние сборки JDK 9. Помимо этого, улучшены соответствующие встроенные инструменты.
• Java 8: улучшен механизм перехода с циклов for на вызовы Stream API и обратного перехода.
• Асинхронный отладчик: такая новая фича, как асинхронный стек-трэйс, упростит отладку async-кода. Помимо этого, Smart Step Into получил поддержку асинхронного кода и лямбда-выражений, работающих на других потоках.
• Улучшение системы контроля версий: лог-панель для Git и Mercurial получила новые опции, история Git стала быстрее и многое другое.
• Поиск: диалоговое окно Find in Path было полностью переработано и теперь в первую очередь показывает мгновенные результаты.
• Spring: Spring Testing получил поддержку Spring Boot 1.4.3 и Spring 5.0. Инструменты Spring Data были обновлены до версии 2.0 (в том числе MongoDB, Redis, Solr, KeyValue, Gemfire, Apache Cassandra, REST, Neo4j, Couchbase и Elasticsearch). Также добавлена новая вкладка Data, упрощающая навигацию по репозиторию.
• Gradle: улучшена поддержка Composite Builds.
• Kotlin 1.1: в новой версии этого языка была добавлена поддержка сопрограмм и компиляции в JavaScript-код.
• Scala: плагин Scala получил крупные улучшения.
• JavaScript: добавлены поддержка Vue.js, улучшения в работе с JavaScript, TypeScript, Angular и Jest, а также многое другое.
• Go: Gogland, новая IDE для языка Go, теперь доступна в виде плагина для IntelliJ IDEA Ultimate.
• Инструменты для работы с БД: IntelliJ IDEA теперь позволяет переносить данные и схемы из одной базы данных в другую (да, это работает даже с MySQL и Microsoft SQL Server).
• Эмодзи: редактор теперь поддерживает Юникод-символы эмодзи.
• Android Studio 2.2.2: это обновление содержит все фичи Android Studio 2.2.2.
• Docker: плагин Docker теперь поддерживает Docker for Mac и запускается через unix://.
• Windows: доступна 64-битная версия IntelliJ IDEA.

Полный список изменений в IntelliJ IDEA 2017.1 можно найти на страничке обновления на официальном сайте проекта. Также напоминаем, что совсем недавно обновилась WebStorm, среда для JS-разработки от JetBrains.

И в чём отличие?

В отличие от стандартной реализации Scala, которая генерирует байткод, запускаемый в JVM, Scala Native создаёт отдельные нативные исполняемые файлы. Это позволяет использовать язык в тех ситуациях, когда виртуальная машина — не вариант.

Список нововведений

Вот интересные фичи, которые попали в версию 0.1:

• поддержка Scala (с небольшими семантическими различиями);
• «бесплатная» интероперабельность с нативным кодом;
• поддержка существующих IDE для Scala из коробки;
• интеграция с инструментом для сборки sbt;
• поддержка основных библиотек JDK;

Больше информации можно найти на сайте проекта.

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

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

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

Как чаще всего выбирают технологию сейчас:

1. Она мне нравится
2. Знакомый посоветовал
3. Прочитал в Интернете
4. На этой технологии сделан аналогичный сайт

В чем тут проблема:

1. Нравится. Очень субъективно. А что, если по требованиям она не подходит? Или на ней очень дорогие и редкие специалисты? Или она вообще умирает?

2. Знакомый. Обычно это тот знакомый, который «чуть лучше» разбирается в ИТ, чем тот, кому он советует. И даже если он программист с опытом, он не может знать всех решений на всех популярных языках. Ведь никто не спрашивает, по каким критериям выбирал этот знакомый. Если этот знакомы не CTO Google, я бы так просто не доверял такой рекомендации.

3. Прочитал. Тут уже лучше, можно найти разные сравнения и аргументацию. Но опять же, чтобы разобраться во всех решениях человеку, пусть даже с крепкими знаниями в разработке, нужно время. А без знаний в разработке все прочитанные технические обзоры ничего не стоят.

4. Аналог. Большинство популярных сайтов написаны на тех или иных технологиях потому, что так «исторически сложилось» . Если бы Facebook сейчас выбирал технологию для себя, я сомневаюсь, что он взял бы за основу PHP. А еще может быть, что технология уже устарела, её продавили на основе прошлых 3х пунктов, выбрали какую-то разрекламированную технологию, а не действительно эффективную и т.д. Вы вряд ли можете знать реальные причины выбор технологий в других проектах. Оптимальные технологии используются крайне редко в аналогичных проектах.

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

Важные критерии при выборе технологий:

1. Размер и тип проекта
2. Сложность проекта
3. Скорость разработки
4. Стоимость специалистов
5. Доступность специалистов
6. Доступные инструменты разработки
7. Наличие готовых решений
8. Гибкость решения
9. Наличие широкого сообщества
10. Отказоустойчивость решения
11. Тренд его развития
12. Наличие подробной документации
13. Стоимость поддержки
14. Требования к нагрузкам
15. Требования к безопасности
16. Кроссплатформенность
17. Возможности интеграции с другими решениями

Выбирая технологию по таким критериям мы сможем добиться объективного выбора и тем самым сэкономить себе время и деньги.

Какие бывают проекты

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

Сложность проекта

1. Простые (визитки, лендинги, простые интернет-магазины, простые приложения) — такие решения обычно делаются на тематических коробочных решениях, CMS или шаблонах.
2. Средние (сложные интернет-магазины и маркетплейсы, порталы национального масштаба, разнообразные сервисы, продвинутые приложения) — такие решения обычно делаются на фреимворках.
3. Сложные (огромные порталы, социальные сети, инновационные и нетиповые решения) — ядро таких проектов обычно разрабатываются на чистом (нативном) языке программирования.

По тематике: интернет-магазины, доски объявлений, социальные сети и т.д. Для большинства популярных тематических решений уже давно есть коробочные продукты и, если мы не пытаемся сделать какого-то монстра, то правильнее будет выбрать именно их. Решений очень много, все в одной статье описать невозможно.

Языки программирования

В технологиях я бы выделил 3 уровня абстракции:

1. Чистый язык — это материал, из которого можно сделать все, что угодно. Ограничивают нас только возможности языка. На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиарды пользователей, такие как: Instagram, YouTube, Pinterest, Tumblr, Dropbox, Twitter, Facebook, Amazon, Digg, LinkedIn и другие. Более того, крупнейшие проекты в мире даже создают новые технологии для себя, так как уже существующие их не устраивают.
2. Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Фреимворк с одной стороны помогает и ускоряет разработку, а с другой накладывает определенные ограничения. На фреимворках делаются проекты средней сложности с посещаемостью в миллионы.
3. CMS — это уже готовое решения, конструктор, в котором мы по частям собираем нужный проект. Его скорее не программируют, а настраивают. Ограничений тут огромное количество, выйти за границы коробки сложно и неэффективно. На CMS делаются простые сайты с посещаемостью до миллиона пользователей в месяц.

Чаще всего один уровень абстракции базируется на другом. То есть на чистом языке делают фреимворки, а на фреимворках делают CMS. Для каждого популярного языка есть много разных фреимворков и CMS, но об этом позже.

Сегодня есть огромное количество разных языков программирования, на которых делают сайты. И, более того, на всех популярных языках есть примеры огромных сайтов. Если 10 лет назад, говоря о технологиях больших сайтов, все говорили преимущественно про Java, то сегодня это может быть почти любой язык и утверждать, что сайты делаются на каком-то конкретном языке — стереотип. Это связанно с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности. Конечно, каждый язык чем-то отличается и выбирая мы опять же должны руководствоваться объективными критериями с оглядкой на задачи проекта.

На чистом языке, без использования фреимворков и коробочных решений, пишутся огромные проекты с повышенными требованиями по гибкости, нагрузкам и безопасности. Для таких огромных проектов часто бюджет не играет такого значения, как эффективность. Чем больше проект, тем больше будет требований по гибкости и нагрузкам, а значит, проще писать все с нуля, выделяя на это лучших специалистов, чем если брать какие-то готовые решения, которые непонятно кем писались и непонятно какие проблемы в них скрыты. К примеру, когда речь про небольшой проект с посещаемостью в 10 тыс. человек в день, то нам будет дешевле сделать его на CMS, которая будет потреблять в 3 раза больше ресурсов сервера, поставить дополнительный сервер за 50$ / мес. и оно будет работать. Когда же мы говорим про сайт с посещаемостью в 100 млн. пользователей в день, стоимость добавления серверов у нас будет просто космической, поэтому нам проще и дешевле вложить деньги в разработку решения на чистом языке, которое будет оптимальным именно для конкретного проекта.

Чем больше проект, тем больше стек технологий, который в нем используется. В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора технологий. Часто один язык может хорошо делать одну задачу, а другой — другую. Такие проекты могут быть на столько огромными, что его части могут работать на разных серверах, с разными доменами (поддоменами) и разными технологиями. Не следует боятся винегрета технологий в большом проекте, хотя и допускать его нужно только когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google. Он на столько большой, что разные его части написаны на C/C++, Java, Python, JS и других языках. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS.

Попробую дать краткую характеристику каждому из популярных языков:

1. PHP — его используют в основном для простых и средних проектов. Очень много коробочных решений. Относительно дешевые программисты. Антитренд последних лет, хотя с выходом последней версии языка под номером 7, он получил действительно мощные возможности.
2. Python — современный язык, разработка на нем быстрая и качественная. Используют его для средних и больших проектов. Программистов найти проблематично и стоят они не дешево.
3. Ruby — современный язык, разработка на нем так же быстрая. Его используют в основном для разработки простых и средних проектов, часто разрабатывают стартапы. Программистов также мало и они дорогие.
4. Java — разработка на нем очень долгая и дорогая. Его используют в основном для больших проектов со специфическими требованиями. Однако является самым популярным языком программирования в рейтинге TIOBE по состоянию на март 2016.
5. C# — аналог Java, также используют для больших проектов, часть в сфере FinTech.
6. JavaScript — очень быстро развивается, тренд последних лет и самый популярный язык программирования в рейтинге Redmonk по состоянию на июнь 2016. Огромное количество наработок и можно писать все, что угодно, даже игры. Его используют для средних и больших проектов, но действительно мощные возможности этот язык получит недавно, потому примеров больших проектов пока мало, специалисты самые дорогие и найти их сложнее всего.

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

Примеры больших сайтов:

• PHP: Facebook, Вконтакте, КиноПоиск
• Python: Instagram, Pinterest, Reddit
• Ruby: 500px, Groupon, Airbnb
• Java: Ebay, Amazon, Alibaba
• C#: Guru, Stack Overflow, Bank of America
• JS: LinkedIn, Walmart, PayPal

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

Фреймворки и платформы

Это некая среда разработки для программистов, где есть готовая инфраструктура и ряд готовых функций со стандартными решениями типичных задач. Такой себе полуфабрикат, из которого можно сделать конфетку. На каждом языке есть много разных фреймворков. Есть как общие, которые создавались для разработки любых решений, так и специализированных, под узкие задачи. Например, Sylius — специализированный E-commerce фреймворк на основе Symfony. Также есть те, на которых делаются большие и сложные решения, а другие для этого не предназначены. Ниже я опишу популярные фреймворки для каждого из языков, на которых можно писать большие и сложные решения.

На фреймворках разрабатываются довольно большие и сложные сайты с уникальным функционалом. Это значительно быстрее и дешевле, чем на чистом языке, но при этом такое решение позволяет разрабатывать действительно сложные вещи и оптимизировать все это под нагрузки. Кроме того, это почти всегда более безопасно, чем любая коробочная CMS. Если вы хотите узнать об этом больше, посмотрите материал про веб-фреймворки для начинающих.

Популярные фреймворки и платформы:

1. PHP: Symfony, Laravel
2. Python: Django
3. Ruby: Ruby On Rails
4. Java: Spring
5. C#: .NET
6. JS: Node.js, AngularJS

Больше всего фреймворков на PHP и на этом языке есть, из чего выбирать, но действительно функциональных не так много. Меньше на других языках, а на некоторых действительно качественных фреймворков вообще всего один, как у языка Ruby. У Java вообще очень много разных фреймворков для разных целей, и не только для сайтов. Все эти фреймворки ежегодно развиваются, выходят все новые и новые версии, одни фреймворки обгоняют другие. Например, Laravel только в последние несколько лет вышел на первое место по популярности, хотя самые сложные сайты до сих пор делаются на Symfony.

.NET и Node.js — это целые самостоятельные платформы, которые базируются на определенных языках, но имеют очень широкие возможности.

CMS и CMF

Это готовое программное обеспечение, которое нужно только настроить, реже — дописать / переписать какую-то из частей. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные CMS сделаны на PHP. Тут дело в развитие языков, раньше простые сайты, для которых и создавались CMS, писались на PHP. Я еще застал те времена, когда CMS почти не было, были скрипты — отдельные готовые части разных сайтов. Позже эти скрипты собирали в коробочный продукт, который был призван решить потребности 90% простых сайтов. Так и получилось, что основные CMS сделаны на PHP. Сегодня CMS на других языках развиваются слабо, потому, что уже есть сильные конкуренты на PHP, а простому сайту язык не играет большой роли, поэтому все смотрят на возможности этих готовых продуктов.

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

CMS бывают разные по назначению: общие, для интернет-магазинов, для блогов и т.д. Разные по условиям использования: платные и бесплатные. Для каждой популярной CMS есть куча разных платных и бесплатных модулей, которые легко подключать и использовать.

Маленькие сайты, которые в основном нужны для малого бизнеса, почти всегда используют CMS. Это позволяет очень сильно экономить время на разработку. Кроме того, для настройки таких решений не нужны дорогие программисты, обычно это могут делать новички в программировании, по крайней мере саму настройку, если уже нужно писать код, тут сложнее.

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

Я видел решения почти на всех популярных CMS, с многими за более, чем 10 лет работы, пришлось поработать лично. Часть из них популярна в рунете, а часть знают в основном на западе. На используемые в них языки CMS разбивать нет смысла, по причинам, описанным выше. Лучше сказать несколько слов про каждую популярную CMS:

1. WordPress — некогда блоговый движок, сейчас на ней делаются почти любые сайты, включая магазины. Одна из самых популярных CMS в мире, есть примеры довольно посещаемых сайтов. На ней часто делают информационные сайты, в том числе разные СМИ. Система бесплатная.
2. Joomla! — CMS общего назначения. Качеством особо не отличается, на ней делают очень маленькие сайты и обычно дешевле всех других вариантов, так как именно с этой CMS начинают учиться многие начинающие программисты. Система бесплатная.
3. Drupal — это уже CMF для общего назначения, с недавнего времени поставляется со встроенных фреймворком Symfony. Довольно мощная, на ней есть известные сайты, например, официальный сайт Белого Дома. Система бесплатная.
4. Magento — самая популярная система управления для интернет-магазинов в мире. Довольно мощная и сложная. В рунете используется редко, в основном на западе.
5. PrestaShop — одна из самых популярных CMS для магазинов в мире. Тоже довольно мощная, используют в основном на западе. Система бесплатная.
6. OpenCart — еще одна популярная система для интернет-магазинов, но её, наоборот, больше используют в рунете, чем на западе. В основном для маленьких и несложных магазинов. Система бесплатная.
7. 1С-Битрикс — очень распиаренная CMS общего назначения, номер 1 в рунете. Возможности очень широкие. На ней часто пытаются делать большие и сложные сайты, а после определенного порога в посещаемости переписывают их на других технологиях. Многие считают, что только эта CMS может интегрироваться с 1С, что не является правдой, поскольку все перечисленные CMS из этого списка могут интегрироваться с 1С, для этого у всех CMS есть специальные модули. Система платная.

Со всеми перечисленными CMS я работал. В основном со стороны разработчика. Точно НЕ рекомендую — Joomla, с остальными можно работать. Для магазинов лучше выбирать специализированные, а не общие CMS. Кроме 1С-Битрикс в рунете есть еще аналогичные коммерческие CMS, они во многом схожи. У каждой из систем есть свои особенности, но все они не предназначены для больших и сложных проектов, главное это не забывать.

Шаблоны

В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники и т.д. Для всех этих типов малого бизнеса нужно примерно одно и тоже. Поэтому, можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца.

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

Есть специальные каталоги шаблонов: TemplateMonster, ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix, PageCloud и др.

Мобильные приложения

В мобильных приложениях в последнее время используется два подхода: нативная разработка и кроссплатформенные технологии. Нативная ведется на оригинальных языках программирования, в частности Swift (для iOS, ранее был Objective-C) и Java (для Android). Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже. В любом случае, сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных кроссплатформенных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и т.д.

В этих двух подходах люди тоже часто путаются, пытаясь использовать кроссплатформенные подходы на все случаи жизни. Оно и понятно, ведь кроссплатформа позволяет писать код один раз, который сразу работает и на iOS и на Android, в то время, как на нативных технологиях это минимум в два раза дороже выходит. Однако мало кто знает про возможные дальнейшие проблемы в разработке. Я бы рекомендовал очень тщательно выбирать технологии и кроссплатформу брать только для простых приложений, иначе придется переписывать. Впрочем, кроссплатформенные технологии постепенно развиваются и становятся все лучше, а приложения написанные на них все сложнее.

Стек технологий в больших проектах

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

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

Для примера рассмотрим технологии Instagram (данные Insight IT):

• Ubuntu Server 14.04 LTS — основная серверная операционная система
• Python — основной язык программирования серверной части
• Django — фреймворк
• nginx — второй уровень балансировки входящих HTTP-запросов
• gunicorn — WSGI-сервер
• HAProxy — балансировка нагрузки внутри системы
• PostgreSQL — основное хранилище данных
• postgis — поддержка гео-запросов
• pgfouine — отчеты на основе логов
• pgbouncer — создание пула соединений
• Redis — дополнительное хранилище данных
• Memcached — кэширование
• Gearman — очередь задач
• Solr — гео-поиск
• munin, statsd, pingdom — мониторинг
• Fabric — управление кластером
• xfs — файловая система

И это вполне нормальный стек технологий. Сам Instagram не самый большой и сложный сервис в мире.

Стоимость специалистов

Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это самая затратная часть в любом проекте. В рунете есть только одна пузомерка по зарплатам — я отфильтровал по Киеву, уровень Senior, опыт 3-5 лет. Сравним средние значения.

Зарплаты:

1. C# — 3072$
2. Java — 3300$
3. JS — 3500$
4. PHP — 2780$
5. Python — 3000$
6. Ruby — 3000$
7. Scala — 3900$

В США немного другая картина:

Теперь переведем цифры на человеческий язык. Java хоть и не новый язык, но специалисты на ней всегда были одними их самых дорогих. PHP всегда был самым дешевым, да и специалистов на рынке очень много. В сравнение я внес еще и Scala как один из новейших и трендовых языков, по этой причине он дороже всех. Еще дорогой JS, это связанно с его бурным ростом в последние годы и растущей популярностью Node.js, а также AngularJS.

Таким образом, если мы хотим экономить — то лучше смотреть на PHP, специалисты дешевые, а комьюнити большое. А если хотим самое качественное — то смотрим на Scala, который называют будущем веб-разработки, но, правда, на ней найти специалистов почти невозможно и наработок просто нет.

Еще важным параметром будет скорость разработки. Ведь важна не только зарплата программистов, но и скорость разработки. Если не учитывать уже существующие наработки, то одним из самых быстрых в разработке будет Python и Ruby, а самый медленный — Java. Кстати, по этой причине за последние 10 лет почти не вышло новых мегапроектов на Java, зато вышло много проектов на Python, о чем я расскажу ниже.

Тренды

Выбирая технологию, нам нужно смотреть вперед. Особенно, если речь о большом проекте. Все технологии очень быстро развиваются, выходят все новые и новые версии. Языки сильно меняются каждые 5-7 лет, фреймворки — каждые 2-3 года, а CMS — каждые 1-2 года. Важно выбрать не просто хорошую технологию сегодня, а предугадать тренды развития так, чтобы остаться на коне через несколько лет. Иначе, в конечном счете, придется переписывать проект, что всегда очень проблематично.

Есть всевозможные исследования, которые нам могут подсказать некоторые статистические выкладки. Например, исследование TIOBE Index показывает интересную статистику:

По результатам разных исследований можно выделить явных лидеров по росту — это JS (версия ES6 и выше) и мультипарадигмальные языки, в частности Scala. Кстати, именно Scala считается преемником языка Java и во многом на него похож. Также не плохо себя показывает Python.

Антитренды держат ряд старых языков и PHP. Правда, недавно вышла 7я версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Еще многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд.

Для иллюстрации посмотрим, каких специалистов не хватает в США:

Именно это можно считать реальной картиной трендов, которые мы видим и у нас.

На чем делались большие проекты за последние 10 лет?

1. Airbnb — Ruby
2. Instagram — Python
3. Pinterest — Python
4. Foursquare — Python
5. Groupon — Ruby → JS
6. Twitter — Ruby → Scala
7. Uber — JS

Это уже не теоретическая статистика, а реальная практика. Python и JS очень хорошо себя показывают.

Стоимость поддержки

Безусловно, важный критерий выбора технологии — это стоимость поддержки, о которой мало кто задумывается в начале разработки. Обычно все мыслят категориями стоимости часа поддержки, что в корне неправильно. Нам важны несколько параметров: стоимость часа, количество часов, официальная поддержка технологии, доступность специалистов, правильный подход к разработке и некоторые другие.

Стоимость часа зависит от зарплаты специалисты, с этим мы уже разобрались. А вот количество часов зависит от самой технологии и качества написания кода. Если решение коробочное, то часов на него может уходить очень много. То есть, с одной стороны, мы можем сэкономить при разработке первой версии проекта, но после погрязнуть в его постоянной доработке. Хорошо, когда решение популярное и есть официальная документация, но часто выбирают малоизвестные коробочные решения без какой-либо документации — в таких решениям стоимость поддержки будет во много раз выше стоимости самой коробки. То же касается некачественной разработки: у нас почему-то полностью отсутствует культура проведения технических аудитов готовых решений или его частей. В среднем за 20-40 часов можно проверить почти любое решение и найти его основные минусы. Чем более качественный код, тем легче, а следовательно и дешевле его поддерживать.

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

Так что выбрать?

Подведем итог. Для простых сайтов чаще всего отлично подходят коробочные решения и шаблоны. Сложные сайты делаются только на фреимворках или даже чистых языках программирования. Делать можно на очень разных языках, язык выбирается под проект. Простые мобильные приложения можно делать на кроссплатформенных технологиях, а сложные обычно делаются на родных технологиях. Ну и, выбирая платформу, всегда стоит руководствоваться объективными критериями, которые я описал в статье.

Настройка окружения

Scala — язык, работающий на JVM, поэтому для работы требует установленную JDK (минимальная версия 1.6). Ее можно взять отсюда. После установки JDK можно приступить к установке самой Scala. Скачать свежую версию можно на официальном сайте. Последняя версия на момент написания статьи — 2.11.6.

Для того, чтобы все корректно работало из командной строки, рекомендуется прописать переменные среды JAVA_HOME и SCALA_HOME, а также дополнить переменную PATH путями к выполняемым файлам. На Linux и MacOS это делается так:

Для того, чтобы сохранить эти настройки, их надо прописать в ~/.bashrc или ~/.bash_profile.

На Windows команда немного другая:

Прописать эти опции постоянно можно в настройках системы: Control Panel → Advanced System Settings → Environmental Variables.

После выполнения всех манипуляций можно проверить результат, запустив:

SBT

Простые скрипты и маленькие программы можно, конечно, компилировать и запускать вручную с помощью команд scalac и scala. Однако, по мере того, как количество файлов будет расти, ручная компиляция будет становиться все более нудной. Вместо этого используют системы сборки. Для сборки кода на Scala можно использовать стандартные для Java (неофициально) maven, gradle или ant, но сообщество и сами разработчики рекомендуют sbt (simple build tool).

Примечание: если вы устанавливаете sbt, то можете пропустить отдельную установку scala, так как система сборки скачает ее автоматически

Описание процесса сборки находится либо в файле build.sbt в корне проекта, либо в файлах .scala в папке project там же. Само описание – это программа на Scala (которая, в свою очередь, может собираться с помощью sbt как отдельный проект, который… ну, вы поняли).

Синтаксис .sbt-файла напоминает синтаксис Scala с некоторыми дополнениями и ограничениями. Минимальный build.sbt выглядит примерно так (пустые строки обязательны):

Исходники помещаются в папку src/main/scala и src/test/scala по пути, соответствующем иерархии пакетов (как в Java). Чтобы собрать, протестировать и запустить проект, необходимо в любой поддиректории проекта выполнить следующие команды:

или через интерактивную консоль:

Последовательное выполнение команд выглядит немного необычно (обратите внимание на точку с запятой в начале — это особенность синтаксиса):

REPL

Отличным помощником в разработке будет REPL (Read-Eval-Print-Loop), или по-другому, интерактивная консоль. Очень удобно проверять в ней небольшие функции, отлаживать код или просто посмотреть возможности языка. Для запуска REPL наберите sbt console в командной строке. Вы увидите примерно следующее:

Все! Можно писать команды на Scala и сразу же их выполнять:

Для выхода из REPL можно нажать Ctrl+D. Все примеры на Scala далее можно протестировать в REPL, для вставки больших кусков кода можно воспользоваться командой :paste.

IDE

Использование IDE для разработки на Scala не обязательно, однако сильно упрощает процесс. Скала — язык со сложной семантикой, поэтому возможности IDE более ограничены, чем, скажем, при разработке на Java. Тем не менее даже простая подсветка несуществующих методов и автодополнение существующих может сильно облегчить жизнь. Самые популярные IDE для Scala — это IntelliJ IDEA и Eclipse. Для IDEA есть плагин от JetBrains, в случае с Eclipse есть ее вариант Scala IDE.

Переменные, значения и типы.

В Scala переменные и значения объявляются ключевым словом val или var. val — это неизменяемая переменная (значение), аналог final в Java. var — обычная переменная. Например:

Аналогичный код на Java будет выглядеть так:

Здесь мы видим сразу несколько приятных особенностей Scala:

1. точка с запятой не обязательна (работает автоматический вывод);
2. указания типа переменной необязательно (также работает автоматический вывод типов);
3. ключевое слово public подразумевается по умолчанию.

Типы переменных указываются после имени, через двоеточие. Также в Scala нет, как таковых, примитивных типов (int, float, boolean и т.д.). Их заменяют соответствующие классы Int, Float, Boolean и т.д. Любая переменная — экземпляр какого-либо класса. Иерархия классов начинается с Any, все классы наследуются от него (аналог Object в Java).

Применение привычных операторов, при этом, на самом деле — вызов метода: a + b тождественно a.+(b). Вариант записи без точки применим к любым методам (с некоторыми ограничениями).

Функции, анонимные функции, методы

Функция в Scala объявляется с помощью ключевого слова def. Пример объявления и применения функции:

Аналогичный код на Java:

Как видно на примере, необязательны не только точка с запятой и указание типа, но и фигурные скобки вокруг единственного выражения и слово return. Более того, его использование считается плохой практикой. Из функции возвращается значение последней выполненной команды.

На самом деле, функция — это тоже объект. Каждая функция в Scala — это экземпляр класса Function, у которого есть метод apply. Поэтому мы вполне можем записать так (знак подчеркивания ставится на место аргумента функции):

Вызов метода apply подразумевается по умолчанию, поэтому использование функций внешне выглядит как в Java:

Все четыре вызова функции идентичны. Представление функций в виде объектов позволяет оперировать с ними, как с остальными объектами: передавать в качестве аргументов, возвращать из других функций, расширять дополнительными методами и т.д., что позволяет Scala полноценно поддерживать парадигму функционального программирования.

Конечно, присутствуют анонимные функции (лямбда-функции). Они объявляются так:

Здесь мы объявляем анонимную функцию, которая принимает один целочисленный аргумент и присвоил ее переменной f, после чего применяем f как обычную функцию.

Классы и объекты

Если вы программировали на Java, многие вещи, касающиеся объектно-ориентированного программирования будут вам знакомы. Класс объявляется ключевым словом class, новый экземпляр — через new. Методы класса — это функции, объявленные в его теле. Поля класса указываются сразу после имени, как список аргументов. При этом, по умолчанию они объявляются как private val. То есть, если мы не укажем никаких модификаторов, указанное поле будет доступно только внутри класса и будет неизменяемым. Класс можно сделать абстрактным, добавив abstract перед объявлением. Основное отличие от Java здесь заключается в отсутствии конструктора. Код, который должен выполняться при создании объекта, пишется прямо в теле класса. Как при этом реализовать несколько конструкторов с различным числом аргументов, мы рассмотрим позже. Пример использования класса:

И аналогичный код на Java:

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

Кроме того, в Scala мы можем объявить сразу объект, без создания класса, с помощью ключевого слова object. Таким образом реализуется паттерн «Одиночка» (Singleton).

Аналог на Java будет куда более многословен.

В этом примере мы пометили конструктор как protected, чтобы исключить возможность его вызова извне, обращение к объекту будет осуществляться через метод getInstance(), который при первом своем вызове инициализирует экземпляр класс, а при последующих возвращает уже созданный экземпляр. Кроме того, вполне допустимо существование объекта и класса с одним и тем же именем, при этом они делят область видимости. Поэтому необходимость в директиве static отпадает — методы, объявленные не в классе, а в объекте ведут себя как статические. Такой объект называется в терминологии Scala «companion object» («объект-компаньон»).

Вернемся к конструкторам. Вспомним, что при применении любого объекта к некоторым аргументам по умолчанию вызывается метод apply. Этим мы и воспользуемся и напишем класс с несколькими конструкторами, статическими методами, изменяемыми и неизменяемыми полями в идиоматичном для Scala стиле и продублируем этот же код на Java.

Вариант Scala:

Вариант Java:

Интерфейсы и трейты

Аналогом Java-интерфейса в Scala является трейт (trait). Как ни удивительно, объявляется он с помощью ключевого слова trait. Как и интерфейсы Java, трейты содержат только объявления методов и допускают множественное наследование. В отличие от интерфейса, в трейте можно описывать поля класса и частично реализовывать методы. Наследование как трейтов, так и абстрактных классов осуществляется с помощью extend (первый родитель) и with (последующие родители). Пример использования:

Ключевое слово override необязательно, но его использование является хорошей практикой.

Другие особенности и отличия от Java

Как и в Java, в Scala классы, трейты и функции можно параметризовать. Параметры типов пишутся в квадратных скобках после имени класса или функции. Так определяется интерфейс Foo, который принимает некоторый тип A и содержит метод bar? который принимает значение типа A и некоторого типа B и возвращает объект типа C. Конкретные типы A, B и C будут определены в реализации интерфейса.

Конструкция if/else всегда возвращает значение выражения, которое стоит последним ввыполняемом блоке. Скобки вокруг условия обязательны, скобки вокруг тела, в котором только одна инструкция, можно опустить.

Блок try/catch/finally выглядит в Scala так:

Циклы while ничем не отличаются от варианта в Java:

А циклы for — наоборот, совсем не похожи (о них мы подробнее поговорим в следующей статье):

Также вы, возможно, могли заметить литерал ???. Он имеет тип Nothing который является подкласс любого класса. При вызове ??? кидает исключение NotImplemented. Это примерно аналог undefined в Python. ??? можно ставить в качестве заглушки вместо тела функции, к написанию которого вы планируете вернуться позже.

Заключение

Итак, мы установили и настроили среду разработки для Scala, посмотрели основные элементы языка, сходства с Java и отличия от нее. Этого вполне должно хватить для того, чтобы начать писать простой и рабочий код. В следующей статье мы подробнее рассмотрим элементы функционального программирования, case-классы, pattern-matching и другие высокоуровневые особенности языка.

Дополнительные материалы и ссылки

Официальный сайт
SBT
IntelliJ IDEA
ScalaTest