На мой взгляд, JavaFX все ещё сыровата. Когда последний раз смотрел, там нельзя было явно создавать потоки. Также непонятно, можно ли запускать JavaFX-приложения не через WebStart, а, например, из локального jar-файла без использования грязных хаков.

> из локального jar-файла без использования грязных хаков.

Там для такого идет утилита javafx, вместо java. NetBeans же не через вебстарт запускает.

Когда последний раз смотрел, там нельзя было явно создавать потоки

Там можно пользоваться любыми java классами. В том числе и ... Подставьте любое слово.

>Для такого всё-же лучше JavaFX =)

спорно. но в groovy и для javafx есть биндинги:
http://griffon.codehaus.org/FxBuilder

>> Там для такого идет утилита javafx

Но ведь она является частью JavaFX SDK, но не JRE? Формально JavaFX-приложения для запуска ничего, кроме обычной среды исполнения Java (версии 1.5 и выше) не должны требовать. А так придется тянуть ещё и SDK.

>спорно. но в groovy и для javafx есть биндинги:
http://griffon.codehaus.org/FxBuilder

Мне трудно себе даже представить, как это может тормозить... :)

>Также непонятно, можно ли запускать JavaFX-приложения не через WebStart, а, например, из локального jar-файла без использования грязных хаков.

А как вы груви-приложение из одного джарника запустите? :)

Это да. Я ранее писал на ЛОРе о это проблеме. Только с SDK

Вам мешает рядом лежащий groovy-all.jar?

нет, мне и SDK не мешает ;)

>Нафига? Все оно правильно делает - замыкание это тоже функция и return к ней и относится.

Здесь вопрос не в правильности/неправильности. Просто такой синтаксис groovy.))))

С замыканий намного удобней «выпрыгивать» с помощью break, а с метода с помощью return, даже если выполняется код внутри замыкания (как в ruby). А то если результат уже есть внутри замыкания, часто приходится писать дополнительные конструкции. groovy подход не даёт использовать возможности замыканий на все 100%, а жаль, это очень мощная вещь.

>Просто такой синтаксис groovy.))))

Нет, это просто такой изврат в ruby :\

Нет, всё логично, может вы и из циклів хотите выходить с помощью return-а. Хотя проблема, может к стати может быть и решена добавлением нового ключевого слова, чтобы старые программы на groovy работали также.

P.S. Мы собственно используем, groovy в промышленных целях, а что делать, jruby слишком слабо интегрирован в Java, jython, как и python слабо поддерживает ООП.

Где вы Qt'шники

С джавой и груви - незадача. Попробуйте запустить этот код на Maemo или Windows Mobile. Не выйдет. К сожалению, джава оказалась не столь уж и кроссплатформенной, как обещалось. А Qt(+Python) вроде спокойно можно запустить уже почти везде. В общем, XXI век на дворе, а IT всё ещё в каменном веке.

>А Qt(+Python) вроде спокойно можно запустить уже почти везде

Windows Mobile? Symbian без кастрирования? iPhone? Android?

>А Qt(+Python) вроде спокойно можно запустить уже почти везде.

почти везде - это maemo+чуть-чуть symbian?

Ну не реагируйте так. Человек просто высказал ИМХО. Вы думаете он проверил все платформы? Ляпнул что бы не молчать «нативный код на С++ работает везде»

Конечно таки JVM работает везде, но groovy не тестил... Там надеюсь нет ничего такого, что Java ME не переваривает. Кто нибудь знает?

Веселится и ликует весь народ

Usually I do not participate in the discussion but read it often. This time, however, I would like to say a few words. Recently, I have implemented an algorithm which required operation with high order abstraction in C++, java, ruby, scala and groovy for self educational purposes. C++ version appeared 100 times faster (in average). Conclusion. There are no compelling reasons to program in any of these high order languages. However, regular programmers in India and etc. are unable to operate with abstractions efficiently due to lack of sufficient educational background. For them one-fits-all set of routines has been developed which wraps-up the complexity of algorithms and which give raise to java, ruby, scala, groovy and etc. But, the bottom line is following. All this is coming to the end. Those who can read English may examine very interesting document «Task Force on Diversifying the New York State Economy through Industry-Higher Education Partnerships.» (http://www.state.ny.us/governor//reports/pdf/IHETF_Report_FINAL.pdf) The essence of this 93 page document is following: the end of outsourcing and development very own highly educated force capable to do stuff. Which means the end of OpenSource in near future because those capable people who try to find themselves because they were pushed out of the system will be assimilated a put to work. These people do not need java, ruby, scala, groovy and etc. They are those who operate with abstractions and actually implemented them in C and C++ and wrap them up in more simple syntax of these nova-days languages.

(Sorry for English, try in Russian but can do it)

>Ну не реагируйте так. Человек просто высказал ИМХО. Вы думаете он проверил все платформы?

проверил? а что именно он проверил?

учитывая тот факт, что ME - это даже не java 1.4, то не только groovy на ME не заработает, но и большинство современных либ.

>Recently, I have implemented an algorithm which required operation with high order abstraction in C++, java, ruby, scala and groovy for self educational purposes. C++ version appeared 100 times faster (in average).

в 100 раз быстрее java/скалы? ну толсто же, либо очередной баг в скале...

In the case of scala it was 10 times faster. Please, do not forget that scala, at the end is a byte-cod, unless there is underlying actual call to library written in c or c++ it will slow, very slow.

Вас кто-то калёным железом заставляет пользоваться чем-то кроме С++ (не смешите «высокими абстракциями» на си)?

Код бенчмарков где?

Не. Динамическая типизация не для меня. Может кому и удобно, но шанс «наступить» очень велик.

Вообще динамическая типизация не зло, а зло не типизированные операции вроде: сложения строк и чисел (2+2=4 или 22), деление дробных и целых (5/2=2.5 или 2). Знак операции один, а операции совершенно разные, если бы знаки были разные, то автоматическое приведение типов не было бы столь большим злом, а так приходится смотреть, что за тип переменных чтобы понять какой результат будет (если разбираться в чужой вермишели), ну и отсутствие двусмысленности позволяет избегать ошибок.

Truth!? You can't handle the truth!

The truth is benchmarks are meaningless. The point was that it is unnecessary to use nova-days languages. But as long as you asked. Ruby 1.8.7 - 6.613208 sec Ruby 1.9.1 - 2.176231242 sec JRuby 1.40 - 2.57 sec scala 1.7.0 - 0.441 sec C++ - 0.0000616958 sec

For finding of all subranges of given range. Do cod for yourself. Use custom iterator for C++. (Not exactly the algorithm I was talking about)

>scala 1.7.0 - 0.441 sec C++ - 0.0000616958 sec

какая-какая скала? да и потом, вы время стартапа/JIT'а учитывали хоть?

Обычно не учитывают. Ключи запуска JVM тоже мало

Чем оно лучше Common Lisp?
И еще такой вопрос - те, кто орет «груви рулез» и т.п. - пробовали ли, собственно, первый(не кокаин, всмысле, а CL)?

Scala Full cod. See for your self I do not have groovy installed **************************************** object Main { def main(args: Array[String]): Unit = { val s=«AGTFRVYKTakljdlkesfj;sdjfn;sdjfn;sdjfn;dsj;jv;jvn;dsjvn;dsjvn;dsvn;dslvnk;sdlvn;sdlnv;dlfvn;lsdnvl;dnkv;dlsknv;dlsvnk;lasdnksdlkngvoegh'ldfk» var step=0 var times=0 val now = System.currentTimeMillis(); while(times<=100){ val steps= 0 until s.length-1 steps.foreach(step=>{ var subrange=0 until step var first=0 var last=step var currentRange=first until last while(steps.contains(first) && steps.contains(last)){ first=first+1 last=last+1 currentRange=first until last } }) times=times+1 } val then = System.currentTimeMillis(); val diff=(then-now) println(diff) }

} *************************************

<i>Ляпнул что бы не молчать «нативный код на С++ работает везде» </i> Я имел ввиду, что код на PyQt4(в скобках как бы) будет работать вообще без изменений почти везде. А код на С++ просто надо перекомпилировать (в смысле, не надо переписывать или проводить что-то типа хилдонизации)