Lo scorso 17 febbraio Larry Wall, il creatore del linguaggio Perl, è stato ospite del centro COSBI (The Microsoft Research - University of Trento Centre for Computational and Systems Biology) e ha tenuto un seminario dal titolo “That Goes Without Saying (or Does It?)” presso il Polo Scientifico e Tecnologico Fabio Ferrari a Povo. In occasione della sua lezione ho avuto il piacere di parlare con lui degli aspetti inerenti alla progettazione dei linguaggi di programmazione.
Nella progettazione dei linguaggi di programmazione devono essere presi in considerazione molti aspetti, tra i quali performance, usabilità, rigore matematico. Normalmente è facile concentrarsi su alcuni di questi aspetti, tralasciandone altri. Secondo te, quali sono gli aspetti più trascurati e i trabocchetti più comuni nei quali si incorre progettando linguaggi di programmazione?
Lo sbaglio più comune è quello di non considerare i programmi come attività umane. Noi siamo creature linguistiche, e dedichiamo molto tempo comunicando in linguaggio naturale. Le nostre lingue madri sono espressive e l’utilizzo che ne facciamo è spesso guidato da motivazioni diverse da quelle del discorso immediato. Per analizzare correttamente il linguaggio umano, si deve fare attenzione ai diversi livelli di contesto. Per un progettista di linguaggi di programmazione è facile cadere nella trappola di credere che si debba pensare come un computer, anziché cercare di far pensare il computer in maniera più simile a quella umana. Fornire più di un modo per esprimere un’idea nei linguaggi di programmazione va contro al principio matematico dell’ortogonalità, ma dall’altra parte aumenta la capacità espressiva del linguaggio che così può rispondere ai requisiti che sono di interesse al programmatore. […]
In sostanza i linguaggi devono saper rispondere bene ai requisiti esterni. I linguaggi umani sono utilizzati da diverse persone con diverse abilità. I nostri linguaggi sono così ricchi da potere esprimere idee complicate in modo conciso. Alcune persone sono poeti, altre usano il linguaggio solo per risolvere i problemi o per lamentarsi che non li si stanno risolvendo. Analogamente un buon linguaggio di programmazione dovrebbe adattarsi facilmente al problema, permettendo a diversi tipi di persone di risolvere diversi tipi di problemi senza creare inutili complessità nella soluzione. Questa è una buona simbiosi.
I trend attuali nella progettazione di hardware indicano che l'hardware futuro sarà sempre più parallelo. Pensi che i linguaggi di programmazione debbano provare a includere caratteristiche in grado di permettere ai programmatori di sfruttare facilmente le nuove architetture parallele? Se sì, in che modo?
Assolutamente sì. Ma dipende da cosa si intende per “facilmente”. Alcuni linguaggi hanno caratteristiche parallele che non sono sempre facili da usare, perché interferiscono con altre caratteristiche alle quali sono legate. Perl 5, per esempio, ha troppe variabili globali per potere usare i thread adeguatamente, così abbiamo progettato Perl 6 con molte meno variabili globali. La tentazione più grande è quella di pensare di avere risolto il problema del parallelismo quando si è appena aggiunto una caratteristica come i thread, o i pipeline o le operazioni su vettori. Ci sono diversi tipi di parallelismi adatti a diversi problemi; l’approccio "one size fits all" non funziona bene a meno che non scegli i problemi con più cura di quanto facciano gli utenti. Nella progettazione di Perl 6, ci sono molti casi in cui abbiamo considerato il futuro della computazione parallela. Fondamentalmente, il trucco è nell'inventare notazioni che siano naturali al dominio del problema, tali che il programmatore possa esprimere le idee parallele semplicemente, senza introdurre dipendenze o sequenziazioni non volute. Facile a dirsi, ma difficile da farsi senza rimettere in discussione la saggezza degli antichi. […]
Abbiamo pensato al bilanciamento tra dati attivi e passivi, visto che i dati passivi possono essere immutabili, e sono facilmente copiati, mentre i dati attivi devono mantenere uno stato condiviso. Quindi, il parallelismo sui dati passivi si mappa bene alla programmazione funzionale. Abbiamo vari costrutti in Perl 6 che promettono molto sulla parallelizzazione, e evitano di introdurre sequenzializzazione dove non necessario. La maggior parte dei comuni operatori possono essere trasformati in operatori vettoriali che chiamiamo “hyper-operators”. Questi operatori assicurano che non importi l'ordine di esecuzione delle operazioni, a patto che i risultati siano nell'ordine corretto.
I linguaggi domain-specific (DSL) cominciano ad essere utilizzati in molti ambiti per descrivere e analizzare sistemi complessi. Progettare un DSL viene fatto rivolgendosi a piccole comunità di utenti e concentrandosi su aspetti specifici del dominio. Nonostante questo, condivide molti obiettivi con il design dei linguaggi generali. Qual è la tua opinione su questo? Pensi che alcuni aspetti della progettazione divengano più importanti nel caso dei DSL?
Ovviamente, la conoscenza specifica del dominio diventa più importante, o il DSL non sarà più utile di quanto non lo sia un linguaggio generale. Ma ci sono due modi in cui le cose possono andare storte. Se la progettazione è svolta da un esperto del dominio, il linguaggio rischia di essere progettato male come linguaggio. Al contrario, se è realizzato da un esperto di linguaggi, il linguaggio potrebbe risultare progettato male per il dominio. In realtà, qui ci sono due domini, e ci vogliono entrambe le competenze. Sfortunatamente, molti progettisti di linguaggi sono sbilanciati, e tendono a reagire in modo eccessivo ai problemi percepiti. Questo vale in entrambe le direzioni. Un DSL viene normalmente realizzato a causa del percepito fallimento dei linguaggi generali. D’altra parte i linguaggi generali spesso nascono dalle limitazioni percepite nei linguaggi domain-specific. Due sono le possibili soluzioni a questo problema. Una è l'incoraggiare l’uso di molti piccoli linguaggi su domini specifici. L'altra è cercare di fare finta che un linguaggio generale sia specifico per un dominio. […]
Ad ogni modo, la progettazione di linguaggi è al contempo un’arte e una scienza. Ci sono molti principi magnifici in azione, ma non c’è nessun principio che dica in anticipo su quale principio deve essere posta l’attenzione per primo. Quindi bisogna procedere lasciandosi guidare dai propri istinti innati ed essere preparati a sentirsi ripetere come e perché i propri istinti sono sbagliati. Se questa è la tua idea di divertimento, puoi diventare anche tu un progettista di linguaggi.
[Negli approfondimenti si può leggere l’intervista integrale in lingua inglese]