LINUX.ORG.RU

Scala 2.11.0

 


0

6

Состоялся выпуск новой версии языка программирования Scala: 2.11.

Основные изменения:

  • В библиотеке коллекций:
    • У неизменяемых хеш-таблиц и множеств увеличена производительность операций фильтрации, объединения и других подобных. В большем количестве случаев стало возможным использование компонентов исходной таблицы при выполнении операций, создающих новые структуры.
    • Добавлены специализированные реализации хеш-таблиц в которых ключами выступают длинные целые (LongMap) и ссылочные типы (AnyRefMap). Использование этих реализаций позволяет повысить производительность до 2-х и до 4-х раз соответственно.
  • Модуляризация:
    • Размер ядра библиотеки языка Scala уменьшен на 20% за счет выделения в отдельные модули компонентов, связанных с работой с XML, синтаксическим анализом, библиотекой построения пользовательского интерфейса Swing и плагина поддержки ограниченных продолжений.
    • Произведена внутренняя модуляризация компилятора, работа над которой будет продолжена в следующих версиях.
  • Большая работа была произведена в экспериментальной части компилятора — поддержке интроспекции, макросов и quasiquotes.
  • Изменения в back-end компилятора:
    • Новый экспериментальный оптимизирующий back-end для генерации байт-кода GenBCode.
    • Экпериментальный вариант генерации байт-кода для лямбда функций, который позволит в будущем лучше интегрироваться с замыканиями из Java 8.
    • Экспериментальная поддержка генерации Javascript в отдельном проекте Scala-JS.
    • Удалены остатки давно заброшенного модуля для генерации байт-кода .NET
  • Повышена производительность инкрементального компилятора, а так же некоторая оптимизация пакетного компилятора.
  • REPL получил несколько удобных команд для отладки типов высшего порядка. Так же REPL теперь может быть подключен как скриптовый язык через API JSR-223.
  • При сборке теперь будут показываться предупреждения о неиспользуемых локальных переменных и типах, а так же о ситуации когда var может быть заменен на val.

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

>>> Подробности

★★★★★

Последнее исправление: ymn (всего исправлений: 11)

Ответ на: комментарий от h31

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

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

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

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

umren ★★★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от umren

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

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

anonymous
()
Ответ на: комментарий от windofchange

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

stevejobs ★★★★☆
()
Ответ на: комментарий от Hater

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

ymn ★★★★★
()

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

  • В чем она лучше Clojure?
  • На сколько высокий порог вхождения?
  • На сколько она готова для прикладных программ?
silver-bullet-bfg ★★
()
Ответ на: комментарий от silver-bullet-bfg

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

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

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

anonymous
()
Ответ на: комментарий от silver-bullet-bfg

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

Syncro ★★★★★
()
Ответ на: комментарий от silver-bullet-bfg

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

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

Bohtvaroh ★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

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

k_andy ★★★
()
Ответ на: комментарий от Bohtvaroh

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

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

anonymous
()
Ответ на: комментарий от silver-bullet-bfg

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

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

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

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

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

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

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

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

k_andy ★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

k_andy ★★★
()
Ответ на: комментарий от anonymous

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

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

Bohtvaroh ★★★★
()
Ответ на: комментарий от k_andy

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

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

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

Имплициты :)

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

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

k_andy ★★★
()
Ответ на: комментарий от dave

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

dizza ★★★★★
()
Ответ на: комментарий от dizza

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

dave ★★★★★
()
Ответ на: комментарий от stevejobs

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

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

они есть

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

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

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

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

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

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

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

h31 ★★★★
()
Ответ на: комментарий от shahid

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

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

h31 ★★★★
()
Ответ на: комментарий от h31

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

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

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

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

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

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

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

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

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

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

stevejobs ★★★★☆
()
Ответ на: комментарий от dave

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

anonymous
()
Ответ на: комментарий от umren

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

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от h31

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

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

maxcom ★★★★★
() автор топика
Ответ на: комментарий от maxcom

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

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

h31 ★★★★
()
Ответ на: комментарий от DarkEld3r

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

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

h31 ★★★★
()

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

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

anonymous
()
Ответ на: Кэп от SerCe

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

dizza ★★★★★
()
Ответ на: комментарий от h31

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

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

DarkEld3r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.