questo ha il feeling di una DSL per fare HTML.
però non farmi il koan zen dove hai un mucchio di sabbia, e ne togli un
pugno e mi chiedi “è ancora un mucchhio di sabbia? e allora cosa era
prima?
quando smette di esserlo?” 
certo i confini tra DSL e API sono
labili e
soggettivi.
Il giorno ven, 27/10/2006 alle 20.42 +0200, chiaro scuro ha scritto:
questo ha il feeling di una DSL per fare HTML.
Corretto, però si chiama Canvas API 
però non farmi il koan zen dove hai un mucchio di sabbia, e ne togli un
pugno e mi chiedi “è ancora un mucchhio di sabbia? e allora cosa era prima?
quando smette di esserlo?”
soggettivi.
Ammetto che la mia era una po’ una provocazione, proprio per mostrare
come la differenza tra API e DSL spesso sia nell’occhio del
programmatore.
GiovanniOn 10/26/06, chiaro scuro [email protected] wrote:
Ti dico invece i problemi che ho avuto con lisp. se da newbie vuoi iniziare
a far qualcosa non sai che ambiente scaricarti, ce ne sono una miriade e non
è neppure immediato come eseguire qualcosa.
Già provato lo Starter Pack (Edi Weitz - Common Lisp code) e la
Lispbox (http://gigamonkeys.com/book/lispbox/) che ti segnalai?
Forse la community dovrebbe concentrarsi di più sul presentare una visione
coerente eunivoca di un ambiente di base. Tuttavia essendo una community di
innovatori, probabilmente non riescono a stare fermi e fioriscono 100
versioni del linguaggio e degli ambienti.
Mi sembra che la maggior parte della community sia coerentemente
concentrata su Slime. Qualcosa di più simile a Ruby e
Scite probabilmente la trovi nella personal edition di Lispworks (su cui
lo
Starter Pack è basato).
On 10/28/06, David W. [email protected] wrote:
IMO questo e` stato, forse, uno dei problemi di smalltalk, e forse
anche Lisp. Gli “scripting languages” si sono dimostrati sempre molto
disponibili ad interagire con il resto del mondo, e di accettare il
mondo Unix e C. Smalltalk e Lisp mi hanno sempre dato l’ impressione
di volere essere “turtles, all the way down” (*) nel senso che
preferiscono tutto il “mondo” in Lisp o Smalltalk (i lispisti si sono
fissati con l’idea del sistema operativo e perfino il computer stesso
come ambiente lisp).
Pienamente d’accordo – per di più mi inquieta non sapere di preciso
in che formato sono salvati i miei sorgenti, e non poter usare grep,
find etc per manipolarli.
Però c’è un vantaggio – in Smalltalk hanno il refactoring browser, in
Ruby non c’è nulla che ci vada lontanamente vicino. Probabilmente
dipende dal fatto che puoi rifattorizzare una classe Ruby solo dopo
che hai finito di parsarla, e per parsarla devi eseguire un programma
Ruby. In pratica puoi fare il refactoring solo sull’albero sintattico
all’interno dell’interprete, non riesci a fare molto sul file di testo
statico. Perlomeno l’ho capita così…
M
C’è qualcuno che sa Smalltalk? e che ha provato seaside?
Eccomi
Ruby è una specie di fratello minore di Smalltalk. Le differenze
principali, al di là della sintassi, sono che Ruby è basato sui file di
testo, Smalltalk utilizza una immagine che è una specie di enorme
database di oggetti (da qui la battuta: “You keep your source code in
files? How quaint.”). I file di testo servono solo per il backup.
IMO questo e` stato, forse, uno dei problemi di smalltalk, e forse
anche Lisp. Gli “scripting languages” si sono dimostrati sempre molto
disponibili ad interagire con il resto del mondo, e di accettare il
mondo Unix e C. Smalltalk e Lisp mi hanno sempre dato l’ impressione
di volere essere “turtles, all the way down” (*) nel senso che
preferiscono tutto il “mondo” in Lisp o Smalltalk (i lispisti si sono
fissati con l’idea del sistema operativo e perfino il computer stesso
come ambiente lisp).
Questo approccio e` molto difficile - gli unici ad esserci riusciti
recentemente sono quelli di Java, ma avere miliardi di dollari per
marketing ricerca e sviluppo ti facilita la vita un pochino.
–
David N. Welton
Linux, Open Source Consulting
già come funziona? se il linguaggio è dinamico non può che essere euristico,
basato su runtime information, no?
On 10/30/06, Matteo V. [email protected] wrote:
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Chiaroscuro
: : i’m a miner : : | therubymine.com
Però c’è un vantaggio – in Smalltalk hanno il refactoring browser, in
Ruby non c’è nulla che ci vada lontanamente vicino. Probabilmente
dipende dal fatto che puoi rifattorizzare una classe Ruby solo dopo
che hai finito di parsarla, e per parsarla devi eseguire un programma
Ruby. In pratica puoi fare il refactoring solo sull’albero sintattico
all’interno dell’interprete, non riesci a fare molto sul file di testo
statico. Perlomeno l’ho capita così…
Hanno ‘eval’ in smalltalk? Se non bastasse il resto, quello puo`
sconfiggere qualsiasi tentativo di fare alcune cose.
–
David N. Welton
Linux, Open Source Consulting
On 10/30/06, chiaro scuro [email protected] wrote:
già come funziona? se il linguaggio è dinamico non può che essere euristico,
basato su runtime information, no?
Dubito che si avvicini a quanto è possibile fare in Smalltalk, comunque:
On 10/30/06, David W. [email protected] wrote:
Però c’è un vantaggio – in Smalltalk hanno il refactoring browser, in
Ruby non c’è nulla che ci vada lontanamente vicino. Probabilmente
dipende dal fatto che puoi rifattorizzare una classe Ruby solo dopo
che hai finito di parsarla, e per parsarla devi eseguire un programma
Ruby. In pratica puoi fare il refactoring solo sull’albero sintattico
all’interno dell’interprete, non riesci a fare molto sul file di testo
statico. Perlomeno l’ho capita così…Hanno ‘eval’ in smalltalk?
Non lo so
Se non bastasse il resto, quello puo`
sconfiggere qualsiasi tentativo di fare alcune cose.
Secondo me, non è necessario che un refactoring browser sia perfetto
per essere utile. I refactoring più comuni sono Rename Variable ed
Extract Method. Non dovrebbe essere così impossibile farli
funzionare, almeno per il codice che non usa eval. Vale la regola
dell’80-20…
Matteo
si, in smalltak c’e eval
ma io direi che la differenza fordamentale è c’è un modo uniforme di fare le
cose,
perchè nel bene o nel male le cose stanno tutte in unico posto /
repository
/image.
in rails qualche volta si lanciano script qualche volta si scrive codice
Ciao Paolo
Il giorno sab, 28/10/2006 alle 13.15 +0200, David W. ha scritto:
IMO questo e` stato, forse, uno dei problemi di smalltalk, e forse
anche Lisp. Gli “scripting languages” si sono dimostrati sempre molto
disponibili ad interagire con il resto del mondo, e di accettare il
mondo Unix e C. Smalltalk e Lisp mi hanno sempre dato l’ impressione
di volere essere “turtles, all the way down” (*) nel senso che
preferiscono tutto il “mondo” in Lisp o Smalltalk
E questo da una parte può essere uno svantaggio, dall’altra un
vantaggio. Per esempio, per applicazioni che devono gestire piccole
quantità di dati, oppure molti dati ma raramente in maniera
concorrenziale, si può anche evitare completamente di appoggiarsi ad un
db: basta salvare l’immagine quando i dati vengono modificati. In
pratica un DB ad oggetti integrato nel resto del sistema.
Ci sono inoltre alcuni dialetti Smalltalk che tendono per loro stessa
natura ad integrarsi con il resto del sistema: è il caso di Dolphin per
Windows o di Ambrai per Mac OS X.
(i lispisti si sono
fissati con l’idea del sistema operativo e perfino il computer stesso
come ambiente lisp).
Intendi le Lisp Machines di Genera e Symbolics? Beh, allora gli
Smalltalker non sono da meno: cerca in rete notizie sulle workstation
Xerox Alto e Star. Per non parlare di SqueakNOS
Questo approccio e` molto difficile - gli unici ad esserci riusciti
recentemente sono quelli di Java, ma avere miliardi di dollari per
marketing ricerca e sviluppo ti facilita la vita un pochino.
Certo. E per di più Java non raggiunge gli “eccessi” di Smalltalk e
Lisp.
GiovanniIl giorno lun, 30/10/2006 alle 08.44 +0100, Matteo V. ha scritto:
files? How quaint."
Pienamente d’accordo – per di più mi inquieta non sapere di preciso
in che formato sono salvati i miei sorgenti, e non poter usare grep,
find etc per manipolarli.
I sorgenti sono salvati in formato testo, quindi è possibile usare find
e grep per cercare stringhe nei sorgenti. Ma in generale è più semplice
lanciare l’immagine e usare il tool apposito (in Squeak: Method Finder,
Senders/Implementors Browser, Reference finder).
Però c’è un vantaggio – in Smalltalk hanno il refactoring browser, in
Ruby non c’è nulla che ci vada lontanamente vicino. Probabilmente
dipende dal fatto che puoi rifattorizzare una classe Ruby solo dopo
che hai finito di parsarla, e per parsarla devi eseguire un programma
Ruby. In pratica puoi fare il refactoring solo sull’albero sintattico
all’interno dell’interprete, non riesci a fare molto sul file di testo
statico. Perlomeno l’ho capita così…
Si, lavorare sull’AST è più semplice che non sul testo statico. Ma per
il refactoring entrano anche in gioco alcune differenze fondamentali tra
Ruby e Smalltalk che sono spiegate molto bene in questo messaggio:
http://tinyurl.com/ayuo2 .
Giovanni
Il giorno lun, 30/10/2006 alle 22.05 +0100, David W. ha scritto:
Però c’è un vantaggio – in Smalltalk hanno il refactoring browser, in
Ruby non c’è nulla che ci vada lontanamente vicino. Probabilmente
dipende dal fatto che puoi rifattorizzare una classe Ruby solo dopo
che hai finito di parsarla, e per parsarla devi eseguire un programma
Ruby. In pratica puoi fare il refactoring solo sull’albero sintattico
all’interno dell’interprete, non riesci a fare molto sul file di testo
statico. Perlomeno l’ho capita così…Hanno ‘eval’ in smalltalk? Se non bastasse il resto, quello puo`
sconfiggere qualsiasi tentativo di fare alcune cose.
Esiste Compiler>>evaluate: e affini, ma sono poco utilizzati
(soprattutto per DoIt e PrintIt, direi).
GiovanniIl giorno mer, 01/11/2006 alle 21.27 +0100, Matteo V. ha scritto:
On 10/30/06, David W. [email protected] wrote:
Se non bastasse il resto, quello puo`
sconfiggere qualsiasi tentativo di fare alcune cose.Secondo me, non è necessario che un refactoring browser sia perfetto
per essere utile. I refactoring più comuni sono Rename Variable ed
Extract Method. Non dovrebbe essere così impossibile farli
funzionare, almeno per il codice che non usa eval. Vale la regola
dell’80-20…
D’accordo per Extract Method, ma magari Rename Variable potrebbe creare
qualche problema, visto l’uso diffuso dei vari metodi attr_* .
Giovanni
On 11/2/06, Giovanni C. [email protected] wrote:
D’accordo per Extract Method, ma magari Rename Variable potrebbe creare
qualche problema, visto l’uso diffuso dei vari metodi attr_* .
Ora che ci penso, il problema di Rename (anything) è che se io ho una
classe che ha un metodo pippo, e da un’altra parte c’è un’altra classe
che contiene un metodo tipo
def foo(x)
x.pippo
end
come faccio a sapere se devo rinominare anche la chiamata a pippo
dentro foo? E se questa chiamata a “pippo” servisse anche per una
terza classe che ha anche lei un metodo “pippo”? Il duck typing mi
impedisce di sapere di preciso tutti i posti dove il metodo pippo
potrebbe essere usato. 
M
Il giorno gio, 02/11/2006 alle 21.34 +0100, Matteo V. ha scritto:
On 11/2/06, Giovanni C. [email protected] wrote:
Bel messaggio, ho capito un po’ meglio come funziona Smalltalk!
La mia reazione di “pelle” è che preferisco di gran lunga tenere i
miei sorgenti nei file di testo e tenermi la “narrativa”, come dice
lui. Preferisco di gran lunga vedere una singola riga che dice
attr_accessor :x, :y, :z
che non vedermi nel browser i sei getter e setter risultanti.
Beh, non è che li vedi sempre, ma solo quando selezioni la categoria di
metodi “Accessors”. E anche selezionandola vedi solo la lista dei metodi
accessors, e devi selezionare quale accessor vuoi vedere.
Sono
sicuro che Smalltalk avrà il suo fascino, e se tipi del calibro di
Kay, Cunningham e Beck sono smalltalkisti, vorrà ben dire qualcosa…
ma a me personalmente, “non mi acchiappa”.
Il modo migliore per comprendere davvero Smalltalk è farselo spiegare di
persona, in modo che si possa esplorare l’ambiente a mano a mano che
vengono illustrate le caratteristiche del linguaggio e della libreria.
In alternativa, gli screencast di James Robertson, product manager di
Cincom Smalltalk, sono interessanti:
http://www.cincomsmalltalk.com/blog/blogView?searchCategory=screencast
Giovanni
On 11/2/06, Giovanni C. [email protected] wrote:
Ruby e Smalltalk che sono spiegate molto bene in questo messaggio:
http://tinyurl.com/ayuo2 .
Bel messaggio, ho capito un po’ meglio come funziona Smalltalk!
La mia reazione di “pelle” è che preferisco di gran lunga tenere i
miei sorgenti nei file di testo e tenermi la “narrativa”, come dice
lui. Preferisco di gran lunga vedere una singola riga che dice
attr_accessor :x, :y, :z
che non vedermi nel browser i sei getter e setter risultanti. Sono
sicuro che Smalltalk avrà il suo fascino, e se tipi del calibro di
Kay, Cunningham e Beck sono smalltalkisti, vorrà ben dire qualcosa…
ma a me personalmente, “non mi acchiappa”.
M
Giovanni, quando sei a Roma? vogliamo la tua testa… per una sera almeno
On 11/3/06, Giovanni C. [email protected] wrote:
come faccio a sapere se devo rinominare anche la chiamata a pippo
dentro foo? E se questa chiamata a “pippo” servisse anche per una
terza classe che ha anche lei un metodo “pippo”? Il duck typing mi
impedisce di sapere di preciso tutti i posti dove il metodo pippo
potrebbe essere usato.Se lavori sul file di testo, sicuro. Ma se lavori sull’AST, tramite type
inference puoi determinare la classe degli oggetti. E così salvi papera,
capra e cavoli
No, quello che voglio dire è che se tu da qualche parte hai una
chiamata x.pippo, non potrai mai sapere di che classe sia l’oggetto x
a runtime. Siccome a “x” non è associato nessun tipo (è una
variabile) potrebbe essere istanziata di volta in volta con un’oggetto
di qualsiasi tipo, purché risponda al messaggio “pippo”. E non cambia
lavorare sull’albero sintattico o sul file di testo. E allora se io
dico che voglio rinominare il metodo Foobar#pippo in Foobar#pluto,
dovrò andare a esaminare tutte le chiamate a pippo in tutto il
programma. E poi devo vedere se ci sono altre classi che implementano
un metodo “pippo” e chiedermi se anche in quelle classi “pippo” va
rinominato.
Non c’è che dire, Rename Method in Ruby è un bel casino da implementare.
M
Il giorno ven, 03/11/2006 alle 03.37 +0200, chiaro scuro ha scritto:
Giovanni, quando sei a Roma? vogliamo la tua testa… per una sera almeno
Non prima di Gennaio 
GiovanniThis forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs