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

такая тенденция сейчас существует практически во всех «живых» платформах

JavaScript -> Миллион других языков
CSS -> Миллион препроцессоров которые генерят менее эффективный ксс
PHP -> Hack выкатили недавно
C# -> F# соснул
Erlang -> Elixir очередная игрушки для маргиналов
ActionScript3 -> Haxe

и наверное еще куча таких примеров есть, первое что пришло в голову просто

так можно или не можно?

иммутабельность/STM/агенты

Это я ответил на вопрос «в чем отличие от lisp»

Вот на Hack не наезжай, это подмножество PHP, а не всякие борщехлебские хипстерские расширения.

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

яву не знаю

можно. Надо попробовать. Как раз в /webdev спрашивал, на чем писать вместо JS. Советовали Clojurescript. Но имхо если вручать верстальщику/кодеру логики, то «чем тупее - тем лучше». Clojure простой только для программистов. И стектрейсы там нечитабельные.

А какого рода проекты? И почему выбрали кложур?

Телеком. Пишем протитипы и софт для внутреннего использования.

Для скальщиков вопросы (давно к ней присматриваюсь, не могу выбрать между ней и Clojure)

• В чем она лучше Clojure?
• На сколько высокий порог вхождения?
• На сколько она готова для прикладных программ?

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

Порога вхождения нет. Бери и едь. Вот если хочется статической типизации по хардкору, как в ScalaZ, то вхождение простое, использование офигенно трудоемко.

Кто такие прикладные программы? Web? Play Framework 2, хотя какой-нибудь RoR лучше. GUI? scala.swing. Но здесь лучше груви. Консоль? Ну, консоль на Java вообще неадекватная получается, запуск JVM уж слишком долгий.

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

Для скальщиков вопросы (давно к ней присматриваюсь, не могу выбрать между ней и Clojure)

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

При чем статическая типизация к Scalaz? Это фича языка. Scalaz - это просто продукт деятельности редкого подвида гомо сапиенс - гомо категорщикус джавистикус усложнятикус.

Но поддержка IDE у скалы гораздо лучше, что перечеркивает все плюсы кложуры

Для Clojure пилят https://cursiveclojure.com/ - вроде бы не всё так плохо.

Отказались от скалы из-за проблем с потреблением памяти. Clojure оказался сподручнее.

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

Неплохо, да плохо в мелочах. Когда я ковырял, было забавно: нельзя грохнуть скобку, del на нее не срабатывает. Только костыльно через Ctrl+x. Видимо, защита от дурака, чтобы случайно скобки не стирались, и их парность никогда не нарушалась. Но вот когда экспериментируешь с выражением, то мешает очень и очень неслабо.

Ну и отдельный минус: в постфиксной записи stringBuilder.toString() toString автодополняется, а вот когда префикно пишешь, то IDE не знает, кого дополнять, (.toString stringBuilder). Или пиши сразу правильно, или записывай объект, шуруй в начало строки и уже потом выбирай метод. Да и в принципе дополнение в статике гораздо лучше динамики.

В чем она лучше Clojure?

Тут я столкнулся с двумя позициями одновременно:

1) это как джава только лучше. Итог: разочарование, неоправданно сложно;

2) это почти хаскель. Итог: недостаточно хаскель.

На сколько высокий порог вхождения?

Зависит от бэкграунда. Поначалу норм, но скала она как C++, куча подводных камней и мистических знаний с сомнительным выхлопом.

На сколько она готова для прикладных программ?

На 95%. Основная претензия — ломают совместимость между версиями (вроде как исправляются).

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

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

Груви, кстати, тоже память любит; его вы не пробовали на зуб?

Но поддержка IDE у скалы гораздо лучше, что перечеркивает все плюсы кложуры.

Коллега, не осиливший Emacs, пересел на https://nightcode.info/ и ему норм. А так, и в IDEA есть поддержка.

нельзя грохнуть скобку, del на нее не срабатывает

У них там по идее закос под paredit, собственно так и должно быть.

Груви не пробовал. Но тех проблем, с которыми я столкнулся в скале, в груви я не вижу.

Что за проблемы, если не секрет? В самой Scala или в какой-то либе/фреймуорке? Имхо, ничего нерешаемого в этом плане в ней нет, хотя рантайм Clojure мне кажется более предсказуемым.

Что за проблемы, если не секрет?

Имплициты :)

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

Даже в стандартной библиотеке их полно. Например, BigDecimal.

Проблему с BigDecimal вроде починили, посмотри анонс по ссылке

Не-не-не. Речь не за то. В скале BigDecimal это scala.math.BigDecimal, а внутри него java.math.BigDecimal.

https://github.com/scala/scala/blob/master/src/library/scala/math/BigDecimal....

А между ними вот https://github.com/scala/scala/blob/master/src/library/scala/math/BigDecimal....

И так для всего.

2) это почти хаскель. Итог: недостаточно хаскель.

Увы, но скале до хаскеля как до луны.

Штоа? А value classes?

Есть мнение, что в скале систеиа типов более мощная, чем в хаскеле. Про мощно ниче не скажу, но как по мне, хаскель уж точно проще скалы.

По мне так системы типов очень разные. Да и сами языки очень разные (ссылочная прозрачность как водораздел). Еще мне очень нравится инфраструктура haskell platform (haddock, cabal, emacs/aquamacs-mode, просто замечательный профилировщик). Все просто и логично, юних-вей. Настолько все изящно. А в скале видим монструозность почти во всем. Хотя это только мое личное мнение.

вообще-то и scala тоже не айс, т.к. есть Clojure

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

они есть

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

и только не говори что не понимаешь, зачем это сделано

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

возможно ты просто не знаешь библиотеки и тебе приходится писать конструкции, которые кем-то уже написаны

Я не слышал про библиотеки, которые упрощают filter/map (ну может быть кроме наркоманской ScalaZ).

во-вторых, там где действительно «паровоз-однострочник» единственный выход - аналогичный код на яве (с использованием циклов) - будет занимать в тыщу раз больше места
а теперь подпишись на github на какой-нибудь популярный проект и читай коммиты

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

Почему не вспомнил невозможность вызывать разные конструкторы супер-класса при наследовании?

Ух ты, как я мог забыть такой эпичный фейл? :)

Главный принцип скалы - писать всё меньше и меньше, пока не останется почти ничего. Первое что выбрасывается — это информация о типах. Которая получается через Type Inference.

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

- конвенция C++ о том, что * и [] - синтаксически не часть типа, а часть имени символа, в то время как семантически - всё-таки часть типа, выворачивала наизнанку новичков, и приводила к огромному количеству ошибок даже у неновичков, когда несколько переменных объявлялось на одной строке. В Скале тут не осталось никаких разночтений.

но кроме того, учитывая и эргономика:

- с точки зрения стиля, важное должно писаться первее неважного. Типы не важны, т.к. TI.

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

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

- val, var и def имеют одинаково три буквы. Поэтому имена переменных всегда выстраиваются по вертикали в линию. Во-первых это удобно для глаза.

- во-вторых, если ты только поменял тип, в diff можно показать, что изменился только тип, а имя осталось неизменным. Точно так же изменения val/var/def очень читабельны в диффе.

- «перменная X с типом T» - это правильный порядок слов как в английском, так и в русском языке. Так люди говорят и думают. Поэтому «переменная: тип» более правильная языковая конструкция чем «тип переменная». «Типа Т переменная эта X» — так говорит только Мастер Йода и другие зеленые человечки его расы.

Ты так говоришь, как будто скаладок и sbt не покрывают 90% того, о чем ты сказал, и делают это монструозно. sbt, например - это вообще песня.

имхо просто настало время, когда язык не нужно «знать», и можно писать хоть на 20 языках одновременно

- val, var и def имеют одинаково три буквы. Поэтому имена переменных всегда выстраиваются по вертикали в линию. Во-первых это удобно для глаза.

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

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

надо его в том же файле размещать что и класс

надо его в том же файле размещать что и класс

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

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

Вообще не напрягает. var и val на самом деле трудно спутать, но даже если спутаешь, то нужно очень постараться, чтобы из-за этого что-то неприятное вылезло.

настоящие индейцы скачут через shift-shift;)

Кэп

Надежность, скорость выполнения, удобство, простота - все это в Java уже давно есть.

типов высшего порядка

что это такое?

Разве что удобства немного не хватает. Я бы например сделал все переменные по умолчанию final, а для изменяемых сделал модификатор mut. Nullable для всех refernces - было очень плохое решение. Вот, kotlin язые мечты, но что-то не взлетает пока.

Вообще не напрягает. var и val на самом деле трудно спутать, но даже если спутаешь, то нужно очень постараться, чтобы из-за этого что-то неприятное вылезло.

Возможно, я скалу на практике не применяю. Подумал, что было бы «правильно» дополнительно поощрять использование «val» сделав «var» более длинным.