Avi Bryant (l’inventore di Seaside) dopo aver a lungo confrontato Ruby e
Smalltalk sul suo blog, ha deciso di passare dalle parole ai fatti e ha
iniziato un progetto per implementare un ambiente Ruby su una virtual
machine Smalltalk (Squeak, in particolare).
Avi Bryant (l’inventore di Seaside) dopo aver a lungo confrontato Ruby e
Smalltalk sul suo blog, ha deciso di passare dalle parole ai fatti e ha
iniziato un progetto per implementare un ambiente Ruby su una virtual
machine Smalltalk (Squeak, in particolare).
E’ interessante però… merita la lettura!
Il succo sembra essere:
CRuby è lento e ha dei problemi e tutti sembrano d’accordo
JRuby non convince Avi Bryant
Le similitudini tra Ruby e Smalltalk rende (probabilmente)
possibile l’uso dei VM per Smalltalk per sostituire a CRuby (o averlo
come alternativa insomma)
C’è un bel scambio di commenti e pareri tra uno dei sviluppatori
core di JRuby e Bryant, il quale sembra mezzo partito a fare una
prima
imlpementazione di “SRuby”
SUN ha poc’anzi opensource-ato un VM di Smalltalk che si chiama
Strontalk e Bryant gioca con l’idea di usarlo…
Paolo Donà wrote:
Giovanni, ammetto la mia pigrizia nel (non) leggere i riferimenti
che ci hai
dato,
ma che vantaggi porta avere un ambiente del genere?
Paolo
On 11/14/06, Giovanni C. [1]<[email protected]> wrote:
Ciao belli,
Avi Bryant (l'inventore di Seaside) dopo aver a lungo confrontato
Ruby e
Smalltalk sul suo blog, ha deciso di passare dalle parole ai fatti
e ha
iniziato un progetto per implementare un ambiente Ruby su una
virtual
machine Smalltalk (Squeak, in particolare).
Riferimenti:
[2]http://smallthought.com/avi/?p=16
[3]http://smallthought.com/avi/?p=17
[4]http://smallthought.com/avi/?p=18
[5]http://smallthought.com/avi/?p=19
e la mailing list
[6]http://groups.google.com/group/smalltalk-ruby?lnk=lr
Ciao,
Giovanni
_______________________________________________
Ml mailing list
[7][email protected]
[8]http://lists.ruby-it.org/mailman/listinfo/ml
–
“Remember, always be yourself. Unless you suck.” - Joss Whedon
Vi porta un passo più vicini a Smalltalk, e già questo è un
vantaggio
Si, beh, dipende. Cioe’ credo che portare un linguaggio vicino ad un
altro linguaggio non necessariamente sia una cosa buona (e questo a
prescindere di quanto sia buono il linguaggio target).
Cioe’, se volessi sviluppare in Smalltalk, credo che svilupperei in
Smalltalk. Invece ci giro intorno e lavoro in Ruby e ObjectiveC (beh,
anche Python, Haskell e Prolog, anzi, piu’ che anche, soprattutto,
specialmente rispetto ad ObjectiveC).
Detto questo non sono del tutto convinto che una VM scritta in
Smalltalk sia necessariamente piu’ veloce di una scritta in C. Anzi.
Nel senso che un interprete in Prolog si scrive alla velocita’ della
luce… ma le performance sono quelle che sono, per dire.
Tra l’altro non ho ancora esattamente capito perche’ Smalltalk sia
caduto in disuso (rispetto a prima, ben inteso, non parlo di numeri
assoluti).
Complessivamente con lo stato attuale di cose nutro piu’ fiducia in
Yarv (o al limite in Parrot).
Semmai il vero vantaggio di portare Ruby su smalltalk sarebbe quello
di usarne i tools. Per chi li possiede. Ma dal punto di vista
prestazionale, sono abbastanza convinto che una VM fine-tuned su come
Ruby gestisce le cose sia comunque una scelta migliore.
Performance is one reason. The various Smalltalk VMs have a few
decades of work at getting a dynamic OO language to run really really
well.
Another is that the Smalltalk IDE is simply incredible, and being
able to develop Ruby with those same tools would be a great boon.
A third is that Smalltalk is mostly written in Smalltalk, save for a
small set of VM-level primitives. This kind of “turtles all the way
down” is really fascinating to work in and contrast to other
languages that have a large core written in C (as are Ruby’s core
classes, which has complications such as overriding methods on a
core classes like Array can be problematic).
Il giorno mer, 15/11/2006 alle 12.11 +0100, Enrico F. ha scritto:
specialmente rispetto ad ObjectiveC).
Male. Non sai che Smalltalk è l’Unico e Vero Linguaggio OOP?
(Ovviamente sto scherzando, così come stavo scherzando prima).
Detto questo non sono del tutto convinto che una VM scritta in
Smalltalk sia necessariamente piu’ veloce di una scritta in C. Anzi.
Nel senso che un interprete in Prolog si scrive alla velocita’ della
luce… ma le performance sono quelle che sono, per dire.
La VM di Squeak è scritta in un subset di Squeak per motivi di velocitÃ
di sviluppo che proviene dall’avere un linguaggio più espressivo, e non
dalla velocità di esecuzione. Il codice della VM viene poi convertito in
C e compilato (generalmente con GCC). E’ la stessa strategia adottata da
PyPy per dire, e da Squawk ( http://research.sun.com/projects/squawk/ ).
Le altre VM sono scritte direttamente in C o C++.
Tra l’altro non ho ancora esattamente capito perche’ Smalltalk sia
caduto in disuso (rispetto a prima, ben inteso, non parlo di numeri
assoluti).
I motivi sono vari: l’abbandono da parte di IBM (che a deciso che
avrebbe fatto più soldi con Java), più scelte commerciali decisamente
avventate da parte dei due maggiori vendor del periodo.
Complessivamente con lo stato attuale di cose nutro piu’ fiducia in
Yarv (o al limite in Parrot).
Semmai il vero vantaggio di portare Ruby su smalltalk sarebbe quello
di usarne i tools. Per chi li possiede. Ma dal punto di vista
prestazionale, sono abbastanza convinto che una VM fine-tuned su come
Ruby gestisce le cose sia comunque una scelta migliore.
Su questo sono d’accordo. Ma lo scopo di questo progetto è soprattutto
quello di verificare se sia megliore un approccio più simile a quello di
Smalltalk, ovvero spostare la maggior parte delle funzionalità da C a
Ruby e tenere in C solo le parti realmente critiche per le performance.
Detto questo non sono del tutto convinto che una VM scritta in
Smalltalk sia necessariamente piu’ veloce di una scritta in C. Anzi.
Nel senso che un interprete in Prolog si scrive alla velocita’ della
luce… ma le performance sono quelle che sono, per dire.
Forse ho capito male io, ma penso che Strongtalk (il VM di cui parla
Bryant nei suoi articoli) non sia scritto in Smalltalk; è un VM per
Smalltalk e dice che si potrebbe adattare facilmente anche per Ruby.
Complessivamente con lo stato attuale di cose nutro piu’ fiducia in
Yarv (o al limite in Parrot).
Sono un po’ preoccupato che si finisce per avere 8 VM, nessuno dei quali
totalmente compatibile con gli altri. C’è una parte in me che pensa che
era meglio se Matz si sbrigasse un attimo e desse un po’ più di fiducia
alla communità su questa vicenda.
Male. Non sai che Smalltalk è l’Unico e Vero Linguaggio OOP?
(Ovviamente sto scherzando, così come stavo scherzando prima).
Si, sapevo che stavi scherzando. Ho preso spunto dal tuo scherzo per
iniziare una discussione ‘semi-seria’. Mi spiego… io sarei il primo
a dire che se ‘Java assomigliasse piu’ a Ruby’ sarei contento (ovvero
fosse un po’ piu’ dinamico).
Tuttavia non sarei contento che Python assomigliasse piu’ a Ruby. Ci
sono cose che mi piacciono piu’ in Python e cose che mi piacciono piu’
in Ruby. Ma sono piccole cose, dopotutto.
Diciamo che le considererei ‘migliorie’ di un linguaggio rispetto che
un effettivo assomigliare ad un altro (alla fine ormai quasi ogni
singola feature e’ stata implementata da qualcun altro).
Il giorno mer, 15/11/2006 alle 12.19 +0100, david ha scritto:
Detto questo non sono del tutto convinto che una VM scritta in
Smalltalk sia necessariamente piu’ veloce di una scritta in C. Anzi.
Nel senso che un interprete in Prolog si scrive alla velocita’ della
luce… ma le performance sono quelle che sono, per dire.
Forse ho capito male io, ma penso che Strongtalk (il VM di cui parla
Bryant nei suoi articoli) non sia scritto in Smalltalk; è un VM per
Smalltalk e dice che si potrebbe adattare facilmente anche per Ruby.
Secondo gli autori di Strongtalk (che sono i principali sviluppatori di
HotSpot) la VM di Strongtalk è in generale la VM per linguaggi OOP più
avanzata che esista al momento (grazie al suo sistema di type inference
e di runtime profiling).
Complessivamente con lo stato attuale di cose nutro piu’ fiducia in
Yarv (o al limite in Parrot).
Sono un po’ preoccupato che si finisce per avere 8 VM, nessuno dei quali
totalmente compatibile con gli altri. C’è una parte in me che pensa che
era meglio se Matz si sbrigasse un attimo e desse un po’ più di fiducia
alla communità su questa vicenda.
Beh, non credo che Smalltalk.rb voglia scalzare YARV
Si, sapevo che stavi scherzando. Ho preso spunto dal tuo scherzo per
iniziare una discussione ‘semi-seria’. Mi spiego… io sarei il primo
a dire che se ‘Java assomigliasse piu’ a Ruby’ sarei contento (ovvero
fosse un po’ piu’ dinamico).
Forse ho capito male io, ma penso che Strongtalk (il VM di cui parla
Bryant nei suoi articoli) non sia scritto in Smalltalk; è un VM per
Smalltalk e dice che si potrebbe adattare facilmente anche per Ruby.
Allora ho capito assolutamente male io. O meglio, ho letto io con
superficialita’, mettendo insieme pezzi da piu’ oist.
Secondo gli autori di Strongtalk (che sono i principali sviluppatori di
HotSpot) la VM di Strongtalk è in generale la VM per linguaggi OOP più
avanzata che esista al momento (grazie al suo sistema di type inference
e di runtime profiling).
I love type inference. Chiedo scusa.
Sono un po’ preoccupato che si finisce per avere 8 VM, nessuno dei quali
totalmente compatibile con gli altri. C’è una parte in me che pensa che
era meglio se Matz si sbrigasse un attimo e desse un po’ più di fiducia
alla communità su questa vicenda.
Probabile. D’altra parte anche su Python c’è cPython, IronPython,
Jhyton (vecchio).
Alla fine il modo principale per distribuire i programmi sui linguaggi
dinamici e’ proprio via sorgente. Se le VM sono scritte bene (e il
linguaggio e’ specificato in modo decoroso) non ci dovrebbero essere
grossi problemi.
Comunque confesso che da utente Python e Ruby, non mi dispiacerebbe
che ci fosse un unica VM che esegue Python, Ruby e magari Perl, TCL
etc. Complessivamente potrebbe essere interessante usare librerie
scritte in un linguaggio da un altro linguaggio.
Dopo tutto e’ spiacevole dovere scrivere codice in C++ solo per avere
la possibilita’ di chiamarlo sia da Python che da Ruby che etc…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
