Scala: A Scalable Language

>Жаба везде!

хорошо наверное жить в собственном уютном мирке

> На яве/с++ с исключениеми вообще отлично будет.

На яве это будет полный кал. Представь, что тебе надо открыть не один файл, а три. В итоге только обвязка, т.е. три вложенных try-finally блока, даст строк 15 boiler-plate кода минимум. Плюс волшебные checked exceptions раздуют этот код ещё в два раза. В то же время нормальная поддержка лямбда-выражений позволила бы выразить тот же функционал гораздо короче, см. например лисповский with-open-file.

> Так в чем конкретно преимущество? Покажите, чем "лямбда-выражение" лучше старого-доброго подхода?

Да и просто работа с коллекциями в фунциональном стиле на мой вкус выглядит гораздо симпатишнее.

InputFileStream f1 = null, f2 = null, f3 = null;
try {
    f1 = new ...;
    f2 = new ...;
    f3 = new ...;
} finally {
    if (f1 != null) {
        f1.close();
    }
    if (f2 != null) {
        f2.close();
    }
    if (f3 != null) {
        f3.close();
    }
}

ась?

s/InputFileStream/FileInputStream

> Как это? Что вы хотели этим сказать?

Что M$ не имеет к нему совершенно никакого отношения, более того - "отцы основатели" разарабатывали его под моно и линуксом (по крайней мере - один из них) ;)

> В каком смысле? Главный разработчик на него забил или как?

Именно. Оба его автора в его-же рассылке заявили что не имеют больше времени и/или интереса для дальнейшего участия в его развитии.

> Например для меня, с появлением Groovy, питон/перл/руби умерли! Потому что, получая все рюшечки динамических языков, я в тоже время сохраняю полную интероперабельность с жабой.

Я бы с вами совершенно согласился, но скорость!...

> А где нужны функциональные возможности?

При написании программ вестимо. А вы где думали?...

> В основном данные на предприятиях хранятся в РБД...

Ни какого отношения ни к ФП-щине ни к ООП-щине

> ...для отображения юзерям хватает ООП...

Юзверям вообще пофиг. Code-monkeys конечно проще то, что вбито в голову. Многим людям не хватает "фишек ФП" (в дополнение к..., а кому-то и "только" ;)

> Куда всунуть функциональщину?

Судя по всему - тебе некуда. Расслабься.

>Именно. Оба его автора в его-же рассылке заявили что не имеют больше времени и/или интереса для дальнейшего участия в его развитии.

Это ты http://www.rsdn.ru/Forum/message/2649855.flat.aspx#2649855 здесь прочитал?

>При написании программ вестимо. А вы где думали?...

>> В основном данные на предприятиях хранятся в РБД...

>Ни какого отношения ни к ФП-щине ни к ООП-щине

>> ...для отображения юзерям хватает ООП...

>Юзверям вообще пофиг. Code-monkeys конечно проще то, что вбито в голову. Многим людям не хватает "фишек ФП" (в дополнение к..., а кому-то и "только" ;)

>> Куда всунуть функциональщину?

>Судя по всему - тебе некуда. Расслабься.

Ничего. Это бывает. Пойдешь искать работу, вся эта твоя студенческая спесь пройдет. Будешь на "нанотехнологов" в визуал студии 2010 спину гнуть за $1000/month

>fd = open("file.txt") if (fd > 0) { ... close(fd) }

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

Человек может держать в памяти не более 6-7 объектов, поэтому расточительно тратить человеческие возможности на всякий побочный мусор (именно поэтому так хороши DSL - ничего лишнего). Человек мыслит объектами, поэтому иметь объект-функцию со встроенной в язык поддержкой (или созданной средствами метапрограммирования) хорошая идея. Отдельно скажу про обработку коллекций: я думаю бесполезно объяснять людям что либо, если они никогда не видели в глаза лисп (ну или хотя бы руби или ему подобный язык, например пайтон, хотя там обычно предпочитают list comprehension, но это видимо из-за того что слишком много code-monkeys им пользуються)

> Что M$ не имеет к нему совершенно никакого отношения

Ок. Я теперь знаю, что родной для .NET значит то, что создано в MS.

> пайтон, хотя там обычно предпочитают list comprehension, но это видимо из-за того что слишком много code-monkeys им пользуються

А list comprehensions в Эрланге - это тоже от засилья code monkeys? Вроде и в Хаскеле есть list comprehensions - тоже monkeys?

>Ок. Я теперь знаю, что родной для .NET значит то, что создано в MS.

Ну наконец-то. Теперь ты узнал. И Mono поделка любителей. MS не нужна Mono

> Ничего. Это бывает. Пойдешь искать работу, вся эта твоя студенческая спесь пройдет. Будешь на "нанотехнологов" в визуал студии 2010 спину гнуть за $1000/month

Я же сказал - расслабься. Я как раз по середине трудового стажа ;)

> ась?

OK, 11 строк, только catch IOException осталось расставить, попробуйте. Так, чтобы вылет оного из f1.close() не мешал остальным.

>> ась?

> OK, 11 строк, только catch IOException осталось расставить, попробуйте. Так, чтобы вылет оного из f1.close() не мешал остальным.

А как насчет эквивалентного кода на Руби?

> Метапрограмирование является подпоркой и говорит о несовершенстве семантического базиса языка программирования

Чушь.

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

P.S. Твоя фамилия не Зефиров? А то уж больно похожие речи.

> моно ненужно. Не нужны красноглазые интеллектуальные недомерки с ЛОРа.

> А где нужны функциональные возможности?

Вылезай из танка, ламер. Они везде нужны. В том числе и в работе с реляционкой.

Забавен однако нынешний ЛОРовский контингент. Такого отребья как сейчас ещё никогда не было.

> Приведите такой же пример.

Ты никакого примера, между прочим, и не привёл, ламерюга презренный.

Ха ха ха. Сосунок пытается рассказать, какое оно взрослое и какое оно зарабатывающее. Вот это на ЛОРе никогда не меняется, мразь остаётся такой же.

Простите, что прерываю великоучёное обсуждение, но хочу добавить по теме новости: на тоим же сайте выложены 3 главы из книги "Programming in Scala" в PDF.

Садись, два. Если f1.close() бросит исключение, f2 и f3 не закроются.

>OK, 11 строк, только catch IOException осталось расставить, попробуйте. Так, чтобы вылет оного из f1.close() не мешал остальным.

В принципе, для InputStream-а можно IOUtils.closeQuietly(), который глотает исключения. Так как мы вычитали всё, что нам нужно, на исключение при закрытии можно забить (но надо всё-таки хотя бы залогировать).

>Я бы с вами совершенно согласился, но скорость!...

Она почти одинакова, вот пример:

груви (компилируем в class и запускаем через "java -server -Xbootclasspath/a:......."):
def fib(int _n)
{
if (_n == 0) {return 0;}
else if (_n == 1) {return 1;}
else {return fib(_n-1)+fib(_n-2);}
}

startTm = System.currentTimeMillis();
println fib(36);
endTm = System.currentTimeMillis();

println "Total time: "+((endTm - startTm)/1000);

Результат:
Total time: 27.396

питон:
#! /usr/bin/python2.5
import time
def fib(n) :
if n==0:
return 0
elif n==1:
return 1
else:
return(fib(n-1)+fib(n-2))


time_begin=time.clock()
the_end_count=36
print fib(the_end_count)
time_end=time.clock()
real_time=time_end-time_begin
print real_time

Результат:
26.87


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

>А как насчет эквивалентного кода на Руби?

Что мешает посмотреть как этот код выглядит на руби самостоятельно? Я все время убеждаюсь, что людей умеющих пользоваться поиском - единицы, а реально умеющих писать программы еще меньше. К сожалению я могу себя полностью отнести только к первой категории, так что я все таки приведу код

Все зависит от того что нужно. В крайнем случае никто не запрещает воспользоваться стандартной схемой с исключениями. Интересней другое, а именно некоторые частные случаи, на которых можно сэкономить. Например нужно только лишь прочитать что-то из файла: File.open('file.txt'){|f| ...f.gets... } if File.readable?('file,txt') Или прочитать все: text = File.read('file.txt') if File.readable?('file.txt') Конечно есть всякие writable?, exist? и прочее.

> Мартин Одерски является создателем компилятора javac.

Чей-то похоже на явный ГОН! Читаем

Martin Odersky (b. 5 September 1958) is a professor of programming methods at the EPFL. He specialises in code analysis and programming languages.

He designed the Scala programming language and Generic Java.

He was programme Chair of ECOOP 2004. In 2007 he was inducted as a Fellow of the Association for Computing Machinery.

Martin Odersky heads the programming research group at EPFL. His research interests cover fundamental as well as applied aspects of programming languages. They include semantics, type systems, programming language design, and compiler construction. The main focus if his work lies in the integration of object-oriented and functional programming. His research thesis is that the two paradigms are just two sides of the same coin and should be unified as much as possible. To prove this he has experimented with a number of language designs, from Pizza to GJ to Functional Nets. He has also influenced the development of Java as a co-designer of Java generics and as the original author of the current javac reference compiler. His current work concentrates on the Scala programming language, which unifies FP and OOP while staying completely interoperable with Java and .NET.

Martin Odersky got his doctorate from ETH Zürich, in 1989. He held research positions at the IBM T.J. Watson Research Center from 1989 and at Yale University from 1991. He was then a professor at the Univerisity of Karlsruhe from 1993 and at the University of South Australia from 1997. He joined EPFL as full professor in 1999. He is associate editor of the Journal of Functional Programming and member of IFIP WG 2.8. He was conference chair for ICFP 2000, and program chair for ECOOP 2004 as well as ETAPS/CC 2007.

То есть это ТЕОРЕТИК. Который ни разу не принимал участия в коммерческом проекте! :)))) В отличие от Tim Lindholm и Frank Yellin из SUN.

>> А где нужны функциональные возможности?

> Они везде нужны

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

Как "сделали" крупного профессора Лугоффского на форуме

"Молодец, а какой молодец. А ты на Бентли ездишь?" (с)

"Я велосипед предпочитаю." (с)

http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654

"as the original author of the current javac reference compiler" - где это еще подтверждается? Ведь сам себя не похвалишь, кто же похвалит? Это господин участвовал в JSR-014. "Odersky's GJ compiler is the basis of Sun's current javac compiler " Но все-таки это только базис, а не сам компилятор.

"GJ is an extension of the Java programming language that supports generic types.

GJ was designed by Gilad Bracha of JavaSoft, Martin Odersky of the University of South Australia, David Stoutamire of JavaSoft, and Philip Wadler of Bell Labs, Lucent Technologies. Although JavaSoft employees contributed to its design, GJ is not a product of JavaSoft or Sun Microsystems and neither JavaSoft nor Sun Microsystems makes any claims regarding it."

Так, что фраза "Мартин Одерски является создателем компилятора javac" - это явно игра в "испорченный телефон".

>Так, что фраза "Мартин Одерски является создателем компилятора javac" - это явно игра в "испорченный телефон".

ну он в любом случае имеет отношение к созданию компилятора - scalac ;)

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

Параноид. Как у людей сил хватило QT4 накатать?

>>Я бы с вами совершенно согласился, но скорость!...

>Она почти одинакова, вот пример:

<skip code>

Да, но это только треть дела. Вы предложили замену "скриптовым языкам". А значит надо сравнивать и скорость интерпретации кода и скорость загрузки среды (фиг с ним - скорость компиляции опустим). Вот по этим параметрам Groovy "сливает по полной". А в откомпилированном виде он в хвосте прочих компилируемых в JVM языков.

А простой доступ ко всем java-библиотекам я и в kawa имею ;)

>Да, но это только треть дела. Вы предложили замену "скриптовым языкам". А значит надо сравнивать и скорость интерпретации кода и скорость загрузки среды (фиг с ним - скорость компиляции опустим). Вот по этим параметрам Groovy "сливает по полной". А в откомпилированном виде он в хвосте прочих компилируемых в JVM языков.

вот запуск без явной генерации class файлов (groovy fib.groovy):

Total time: 28.35

А нахрена его интерпретировать, когда можно сформировать бкод, загрузить в JVM и тут же выполнить. Так что нихрена он не сливает. Хотя сам старт среды+компиляция бкода возможно идет дольше. Лично для меня скорость старта JVM не являтся критичным моментом - гораздо важнее удобство для быстрого прототипировния и интероперабельность с жабой. И еще один момент - замечательная встраиваемость в жабу - подгрузить откуда угодно исходники (файлы/сеть/база), скомпилировать их не доходя до фазы генерации файлов и тут же засунуть в класслоадер (а его потом установить загрузчиком по умолчанию для спринга - ловкость рук, две сотни строк кода и никакаго мошеничества). Так что для меня перл/питон/руби мертвы.

>Ещё бы метапрограммирование скале.

зачем? там есть lazy и call by name - это позволяет делать очень многое из того, для чего предназначено "метапрограммирование".

одно гнусно - всякие "magic words" типа "apply" - это значит "a()", update - значит "a(i) = x", всякие там Tuple1, ... Tuple22, Function1, ..., Function22, (неправда ли веет С++ шными именами темплейтов сгенеренными макрой?), нельзя писать идентификаторы типа "go!" поэтому лепят "go_!" или "`go!`" например автогенерируемые сеттеры для "x" выглядят как "x_=" и т.п. сор.

идея хороша, однако до практического применения, как мне кажется, еще не доросла.

> вот запуск без явной генерации class файлов (groovy fib.groovy):

> Total time: 28.35

Есть подозрения что Groovy слукавил и взял имеющийся .class файл, ибо у меня питон на интерпретации показал 20 секунд против 135 у Groovy. Где-то собака порылась...

> А нахрена его интерпретировать, когда можно сформировать бкод, загрузить в JVM и тут же выполнить.

Тогда это та-же java, только с другим синтаксисом (согласен, более приятным), но и более тормознутая

> Лично для меня скорость старта JVM не являтся критичным моментом - гораздо важнее удобство для быстрого прототипировния и интероперабельность с жабой. И еще один момент - замечательная встраиваемость в жабу - подгрузить откуда угодно исходники (файлы/сеть/база), скомпилировать их не доходя до фазы генерации файлов и тут же засунуть в класслоадер (а его потом установить загрузчиком по умолчанию для спринга - ловкость рук, две сотни строк кода и никакаго мошеничества).

Groovy - не единственный в таком роде.

> зачем? там есть lazy и call by name - это позволяет делать очень многое из того, для чего предназначено "метапрограммирование".

??? Метапрограммирование предназначено для кодогенерации, и с его помощью можно делать _и_ то, для чего предназначены "lazy и call by name" - разницу улавливаешь?

>Метапрограммирование предназначено для кодогенерации, и с его помощью можно делать _и_ то, для чего предназначены "lazy и call by name" - разницу улавливаешь?

нучитесь читать (и думать). было сказано "позволяет делать очень многое из того, для чего предназначено "метапрограммирование"."

например в лиспе "for" можно сделать с помощью макры и никак иначе, а в скале для этого вполне хватает пресловутого "call by name".

>Есть подозрения что Groovy слукавил и взял имеющийся .class файл, ибо у меня питон на интерпретации показал 20 секунд против 135 у Groovy. Где-то собака порылась...

Нет

На чем запускали?

Я: JDK1.6u6, groovy 1.5.6, Athlon X2, Linux

Я имел в виду javac. Над GJ работала группа из 4 человек. Так, что сведения о данном господине, как о "Творце" javac, мягко говоря, преувеличены. Это все равно, что Луговского назвать создателем jikes, хотя он, если я правильно помню, "мантейнил" этот пакет в АЛТ'е. :)

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

> нучитесь читать (и думать).

ну давай попробуем :)

> было сказано "позволяет делать очень многое из того, для чего предназначено "метапрограммирование"."

На что я возразил, что "метапрограммирование" предназначено исключительно _для_ кодогенерации, с помощью которой можно реализовать очень многое, в том числе и то, что в других языках позволяют "lazy и call by name" - что не так?

> например в лиспе "for" можно сделать с помощью макры и никак иначе, а в скале для этого вполне хватает пресловутого "call by name".

Да? И то что вы наваяете в скале на 100% покроет возможности for-а из CL? "Не верю!" :)

> Я: JDK1.6u6, groovy 1.5.6, Athlon X2, Linux

JDK тот-же, groovy 1.5.4, старенький интел на 2.8, оффтопик... Может в последнем дело? :)

>JDK тот-же, groovy 1.5.4, старенький интел на 2.8, оффтопик... Может в последнем дело? :)

седня вечером проверю

Задачка прохвессору Одерскому. JSR-14, типа. Что будет

// polymorphic recursion

class MyClass<T> {  
  public Object nest(int i) {
    if (i == 0) {
        return this;
    }
    else {
        return new MyClass<MyClass<T>>().nest(i - 1);
    }
  }
}

при больших значениях i?

(StackOverflowError рано или поздно - это классика!)

Как это обойти? (3 способа предлагается, правда "ручками", решил некто Eric Allen)

Так, что одно не довел этот теоретик М.Одерский одно до завершения, а уже за другое берется. Типа, "Движение все - конечная цель ничто" (с).

>Представь, что тебе надо открыть не один файл, а три. В итоге только обвязка, т.е. три вложенных try-finally блока, даст строк 15 boiler-plate кода минимум.

Никому больше про такое не рассказывай.

>В то же время нормальная поддержка лямбда-выражений позволила бы выразить тот же функционал гораздо короче, см. например лисповский with-open-file.

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

Что будет есть в руби File.open("") {...} внутри произойдет исключение?

Магии не будет - ее отменили в 1917.

>Да и просто работа с коллекциями в фунциональном стиле на мой вкус выглядит гораздо симпатишнее.

Вот тут как пить дать.

>А как насчет эквивалентного кода на Руби?

На руби эквивалентного кода не бывает - его видно в логе монгрегля - рубипрограмеры относятся к IO исключениям как к пргограммерским ошибкам и исправляют их подкладывая ненайденный файл:)

>Садись, два. Если f1.close() бросит исключение, f2 и f3 не закроются.

Все давно уже написали или пользуют apache-commons-io подобного типа:

class IOUtils {
  public static void closeQuietly(Closable closable) {
      try {
          if (closable != null) closable.close();
      } catch (IOException e) {
          log.warn(e,e);
      }
  }
}

и де долбят друг другу мозги детскими вопросами.

>Конечно есть всякие writable?, exist? и прочее.

Больше вопросов нет, школьник.

> Что будет есть в руби File.open("") {...} внутри произойдет исключение?

Не знаю как в руби, а в CL with-open-file (with-open-stream) всё корректно закроет. Цитата из Hyperspec:

stream is automatically closed on exit from with-open-stream, no matter whether the exit is normal or abnormal.