Scala: введение для занятых программистов

> Он мне расскажет как ровно один и тот же код запустить на Win/Lin/Solaris

Я это делал на D. (Без Solaris конечно) Потребовалась простая перекомпиляция и линковка к другим динамическим библиотекам. В исходнике не изменил ни строчки. Если бы DDL довели до ума, была бы совместимость без перекомпиляции на процессорной архитектуре. Если бы довели до ума LLVMDC, была бы полная совместимость, как у Java. LLVM гораздо лучше подходит для компиляции в машинный код и не навязывает в лучшем случае пятимегабайтную JDK. Останется только портировать пакеты tango.sys и tango.core на желаемую систему.

Подход будет примерно как у современных AOT компиляторов, но с LLVM вместо Java bytecode.

Надо заметить, что и то и другое до ума постепенно доводится. Все проекты здесь: http://www.dsource.org

> 10 лет на доведение HotSpot до приемлимой скорости

Walter Bright wrote:

 Robert Fraser wrote:
> Right now in-flight optimization rarely makes code that runs faster,
> but it's a new technology. In 10 years, I'm guessing that most code
> will run equally fast under a VM as native, and another 10 and the VM
> will be superior. Especially as multi-core architectures become more
> popular, I think this will be a big issue (since the VM can
> automatically parallelize loops, etc.).


 2 years ago, I attended a Java seminar by a Java expert who predicted 
 that in 10 years, Java code would run as fast as C code. Since it's 
 still 10 years out, it must be like chasing a mirage <g>.

Источник: http://www.digitalmars.com/d/archives/digitalmars/D/Re_D_vs._C_60648.html

> Ага. Память сейчас дешевая, процы - быстрые.

современное оборудование настолько уёбищно, что создание средств отличающихся природой вычислений от архитектурной императивщины - это уже победа

>> 10 лет на доведение HotSpot до приемлимой скорости

> Walter Bright wrote:

Ну ты же помнишь, там была и другая нить :)

>>> 10 лет на доведение HotSpot до приемлимой скорости

>> Walter Bright wrote:

> Ну ты же помнишь, там была и другая нить :)

Ну да. То самое, про что говорил Absurd: "Кривая виртуализация и медленное переключение контекста в x86"

>и не навязывает в лучшем случае пятимегабайтную JDK.

ЖДК она не чтобы было а стандартная библиотека.

>Потребовалась простая перекомпиляция и линковка к другим динамическим библиотекам.

Ну вот. А я даже не знал что наши япошки стявят софт на старые солярки - без всяких перекомпиляций.

> ЖДК она не чтобы было а стандартная библиотека.

Тоесть javac заработает и прекрасно все скомпилирует, даже если у него будет только java.lang.Object и java.lang.String? И если я ничего из JDK не использую, то она мне и не нужна? Я не утверждаю, что большие стандартные библиотеки - зло. Просто неприятно, когда приходится тащить всю JDK, а не только нужные мне пакеты.

> Ну вот. А я даже не знал что наши япошки стявят софт на старые солярки - без всяких перекомпиляций.

Решение есть всегда, просто одна крупная корпорация решила вкладывать деньги в VM, а не в компиляторы. И у этого решени есть свои недостатки. Читай мои предыдущие комменты.

> я даже не знал что наши япошки стявят софт на старые солярки - без всяких перекомпиляций.

С перекомпиляцией. Ты просто не знал :D

>> Ну ты же помнишь, там была и другая нить :)

> Ну да. То самое, про что говорил Absurd: "Кривая виртуализация и медленное переключение контекста в x86"

Absurd сказал отчасти глупость, отчасти не относящуюся к делу вещь. Я же говорил вот об этой нити: http://www.digitalmars.com/d/archives/digitalmars/D/Dynamic_Code_in_D_64872.html

Для компилируемых языков нет хороших открытых оптимизаторов. gcc и dmd используют не все возможности для оптимизации. Смотрим сюда: http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=dla...

И выбираем для каждого компилятора лучший результат. То что получится от объединения их оптимизаторов будет процентов на 20-30 быстрее, чем каждый из них по отдельности.

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

Я вижу только одну реальную проблему - медленное аппаратное переключение контекстов.

> Для компилируемых языков нет хороших открытых оптимизаторов

Не понял, к чему ты это.

> Я вижу только одну реальную проблему - медленное аппаратное переключение контекстов.

А я почти всегда плАчу, когда слышу эту фразу :/ Причем переключение контекста к эффективности трансляции?

> Но есть + - он интероперабельный с жабой. Если там все по теме гладко - то можно нафигачить прокси фреймворков на J2EE и все должно быть кошерно.

Я уже говорил - kawa? :)

>Причем переключение контекста к эффективности трансляции?

Ну в общем-то jvm придумали чтобы изолировать программные компоненты друг от друга, т.е чтобы они не могли ломать чужкю память. Было бы колец побольше двух, можно было бы какие-нибудь другие варианты кроме jvm поискать. А насчет кривой виртуализации - возможно я выразился некорректно, но виртуализация это другой современный тренд помимо jvm и .net, и поддержка ее на x86 не очень хороша.

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

То есть вместо программной защиты managed-языка, использовать unmanaged-языки и аппаратную защиту процессора? Это не решение потому что 1) мы имеем большую часть проблем unmanaged-языков и кое-какие новые 2) _ни у одного_ процессора нет достаточно быстрого переключения контекстов (почитайте о том, почему провалились микроядра). Кстати, количество колец тут совсем ни при чем :)

> виртуализация это другой современный тренд помимо jvm и .net, и поддержка ее на x86 не очень хороша.

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

Франц - http://www.uni-vologda.ac.ru/oberon/infoart/otherfly.htm

>Решение есть всегда, просто одна крупная корпорация решила вкладывать деньги в VM, а не в компиляторы. И у этого решени есть свои недостатки. Читай мои предыдущие комменты.

Microsoft чтоле? Ну ты подумай, вот дураки, нет бы свой MS C++ до ума доводить, тоже туда же, что и все нормальные люди, свою managed среду заделали. Так в чем же недостатки подхода Microsoft?

> Microsoft чтоле?

Хорошо. Тогда замени на "несколько крупных корпораций".

> нет бы свой MS C++ до ума доводить

С++ - FUBAR

> Так в чем же недостатки подхода Microsoft?

Недостатки VM? На мой взгляд это уже достаточно долго обсуждалось. Хотя бы и в этих же комментах.

>Я уже говорил - kawa? :)

kawa это схема. Как ни крути а пропихнуть что-то лиспосхемообразное в массы трудно.

> Порадовала наличием интерпретатора.

Чёт не заметил. Где искать интерпретатор?

> Где искать интерпретатор?

scala - интерактивный интерпретатор

scalac - компилятор

Оба должны быть в официальном дистрибутиве

> scala - интерактивный интерпретатор

> scalac - компилятор

Со scalac разобрался сразу, а насчет scala думал что он только пускалка для class файлов (по аналогии javac и java). Попробовать без параметров не догадался.

Тогда еще вопрос. Если в файле HelloWorld.scala написано

Console.println("Hello,world!")

то команда scala -howtorun:script HelloWorld.scala отрабатывает нормально, а если в этом файле

object HelloWorld {

def main(args:Array[String]):Unit={

Console.println("Hello,world!")

}

}

то ругается. Если же скомпилировать, то все работает нормально. А хотелось бы запускать именно без компиляции, для прототипирования, как в OCaml или Haskell, хочешь запускай предварительно скомпилированную программу, хочешь, запускай в интерпретаторе, хотя может я слишком много хочу, ведь fsc и так быстро компилирует.

Разобрался. Надо дописать в конец файла

HelloWorld.main(Array(""))

Тогда все нормально интерпретируется.

Я Scala вчера только скачал. Лучше спроси у знающих людей, например на форуме Development.

Могу предположить, что скрипт не может состоять из одного только определения.

> kawa это схема. Как ни крути а пропихнуть что-то лиспосхемообразное в массы трудно.

Труднее чем Java? Скорее "да" чем "нет" (ибо уже "пропихнуто" и таки "да" - очень просто). Труднее чем Scala? А вот здесь уже не уверен. Объяснять "ортодоксальным джавистам" преимущества функционального подхода на "почти таком-же синтаксисе, но всё же совсем не таком", к тому же порождающем доп. тормоза (и услышать дружный хор "Нафиг нужно - мы это и так всё умели, пусть с большим количеством кода")? Или предложить совершенно другой синтаксис (с возможностью кодогенерации) в котором есть почти полная аналогия работы к java-классами, и это помимо прочих вкусностей? Не знаю... Надо пробовать :)

Т.е. лично я практически уверен, что scala не заменит java в "массе JVM-кодеров" (как тот-же nemerle не заменит C# на .NET), а если так, то для выбора именно scala должна быть потребность именно в её фичах (и отсутствовать надобность в фичах прочих языков).

Есть такая штука! (^__^)

http://ocamljava.x9c.fr/

Cafesterol is a compiler that is the Java counterpart of ocamlc/ocamlopt.
As a program, Cadmium acts as a replacement for the ocamlrun program; it thus allows to run Objective Caml bytecode files. As a library, Cadmium acts as the runtime support of Cafesterol-compiled files.

Но оно как я понял как раз таки в части взаимодействия с жавой черезжопное :(
http://nickel.x9c.fr/ - писать XML-ные IDL файлы врукопашную это жутко удобно наверное.

+ http://www.pps.jussieu.fr/~henry/ojacare/index.en.html
но это JNI и не обновляется

Сам я на жизнь как раз жабакодерством зарабатываю, но синтаксис OCaml мне нравится больше чем Scala, да и Haskell. Единственное что не нравится - неконсистентные интерфейсы в стандартной библиотеке, ощущение что каждый модуль писался сам по себе. Хочется module type FoldableI :) и.т.п. в стандартной библиотеке.

--
Regards,
Igor Borski aka sirGrey

>Труднее чем Scala? А вот здесь уже не уверен. Объяснять "ортодоксальным джавистам" преимущества функционального подхода на "почти таком-же синтаксисе, но всё же совсем не таком", к тому же порождающем доп. тормоза

При чем тут функциональный подход? Скала, окамл - это такая жава, Ц с крестами или питон который к тому же функциональный. Лисп это такая хрень со скобками. В смысле безотносительно функциональности - скала, руби, питон - это такой паскаль просто хитрый. В отличии от лиспа или, например, пролога или эрланга.

>и услышать дружный хор "Нафиг нужно - мы это и так всё умели, пусть с большим количеством кода"

Это ты про трудности функционального подхода. А дело не в этом. Вот посмотри на С#. Уже лямбды нормальные появились и вывод типов для локальных переменных - и все народ схавал. А попробовал бы им подсунуть просто заменой С#->F# - нефига бы не вышло. слишком большая разница. Тут то же самое. Если вот пройдет спека про замыкания - все с радостью их схавают. Скалу начнет юзать меньшее количество народу. Подсунуть каву - вообще нереально.

Гы - интересная штука. Когда ж на это все времени набрать...

> При чем тут функциональный подход?

Как характеристика "массы новых фич", не более.

> Это ты про трудности функционального подхода.

Нет, это я про трудности перехода на иной язык (scala=/=java) ради некоторого набора фич.

> Вот посмотри на С#. Уже лямбды нормальные появились и вывод типов для локальных переменных - и все народ схавал. А попробовал бы им подсунуть просто заменой С#->F# - нефига бы не вышло. слишком большая разница.

Дык и я о том-же, только не о С#->F#, а о java->scala. И вывод тот-же: "нифига не выйдет" :)

> Тут то же самое. Если вот пройдет спека про замыкания - все с радостью их схавают. Скалу начнет юзать меньшее количество народу. Подсунуть каву - вообще нереально.

В свете найденного консенсуса перефразирую свою мысль: "нафиг использовать scala, если жабку она не заменит, а для одиночек с той-же JVM-интероперабельностью (да хоть наборы классов генери) _мне_ больше подходит kawa?" :)