Вышел JRuby 0.8.0

Супер. Осталось написать на JRuby RPython, на RPython написать PRexx, а на PRexx написать RJava. И будет мир во всем мире.

jpython уже давно есть...

1. А Фортран?
2. А XML???

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

Доп. бонус - простота обращения к явским расширениям типа jdbc, mail, xml коих просто дофига и многие из которых являются образцом универсальности, качества и функциональности.

> 1. А Фортран? А зачем? В смысле, зачем фортран на Яве? Если нужно серьезно работать с математикой, то, скажем, MatLab имеет Java API.

> 2. А XML??? Что имеется в виду, XML-парсер/XSLT-процессор на Яве? Полно, например Apache Xerces/Xalan.

ИМХО лучше бы компилятор Ruby в Java-байт-код...

Хорошая программа.

(Модератор, не удаляй сообщение, я в теме :)

Да я вообще-то дурака валял. В ответ на комментарий о зациклинивании реализаций языков...

Тем кто в танке. В качестве одного из проектов где используют JRuby прошу сюда http://datavision.sourceforge.net/ А еще можно бизнес логику реализовать на встроенных скриптовых языках. Что многие с успехом и делают.

Терпение, только терпение :)

2vladare:

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

И на каких платформах для бизнеслогики не реализован C, чтобы нельзя было скомпилить нативный интерпретатор Ruby?

телефоны?

2AVL2:

>телефоны?

На старых телефон Java еле ворочается, куда ещё интерпретатору поверх неё?:)

А на новых и планируемых - Windows Mobile и Linux, неужто для них нельзя нативный Ruby скомпилить?:)

> И на каких платформах для бизнеслогики не реализован C, чтобы нельзя было скомпилить > нативный интерпретатор Ruby?

J2EE, например.

2anonymous:

>J2EE, например.

Тогда и Ruby, и Perl, и Tcl - платформы:)

>>J2EE, например.
>Тогда и Ruby, и Perl, и Tcl - платформы:)
не вижу сходства

> ИМХО лучше бы компилятор Ruby в Java-байт-код...
ну не Ruby но рядом
http://groovy.codehaus.org/

2ed:

>не вижу сходства

Это смотря что "платформой" называть. Если Hardware+OS, то J2EE - ИМХО ни разу не платформа, а если Сруду запуска софта, то Tcl, Ruby, Perl, etc. - тоже платформы

Да ты, видимо, не занимался промышленной разработкой софта. (Что, впрочем, неудивительно в нашей стране с колониальной экономикой)

Иначе понимал бы разницу между J2EE и Tcl, Ruby, Perl, etc...

в данном случае платформа это то, под чем работает софт для которого
мы хотим писать бизнес-логику на руби.
я не большой спец по J2EE, так что в спор что является платформой а
что нет ввязываться не буду.
но то что к жирному java-софту прикручивать нативный руби-интерпретатор
глупо -- это факт. с jruby не работал, но из опыта с встраиванием jython
знаю что java-версии скриптовых языков интегрируются значительно проще
и, что самое главное, не ломают архитектуру всей системы и все наработки
безболезненно переносятся на другие ОС.

2anonymous:

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

>Иначе понимал бы разницу между J2EE и Tcl, Ruby, Perl, etc...

Разница естественно есть, но не в терминологии "платформа" - "не прлатформа", "промышленная" - "не промышленная"...

А ты видно не видел промышленного софта на Tcl, раз делаешь подобные идеологические заявления:)

2anonymous:

>софт для которого мы хотим писать бизнес-логику на руби.

Уже говорил: в этом случае лучше компилятор Ruby в Java-байт-код ИМХО.

>но то что к жирному java-софту прикручивать нативный руби-интерпретатор глупо -- это факт.

Ну-ну? исходя из чего такой "факт"?

>java-версии скриптовых языков интегрируются значительно проще

в промышленном софте главнее как работает потОм, а не как просто интегрируется ИМХО...