Chi segue il blog di Zio Bob e quello di Ron Jeffries avrà di certo notato come quando questi due BIG incollano del codice nei loro post, il linguaggio di questi frammenti di codice è spesso Ruby.

In questo post Robert Martin dice la sua sul futuro di Ruby e RoR, e soprattutto su quale debba essere attualmente la collocazione di questo linguaggio nel mondo degli applicativi Web.

Cito alcuni dei passaggi più significativi (grassetti miei): Read the rest of this entry »

Da qualche tempo - come avrete notato dalla mia sezione del.icio.us - sto studiando a tempo perso una argomento molto interessante: i domain specific languages. Nei prossimi post vorrei parlarne con voi. Inizio con un brevissimo post giusto per rompere il ghiaccio.

Per farla breve, i dsl sono linguaggi di programmazione creati specificamente per descrivere un particolare dominio, e che possono anche non essere Turing-completi. Per fare un esempio banale, il seguente file di configurazione è un dsl (detto esterno):

TransazioneAttivita.View = Attivita TransazioneAttivita.IdAttivita.UI.Update = False TransazioneAttivita.TipoAttivita.UI.Update = True TransazioneAttivita.Indirizzo.UI.Update = True

Questo semplice linguaggio è costruito appositamente per descrivere le caratteristiche di transazione applicativa, in particolare sono mostrati quali sono i campi su cui è possibile fare l'update per l'oggetto di dominio Attivita. E' chiaro che con questo specifico linguaggio non sarà possibile descrivere nient'altro che non riguardi alcune proprietà di una transazione.

Fin qui solo limiti. Ciò che però rende questo linguaggio di "valore" è il fatto che chiunque non sia un programmatore, ma che sappia che cosa è un'attività programmata, può modificare a suo piacimento la transazione di modifica delle attività programmate. Sottovalutare questo aspetto vorrebbe dire non avere compreso quanto sia importante la comunicazione tra esperti di dominio e sviluppatori.

La cosa interessante è che se avessimo dovuto descrivere le stesse proprietà della transazione di attività programmate in Java, tale descrizione sarebbe stata fruibile solo da uno sviluppatore che conosce Java.

La domanda quindi è: più un linguaggio di programmazione è espressivo e più ristretta è la comprensione dai non addetti ai lavori? O la relazione è tra astrazione del linguaggio e comunicazione?

Ai prossimi post la risposta.

Il cuore del software è la sua capacità di risolvere problemi di dominio per i suoi utenti.

Questa frase di Eric Evans implica una serie di aspetti, ne elenco di seguito alcuni:

1. Il software risponde all'esigenza di risolvere problemi reali
2. Il software viene costruito per i suoi utenti
3. Chi crea il software conosce le esigenze degli utenti
4. Il software è una rappresentazione del dominio
5. Chi crea il software lavora a stretto contatto con gli esperti di dominio al fine di rappresentare la loro conoscenza del dominio stesso
6. Il reale valore del software risiede nell'implementazione del modello del dominio

Tom negli ultimi due post ha affrontato un argomento molto interessante, e cioè l'evoluzione dei linguaggi di programmazione soprattutto in ambito Web dal punto di vista della produttività e della reale utilità. Con questo mio post vorrei continuare questa stimolante discussione.

In questo video il grande Ward Cunningham (per chi non lo conoscesse, l'inventore del Wiki, nonchè una delle menti dell'eXtreme Programming, e inventore di FIT), parla del rapporto tra computer e uomo, dei linguaggi di programmazione, e di molte altre cose interessanti. Di seguito un breve riassunto dell'intervista e un mio breve commento.

Innanzitutto Cunningham esordisce dicendo che ha imparato nella sua vita più di duecento linguaggi di programmazione. Molti li considera pessimi, perché chi li ha disegnati aveva come obiettivo quello di implementare funzioni matematiche, senza concentrarsi sui costrutti del linguaggio in sè. Da questa affermazione Cunningham entra nel cuore dell'intervista, affermanso che la cosa fondamentale di un linguaggio di programmazione è la sua capacità di definire e di avere al suo interno concetti, e che questi concetti abbiano un confine che li delimiti, che gli si possa inviare messaggi per poterli interrogare. E' importante che io programmatore possa stabilire, indicare, qual è l'idea più importante tra quelle che sto modellando, e che possa dire che gli altri sono concetti secondari. A questo riguardo Cunningham afferma che da quando ha conosciuto Smalltalk, ha smesso di imparare altri linguaggi. Infatti nella programmazione ad oggetti, ogni oggetto diventa un linguaggio, ed io programmatore divento un language designer definendo questi concetti. Il computer in questo modo mi insegna quali sono i concetti principali che devo conoscere di un certo argomento, costruendo un linguaggio che lo descriva. Il computer quindi ci fa conoscere cose del nostro mondo che prima non conoscevamo. Un linguaggio di programmazione diventa così un ponte, uno strumento verso la conoscenza del mondo che stiamo modellando, nonché uno strumento per l'interazione tra essere umani.

Quest'ultimo aspetto secondo me è la cosa fondamentale di un tool o di un linguaggio di programmazione, o comunque di qualsiasi cosa riguardi un computer: la sua capacità di sapere rappresentare concetti, conoscenza, in maniera chiara, precisa, "delimitata da confini", contestualizzata, e la capacità di poterci ragionare sopra permettendoci di concentrarci sulle idee stesse, senza tecnicismi che offuscano i concetti. Strumenti che permettano di reagire con il minimo sforzo possibile al dinamismo della conoscenza, al naturale evolvere della stessa, che permettano di imparare e conoscere più di quanto sappia o di quanto possa conoscere se non li informatizzassi. Tutto ciò ovviamente coinvolge la comunicazione tra essere umani ed è qui che un tool o un linguaggio si differenziano nella loro bontà, a livello di conoscenza e espressività: quanto migliorano la comunicazione tra le persone? Ad esempio l'assembler molto poco! C molto poco ma già meglio! Altri linguaggi ad alto livello forse meglio ancora. A questo aspetto se ne aggiunge un altro, e cioè che ogni linguaggio deve essere in grado di supportare il naturale dinamismo del processo di comprensione e di knowledge crunching in modo iterativo e graduale. E' qui che diventa importante la capacità di un linguaggio o di un tool di garantire flessiblità, testabilità, robustezza e chiarezza.