Scusate ma, causa ignoranza, non capisco a cosa servono le diverse
implementazioni di ruby.
uby in java, jruby, ruby scritto in ruby, non ricordo come si chiama,
e probabilmente ce ne sono anche delle altre.
Ma a che servono?
In che ambito verrebbero utilizzate diverso da quello in cui si
utilizza ruby quello vero…
ciao
In che ambito verrebbero utilizzate diverso da quello in cui si
utilizza ruby quello vero…
quale sarebbe secondo te quello vero?
Per fare un paragone, che se non ci fosse AMD, Intel non metterebbe
lo stesso impegno nello sviluppo dei microprocessori.
4 occhi ci vedono comunque meglio di 2 e quindi ben vengano
varie implementazioni.
Per rispondere alla curiosità, le mie implementazioni non MRU preferite,
sono jruby, in java e maglev, in smalltalk
ciao Paolo
2009/1/31 paolo foletto [email protected]:
4 occhi ci vedono comunque meglio di 2 e quindi ben vengano
varie implementazioni.
Per rispondere alla curiosità, le mie implementazioni non MRU preferite,
sono jruby, in java e maglev, in smalltalkciao Paolo
Per quello vero intendo quello che si chiama ruby, non jruby, non
maglev, ecc. ecc., quello che mi sono scaricato dai deb di debian, che
ho usato per installare rubygems, ecc. ecc.
Cosa vuol dire MRU?
Perche’ sono le tue preferite le implementazioni da te citate?
2009/1/31 Mauro [email protected]
E’ una domanda molto interessante. Le diverse implementazioni servono
per
“definire” con tecniche (o linguaggi) diversi i costrutti che danno vita
al
linguaggio Ruby.
In altre parole quello che tu usi è sempre lo stesso, ma il modo in cui le
cose funzionano sotto sono diverse. Poi, nel caso di JRuby, hai la
possibilità di integrare Java all’interno dei tuoi script ruby; nel caso
di
Ruby 1.9.1 hai maggiori performance rispetto a Ruby 1.8.7, e così via.
Se sei curioso Antonio C. ha fatto ottimi
lavorihttp://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008/nelle
loro comparazioni.
–
Andrea R., http://mikamai.com
Writing http://sensejs.wordpress.com/
Collaborating http://therubymine.it
Reading http://stacktrace.it
ciao
Cosa vuol dire MRU?
scusa per l’errore ortografico volevo dire MRI
E’ la reference implementation di Matsumoto, quella che trovi
nel cd di debian
Perche’ sono le tue preferite le implementazioni da te citate?
Premesso che professionalmente uso la 1.8.6
perché in produzione usano Debian standard,
credo che jruby presenti dei vantaggi in termini di prestazioni
e di possibilità di introduzione rapida in ambienti Enterprise
standard basti su java
Maglev perchè il primo linguaggio che ho iniziato ad usare
e’ stato moltissimo tempo fa Smalltalk e come sai il primo amore
non si scorda mai.
Su jruby avrei una ulteriore considerazione
Poter disporre di un vero e proprio application server GlassFish 3 che
attiva
le istanze on demand, invece di avere numero
fisso di istanze di mongrel, ma forse sto entrando troppo in dettaglio.
ciao Paolo
2009/1/31 Mauro [email protected]
Scusate ma, causa ignoranza, non capisco a cosa servono le diverse
implementazioni di ruby.
uby in java, jruby, ruby scritto in ruby, non ricordo come si chiama,
e probabilmente ce ne sono anche delle altre.
Ma a che servono?
In che ambito verrebbero utilizzate diverso da quello in cui si
utilizza ruby quello vero…
Nonostante la mancanza di una grammatica formale, Ruby è un linguaggio di
programmazione prima di essere una particolare implementazione. Alcuni
anni
fa l’implementazione sviluppata da Matz e nota per questo come MRI era
l’unica disponibile. Questa implementazione, tuttora la più diffusa, è
principalmente scritta in C ed ha il difetto di essere poco ottimizzata,
garantendo al linguaggio Ruby la fama di essere uno dei più lenti al mondo.
In realtà non è il linguaggio ad essere lento, ma la sua implementazione
principale.
Per rispondere al problema della lentezza, negli anni sono nate diverse
implementazioni alternative. Il problema delle performance in realtà è
solo
uno dei motivi per cui delle implementazioni alternative esistono oggi.
Ci
sono anche altri vantaggi specifici di ogni implementazione.
Ad esempio, JRuby nasce dall’idea di poter far girare Ruby sulla JVM, e
ottenere in questo modo la vasta gamma di librerie e framework
disponibili
nell’enorme mondo Java. Nell’ambito enterprise, JRuby è spesso accettato
maggiormente rispetto a Ruby MRI, per via del fatto che i manager
possono
considerarlo come una forma alternativa di scrivere codice Java. Da un
punto
di vista dell’infrastruttura necessaria per il deployment, non cambia
nulla.
In maniera simile sono nati progetti per Microsoft .NET e Mono, anche se
al
momento l’unico progetto che sembra avere un futuro per questa
piattaforma è
IronRuby, sviluppato da Microsoft stessa. Immagina poter creare
applicazioni
desktop con Visual Studio ma invece di usare linguaggi verbosi come C#,
usare l’amato Ruby.
Nel frattempo, Apple non è rimasta a guardare visto che sta sviluppando
MacRuby, una versione di Ruby che renderà lo sviluppo di applicazioni per
Mac molto più semplice di quanto non sia oggi.
Rubinius è un progetto sponsorizzato da Engine Y., e ha come scopo
principale quello di creare una versione veloce, con un core
minimalistico
in C++, e usando Ruby per implementare quanto più possibile. Altri obiettivi
del progetto sono fornire un’implementazione con la quale è facile
contribuire e un’ottima copertura RSpec del linguaggio. Da un punto di
vista
performance non hanno ancora raggiunto gli scopi prefissi, ma il loro
lavoro
con RSpec è stato utilissimo per testare altre implementazioni.
MagLev è il più giovane della compagnia e sta cercando di riprodurre la
velocità di esecuzione di Smalltalk, un linguaggio abbastanza simile a
Ruby.
Questo, in aggiunta alla scalabilità della piattaforma proprietaria
GemStone, renderà il progetto molto interessante per aziende che non si
sarebbero altrimenti fidate di Ruby MRI.
Per finire, c’è Ruby 1.9.1 appena rilasciato nella sua versione stabile.
Questo è un progetto nato molto tempo fa e destinato a sostituire in
futuro
Ruby 1.8.x. Il cuore di Ruby MRI è stato sostituito da una virtual machine
nota come YARV, che lo rende molto più veloce di Ruby 1.8. Il linguaggio
stesso è stato modificato per migliarlo e rimuovere alcuni difetti
esistenti. Questi cambiamenti comportano delle incompatibilità che rendono
molte delle librierie esistenti inutilizzabili. Per questo è ancora presto
per passare tutti a Ruby 1.9.1. Ma il futuro dell’implementazione
principale
di Ruby è già qui.
In altre parole, continua pure a usare Ruby 1.8.6 o 1.8.7, almeno
finché non
avrai motivo di passare ad altro.
Ciao,
Antonio
http://antoniocangiano.com - Zen and the Art of Programming
http://math-blog.com - Mathematics is wonderful!
http://stacktrace.it - Aperiodico di resistenza informatica
Currently writing “Ruby on Rails for Microsoft Developers” for Wrox.
si , puoi usare rails,i driver per l’accesso fanno una cosa, per te
abbastanza
trasparente, usano una connessione jdbc e e quindi un
pool di connessioni.
Questo aumenta le prestazioni nel caso di accessi
multipli , si risparmia il tempo di istanziare ogni volta
la connessione.
Una domanda stupida, ma con jruby posso continuare ad usare rails per
lo sviluppo?
There is no dumb question
NON esistono domande stupide.
credo che nessuno sia nato imparato.
Che tipo di applicazione state sviluppando ora?
ciao Paolo
2009/1/31 paolo foletto [email protected]:
credo che nessuno sia nato imparato.
Che tipo di applicazione state sviluppando ora?
Un banalissimo gestionale che ho preso come spunto per imparare rails.
Purtroppo le scelte aziendali sono orientate su java cosi’ mi hanno
imposto di cambiare rotta, pensavo appunto a jruby in modo da restare
nel mondo java pur usando un linguaggio che io preferisco.
2009/1/31 paolo foletto [email protected]:
Su jruby avrei una ulteriore considerazione
Poter disporre di un vero e proprio application server GlassFish 3 che
attiva
le istanze on demand, invece di avere numero
fisso di istanze di mongrel, ma forse sto entrando troppo in dettaglio.
In azienda sviluppiamo principalmente in java, credo che jruby sia
allora la mia scelta d’obbligo.
Una domanda stupida, ma con jruby posso continuare ad usare rails per
lo sviluppo?
2009/1/31 Mauro [email protected]:
2009/1/31 paolo foletto [email protected]:
credo che nessuno sia nato imparato.
Che tipo di applicazione state sviluppando ora?
Un banalissimo gestionale che ho preso come spunto per imparare rails.
Purtroppo le scelte aziendali sono orientate su java cosi’ mi hanno
imposto di cambiare rotta, pensavo appunto a jruby in modo da restare
nel mondo java pur usando un linguaggio che io preferisco.
Il dubbo e’ che potrei utilizzare jruby se volessi far uso di classi
java gia’ esistenti, insomma se volessi utilizzare del codice java
gia’ sviluppato all’interno delle applicazioni ruby.
Ma se volessi sviluppare un’applicazione ex novo allora sarebbe meglio
utilizzare direttamente l’implementazione nativa di ruby?
ciao
Il dubbo e’ che potrei utilizzare jruby se volessi far uso di classi
java gia’ esistenti, insomma se volessi utilizzare del codice java
gia’ sviluppato all’interno delle applicazioni ruby.
Ma se volessi sviluppare un’applicazione ex novo allora sarebbe meglio
utilizzare direttamente l’implementazione nativa di ruby?
direi che sono molto rari i casi in cui conviene reinventare
completamente la ruota. e quindi se disponi di librerie aziendalmente
già consolidate conviene riutilizzarle.
Praticamente per lo sviluppo di una applicazione semplice ex novo è
praticamente lo stesso usare ruby o jruby.
Le differenze iniziano solo , quando devi andare in produzione
prestazioni, capacità e competenze sistemistiche disponibili in azienda,
scalabilità , accettazione da parte del management,
duplicazione degli ambienti di deploy etc
aspetti fondamentali per la gestione della produzione ma distanti dal
linguaggio ruby
ciao Paolo
Il 31 gennaio 2009 18.44, Mauro [email protected] ha scritto:
Il dubbo e’ che potrei utilizzare jruby se volessi far uso di classi
java gia’ esistenti, insomma se volessi utilizzare del codice java
gia’ sviluppato all’interno delle applicazioni ruby.
Ma se volessi sviluppare un’applicazione ex novo allora sarebbe meglio
utilizzare direttamente l’implementazione nativa di ruby?
secondo i benchmark che ho visto, le prestazioni migliori si hanno,
nell’ordine, con ruby 1.9.1 e con jruby.
per sviluppare la mia applicazione ho usato la mri (perché ruby1.9 era
ancora instabile), ma ora proverò se è più facile farla funzionare con
la 1.9.1 o con rjuby, e
sceglierò.
personalmente, preferirei la 1.9.1, semplicemente per non portarmi
dietro la dipendenza della jre, ma se in azienda fate un uso forte di
java, direi che la jre non è un problema.
probabilmente ti conviene jruby: la mia esperienza è che se un’azienda
ha due applicazioni diverse, prima o poi vorrà in qualche modo
integrarle, o almeno renderle interoperabili.
2009/2/1 Pietro G. [email protected]:
per sviluppare la mia applicazione ho usato la mri (perché ruby1.9 era
ancora instabile), ma ora proverò se è più facile farla funzionare con
la 1.9.1 o con rjuby, e sceglierò.personalmente, preferirei la 1.9.1, semplicemente per non portarmi
dietro la dipendenza della jre, ma se in azienda fate un uso forte di
java, direi che la jre non è un problema.
Ho capito.
Usando jruby non posso utilizzare le gems installate co nruby 1.8
giusto?
Dovrei riinstallarle.
2009/2/1 Andrea R. [email protected]:
Secondo me sarebbe più interessante sviluppare unicamente con la 1.9.1 (o
previous). Ho usato JRuby solo una volta, cioè quando sapevo che non
esistevano librerie per Ruby per risolvere un determinato problema.Ma in generale, io andrei con Ruby e Web Service REST. In questo modo la tua
app sarà aperta a tutti, ed un pochino alla volta questo ragionamento sarà
diffuso all’interno di tutti i tuoi progetti.
mmmmmmmm i dubbi si insinuano…in effetti, ho anche mandato un
messaggio in lista, ho provato ad utilizzare jruby ma sembra ci sia
qualche problemino con postgres.
In azienda mi stanno rompendo i maroni non permettendomi di sviluppare
in rails, usano java.
Credo che mi adattero’ a sviluppare in java e continuero’ per conto
mio la conoscenza di rails e ruby sperando che un giorno possa essere
accettato, anziche’ orientarmi su jruby.
Non so pero’…ma c’e’ qualcuno che usa jruby qui?
2009/2/1 Andrea R. [email protected]:
Secondo me sarebbe più interessante sviluppare unicamente con la 1.9.1 (o
previous). Ho usato JRuby solo una volta, cioè quando sapevo che non
esistevano librerie per Ruby per risolvere un determinato problema.
E ancora problemi…ho installato ruby1.9, installato la gemma
rails ma quando ho tentato di installare la gemma postgres mi dice:
/usr/bin/ruby1.9 extconf.rb install postgres
extconf.rb:4:in `': uninitialized constant PLATFORM (NameError)
e non capisco perche’, probabilmente la versione 1.9.0 di ruby ha
qualche problema, ho l’impressione a questo punto che la cosa migliore
sia quella di fermarmi alla 1.8 e lasciar perdere juby e ruby1.9.
Credo che sia una cosa positiva avere alcune implementazioni
alternative, ma puo essere anche fonte di confusione per chi conosce poco il linguaggio. Basta guardare Scheme, dove per anni, la gente, finalmente convinta di provare un linguaggio un po' 'diverso', doveva subito affrontare la domanda "ok, ma quale", senza una risposta molto chiara (ora come ora, credo che MzScheme sia uscito dal plotone, ma potrei sbagliarmi). Quindi... e anche bene stare attenti. Ho
scritto qualcosa a proposito in passato (in inglese):
Questo concetto del “paradox of choice” e` la base di questo libro:
http://www.squeezedbooks.com/book/show/19/the-paradox-of-choice-why-more-is-less
–
David N. Welton
2009/2/2 David W. [email protected]:
Credo che sia una cosa positiva avere alcune implementazioni
alternative, ma puoessere anche fonte di confusione per chi conosce poco il linguaggio. Basta guardare Scheme, dove per anni, la gente, finalmente convinta di provare un linguaggio un po' 'diverso', doveva subito affrontare la domanda "ok, ma quale", senza una risposta molto chiara (ora come ora, credo che MzScheme sia uscito dal plotone, ma potrei sbagliarmi). Quindi... eanche bene stare attenti. Ho
scritto qualcosa a proposito in passato (in inglese):
Si pero’ ruby 1.9.0,almeno il pacchetto installato da debian, ha
qualche problema ancora…penso…a meno che qualcuno non mi
sappia spiegare da cosa dipende l’errore
/usr/bin/ruby1.9 extconf.rb install postgres
extconf.rb:4:in `': uninitialized constant PLATFORM (NameError)
personalmente, preferirei la 1.9.1, semplicemente per non portarmi
dietro la dipendenza della jre, ma se in azienda fate un uso forte di
java, direi che la jre non è un problema.Ho capito.
Usando jruby non posso utilizzare le gems installate co nruby 1.8 giusto?
Dovrei riinstallarle.
Secondo me sarebbe più interessante sviluppare unicamente con la 1.9.1 (o
previous). Ho usato JRuby solo una volta, cioè quando sapevo che non
esistevano librerie per Ruby per risolvere un determinato problema.
Ma in generale, io andrei con Ruby e Web Service REST. In questo modo la
tua
app sarà aperta a tutti, ed un pochino alla volta questo ragionamento sarà
diffuso all’interno di tutti i tuoi progetti.
–
Andrea R., http://mikamai.com
Writing http://sensejs.wordpress.com/
Collaborating http://therubymine.it
Reading http://stacktrace.it
2009/2/2 Mauro [email protected]:
Si pero’ ruby 1.9.0,almeno il pacchetto installato da debian, ha
qualche problema ancora…penso…a meno che qualcuno non mi
sappia spiegare da cosa dipende l’errore
/usr/bin/ruby1.9 extconf.rb install postgres
extconf.rb:4:in `': uninitialized constant PLATFORM (NameError)
Dipende dal fatto che la costante PLATFORM è stata deprecata in favore
della costante RUBY_PLATFORM (che c’era già in 1.8.6). Prova a
sostituire tutte le occorrenze di PLATFORM con la suddetta, oppure
imposta PLATFORM = RUBY_PLATFORM, e verifica se incontri altri
problemi.