Проект на Scala — в чем сложности поддержки кода со временем?

Question

[Рома Зварич]

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

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

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

Answer 1

[Сергей Горностаев]

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

Comments

[⚡ Kotobotov ⚡]

превратиться в трудную для понимания мешанину стилей и подходов

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

[Сергей Горностаев]

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

[Сергей Горностаев]

⚡ Kotobotov ⚡, кстати, одна девочка-скалистка жаловалась, что меняет уже не первое место работы, но везде почти не используют FP, пишут на Scala обычный ОО-код, как на Java с финтифлюшками.

[⚡ Kotobotov ⚡]

обычный ОО-код, как на Java с финтифлюшками.

это же замечательно, люди нашли пользу в инструменте которую активно используют.
Сергей Горностаев, В Scala основная философия - это практичность и маштабируемость, никаких проблем нет НЕ писать идиоматический FP, а только использовать то что удобно для конкретного программиста.
а у кого FP головного мозга - тем лучше использовать Haskell))))

[⚡ Kotobotov ⚡]

Сергей Горностаев, не думал что гибкость - оказывается минус, на который жалуются)))))

[Сергей Горностаев]

⚡ Kotobotov ⚡, всё в этом мире не является однозначно плохим или хорошим, у всего есть плюсы и минусы. Но точно то, что все парадигмы программирования, появившиеся за последние 50 лет, не дают программистам новых возможностей, а наоборот отнимают.

Структурное программирование
Первой, получившей всеобщее признание (но не первой из придуманных), была парадигма структурного программирования, предложенная Эдсгером Вибе Дейкстрой в 1968 году. Дейкстра показал, что безудержное использование переходов (инструкций goto) вредно для структуры программы. Как будет описано в последующих главах, он предложил заменить переходы более понятными конструкциями if/then/else и do/while/until.
Подводя итог, можно сказать, что:
Структурное программирование накладывает ограничение на прямую передачу управления.

Объектно-ориентированное программирование
Второй парадигмой, получившей широкое распространение, стала парадигма, в действительности появившаяся двумя годами ранее, в 1966-м, и предложенная Оле-Йоханом Далем и Кристеном Нюгором. Эти два программиста заметили, что в языке ALGOL есть возможность переместить кадр стека вызова функции в динамическую память (кучу), благодаря чему локальные переменные, объявленные внутри функции, могут сохраняться после выхода из нее. В результате функция превращалась в конструктор класса, локальные переменные — в переменные экземпляра, а вложенные функции — в методы. Это привело к открытию полиморфизма через строгое использование указателей на функции.
Подводя итог, можно сказать, что:
Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

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

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

© Роберт Мартин "Чистая архитектура"

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

[⚡ Kotobotov ⚡]

все парадигмы программирования, появившиеся за последние 50 лет, не дают программистам новых возможностей, а наоборот отнимают

Сергей Горностаев старый пердун вас троллит, а вы ведетесь)

[Elmo Sputterspark]

⚡ Kotobotov ⚡, дед затроллил кучу банков и корпораций по всему миру, только бравый стартапер не поддался.

[Сергей Горностаев]

⚡ Kotobotov ⚡, если вы готовы опровергнуть его слова, то было бы интересно посмотреть на пример того, что можно сделать на Scala, чего нельзя на Ассемблере.

[⚡ Kotobotov ⚡]

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

[Сергей Горностаев]

⚡ Kotobotov ⚡, он не об этом говорит, а о том, что за 50 лет выяснили, что ограничения - это хорошо и выработали ограничивающие правила.

[⚡ Kotobotov ⚡]

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

[1001001]

тогда надо брать kotlin, середина между джавай и скалой. Пиши как хочешь на крайняк уйди обратно в джаву ;)

Answer 2

[⚡ Kotobotov ⚡]

Вам нужно предоставить решение технических вопросов, техническим специалистам, которые и будут заниматься реализацией.
проще поддерживать то что тебе более понятно, а более понятные вещи - это просто привычные вещи.
Вам нужно понять кто будет поддерживать проект (Scala - не так распространена например как JS), если вам нужно найти 1-2 толковых человека для поддержки, вы это можете на любом языке сделать (в том числе и на scala).
Если вам нужны сотни человек набирать - вы конечно хрен найдете себе сотню скалистов. Хотя наверно и сотню толковых JS-ников тоже не найдете))))
Если проект будет поддерживать тотже разраб (то нужно позволить ему выбирать самостоятельно более удобный инструмент)
-------
опять же типовая практика сейчас, упаковывают часть функционала в микросервис и вообще туда не лезут, разрабатывают разные микросервисы по тем технологиям которые удобны разработчикам.
типовой срок жизни такого микросервиса 3-5 лет, потом он часто вообще выкидывается/заменяется.

Answer 3

[Евгений]

Скорее всего, найти программиста на Scala будет достаточно сложно, в случае, если текущий уйдет, а проект поддерживать и развивать надо.

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