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

Надо же, именно сегодня начал разбираться со Scala :-)

Отличный язык, надо сказать.

Хм, это мне одному Скала показалась уродской? От XML-литералов меня просто корежит :(

Если Скала и в самом деле станет мэйнстримом, маятник JVM-языков качнулся в другую сторону.

> Хм, это мне одному Скала показалась уродской?

Мне наоборот показалась очень консистентной. Правда моё знакомство с ним длится третий час.

> От XML-литералов меня просто корежит :(

От XML-литералов корежит даже эклипс :-) Хотя, имхо, штука интересная, иногда с XML-ом приходится работать, возможно будет очень удобно.

> возможно будет очень удобно.

Я имею в виду например паттерн-матчинг по XML-у, это мне показалось очень мощной возможностью.

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

Странно... Про то что D может стать мейнстримом никто не говорил...

ИМХО всем стало бы легче, если бы программеры C++ перешли на D чем быстрее тем лучше. Аналогично с Java и Scala.

В абсолютное господство Scala я не верю. Производительность маловата (http://shootout.alioth.debian.org/) и не системный он ЯП.

Схожу по ссылке, что ли... познакомлюсь со зверем...

http://scala.sygneca.com/faqs/language

http://www.artima.com/scalazine/articles/steps.html

http://www.scala-lang.org/docu/files/ScalaTour.pdf

http://www.scala-lang.org/docu/files/ScalaTutorial.pdf

http://www.scala-lang.org/docu/files/ScalaByExample.pdf

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

Как раз прочитал Tour и Tutorial :)

Итого:

1)Пишем на C++

2)Ждем С++0x

3)Любуемся велосипедами ака Scala

>Производительность маловата (http://shootout.alioth.debian.org/) и не системный он ЯП.

А что, D или Ruby или Python или F# или Nemerle уже вытеснили C из ниши, системных языков, драйверы писать? По-моему вместо C еще долго не появится ни одного языка ему на замену.

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

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

По теме: http://www.linux.org.ru/view-message.jsp?msgid=2148854
http://blogs.sun.com/sundararajan/entry/scala_for_java_programmers
http://scala.sygneca.com/code/start

> Ни хрена се ты читаешь. У меня эти статьи заняли целый день чтобы прочесть. Надо же все пропустить через себя.

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

> А там много незнакомых понятий

А по-моему, Скала - очень "велосипедный" язык, ничего нового, всё было в Haskell/C#/Ocaml/ещегдето. В конце тюториала есть список языков, из которых взяты идеи.

Кстати, Одерский участвовал в разработке Java generics... вряд ли это является хорошей рекомендацией :)

s/тюториала/overview/

XML-литералы стали мэйнстримом, а маятник JVM-языков качнулся очень консистентно, что корежит даже эклипс. вот если делать паттерн-матчинг по XML-у(он пиздатый ЯП), то "велосипедный" язык круче учить по тюториалу

> ..и не системный он ЯП...

А кто сказал, что Scala должен быть системным? да и производительность НА СОВРЕМЕННОМ ОБОРУДОВАНИИ это лишь мнимая оценка реальных возможностей..

Пока что не понятно чем оно лучше JRuby того же

>Пока что не понятно чем оно лучше JRuby того же

Производительностью, ясен пень
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ruby&am...

Нет multiple dispatch в рантайме, вот скорость и сравнима с нативными языками aka C, C++, D, Clean

> А что, D или Ruby или Python или F# или Nemerle уже вытеснили C из ниши, системных языков, драйверы писать?

=) Особенно про Ruby понравилось.

> А нормальные языки с VM нужны нормальным, прикладным программистам, писать всякие жабберы, азуреусы и прочие аутлуки, опенофисы с эклипсами

Не спорю, нормальный язык это хорошо. А вот VM - всего лишь временные костыли, по странным, никому не понятным причинам ставшие _постоянными костылями_.

Вот никак не пойму, да, видимо, и мало кто сейчас поймёт, какой язык предпочесть, если хочется самую малость к JVM добавить функционального подхода? Вроде Groovy и развит сейчас уже больше, и информации по нему больше, да и конструкции в нём не ломают моск. Но что-то есть интересное и в Scala, чего Gr. не хватает

Что-то и не выбрать, и разбираться сразу в двух не охота. :)

> VM - всего лишь временные костыли, по странным, никому не понятным причинам ставшие _постоянными костылями_.

+inf

> какой язык предпочесть, если хочется самую малость к JVM добавить функционального подхода?

И функционального и какого хочешь подхода легко можно добавить с помощью MPS: http://www.jetbrains.com/mps/

Понимается с трудом, но если поймешь, любое расширение за сутки пишется. Один недостаток: почти никто пока не использует. Но куча умных людей уже считают, что за Language Oriented Programming будущее.

>Не спорю, нормальный язык это хорошо. А вот VM - всего лишь временные костыли, по странным, никому не понятным причинам ставшие _постоянными костылями_.

Кривая виртуализация и медленное переключение контекста в x86 ?

tailgunner, вспоминая твое высказывание про фреймворки, уточняю.

Я имею ввиду именно VM. Многофункциональный, качественный, модульный фреймворк никогда не помешает. Жаль, что модульности нет ни в JDK ни в .NET. Например, если моя программка производит страшные вычисления и из JDK использует только System.out и System.in, ей все равно понадобится вся JDK. У разработчиков Tango модульность неплохо получилась, но там сейчас нет полноты и надежности JDK.

Чем больше идей принесено на распространенные VM, тем лучше; поэтому JRuby и Scala  свою нишу найдут. Статья средней паршивости, впрочем :)

> Я имею ввиду именно VM

Я тоже. Всю эту бессмысленную тряхомудию с байткодом и круговоротом JIT в природе.

Посмотрел поближе на Scala. Приятный для глаза, и достаточно чистый. Порадовала наличием интерпретатора. Но мне показалось, что нет ничего такого, что может оправдать использование VM и низкую производительность.

Посмотрел на туториал. Много лишнего в коде. Кому с Жабы уйти не удаётся, может Скала и пригодится. А так Питон лучше.

>какой язык предпочесть, если хочется самую малость к JVM добавить функционального подхода?

Groovy похож на язык для быстрого написания скриптов и прототипов. Scala это упор на мультипоточность, отсюда название Scalable Language. Функциональность как средство достижения этой цели через Immutable objects

>А так Питон лучше.

Чем лучше? Что, в Python уже Actorы искаропки?

Не говори, анонимус. Ни Акторов, ни Функторов, ни этих, как ево, Джегериков! Лажа ваш Питон, ога.

>Пока что не понятно чем оно лучше JRuby того же

Скоростью (все можно скомилировать в .class, а там уже все упирается в кривость алгоритмов и производительность JVM) и интероперабельностью с жабой (и с груви). А уж какие либы из какого языка использовать - разницы все равно нет (один хрен все в байткоде JVM).

А про обработку XML в коде - это совершенно замечательная фишка - кому приходилось писать и отлаживать XSL с расширениями (например для работы с БД) тот в цирке не смеется....

+1

Hotya Scala ochen' dazhe posle OCaml.

> Скоростью

Ололо, иди с этим к девачкам. Скала нечеловечески медленна, при всей своей статической типизации она работает едва ли не медленнее Эрланга, не говоря уже о Хаскеле и ОКамле. Я уж молчу молчу про то, как JVM есть память. Добро пожаловать в реальный мир, анонимус.

> А про обработку XML в коде - это совершенно замечательная фишка - кому приходилось писать и отлаживать XSL с расширениями (например для работы с БД) тот в цирке не смеется....

Открой для себя CDuce/OCamlDuce и больше не смеши меня этим поделием.

> Scala это упор на мультипоточность, отсюда название Scalable Language. Функциональность как средство достижения этой цели через Immutable objects

Они не знали про Erlang? =:(

В Эрланге нет фигурных скобок => не годится для ынтерпрайза.

У интерпрайз абизьянок выработанный многолетний рефлекс на фигурные скобки?

>да и производительность НА СОВРЕМЕННОМ ОБОРУДОВАНИИ это лишь мнимая оценка реальных возможностей..

Ага. Память сейчас дешевая, процы - быстрые. И все с таки подходом хорошо до тех пор, пока не получается Windows Vista: жрет 750 мегабайт, тормозит на Intel Core 2 Duo.

>Ололо, иди с этим к девачкам. Скала нечеловечески медленна, при всей своей статической типизации она работает едва ли не медленнее Эрланга, не говоря уже о Хаскеле и ОКамле. Я уж молчу молчу про то, как JVM есть память. Добро пожаловать в реальный мир, анонимус.

Компилировать в class'ы не пробывал? (scalac'ом)

>Открой для себя CDuce/OCamlDuce и больше не смеши меня этим поделием.

Видишь ли дорогой ананимус, в перечисленных табой поделках нет тех библиотек/фреймворков и стандартов к которомы я привык, а еще к ним нет нормальных сред разработки с отладчичком и профайлером и пр. Так что эти свои поделия можешь засунуть себе... впрочем они и так там находятся (тебе может это не нравится, но это факт).

А поводу того что JVM есть память - вынь ручки из попки! Посмотри любую жабо программу под профайлером и ты сразу поймешь кто?, почему?, и сколько? ест.

P.S. К великому сожалению наш мир недетерминирован и все в нем обладает состоянием. Так что кривые академические поделки в которых надо извращаться с монадами для работы с вводом-выводом идут лесом.

<s>Java</s>Jaja и компания. :)

http://upyachka.ru/images/blog/00007509

>А по-моему, Скала - очень "велосипедный" язык, ничего нового, всё было в Haskell/C#/Ocaml/ещегдето.

+1. Но есть + - он интероперабельный с жабой. Если там все по теме гладко - то можно нафигачить прокси фреймворков на J2EE и все должно быть кошерно. Хотя если бы они реализовали лучше OCaml - их бы никто ногами бить не стал а скорее похвалили бы.

>Пока что не понятно чем оно лучше JRuby того же

Сча делаю проект на руби - начинаю его тихо ненавидеть. При чем не за язык, а за соглашения - я такое у перлпрограммистов видел некоторых. Когда аргументы функции подменяются одним аргументом типа hash абы было пофетишировать на смолтолк, а внутри еще если итдет распознавание типа "а вдруг стринг", "а вруг хеш" то я бы руки пооторвал этим гениям, которые такой апи сочиняют, по которому вообще нихрена вкурить нельзя чего собственно ждет функция, потому, что аргументы обявлены хешом. И не писать описание функций и типов аргументов для стандартных гемов - это позор - приходится методом тыка и глубокого анализа исходников подбирать, что оно хочет. Матц лучше бы малейшую культуру своим коллегам привил.

>Всю эту бессмысленную тряхомудию с байткодом и круговоротом JIT в природе.

Ну не скажи. Приятно не парится где собственно запускается твоя аппликуха. И да это реальность и да запускается на туче архитектур и да я этим пользуюсь в ентерпрайз левел аппликухах.

>Но мне показалось, что нет ничего такого, что может оправдать использование VM и низкую производительность.

А без JVM он нахрен никому не нужен. ТАм и без него хватает всяких окамлов.

>> Всю эту бессмысленную тряхомудию с байткодом и круговоротом JIT в природе.

> Ну не скажи. Приятно не парится где собственно запускается твоя аппликуха.

Байткод для этого не нужен и даже вреден :D (почитай Франца). И я еще не видел расчетов того, какой выигрыш достигается от dynamic JIT или как там называется эта техника JIT "с обратной связью".

>Байткод для этого не нужен и даже вреден :D (почитай Франца)

Он мне расскажет как ровно один и тот же код запустить на Win/Lin/Solaris(во всяком спектре начиная с SunOS5.2)/Irix/OSX/OS9/HPUX с незначительными телодвижениями в случае проблем? На всем этом у нас есть клиенты. При чем почти все с гетерогеникой типа OS9-Solaris-Win, OSX-Irix-Linux, etc...

>>Байткод для этого не нужен и даже вреден :D (почитай Франца)

>Он мне расскажет как ровно один и тот же код запустить на Win/Lin/Solaris(во всяком спектре начиная с SunOS5.2)/Irix/OSX/OS9/HPUX с незначительными телодвижениями в случае проблем?

Примерно. Он расскажет тебе, как _можно было бы_ это реализовать так, что не потребовалось бы 10 лет на доведение HotSpot до приемлимой скорости, и представит доказательства своей точки зрения.

>Примерно.

ДАвай ссылку.

> ДАвай ссылку.

Нет ссылки... была раньше здесь: http://www.ics.uci.edu/~franz/Site/pubs-pdf/J11Prepub.pdf, но, видно, убрали из открытого доступа, суки проприетарные :/ вот ее сокращенная версия http://www.ics.uci.edu/~franz/Site/pubs-pdf/C05.pdf

Его диссертация, на эту же тему: http://www.ics.uci.edu/~franz/Site/pubs-pdf/DissETH10497.pdf

Если есть доступ к ACM, IEEE и прочему, то здесь много интересного: http://www.ics.uci.edu/~franz/Site/publications