JRuby 1.1

> Python наше всё!

у питона есть стандарт, который не меняется гвидо, когда он захочет?

Вот тут кто-то gil упомянул :) А ведь даже были попытки сделать питон без жил, да вот гвидо сказал надо, пионерия ответила, что жил это круто.

>> А ведь даже были попытки сделать питон без жил

во времена 1.5 версии.

>во времена 1.5 версии.

А stackless?

> А stackless?

Давно ее не щупал. Когда щупал, такая дрянь была.

>Давно ее не щупал. Когда щупал, такая дрянь была.

Я тоже не щупал. Но сегодня на stackless крутится сервер EVE-Online. А это - десятки тысяч народа в онлайне. ИМХО, проблемы GIL там нет :D

Интересно, а зачем интерпретатор писать на Жабе? Много свободного времени у теоретиков от программирования?

>Интересно, а зачем интерпретатор писать на Жабе?

Чтобы был Ruby, взаимодействующий с JVM.

...

Вот тот же Quercus, например. Позволяет писать на PHP и спокойно дёргать из него методы на Java. Берёшь и расширяешь банальную Mediawiki или punBB скоростными Java-методами.

> Чтобы был Ruby, взаимодействующий с JVM

А зачем это нужно? Реально бабло за джаву башляют, а не за теоретические изыски. Платят (я имею в виду нормальные деньги, а не грошевые гранты во всяких НИИЧАВО) за результат работы коммерческой проги, а не за то, что кто-то считает себя шибко яйцеголовым.

Короче, JRuby - еще один "сферический конь в вакууме" (с).

>А зачем это нужно? Реально бабло за джаву башляют, а не за теоретические изыски.

Для меня востребованы Quercus, Jython и JBForth.

Вполне легко допустить по аналогии, что для кого-то востребован и JRuby.

А то, что тебе это нах. не надо, других не колышет. Как это для тебя ни прискорбно, ты не пуп земли.

А какую IDE для jython используешь?

> А ведь даже были попытки сделать питон без жил, да вот гвидо сказал надо

Гвидо ничего такого не говорил - просто CPython без GIL получился в полтора раза медленнее. Jython и IronPython сделаны без GIL, IIRC.

>> А зачем это нужно? Реально бабло за джаву башляют, а не за теоретические изыски.

> А то, что тебе это нах. не надо, других не колышет. Как это для тебя ни прискорбно, ты не пуп земли.

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

>А какую IDE для jython используешь?

Я вот давеча посмотрел на плагин PyDev, ничего так. Всех возможностей Eclipse у него нет, но поудобнее чем emasc/vim для скриптов длиннее 20 строчек.

>> Гвидо ничего такого не говорил

дада, гвидо сказал шо это сильно сложно убрать GIL.

Кстати Jython быстрее работает с потоками. проверял на задаче, которой требовалось около часа на двухголовом кзеоне. Jython быстрее чуть ли не на 20 минут с ней справился.

J# закрыли. Шоб не конкурировал с C#

>> Гвидо ничего такого не говорил

> дада, гвидо сказал шо это сильно сложно убрать GIL.

Ты читать умеешь? GIL убрали однажды, это не дало выигрыша для CPython.

> Ты читать умеешь? GIL убрали однажды, это не дало выигрыша для CPython.

У меня есть подозрения что refcounter не лучший механизм для обеспечения thread-safe garbage collector. По-видимому попытались забить гвоздем да получилось тормознуто, а на нормальный generational gc со thread-safe силенок не хватило.

Кстати, ты зря гвидо мажешь. Точно помню ссылку на english, где он морозил, что ГИЛ зашибись и вообще потоки треш, а лучше использовать fork. Так, что не обманывай, врунишко.

> У меня есть подозрения что

Твои подозрения - это веско.

> refcounter не лучший механизм для обеспечения thread-safe garbage collector

Он знал джиу-джитсу, кунфу, каратэ и много других страшных слов.

> Кстати, ты зря гвидо мажешь.

Вот что сказал Гвидо: http://www.artima.com/weblogs/viewpost.jsp?thread=214235

Для труЪ:

"I would also be happy if someone volunteered to maintain a GIL-free fork of Python, in case that the single-threaded performance goal can't be met but there is significant value for multi-threaded CPU-bound applications."

"While it is my personal opinion, based upon the above considerations, that there isn't enough value in removing the GIL to warrant the effort, I will welcome and support attempts to show that times have changed."

> Точно помню ссылку на english, где он морозил, что ГИЛ зашибись и вообще потоки треш

...а не на мутные цитаты с непонятным контекстом.

> Так, что не обманывай, врунишко.

Бггг. Пруфлинк или фэйл.

>> refcounter не лучший механизм для обеспечения thread-safe garbage collector

> Он знал джиу-джитсу, кунфу, каратэ и много других страшных слов.

Про это есть много литературы. Тебе дать ссылку на Гугл?

>> Точно помню ссылку на english, где он морозил, что ГИЛ зашибись и вообще потоки треш

> ...а не на мутные цитаты с непонятным контекстом.

Я знал, что ты это попросишь =))))) :

http://mail.python.org/pipermail/python-3000/2007-May/007414.html

Для Труъ:

The difference is, for an OS kernel, there really isn't any other way to benefit from multiple CPUs. But for Python, there is -- run multiple processes instead of threads! (это про fork)

===

Nevertheless, you're right the GIL is not as bad as you would initially think: you just have to undo the brainwashing you got from Windows and Java proponents who seem to consider threads as the only way to approach concurrent activities. (это о том, что ГИЛ зашибись)

Just because Java was once aimed at a set-top box OS that didn't support multiple address spaces, and just because process creation in Windows used to be slow as a dog, doesn't mean that multiple processes (with judicious use of IPC) aren't a much better approach to writing apps for multi-CPU boxes than threads. (это тоже про fork)

Ну и напоследок, пионерия радостно запевает вместе с Гвидо:

Just Say No to the combined evils of locking, deadlocks, lock granularity, livelocks, nondeterminism and race conditions.

>>> refcounter не лучший механизм для обеспечения thread-safe garbage collector

>> Он знал джиу-джитсу, кунфу, каратэ и много других страшных слов.

> Про это есть много литературы. Тебе дать ссылку на Гугл?

Мне - не нужно. А ты поищи, в чем были проблемы Питона без GIL. Хинт - это была не сборка мусора.

> Nevertheless, you're right the GIL is not as bad as you would initially think: you just have to undo the brainwashing you got from Windows and Java proponents who seem to consider threads as the only way to approach concurrent activities. (это о том, что ГИЛ зашибись)

Нет, ты точно не умеешь читать. "GIL is not as bad as you would initially think" - это значит, что GIL всё же bad, просто не настолько, как изначально заявлялось. Но он всё же bad.

> Just Say No to the combined evils of locking, deadlocks, lock granularity, livelocks, nondeterminism and race conditions.

Ну да, в мнении других тоже виноват Гвидо. Вопросов больше нет.

> Эта версия Руби еще интересна тем, что поддерживает нативные потоки без GIL-a(привет питону :)) и может работать прозрачно с явовскими библиотеками. Кроме того есть glassfish gem для удобного деплоймента на соответствующий веб-сервер.

Ну вообще-то jython тоже держит нативные потоки без GIL-а и может работать прозрачно с явовскими библиотеками. Кстати, IronPython тоже держит нативные потоки без GIL-а. Так что мимо кассы, ничего уникально хорошего в вашем раби нет..

> Ну да, в мнении других тоже виноват Гвидо. Вопросов больше нет.

Гвидо такой маленький, что не отвечает за то, что он говорит? Тогда и вправду вопросов больше нет.

> Так что мимо кассы, ничего уникально хорошего в вашем раби нет..

В пейсоне уже сделали нормальные блоки? Или Гвидо так давно писал python.y что забыл как bison-ом пользоваться?

> А зачем это нужно?

Интегрировать фронтальный сервер на RoR с интранет-сервером на jBoss Portal и с GroupWare сервером на IceCore. Или для наиболее полной имплементации JSR-168 средствами Ruby. Или для использования массива кода на Ruby в проектах на Java/Scala/etc.

> Короче, JRuby - еще один "сферический конь в вакууме" (с).

Можно подумать что хоть кто-то сомневался в твоем мнении.

А есть C# на java?

> В пейсоне уже сделали нормальные блоки?

А чем сейчас не нормальные? может хватит уже пользоваться досовскими редакторами без разметки.

был, да весь вышел.

> Интересно, как скорость его соотносится с оригинальным Ruby? Да плевать на это. где то тут недавно инфа пролетала, что сам основной Руби почти в 100 раз медленне, той же быдложабы. Поправте если ошибаюсь.

>Ну вообще-то jython тоже держит нативные потоки без GIL-а

Если бы Jython ещё бы понимал хотя бы Python 2.4 :-/

Кроме того, боюсь, Jython намного тормознее JRuby. Когда я его последний раз бенчил (правда, было это давно) Фибоначи он считал в 29 раз медленнее, чем PHP.

>А есть C# на java?

Есть. Java называется.

>>> Эта версия Руби еще интересна тем, что поддерживает нативные потоки без GIL-a(привет питону :))

Ага, привет JRuby от Jython, умник, ёлки-палки :-)

Если бы Jython ещё бы понимал хотя бы Python 2.4 :-/

Кроме того, боюсь, Jython намного тормознее JRuby. Когда я его последний раз бенчил (правда, было это давно) Фибоначи он считал в 29 раз медленнее, чем PHP. (c) Крон 3 постами выше

2anonymous (*) (07.04.2008 17:52:53):

>> В пейсоне уже сделали нормальные блоки? Или Гвидо так давно писал python.y что забыл как bison-ом пользоваться?

А ещё Python не похож на ML языки, например, и что из того?

>>> Кроме того, боюсь, Jython намного тормознее JRuby.

Мне это, в общем-то, всё равно. Я не особенно перевариваю Ruby вообще, и JRuby в частности. До масштабируемости Python ему далеко. Ruby не годится для крупных проектов. Разве что для мелкого скриптования. Здесь его ниша.

Получается что J# есть, а JCsharp нету?
Не верю (с)

> А ещё Python не похож на ML языки, например, и что из того?

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

Если бы Ocaml пиарили так же как Haskell, функциональные языки уже давно могли бы занять достойное место в программировании. А так подходит ко мне человек, спрашивает чего-бы поучить из функционального... Ну я ему говорю, попробуй Окамл, Хаскелл или Эрланг. Он слышит Хаскелл - имя на слуху и уходит. Хотя посидит он за ним недельку и забьет. А Окамл намного добрее к новичкам и ближе к жизни, да и язык красивый и по-скорости шустрый.

А чего с хаскеллем не так?

> А чего с хаскеллем не так?

Тяжелее он людям дается. Окамль выучить напорядок проще. И дело не только в сложности языка но и в количестве литературы и документации. Если бы их поменять местами по распиаренности, думаю функциональные языки были бы намного популярнее, чем сейчас.

>Если бы Jython ещё бы понимал хотя бы Python 2.4 :-/

>Кроме того, боюсь, Jython намного тормознее JRuby. Когда я его последний раз бенчил (правда, было это давно) Фибоначи он считал в 29 раз медленнее, чем PHP.

Ну ничего, Sun в марте наняла двух разработчиков Jython, надеюсь они его подтянут до уровня.

Вообще, хорошо что проект ожил (в прошлом году)...

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

1. Oсaml пиарится как F#.

2. Однако, Ocaml в руках среднего программиста может стать не особо функциональным, как и ерланг. А Хаскелл -- Ъ.

> Да плевать на это. где то тут недавно инфа пролетала, что сам основной Руби почти в 100 раз медленне, той же быдложабы. Поправте если ошибаюсь.

Это дуракам плевать. Мы не в вычисления предполагаем это тащить, а вот скорость типичной веб-морды на практике интересует.

> И зачем оно надо?

(Для тех, кто не в курсе.)

Несмотря на "глобальность и надёжность" PHP, имеется очень много корпоративных программных систем на платформе Java. Поэтому её развитие весьма востребовано. Сообщество Java давно оценило достоинства динамических языков (JSR 223: Scripting for the JavaTM Platform). Так что разработка Groovy, JRuby, Jython, ... вполне закономерна и планомерна.

Никого же не удивляют разные языки программирования для MS dotNET?

Как же приятно читать сообщения пионеров про тормозящую джаву :). Особенно когда в качестве опонентов выступают ruby/python/(любой другой не компилируемый язык).

Ребятки, вы хотя бы узнайте как в ваших говно-языках GC устроен, а потом почитайте как он устроен в Java. Они просто не могут работать сколько-нибудь быстро :).

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

Давай расскажи как ява не тормозит :))))

Иди напиши на питоне hello world и покажи как она запускается в 100 раз быстрее джавы. На этом тесты можешь закончить ибо мозга у тебя нет.

> 1. Oсaml пиарится как F#.

Да, но это пиар под винду.

> 2. Однако, Ocaml в руках среднего программиста может стать не особо функциональным, как и ерланг. А Хаскелл -- Ъ.

Согласен, но в руках среднего программиста Хаскелл скорее всего не окажется никогда, уж больно сильно гайки закручены. Да и опять же сейчас литературы по Окамлю пруд пруди. И по Эрлангу появилась толковая книжка. А по Хаскелу одна старая, еще 1999 года издания.

А сейчас проблема скорее в том, чтобы набрать ядро, которое напишет библиотеки, книжки нормальные сделает. И набрать его с Окамлем проще, потому что как язык он ничем не уступает Хаскеллу, а как платформа для перехода на функциональную парадигму намного лучше.

> Ребятки, вы хотя бы узнайте как в ваших говно-языках GC устроен, а потом почитайте как он устроен в Java. Они просто не могут работать сколько-нибудь быстро :).

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

Язык - это идея, набор средств и абстракция для реализации задачи. А сборщик мусора одна из компонент для __реализации__ этой идеи. К языку GC имеет очень отдаленное отношение. Скажем, в Эрланге сборщик мусора лучше. Но тут сыграло роль, особенность самого языка(отсутствие деструктивного присваивания, интенсивное использование процессов).

жаба не нужна. ты тоже. иди сделай апстену.