LINUX.ORG.RU

Scala 2.10 RC2

 ,


1

2

Не далее как 9-го ноября сего года было объявлено о выпуске второго релиз-кандидата языка пограммирования Scala версии 2.10.

Основные нововведения и улучшения таковы:

  • Классы-значения (value classes) — снижают накладные расходы на выделение памяти.
  • Неявные классы — служат для упрощения создания классов, обеспечивающих методы расширения для другого типа.
  • Интерполяция строк — позволяет разработчику добавлять в выражение присваивания ссылки на (строковые) переменные, которые превращаются в итоговую строку.
  • Улучшения в обработке многопоточного кода: Futures и Promises.
  • Параллельные коллекции теперь могут настраиваться под отдельный пул потоков.
  • Новый кодогенератор, основанный на ASM: поддерживаются форматы Java 6 (по умолчанию) и Java 7, Java 5 будет объявлен устаревшим.
  • Динамические типы выведены из числа экспериментальных возможностей.
  • Улучшено сопоставление по образцу.
  • Библиотека акторов Akka введена в ядро языка.
  • Объявлены устаревшими восьмеричные литералы.
  • Введены следующие экспериментальные возможности языка: отражения (reflection), макросы.
  • Также проведена работа по оптимизации библиотеки, в частности вычисление Range.sum теперь имеет сложность O(1).

А также много других улучшений в Scaladoc и в библиотеке языка.

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

★★★★★

Проверено: tazhate ()
Последнее исправление: CYB3R (всего исправлений: 2)

Супер! Недавно начал изучать (по книге Одерски) - очень нравится.
Еще порадовало, что Akka внесли в ядро.

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

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

Вот это уже точно отсебятина: в целом Scala 2.8 проседала на процентов 2-10, но в некоторых случаях, например, с использованием @specialized, scalac порождает более быстрый байткод, чем возможен в джаве. Так что аналогия с си/ассемблер и т.п. - неверная. Но в целом скала, к сожалению, монстр.

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

бред. Scala медленее на какие-то проценты (из-за накладных расходов), в некоторых случаях даже быстрее. Если нужно, никто не мешает писать либы на С/С++.

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

Суть в том, что про Java всегда говорят ,что медленнее C, потому что компилирует в байт-код, а C в машинный код.

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

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

я замеров не проводил. пожалуй, стоит.

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

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

Ой, да знаю я про JIT. Что вы мне рассказываете?

Это устойчивое стереотипное мнение, что Java медленнее, чем C. Иногда оно верно, иногда нет.

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

Eсли сравнивать десктопные программы на си/си++ и ява, ява окажется жутким тормозом, жрущим память в три горла...

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

Ужос! Все что можно придумать пихают в скалу...

Вот это действительно мне кажется проблемой (а не гипотетическое снижение производительности на 2%... Да с теми возможностями для распараллеливания (сейчас .par, потом доживём и до .cl) почти всегда будет прирост). Скала сама по себе не так уж сложна, чуть разобраться и привыкнуть… Но если в неё продолжать пихать вообще все идеи, то ВСЮ Скалу знать будет всё сложнее, сложнее, а в итоге и невозможно. А если никто не знает язык целиком и все знают только какие-то куски, то чужой код почти всегда будет нечитаем.

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

Но 100500 фич языка и 100500 фреймворков для решения тех же задач в примитивном ЯП имеют похожий уровень нечитаемости

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

Но 100500 фич языка

Чисто гипотетически, стоит стремиться к «ортогональности» концепций языка, чтобы комбинируя их небольшое количество, можно было эффективно получить всё необходимое. Вместо того, чтобы плодить 100500 фич языка, которые никак не связать между собой… Но это и без меня всем понятно, что так «надо», а конкретику предложить всем тяжело.

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

Scala тут ближе чем большинство ЯП

Сейчас, наверное, да. Но мне не нравится, куда она идёт. Меня пугает список фич в 2.10. Может, я и не прав, и как будет время, надо будет посмотреть всё поподробнее. Вот для простого примера: String Interpolation. Вы можете использовать s, f, raw. Ортогональности нет никакой: просто набор фич, из которых нужно знать все, а выбрать для использования в конкретном месте одну. Ага, а к версии 2.12 ждём в стандартной поставке для интерполяции строк все методы от a до z, 20 двухбуквенных и 15 трёхбуквенных.

P.S. Вообще Скалу люблю, а те языки, что не люблю, я и не обсуждаю. Буду рад, если вы докажете мне, что про Скалу я тут не прав :)

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

Вообще как-то пока обсуждается Скала как язык вообще. Реквестую мнение специалистов, пробежались бы по списку изменений и сказали бы авторитетно про каждое, что Мартин делом занимается, а не просто фичи копит :)

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

Но на Scala доступна вся платформа Java, этим все сказано

С одной стороны в Erlang есть jinterface чтобы JVM в качестве ноды подключить и пользовать платформу, с другой стороны оно далеко не всегда нужно. Хотя в целом позиция понятна - лучше использовать один язык/платформу вместо микса под задачи.

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

F#?

(/me не в теме, с решётками не знаком, только со scala почуть)

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

Но мне не нравится, куда она идёт. Меня пугает список фич в 2.10.

(+) 1

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

то ВСЮ Скалу знать будет всё сложнее, сложнее, а в итоге и невозможно.

то получится новый lisp, а чтобы его упростить придумают новый C, а вслед за и новая java появится, которую начнут доводить до ума... чтобы изобрести новую скалу, сложную как lisp....

Karapuz ★★★★★
()

А что Java уже не модно? Теперь Scala на обложках глянцевых журналов?

Видно пошёл новый цикл развода лохов, сказки про Java уже не срабатывают.

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

ну я не знаю... в java хотя бы есть примитивные типы, в то время как в скала любая переменная = объект. Скажете, на производительность не сказывается, что все типы ссылочные?

Хотя обращаться к java-коду можно, да.

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

в java хотя бы есть примитивные типы, в то время как в скала любая переменная = объект

В байткод бы хоть для начала посмотрел.

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

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

Для меня уже давно производительность и прожорливость языка не стала определяющим фактором при выборе... слишком много задач, которые надо бы сделать «вчера», а оптимизировать скорость можно и потом (или вообще не делать)

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

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

var n = 1;
var f: Float = n.asInstanceOf[Float];
var s = n + f;
   0:	iconst_1
   1:	istore_2
   2:	iload_2
   3:	i2f
   4:	fstore_3
   5:	iload_2
   6:	i2f
   7:	fload_3
   8:	fadd
   9:	fstore	4
   11:	iload_2
   12:	istore	6
val r = n match {
    case 1 => 2
    case 2 => 4
    case x => x * 2
}
   14:	iload	6
   16:	tableswitch{ //1 to 2
		1: 51;
		2: 47;
		default: 40 }
   40:	iload	6
   42:	iconst_2
   43:	imul
   44:	goto	52
   47:	iconst_4
   48:	goto	52
   51:	iconst_2
   52:	istore	5

(Для не знающих jvm ассемблер, сгенерированный код полностью совпадает с аналогичным на java (в начале (float)n, в конце switch))

note173 ★★★★★
()
Последнее исправление: note173 (всего исправлений: 1)
Ответ на: комментарий от BattleCoder

ну я не знаю... в java хотя бы есть примитивные типы, в то время как в скала любая переменная = объект. Скажете, на производительность не сказывается, что все типы ссылочные?

В ГрецииScala есть все. Примитивные типы наследуют от AnyVal, включая Unit.

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

Беги покупай курсы у Java Champion'ов, а потом плачься, что не смог найти работу.

За знание языка никто на работу не берёт. Это сказки для быдла.

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

ЩИТО? Если мне не изменяет память, final в Java означает константу, или переменную, которой значение присваивается только один раз, причём при определении.

А в scala var - это переменные, которые можно переприсваивать много раз.

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

Топ 5 народных способов разбогатеть:

1. Создать сайт (любой).

2. Создать блог о том, как разбогатеть.

3. Послать небольшую сумму на десять кошельков с номерами...

4. Вступить в МММ.

5. Выучить Java.

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

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

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

от использования val вместо var в локальных переменных никаких дополнительных возможностей не появляется и не исчезает.

Почему же? По мне так появляется возможность у Старого Джорджи нашептать стремление к очень, очень плохому коду – как только в методах начинают появляться var. Если в методе только val, то его почему-то и не тянет начать ширить до бесконечности, методы остаются славными, компактными, в функциональном стиле.

Вот сейчас закончился курс по функциональному программированию и Scala на Coursera от самого Мартина О., так там в «домашних заданиях» нельзя было использовать ни одного var, в том числе в локальных переменных.

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

а куски, критичные к производительности на java.

С производительностью там все в порядке. Одерски писал java 1.4 и 1.5 для сана. Scala компилирует в байткод java и достаточно хорошо оптимизирована.

Другой момент, что библиотеки java в scala не всегда работают оптимально.

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

ну я не знаю... в java хотя бы есть примитивные типы, в то время как в скала любая переменная = объект. Скажете, на производительность не сказывается, что все типы ссылочные?

Там компилятор потом их преобразует в примитивные типы. Писалось еще в книжке Beginning Scala.

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

методы остаются славными, компактными, в функциональном стиле

Это хорошо и я нигде не говорил, что нужно использовать var.

var придется использовать, если писать на scala как на java (что полностью возможно), и в итоге получится почти идентичный байткод, за исключением некоторых особенностей компилятора.

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

Другой момент, что библиотеки java в scala не всегда работают оптимально.

А почему?

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

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

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

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

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

Классы-значения (value classes) — снижают накладные расходы на выделение памяти.

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

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

Кстати, это одна из главных возможностей .net, которых не хватает в jvm (структуры и value types).

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