Fractal Programming (considerazioni su DSL e Language Oriented Programming)

[shinya]

Posto il link ad un articolo interessante, vorrei sapere le vostre opinioni:

http://ola-bini.blogspot.com/2008/06/fractal-programming.html

Credo sia un approccio da valutare.

[marco.r]

Il problema di un approccio come quello proposto secondo me non e' tanto la difficolta' del dover conoscere due (o piu'!) linguaggi diversi, ma dall'attrito che si genera tra uno "strato" e l'altro della piramide, dovute proprio alla diversita' che li caratterizzano. Quando dallo strato dinamico usi quello stabile ti trovi necessariamente a lavorare con un'API un po' aliena e molto probabilmente poco idiomatica, e c'e' poca alternativa ad una buona mole di lavoro manuale per ammorbidire le differenze. Questa quantita' di lavoro e' giustificata quando si producono binding per una libreria per uso pubblico, quando invece si e' fatto una scelta per lavorare meglio e in meno tempo e' gia' diverso. Bisogna trovare il "punto giusto" dove piazzare il salto tra uno strato e l'altro, (diciamo quanto piu' in basso e' ragionevole andare), ma non e' banale, e spesso neanche chiaro finche' si' e' iniziato il lavoro.

[shinya]

Quello che dici mi sembra sensato.
Non credo si possa definire una regola metodologica da usare sempre per definire dove fermarsi nell'interazione tra i vari livelli.

Per come la vedo io, il livello dinamico (quello centrale) dovrebbe fungere solo da "interprete" per i vari dsl ad alto livello, che nella mia personale visione sarebbero sempre linguaggi "interni", che non sono poi cosi difficili da implementare, e da, ovviamente, "aggancio" allo strato stabile (quello in basso).

Qui si genera l'attrito di cui parli, tutto vero, ma credo si tratti sempre di un problema di astrazione come ne affrontiamo tutti i giorni. Non credo sia un caso speciale. I videogiochi li fanno cosi da anni (c++/lua ad esempio...).

Io stavo pensando ad un approccio del genere per un web framework che sto pensando per il lavoro. Mi fanno tutti piuttosto schifo, e devo lavorare in un ambiente piuttosto "livellato" tra le varie applicazioni (java su websphere con la parte db a cura di stored procedure su oracle...la situazione è sempre questa. La maggior parte è solo CRUD, e raramente si sfora dagli schemi.).

Se un giorno mai avrò successo con questo approccio te lo farò sapere :)

[banryu79]

Ho letto anche io l'articolo e l'ho trovato interessante.
Premesso che non sono un programmatore esperto, e le mie conoscenze sono ristrette solo ad alcuni ambiti limitati, la mia sensazione si identifica molto con l'opinione espressa da marco.r nel suo post.

Anche secondo me la sfida non sta tanto nel "diventare poliglotti" ma nel far lavorare in maniera flessibile i layer a contatto tra loro...

Questo per me significa trovare astrazioni comuni per definire un'interfaccia tra i vari layer, e il concetto mi ricorda molto cose come CORBA e COM; cioè una serie di standardizzazioni per creare l'infrastruttura neccessaria alla comunicazioni interprocesso.

[cdimauro]

Concordo con marco.r. A lavoro utilizziamo diversi linguaggi e la coesistenza non è affatto facile. Tutt'altro.

Per fortuna ci stiamo muovendo verso la creazione di middleware con Ice alla base (è simile a CORBA, ma molto più semplice, flessibile ed efficiente), ma purtroppo al momento manca il binding per PERL (e l'unico collega che lo usa si amputerebbe le mani piuttosto che smettere e passare a... eresia! Python! :p).

Quanto ai DSL, personalmente non mi piacciono: preferisco affidarmi a linguaggi già sviluppati e con una solida comunità alle spalle.

Comunque giusto oggi ho creato un DSL molto semplice (con ANTLR e generatore di parser in Python) per particolari esigenze che ho per un preciso progetto, ma si tratta di un evento raro, fortunatamente.

Certo, creare nuovi linguaggi mi affascina ed è da parecchi anni che mi cimento, ma dev'esserci uno scopo con un fondamento e il piatto della bilancia che penda inesorabilmente sul versante dei vantaggi.

Infatti per un'altra parte dello stesso progetto ho preferito non creare un DSL ad hoc, e affidarmi a Python: i vantaggi dell'avere un nuovo DSL erano decisamente inferiori.

[shinya]

@cdimauro:
Certo, creare un linguaggio a sè stante (con parser e tutto quanto) anche con tool fighi come ANTLR (ci sto giocando un pò anch'io nei ritagli di tempo) può diventare molto dispendioso. Infatti non è la strada che percorrerei volendo usare vari DSL per risolvere problemi.

Quando si parla di DSL si parla di due tipologie: esterni (usando ANTLR o sarcazzo) e interni (modellando il linguaggio in modo che assomigli a qualcos'altro).

Io per esempio mi sono fatto, come esercizio un piccolo DSL che wrappa attorno a jdbc, in java:


withConnection(JDBC_URI)
.doThis(
select("select * from emp where ename = ?")
.in("Martin")
.saveToList(empList, EmpBean.class));


Questo anche se non sembra, è java al 100%. Per me è un grosso passo avanti, perchè il corrispettivo codice "canonico" è mooolto più verboso ed è facile dimenticarsi di chiudere una connessione/statement/resultset/ecc...

E non è necessario molto impegno per scrivere una cosa del genere. Usando altri linguaggi, tipo ruby/groovy/lisp/... viene ancora più facile giocare sulla sintassi.
In lisp poi è l'approccio che si usa di solito, vedi On Lisp di Graham.

Poi i gusti sono gusti ovviamente :) Ma forse i tuoi gusti sono condizionati dal fatto che in python non è cosi facile modellare la sintassi per creare un DSL interno. Almeno, cosi dicono, io python lo conosco poco.

[cdimauro]

@cdimauro:
Certo, creare un linguaggio a sè stante (con parser e tutto quanto) anche con tool fighi come ANTLR (ci sto giocando un pò anch'io nei ritagli di tempo) può diventare molto dispendioso. Infatti non è la strada che percorrerei volendo usare vari DSL per risolvere problemi.
Francamente non lo trovo complicato. Poi ovviamente dipende da ciò che bisogna farci: non è che realizzo compilatori, ma parser ed eventualmente qualche interprete per linguaggi semplici.
Quando si parla di DSL si parla di due tipologie: esterni (usando ANTLR o sarcazzo) e interni (modellando il linguaggio in modo che assomigli a qualcos'altro).

Io per esempio mi sono fatto, come esercizio un piccolo DSL che wrappa attorno a jdbc, in java:


withConnection(JDBC_URI)
.doThis(
select("select * from emp where ename = ?")
.in("Martin")
.saveToList(empList, EmpBean.class));


Questo anche se non sembra, è java al 100%. Per me è un grosso passo avanti, perchè il corrispettivo codice "canonico" è mooolto più verboso ed è facile dimenticarsi di chiudere una connessione/statement/resultset/ecc...

E non è necessario molto impegno per scrivere una cosa del genere. Usando altri linguaggi, tipo ruby/groovy/lisp/... viene ancora più facile giocare sulla sintassi.
In lisp poi è l'approccio che si usa di solito, vedi On Lisp di Graham.

Poi i gusti sono gusti ovviamente :) Ma forse i tuoi gusti sono condizionati dal fatto che in python non è cosi facile modellare la sintassi per creare un DSL interno. Almeno, cosi dicono, io python lo conosco poco.
Ho capito cosa intendi. I DSL interni al momento non li userei: è troppo facile estendere la sintassi con costrutti che magari servono poche volte, e rimane il problema di condividere queste estensioni con gli altri colleghi / utenti e la comunità.

Quanto a Python, è abbastanza facile giocare con la sintassi. Perché dici che con altri linguaggi è più facile realizzare DSL interni?