DSL vs API

On 10/25/06, david [email protected] wrote:

Perché le chiamate alle funzioni non hanno più le parentesi.
:wink:

Un argomento in piuper dire che Tcl e migliore per creare DSL
allora;-)

Scherzi a parte, per me la differenza eche una vera DSL ha la sintassi diversa o modificata in qualche modo. Esempi che saltano in mente sono le espressioni regolari, SQL che e un linguaggio molto
specifico al suo dominio, oppure magari anche qualcosa come Tk quando
usato da Tcl, che inizia ad avere elementi che ‘significano’ qualcosa
in Tk, ma non in Tcl.


David N. Welton

Linux, Open Source Consulting

Si, hai ragione. diciamo che si fa quel che si può :slight_smile:

trovo ruby una buona via di mezzo che mi permette di non dover riesumare
le
& yacc per fare cose semplici.

se mi andassero giù le parentesi probabilmente lavorerei in lisp…

Una buona descrizione dei “confini” dei DSL rispetto alle APIs o ai
linguaggi “General purpose” c’e’ qui:

http://www.martinfowler.com/bliki/DslBoundary.html

In sostanza un linguaggio si puo considerare o meno un DSL a seconda
delle intenzioni di chi lo implementa e di chi lo usa (che possono
essere anche diverse), ma in generale in un DSL si cerca la capacita di
risolvere classi di problemi specifici in maniera molto espressiva…

Luca


Web: http://spazidigitali.com, http://thetyper.com
Email: mailto://[email protected]

On 10/25/06, chiaro scuro [email protected] wrote:

se mi andassero giù le parentesi probabilmente lavorerei in lisp…

Le parentesi sono come il caffè: più le mandi giù, più ti tiran su.

:slight_smile:

ok, sono pronto per una guerra di religione su DSL, linguaggi e
parentesi
:slight_smile:

in genere cerco di scrivere DSL dall’alto (dal punto di vista
dell’utente
della DSL) e contemporaneamente una API dal basso.

ho provato l’approccio DSL first ma in diversi casi l’ho trovato
fallimentare.
l’estrazione di una DSL tramite refactoring dalla API è stato più fruttuoso.
lavorando da entrambe le direzioni riesci a informare entrambi gli
sviluppi
fin dall’inizio.

On 10/25/06, Luca M. [email protected] wrote:


Chiaroscuro

: : i’m a miner : : | therubymine.com

partendo da joel spolsky che linka a Avi Bryant sono finito per
leggere (di nuovo) di Smalltalk. E di Seaside. E mi sono visto il
filmatino su dabblerDB che è veramente una roba impressionante. C’è un
David P. che confronta Ruby con Smalltalk e che scrive piuttosto
bene ([1]https://www.lostlake.org/blog/ no, non so perché tiene il
blog su ssl…).
Tra i commenti al blog di Avi c’è della gente brava (mi sembra). C’è
una che propone di vedere Ruby come un dialetto di Smalltalk, e
viceversa: forse potrebbero essere addirittura compatibili?
C’è qualcuno che sa Smalltalk? e che ha provato seaside?
:slight_smile:
chiaro scuro wrote:

 ok, sono pronto per una guerra di religione su DSL, linguaggi e
 parentesi
 :-)
 On 10/25/06, Massimiliano M. [2]<[email protected]>
 wrote:

 On 10/25/06, chiaro scuro [3]<[email protected]> wrote:
 > se mi andassero giù le parentesi probabilmente lavorerei in
 lisp..
 Le parentesi sono come il caffè: più le mandi giù, più ti tiran su.
 :-)

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


“Remember, always be yourself. Unless you suck.” - Joss Whedon

References

  1. https://www.lostlake.org/blog/
  2. mailto:[email protected]
  3. mailto:[email protected]
  4. mailto:[email protected]
  5. http://lists.ruby-it.org/mailman/listinfo/ml

On 10/25/06, chiaro scuro [email protected] wrote:

ok, sono pronto per una guerra di religione su DSL, linguaggi e parentesi
:slight_smile:

AKA “Tutto, ma non toccatemi il caffè!”

;-D

Alle 15:36, mercoledì 25 ottobre 2006, david ha scritto:

Se interessano ho un po’ di link al riguardo.

  1. Borges
    http://borges.rubyforge.org/
    praticamente si tratta di IWOA (progetto in Ruby) che è diventato Seaside
    (in
    smalltalk) che è stato ripreso da un altro programmatore che lo ha
    riportato
    in Ruby

  2. Wee
    http://www.ntecs.de/blog-old/Blog/WeeFramework.rdoc
    altro web framewark ispirato a seaside

Qui c’è un commento di Avi Bryant
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3276420615

Per quanto riguarda la flame war sui linguaggi, sarebbe interessante
capire se
davvero Ruby riesce a incorporare i concetti più importanti di smalltalk e
Lisp, come spesso si dice in giro.
Un mio tentativo di imparare smalltalk e un secondo tentativo di portare
su
Ruby esempi di programmazione presi da un libro sui linguaggi funzionali
sono
naufragati miseramente per mancanza di tempo.
Però i vari linguaggi e le diverse soluzioni escogitate per risolvere
problemi
analoghi sono un argomento a mio parere piuttosto interessante.
ciao
Francesco L.

Francesco L.

…tiran su fino a che non viene il mal di pancia e il sudore
freddo…
Massimiliano M. wrote:

 On 10/25/06, chiaro scuro [1]<[email protected]> wrote:

 se mi andassero giù le parentesi probabilmente lavorerei in lisp..

 Le parentesi sono come il caffè: più le mandi giù, più ti tiran su.
 :-)


“Remember, always be yourself. Unless you suck.” - Joss Whedon

References

  1. mailto:[email protected]

Per quanto riguarda la flame war sui linguaggi, sarebbe interessante capire se
davvero Ruby riesce a incorporare i concetti più importanti di smalltalk e
Lisp, come spesso si dice in giro.

Forse no, ma secondo me essere accessibile eanche un virtu per un
linguaggio, perchequella gente che e esperta di qualcosa che non ela programmazione puo prenderlo e farci qualcosa di utile mentre noi
programmatori stiamo discutendo lexical vs dynamic scoping, parentesi
vs altra sintassi, ecc…

Vi spammo con qualcosa che scrissi a proposito:

http://www.dedasys.com/articles/scalable_systems.html


David N. Welton

Linux, Open Source Consulting

Il giorno mer, 25/10/2006 alle 23.37 +0200, David W. ha scritto:

Per quanto riguarda la flame war sui linguaggi, sarebbe interessante capire se
davvero Ruby riesce a incorporare i concetti più importanti di smalltalk e
Lisp, come spesso si dice in giro.

Forse no, ma secondo me essere accessibile eanche un virtu per un
linguaggio, perchequella gente che e esperta di qualcosa che non ela programmazione puo prenderlo e farci qualcosa di utile mentre noi
programmatori stiamo discutendo lexical vs dynamic scoping, parentesi
vs altra sintassi, ecc…

Beh, Smalltalk salta la cosa completamente perchè da una parte la
sintassi è fissa (a differenza di LISP dove le macro ti permettono un
po’ più di libertà ) e dall’altra l’abitudine all’uso di interfacce
grafiche rende più naturale per uno sviluppatore creare una interfaccia
per l’utente piuttosto che un DSL.
Uno dei concetti base dell’interfaccia di Smalltalk è infatti quello dei
Browser, che vengono usati per navigare le strutture del sistema
(gerarchia delle classi, stack trace etc). E’ quindi più semplice
specializzare un browser per creare/navigare una struttura dati che non
definire un DSL che crei questa struttura dati. Poi i DSL ci sono anche
in Smalltalk, ma in genere non li diamo in pasto agli utenti.

Giovanni

Il giorno mer, 25/10/2006 alle 15.36 +0200, david ha scritto:

:slight_smile:
Eccomi :wink:

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.” :slight_smile: ). I file di testo servono solo per il backup.
Inoltre Smalltalk ha un workflow di sviluppo fortemente incrementale:
prima definisci la classe con le sue variabili di instanza, che viene
quindi creata senza avere metodi propri; poi alla nuova classe inizi ad
aggiungere i metodi che vuoi, ma “accettandoli” (cioè compilandoli) uno
per volta.

Il modello computazionale sottostante è anche leggermente più semplice:
i blocchi, ad esempio, sono oggetti come gli altri e non hanno bisogno
di accorgimenti particolari (tipo chiamate a #lambda o parametri &).

Inoltre praticamente tutto in Smalltalk viene mantenuto a livello di
immagine, compreso il compilatore, il debugger etc. Questo permette, ad
esempio, di poter aggiungere le continuazioni senza dover toccare la
virtual machine, oppure di scrivere motori bytecode-to-native
direttamente in Smalltalk.

Per quel che riguarda Seaside, ho fatto giusto qualche piccola
applicazione. A differenza di Rails, che si basa ancora sul classico
modello Request/Responde, Seaside grazie alle continuations permette di
lavorare ad un livello di astrazione più elevato: in pratica si può
sviluppare un’applicazione web come se fosse una applicazione desktop.
Questo è molto utile quando si sviluppano applicazioni web molto
interattive.
Inoltre Seaside non utilizza template: grazie al sottosistema Canvas (e
al precedente Builder) si può generare l’HTML direttamente da Smalltalk.
L’unico svantaggio è che è un po’ più difficile costruire applicazioni
RESTful.

Giovanni

Il giorno mer, 25/10/2006 alle 15.00 +0200, chiaro scuro ha scritto:

ho provato l’approccio DSL first ma in diversi casi l’ho trovato
fallimentare.
l’estrazione di una DSL tramite refactoring dalla API è stato più fruttuoso.
lavorando da entrambe le direzioni riesci a informare entrambi gli sviluppi
fin dall’inizio.

Questo è in genere l’approccio di Smalltalk: crei in maniera evolutiva
una API e dopo un po’ la guardi e ti accorgi che è un DSL. La differenza
è che in genere questa evoluzione in DSL non è voluta: si fa il
refactoring per avere un’API più pulita, senza volere coscientemente
trasformarla in un DSL.

Giovanni

Questo argomento mi interessa molto. Non penso che una DSL sia
semplicemente una API evoluta e ripulita. In una DSL ad esempio spesso
inserisci delle limitazioni per poter fare assumption che semplificano
l’interfaccia. Tutto quello che fai con la DSL lo puoi fare anche con
un’API in modo + verboso.

Ad esempio diverse DSL potrebbero essere costruite sulla stessa API,
mettendo in evidenza caratteristiche diverse e modalità d’uso differenti.

On 10/26/06, Giovanni C. [email protected] wrote:

una API e dopo un po’ la guardi e ti accorgi che è un DSL. La differenza
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Chiaroscuro

: : i’m a miner : : | therubymine.com

“chiaro scuro” [email protected] writes:

se mi andassero giù le parentesi probabilmente lavorerei in lisp…

Purtroppo il problema delle parentesi può essere risolto solo
sviluppando con IDE specializzati. La semplicità delle parentesi (come
sintassi) permette la costruzione di strumenti utili per la loro
manipolazione.

La scelta di questi è purtroppo molto limitata e poco pubblicizzata se
non addirittura obbligata: GNU Emacs + estensioni.

Ã? il solito problema dunque: alcune tecnologie sono ottime ma non sono
mainstream perchè hanno una curva (qualcuno qui in regia dice scalino)
di apprendimento troppo steep all’inizio, anche perchè legate
all’apprendimento di strumenti e metodologie per nulla C-like (cioè
non “comuni”).

Ruby è un ottimo compromesso in tutto ciò :slight_smile:

Ciao


PS: Per gli interessati alle estensioni di Emacs (attenzione: solo per
veri duri :wink: ) per il common lisp:

slime offre supporto per un pò di cose: syntax highlighting, source e
class browsing, docs online and as-you-type, completamento, supporto
per repl, compilazione, debugging, inspecting, profiling

paredit permette di muoversi tra le parentesi e di manipolarle molto
rapidamente ed efficacemente (tipo spezzo form, le includo in
un’altra, mi muovo nella prossima, in quella superiore, le inverto,
etc.).

con emacs inoltre è facile far “scomparire” le parentesi. Io ad
es. non le mostro nel codice e mi fido della formattazione che do al
codice per capire i livelli di nesting.

Ok, dai ho un po esagerato con le parentesi. era un colpo basso e non lo
penso neppure del tutto :slight_smile:

Mathematica è molto elegante da questo punto di vista, con una serie di
notazioni che permettono di usare ogni funzione in modo infisso,
prefisso o
postfisso, con e senza parentesi.

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. Quando ho installato ruby per
la
prima volta, dopo 5 minuti avevo scite aperto e running, no prob.

Poi sarebbe bello vedere snippets eleganti per fare alcune ops di base.
Un
Lisp Recipes se vuoi :slight_smile:

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.

Certo è anche colpa mia che non ho cercato abbastanza, ma il tempo è
limitato e questa è la prima impressione che molti possono avere.

On 10/26/06, Luigi P. [email protected] wrote:

“chiaro scuro” [email protected] writes:

http://therubymine.com

Ottimo, il tuo saggio.
:slight_smile:
David W. wrote:

 Per quanto riguarda la flame war sui linguaggi, sarebbe
 interessante capire se
 davvero Ruby riesce a incorporare i concetti più importanti di
 smalltalk e
 Lisp, come spesso si dice in giro.

 Forse no, ma secondo me essere accessibile e` anche un virtu` per
 un
 linguaggio, perche` quella gente che e` esperta di qualcosa che non
 e`
 la programmazione puo` prenderlo e farci qualcosa di utile mentre
 noi
 programmatori stiamo discutendo lexical vs dynamic scoping,
 parentesi
 vs altra sintassi, ecc...
 Vi spammo con qualcosa che scrissi a proposito:
 [1]http://www.dedasys.com/articles/scalable_systems.html


“Remember, always be yourself. Unless you suck.” - Joss Whedon

References

  1. http://www.dedasys.com/articles/scalable_systems.html

“chiaro scuro” [email protected] writes:

Ok, dai ho un po esagerato con le parentesi. era un colpo basso e non lo
penso neppure del tutto :slight_smile:

Tranquillo, avevo capito che era una esagerazione. Comunque concordo
che il problema di molti linguaggi è extra-tecnologico (didattico,
culturale, economico, etc.). Anche per Ruby nei confronti di Java ci
sono problemi analoghi. Al contrario pensa ad XML…

Mathematica è molto elegante da questo punto di vista, con una serie di
notazioni che permettono di usare ogni funzione in modo infisso, prefisso o
postfisso, con e senza parentesi.

Insomma, se lo devi usare da repl ok, ma se devi fare qualche
programmino di fatto sei obbligato a mettercele e usi le [] al posto
delle () più cento altri fronzoli. Ho un’esperienza solo di qualche
mese con Mathematica e non mi sento di azzardare confronti, ma per
l’utilizzo che se ne fa Mathematica non è paragonabile ad un
linguaggio di programmazione general purpose.

Certo è anche colpa mia che non ho cercato abbastanza, ma il tempo è
limitato e questa è la prima impressione che molti possono avere.

Le cose stanno cambiando velocemente in questi punti (vedi il progetto
gardener, cliki, practical common lisp, filmati, cl-user, etc).

Certo che la lisp community avrebbe bisogno di 4 o 5 kiaroskuro per
funzionare meglio :wink:

La prima impressione è sempre pericolosa e solitamente scoraggiante in
questo campo. Non so quale sia stata la tua strada verso il ruby, ma
molti non iniziano solo perchè hanno la prima impressione che non sia
“professionale” (come java o c++).

Leggiti alcune "strade" verso il lisp: http://wiki.alu.org/RtL_Highlight_Film

Ciao

Il giorno gio, 26/10/2006 alle 09.44 +0200, chiaro scuro ha scritto:

Questo argomento mi interessa molto. Non penso che una DSL sia
semplicemente una API evoluta e ripulita. In una DSL ad esempio spesso
inserisci delle limitazioni per poter fare assumption che semplificano
l’interfaccia. Tutto quello che fai con la DSL lo puoi fare anche con
un’API in modo + verboso.

Ad esempio diverse DSL potrebbero essere costruite sulla stessa API,
mettendo in evidenza caratteristiche diverse e modalità d’uso differenti.

Hmm. Non sono sicuro di essere d’accordo. Ti va se facciamo qualche
esempio? (ehi, potremmo farne un giochino: “API o DSL?”).

Per esempio, come classificheresti questo pezzo di codice Smalltalk:

html paragraph: [
html text: ‘Elenco elementi:’; br.
html orderedList: [
elements do: [:each | html listItem: each] ] ]

Giovanni

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