Forum: Italian Ruby user group ma quanti ruby ci sono?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-01-31 13:57
(Received via mailing list)
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.....
Ea111aa9d75720cbf261e6e6e2f871ec?d=identicon&s=25 paolo foletto (Guest)
on 2009-01-31 14:11
(Received via mailing list)
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
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-01-31 14:15
(Received via mailing list)
2009/1/31 paolo foletto <paolo.foletto@gmail.com>:
> 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

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?
4f4122bc3b9999d9050f0b1a10b63251?d=identicon&s=25 Andrea Reginato (reis)
on 2009-01-31 14:53
(Received via mailing list)
2009/1/31 Mauro <mrsanna1@gmail.com>

> http://lists.ruby-it.org/mailman/listinfo/ml
>

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 Cangiano ha fatto ottimi
lavori<http://antoniocangiano.com/2008/12/09/the-great-ru...
loro comparazioni.

--
Andrea Reginato, http://mikamai.com
Writing http://sensejs.wordpress.com/
Collaborating http://therubymine.it
Reading http://stacktrace.it
6111b4012d1401ca83fdcea6b1d71237?d=identicon&s=25 Antonio Cangiano (Guest)
on 2009-01-31 15:02
(Received via mailing list)
2009/1/31 Mauro <mrsanna1@gmail.com>

> 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 Yard, 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.
Ea111aa9d75720cbf261e6e6e2f871ec?d=identicon&s=25 paolo foletto (Guest)
on 2009-01-31 15:11
(Received via mailing list)
ciao

> Cosa vuol dire MRU?
>
scusa per l'errore ortografico volevo dire MRI
http://en.wikipedia.org/wiki/Ruby_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
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-01-31 15:30
(Received via mailing list)
2009/1/31 paolo foletto <paolo.foletto@gmail.com>:
>>
>
> 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?
Ea111aa9d75720cbf261e6e6e2f871ec?d=identicon&s=25 paolo foletto (Guest)
on 2009-01-31 15:37
(Received via mailing list)
si

2009/1/31 Mauro <mrsanna1@gmail.com>
Ea111aa9d75720cbf261e6e6e2f871ec?d=identicon&s=25 paolo foletto (Guest)
on 2009-01-31 15:44
(Received via mailing list)
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
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-01-31 18:39
(Received via mailing list)
2009/1/31 paolo foletto <paolo.foletto@gmail.com>:
> 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.
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-01-31 18:44
(Received via mailing list)
2009/1/31 Mauro <mrsanna1@gmail.com>:
> 2009/1/31 paolo foletto <paolo.foletto@gmail.com>:
>> 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?
Ea111aa9d75720cbf261e6e6e2f871ec?d=identicon&s=25 paolo foletto (Guest)
on 2009-02-01 00:10
(Received via mailing list)
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
8768bcdbda1adf80e4da6744268868af?d=identicon&s=25 Pietro Giorgianni (giorgian)
on 2009-02-01 09:13
(Received via mailing list)
Il 31 gennaio 2009 18.44, Mauro <mrsanna1@gmail.com> 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.
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-02-01 12:06
(Received via mailing list)
2009/2/1 Pietro Giorgianni <giorgian@gmail.com>:
> 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.
4f4122bc3b9999d9050f0b1a10b63251?d=identicon&s=25 Andrea Reginato (reis)
on 2009-02-01 14:31
(Received via mailing list)
>
>
> > 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 Reginato, http://mikamai.com
Writing http://sensejs.wordpress.com/
Collaborating http://therubymine.it
Reading http://stacktrace.it
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-02-01 15:03
(Received via mailing list)
2009/2/1 Andrea Reginato <andrea.reginato@gmail.com>:
>
> 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?
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-02-01 15:38
(Received via mailing list)
2009/2/1 Andrea Reginato <andrea.reginato@gmail.com>:
>
> 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 `<main>': 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.
9daa9b4739a6e95078cbcfb624d7bb8e?d=identicon&s=25 David Welton (Guest)
on 2009-02-02 09:51
(Received via mailing list)
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):

http://journal.dedasys.com/2006/02/18/maximizers-s...

Questo concetto del "paradox of choice" e` la base di questo libro:

http://www.squeezedbooks.com/book/show/19/the-para...

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-02-02 10:10
(Received via mailing list)
2009/2/2 David Welton <davidnwelton@gmail.com>:
> 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):

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 `<main>': uninitialized constant PLATFORM (NameError)
1c29f9b1bf5f1b88ed8b0c9a9be39788?d=identicon&s=25 Daniele Alessandri (Guest)
on 2009-02-02 11:47
(Received via mailing list)
2009/2/2 Mauro <mrsanna1@gmail.com>:

> 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 `<main>': 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.
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-02-02 12:37
(Received via mailing list)
2009/2/2 Daniele Alessandri <suppakilla@gmail.com>:
> sostituire tutte le occorrenze di PLATFORM con la suddetta, oppure
> imposta PLATFORM = RUBY_PLATFORM, e verifica se incontri altri
> problemi.

Nel file extconf.rb relativo alla gemma da installare non c'e' nessuna
costante PLATFORM,
Dove la trovo?
9daa9b4739a6e95078cbcfb624d7bb8e?d=identicon&s=25 David Welton (Guest)
on 2009-02-02 17:15
(Received via mailing list)
> Si pero' ruby 1.9.0,almeno il pacchetto installato da debian, ha
> qualche problema ancora.......penso.......a meno che qualcuno non mi

Ma quel pacchetto, che io sappia, e` ancora un beta.  E il punto di
quello che dicevo era un po' astratto in ogni caso: bisogna stare
attenti ad avere N versioni - non e` sempre un vantaggio.

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Mauro (Guest)
on 2009-02-02 17:30
(Received via mailing list)
2009/2/2 David Welton <davidnwelton@gmail.com>:

>> Si pero' ruby 1.9.0,almeno il pacchetto installato da debian, ha
>> qualche problema ancora.......penso.......a meno che qualcuno non mi
>
> Ma quel pacchetto, che io sappia, e` ancora un beta.

Come non detto, torno alla 1.8.
This topic is locked and can not be replied to.