Comments 22
«Еще более краткий синтаксис.»
То есть, смысл будет еще сильнее зашифрован, чтобы профаны ничего не понимали. Я Скалу 2 не понимаю, хотя за 40 лет в программировании навидался всяких языков. Ну что ж, быть со всеми или сформировать группу избранных — каждый решает сам.
Если вы не понимаете скалу, то это может означать тольку одну вещь. Вы не приложили усилия для её изучения.
Это вовсе не проблема скалы или любого другого языка, а проблема людей. Почитайте что такое парадокс Блаба, может вам станет понятнее.

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

бизнес уже ответил на этот вопрос. а сегментация на scala2 vs scala3 добьет
Синтаксис Скалы не сложный. Он похож одновременно и на тот же Kotlin, и на Python (начиная с Scala3 там будет даже контроль отступов, как в Питоне). Не говоря о том, что Java и JavaScript многие конструкции заимствуют. Если вы не понимаете исходники на Scala, то вы не понимаете ФП. А это целое семейство языков и целая парадигма, изучить которую безусловно стоит любому программисту, даже с 40летним стажем.
"Если вы не понимаете исходники на Scala, то вы не понимаете ФП."
Не понимаю из-за переусложненного синтаксиса. Разве ФП язык обязан иметь криптованный синтаксис, по иному нельзя?
И заодно вопрос лично вам как знатоку ФП: какие функциональные конструкции Скалы нельзя выразить на простой Яве?
Вот тут не знаю… Мне кажется отступы это вообще самая ужасная вещь, которая есть в питоне.

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

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

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

прежде чем говорить о семантике, надо продраться сквозь синтаксис. А такие синтаксические конструкции как xs filter (pivot ==), elems = args map Integer.parseInt или loop {react {}} попросту ставят в тупик.
Не, ну как бы наговнокодить на Scala проще простого. Гораздо проще чем на java или С++. Тут не спорю. Ну так значит сам себе злобный Буратино! Вы кстати Forth не видели? Ещё более способствует жуткому говнокоду. Но хорошо написанные на нём программы на удивление понятны, приближаясь к естественному языку. Так что никем не понимаемый говнокод это проблема не языка.
Не, ну как бы наговнокодить на Scala проще простого. Гораздо проще чем на java или С++

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

С типами да, согласен. Но мне кажется rfq имел в виду скорее вид синтаксических конструкций. И тут если мы скажем определяем бинарную операцию с именем <=|=>, может действительно прийтись тяжко. Я его во всяком случае понял именно так. Почему я и привёл в пример Forth, как квинтессенцию и возможности наговнокодить, и возможности написать потрясающе ясный код при таком подходе.

С современными иде это вообще не проблема, goto definition даже у меня в емаксе работает

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

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

А если там всё так наговняканно ???
Почему и говорю. Смирись смертный! Ни один язык не защитит тебя от говнокода! Хуже того, чем он мощней и гибче, тем больше шансов наговнякать! Потому именуй РАЗУМНО! И пиши комменты. А по возможности описывай вообще весь код! Знаете какое моё самое частое проклятие говнокодерам?
Чтоб тебе сцуко вернуться к собственному жуткому говнокоду лет так через 5! :)))))

Так, а совместимости с java так и не будет на уровне kotlin?
Нас лично только это остановило при решении куда мигрировать с java в мир близкий к ФП.
Ну, а теперь и kotlin-native подоспел, значит можно и плюсовые части начинать переписывать под arm.

А какие там проблемы совместимости-то? Это же все jvm. Даже на ортогональной clojure делают библиотеки для java.
Пример akka-java и lagom показывает, что никаких проблем там нет. Есть только некоторые приседания которые надо делать для того чтобы библиотеку можно было использовать для java. В котлине тоже нужны приседания, не получится писать код не глядя откуда он будет использоваться.
Мне больше всего интересно что будет со Scala.js. Они который год уже выкатывают 1-ю версию, всё никак не выкатят. Как интересно у них будет с совместимостью с Scala3? Вообще со Scala я пока знаком именно в качестве инструмента программирования на платформе js. Понимаю, что это весьма односторонний взгляд, но тем не менее мои надобности пока именно такие.
Обещают не повторять ошибок Python'а ...

Что-то сомневаюсь. Вон, и Гвидо с Python 2 на Python 3 переводил и сломал совместимость; и у Ларри с Perl 5.х на Perl 6 (ныне Raku) была идея «немного подправить язык», но очень быстро превратилась в «совершенно другой язык».
Only those users with full accounts are able to leave comments. Log in, please.