Newsgroup: it.comp.java
Titolo: altri linguaggi per la jvm

Oltre Java, quali altri linguaggi usate per programmare con la jvm?
Quali preferite/proverete in futuro?

 Quali preferite/proverete in futuro?
Per mia preferenza personale metterei:
* Groovy un linguaggio dinamico per la jvm simile a python e ruby
(
http://groovy.codehaus.org/
)
* Grails un framework web mvc (simile a rails, cakephp, catalyst)
http://www.grails.org/
* scala un linguaggio funzionale (simile un pochino a camel un poco a
lisp) 
http://www.scala-lang.org/
* clojure che per certi versi � un misto dei due (ma pi� sul funzionale
alla lisp) 
http://clojure.org/
michelangelo



Ciao, allora premesso che ho guardato solo Clojure perch� � quasi un
Lisp e quindi mi piace,
Groovy non rischia di essere un *doppione* per chi usa JRuby e Jython?
Grails non mi serve
Scala boh, devo guardarlo, � sicuramente interessante
Clojure � una figata pazzesca :)

 Clojure � una figata pazzesca :)
Cosa puoi fare con clojure che con, ad esempio groovy non si puo'?

 michelangelo
Una precisazione. Grails non è un linguaggio, ma un farmework scritto
in Groovy. Tant'è vero una applicazione Grail si programma in Java e
Groovy. Questo da da pensare riguardo alla potenza di Groovy, la cui
sintassi e struttura lo rende ideale per costruire delle DSL al punto
che una DSL scritta in Groovy possa sembrare addirittura un linguaggio
a se.
Per una lista di linguaggi vedi 
http://en.wikipedia.org/wiki/List_of_JVM_languages
Farei un grosso distinguo fra Groovy/Scala e Rhino/JRuby/Jthon
I primi due sono dei linguaggi che vengono o possono essere compilati
in bytecode, per cui sono nativamente integrati in Java, ovvero la JVM
li tratta come fossero nativamente java. Ciò facilita moltissimo
ovviamente l'integrazione fra linguaggi e paradigmi diversi.
Ovviamente però se vuoi li puoi usare come programmi a se (per es
Groovy ha delle funzionalità tali da far valere la pena di usare il
linguaggio solo per accedere alle std lib, o per le chiusure, l'AOP, i
Builders).
Per quanto riguarda gli ultimi 3, essi sono linguaggi che vengono
interpretati e servono più che altro a dare funzionalità di scripting
a programmi scirtti in Java. Ha poco senso IMHO scrivere un intero
programma in Ruby usando JRuby. O usi il Ruby vero, ò è perché vuoi
avere un sistema di espandibilità del programma.

michelangelo giacomelli ha scritto:

Non c'� anche Fortress?

 avere un sistema di espandibilit� del programma.
E perche'? Jython mi da accesso a tutto quello che gira in Java. Mi
permette di inserirmi in sistemi Java a costo nullo. Preferisco lavorare
in pure Python, se posso. Se devo interagire in modo troppo marcato con
il mondo Java, Jython mi permette di farlo alle mie condizioni.
-- 
-riko

Enrico Franchi ha scritto:

Esattamente come jruby.

 Esattamente come jruby.
Infatti mi torna.
Anzi, in un certo senso la situazione per ruby/jruby e' ancora di piu'
verso "considerare jruby".
-- 
-riko

Enrico Franchi ha scritto:

in che senso

 in che senso
Nel senso che al momento attuale come implementazione Python cPython e'
superiore a Jython. Tuttavia JRuby se la gioca davvero bene con il Ruby
ufficiale, per lo meno fino a Yarv.
-- 
-riko

Cosa puoi fare con clojure che con, ad esempio groovy non si puo'?
Functional programming.

avere un sistema di espandibilit� del programma.
Hai scritto diverse inesattezze, vedi la risposta di Enrico Franchi
per le correzioni del caso.

 Functional programming.
Non so cos'e' :-(

Enrico Franchi ha scritto:

Jruby sembra essere addirittura piu' veloce di ruby 1.8, con la 1.9 non so.

 Jruby sembra essere addirittura piu' veloce di ruby 1.8, con la 1.9 non so.
E' piu' veloce di Ruby 1.8. Con Ruby 1.9 l'ultima volta che ho
controllato, come dicevo, se la giocava. C'erano dei bench, alcuni li
vinceva, altri li perdeva. Grosso modo avrei detto "marginalmente piu'
lento", che, tenendo conto che si tratta di bench, vuole dire tutto e
nulla.
*Sicuramente* e' piu' veloce di Ruby 1.8 (e grazie, compila). E mi
sembra davvero un bell'oggetto.
Credo che il mondo Java abbia davvero bisogno, a livello culturale e
pratico di oggetti come Jython e JRuby.
-- 
-riko

 -riko

 po' di + gli do una riguardata
A quel punto groovy.... o no?

 che sarebbe stato un linguaggio portabile come lo � il C#)
Uh?
Tra l'altro non capisco perche' scambi indiscriminatamente il concetto
di linguaggio (interfaccia) con la sua implementazione.
-- 
-riko