Ruby on Smalltalk

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:

http://smallthought.com/avi/?p=16
http://smallthought.com/avi/?p=17
http://smallthought.com/avi/?p=18
http://smallthought.com/avi/?p=19

e la mailing list
http://groups.google.com/group/smalltalk-ruby?lnk=lr

Ciao,

	Giovanni

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. [email protected] wrote:

http://smallthought.com/avi/?p=16


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Paolo D.’
SeeSaw | Another point of view


[email protected]
personal http://paolodona.blogspot.com

essendo una virtual machine mi immagino facilità di integrazione con
smalltalk e riutilizzo di una serie di tools e risorse di
quell’ambiente.

ma a noi rubyisti che vantaggi porta? :slight_smile:

On 11/14/06, Giovanni C. [email protected] wrote:

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).

/me si lecca i baffi.


Massimiliano M.
code: http://dev.hyperstruct.net
blog: http://blog.hyperstruct.net

E’ interessante però… merita la lettura!
Il succo sembra essere:

  1. CRuby è lento e ha dei problemi e tutti sembrano d’accordo
  2. JRuby non convince Avi Bryant
  3. Le similitudini tra Ruby e Smalltalk rende (probabilmente)
    possibile l’uso dei VM per Smalltalk per sostituire a CRuby (o averlo
    come alternativa insomma)
  4. 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”
  5. SUN ha poc’anzi opensource-ato un VM di Smalltalk che si chiama
    Strontalk e Bryant gioca con l’idea di usarlo…
    :slight_smile:
    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

References

  1. mailto:[email protected]
  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
  6. http://groups.google.com/group/smalltalk-ruby?lnk=lr
  7. mailto:[email protected]
  8. http://lists.ruby-it.org/mailman/listinfo/ml

Vi porta un passo più vicini a Smalltalk, e già questo è un
vantaggio :wink:

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.

Il giorno mar, 14/11/2006 alle 11.56 +0100, chiaro scuro ha scritto:

essendo una virtual machine mi immagino facilità di integrazione con
smalltalk e riutilizzo di una serie di tools e risorse di quell’ambiente.

ma a noi rubyisti che vantaggi porta? :slight_smile:

Vi porta un passo più vicini a Smalltalk, e già questo è un
vantaggio :wink:

Comunque dalla mailing list ( http://snipurl.com/123yi ):

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).

Giovanni

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? :wink:
(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.

Giovanni

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.

On 11/15/06, Giovanni C. [email protected] wrote:

Male. Non sai che Smalltalk è l’Unico e Vero Linguaggio OOP? :wink:
(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 :wink:

Giovanni

“Enrico F.” [email protected] writes:

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).

Dai uno sguardo a

http://groovy.codehaus.org

On 11/15/06, Giovanni C. [email protected] wrote:

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.

| Privacy Policy | Terms of Service | Remote Ruby Jobs