Dr. Carlo Pescio Intervista a Bertrand Meyer

Pubblicato su Computer Programming No. 61

Betrand Meyer è uno dei pensatori più originali nel campo della tecnologia ad oggetti. Ideatore del metodo di sviluppo noto come Design by Contract, che unisce alcune felici intuizioni dei metodi formali con diverse "best practices" dello sviluppo tradizionale, Meyer è anche il progettista di Eiffel, un linguaggio ad oggetti molto interessante che pone il Design by Contract al centro dell'attività di sviluppo, completandolo con un efficace supporto a tempo di compilazione. Meyer è inoltre l'autore di numerosi articoli e libri (tra cui va ricordato "Object-Oriented Software Construction") e presidente delle conferenze TOOLS (Technology of Object-Oriented Languages and Systems). Ho avuto il piacere di discutere con lui alcuni temi caldi dello sviluppo del software, come il confronto tra linguaggi puri ed ibridi (come C++ e Java), l'uso dei CASE tool e delle metodologie di analisi e design. Come sempre, Meyer non ha risparmiato qualche accenno polemico, ma le sue opinioni sono sicuramente di grande interesse per chiunque graviti intorno alla tecnologia ad oggetti.

CP:
Eiffel è un linguaggio object oriented puro, con type checking statico. Molte persone conoscono i vantaggi (dal punto di vista dell'ingegneria del software) dei linguaggi con type checking statico, paragonati a linguaggi con type checking dinamico come Smalltalk. Tuttavia, sembra più difficile trovare degli esempi reali che dimostrino, senza ambiguità di sorta, che un linguaggio OO puro è migliore di un ibrido come il C++ (che, invece, offre un percorso di migrazione più semplice). C'é un gran parlare sui benefici dei linguaggi puri, ma scarsa evidenza tratta dal mondo reale. Puoi darci un buon esempio concreto di come l'approccio "puro" di Eiffel lo renda migliore di altri, come ad es. il C++?

BM:
Innanzitutto dovrei dire che Eiffel compete solo parzialmente con ibridi come il C++ e Java. Eiffel dovrebbe invece essere visto come un sistema di costruzione del software, che può essere usato per assemblare dei componenti. Alcuni di questi componenti saranno scritti in Eiffel, ma è anche importante poter riusare componenti scritti in C, C++, Java, Fortran, eccetera.
Per questa ragione ISE ha speso uno sforzo considerevole nello sviluppo di una interfaccia completa verso tali linguaggi. Si può chiamare il C, il C++, eccetera da Eiffel, e viceversa. Abbiamo anche un nuovo tool, chiamato Legacy++, che prende una classe C++ e produce una classe Eiffel che la incapsula completamente; esiste della documentazione on-line sulla nostra pagina Web, all'URL www.eiffel.com. Usando Legacy++, si può integrare codice C++ esistente con parti in Eiffel, come se fosse tutto scritto in Eiffel.
Più in generale, quello che è importante per me non è una nozione astratta di "purezza" (un termine che io non uso), ma l'enfasi sulla qualità. Usando un ibrido come C++ o Java, non si riesce ad ottenere la necessaria qualità. Questo non in funzione di un idealismo aristocratico, ma per le ovvie conseguenze di carenze tecniche. Il risultato è che molte persone hanno trovato Eiffel più semplice da apprendere che un ibrido, e penso che in effetti il percorso di transizione sia più semplice perché Eiffel è un linguaggio consistente: con un ibrido, ci si deve costantemente confrontare con concetti provenienti da campi diversi - alcuni obiect oriented, altri legati al C - e spesso incompatibili. Questo rende l'apprendimento molto più difficile. Alcuni esempi:

il C++ e Java mantengono la sintassi contorta del C. David Clark, dell'Università di Canberra, che ha insegnato usando sia Eiffel che Java, ha recentemente scritto a proposito della sua esperienza come segue:
"La mia esperienza ha provato che gli studenti non trovano Java facile da apprendere. Troppe volte il linguaggio è di intralcio a quello che voglio insegnare. [...] La prima cosa che gli studenti vedono è:
public static void main (String [ ] args) throws IOException
Ci sono circa sei differenti concetti in quella singola linea che gli studenti non sono ancora pronti ad imparare. [...] Il solo modo per leggere un numero dalla tastiera è di leggere una stringa e farne il parsing. Nuovamente, questo è qualcosa che disturba già dalla prima lezione. Java tratta i tipi di dato primitivi (int, char, boolean, float, long,...) in modo diverso dagli altri oggetti. [...] La mancanza dei generic1 significa essere costretti ad un casting continuo se si vogliono usare collezioni di elementi come Stack o Hashtable. Questi sono tutti ostacoli per gli studenti alle prime armi, e li distraggono dagli scopi principali del corso".
Questo è vero anche per i professionisti. Una delle ragioni del successo di Eiffel in grandi progetti industriali è che persone con ogni tipo di background - programmatori, ma anche funzionari di banca, commerciali, matematici, ingegneri, eccetera - possono apprenderlo bene e rapidamente, senza dover padroneggiare costrutti complicati e soggetti ad errori ereditati dal C.

In C++ e Java, come fatto notare da David Clark, i tipi base (interi e simili) sono al di fuori del type system degli oggetti. Questo impedisce di implementare un intero filone di pattern object oriented.

L'assenza dei generic in Java rende la programmazione più complessa e porta a serie inefficienze (come la necessità di riconoscere i tipi a run-time) e, peggio ancora, a mancanza di sicurezza, dal momento che è impossibile fare un completo type-checking statico. In altre parole: possibilità di crash a run-time. Questo è tutt'altro che un problema astratto che interessa i soli puristi.

I cast del C++ rendono la garbage collection impossibile. Il risultato: una gestione della memoria "manuale", il che significa tempi di sviluppo molto più lunghi (e spiega in parte perché il software è sviluppato più rapidamente in Eiffel), un lavoro tedioso e noioso per i programmatori, e peggio ancora numerosi bug nel software a causa di aree di memoria non reclamate e puntatori impazziti.

L'assenza dell'ereditarietà multipla in Java rende impossibile il corretto progetto di sistemi object oriented.

La lista delle concrete, spiacevoli conseguenze prosegue ancora. Non è una questione di purezza in sé, è una questione di costruire software più rapidamente e meglio - in altre parole, di guadagnare se lo si fa nel modo giusto, di perdere denaro altrimenti.

CP:
Eiffel è ormai in circolazione da dieci anni circa. Mi sembra che la sua popolarità sia in aumento, anche grazie a tool e supporto migliori. Però, non mi pare che sia sul punto di "esplodere". Cosa pensi che manchi ad Eiffel per innescare i meccanismi di un necessario consenso? Qual è l'ingrediente segreto per esplodere come Java (forse uno staff di marketing migliore?).

BM:
In termini di numero di licenze, per ISE Eiffel parliamo di decine di migliaia, quindi inferiore ad alcuni concorrenti fin troppo reclamizzati. Ma in termini di progetti reali, alcuni dei più grandi progetti sviluppati con successo con tecnologia ad oggetti (pongo l'enfasi sul "successo", dato che non sono mancati i disastri con altri linguaggi) sono stati sviluppati proprio usando Eiffel. Nel settore bancario e finanziario, in particolare, progetti ambiziosi che possono far guadagnare o perdere miliardi alle rispettive compagnie, tendono a spostarsi verso Eiffel. Un esempio piuttosto noto è quello della CALFP Bank, 700.000 righe di codice ISE Eiffel su cui si basa l'intero sistema bancario (front office, back office, commerci collaterali, eccetera). Il progetto è stato terminato nei tempi e con i costi previsti, da un gruppo formato per due terzi da non-softwaristi (funzionari commerciali, economisti, funzionari di banca) che hanno immediatamente appreso Eiffel perché la sua chiarezza, semplicità e funzionalità ha permesso loro di programmare i modelli finanziari direttamente. Quale altro approccio avrebbe funzionato? Potremmo pensare di mettere le stesse persone a scrivere codice C++ o Java, pieno zeppo di { e } e & e * e avere risultati corretti? L'abbondanza di materiale di marketing non aiuta quando il software non funziona.

CP:
A questo punto la domanda è indispensabile: cosa ne pensi del boom di Java?

BM:
Mi sembra che il boom sia soprattutto pubblicitario. Per quanto riguarda le applicazioni, è troppo presto per dirlo. Oltre alle applets, non ho visto molte applicazioni Java. Ripetere "Java, Java" non basta a creare un'industria. In tutti i casi in cui ISE Eiffel ha dovuto competere con Java, Eiffel ha vinto. I tool di Java sono semplicemente inadeguati, l'approccio è troppo giovane e privo di verifiche sul campo, ed i limiti del linguaggio sono fin troppo ovvii. Questo non significa che Java sia privo di valore. Assolutamente. Quello che è interessante in Java - molto interessante - è la macchina virtuale con la sua promessa di portabilità istantanea. Presto avremo la possibilità di generare codice Java, o bytecode Java, all'interno di ISE Eiffel, combinando in tal modo il meglio dei due approcci.

CP:
In alcuni casi, ho visto che Eiffel può spaventare i programmatori. A guardare meglio, non è il linguaggio stesso, ma la nozione di Design by Contract che li spaventa. Programmatori senza un background formale in informatica o ingegneria del software non sono semplicemente abituati a pensare alla programmazione in quel modo. Trovano molto difficile cambiare mentalità, e hanno timore di "sprecare tempo" con i dettagli invece di "far funzionare il programma". Inoltre, conosco diversi software engineer piuttosto scettici a proposti dell'applicabilità delle asserzioni al di fuori di domini molto ben definiti (come l'onnipresente esempio dello Stack). Per molti versi, il Design by Contract condivide molte delle difficoltà, vantaggi, e miti dei metodi formali (che non hanno avuto molto successo fuori dall'accademia). È solo una questione di formazione (anche a livello di management) o ci sono reali impedimenti alla diffusione del Design by Contract?

BM:
Questo è molto interessante. Ho visto molte persone che applicavano il Design by Contract e non ho visto nessuno che fosse spaventato dalla tecnica, che è semplice ed accessibile a chiunque con una cultura di scuola superiore.
A dire il vero, l'idea di Design by Contract è proprio di evitare le esagerazioni dei metodi formali, e di ottenere qualcosa di concreto che possa essere usato a beneficio di ogni progetto, grande o piccolo, con un costo limitato. Le conseguenze sono eccezionali: con uno sforzo aggiuntivo trascurabile, si riesce ad ottenere software che funziona sin dalla prima volta. È incredibili quando rapidamente si possano trovare potenziali bug, prima che abbiano il tempo di creare problemi. È qualcosa che chiunque può usare: le tecniche sono semplici da imparare ed applicare.
Alcune persone hanno commentato che il Design by Contract è così importante che i suoi effetti sul processo di sviluppo del software sono paragonabili a quelli di tutte le altre idee della tecnologia ad oggetti messe insieme.
La vera questione è se ci si possa permettere di non applicarlo. L'incidente di lancio di Ariane 5 dell'European Space Agency nel giugno 1996 - 500 milioni di dollari andati in fumo in pochi secondi - era interamente dovuto al riuso di una routine senza le opportune asserzioni (ovvero il giusto contratto)2. Usando il Design by Contract, il bug sarebbe stato riconosciuto come parte del quality assurance, e forse non sarebbe addirittura stato introdotto.
È incredibile come alcune persone pensino che si possa avere un riuso su larga scala senza contratti software - in Java, C++, Ada (il linguaggio usato per Ariane), eccetera. Questa è semplice follia: riusare un componente senza la corretta specifica di cosa questo dovrebbe fare! Come Ariane dimostra, in questi casi sarebbe meglio non riusare.
Come diverse persone hanno scritto (ad es. Tom de Marco, uno dei nomi più rispettati nell'ingegneria del software, nel numero di febbraio di IEEE Computer), solo le asserzioni alla Eiffel, con il meccanismo dei contratti built-in, hanno le basi per stabilire con successo una produzione industriale di componenti software riusabili.

CP:
Qual è la tua posizione rispetto ai CASE tool per Object Oriented Analysis e Design? Io ho visto molte aziende in cui i CASE tool vengono sostanzialmente usati per creare dei bei diagrammi, e pochissime che erano in grado di sfruttarli nell'intero ciclo di vita del software. Per molti versi, una notazione come BON3 rende il round-trip engineering molto più semplice. Però, BON sembra di più basso livello se comparata, ad esempio, con linguaggi/notazioni come UML. Fino a che punto una notazione più vicina al linguaggio di programmazione è la scelta migliore per OOA/D?

BM:
Concordo con la tua opinione su come i CASE tool vengano usati in molte compagnie. Tuttavia, il tuo commento su BON mi sorprende. BON è certamente di più alto livello rispetto ad UML, in particolare grazie al suo supporto per i contratti. È anche molto più semplice.

CP:
Direi che in alcuni casi "alto o basso livello" dipende da chi guarda. Più di una persona direbbe che BON sacrifica le associazioni, le molteplicità, i diagrammi degli stati, e così via in favore della reversibilità. Alcuni andrebbero anche oltre dicendo che, per fare ciò, si è resa la notazione più vicina ai linguaggi di programmazione, e quindi di più basso livello rispetto (ad esempio) ad UML.

BM:
BON fa un buon lavoro nell'identificare l'insieme dei concetti di base su cui si può costruire tutto il resto. UML è diverso. Nei suoi numerosi concetti troviamo l'importante e il marginale, il difficile ed il banale. Io credo che questo sia il risultato del processo di progettazione di UML, che per paura di offendere qualcuno ha incoporato un pezzettino delle idee di tutti, ottenendo però un risultato a bassa coerenza. Un po' di OMT, un po' di use-case qua e là, ovviamente le idee di Booch, una genuflessione ai pattern... Il risultato è complesso e inconsistente. Questa non è la strada per produrre un buon metodo. Confrontiamolo con BON, che è piccolo, potente e semplice.
L'idea di un metodo di analisi è di aiutare analisti e sviluppatori a pensare. Se devono cominciare leggendo centinaia di pagine di documentazione (come quelle che descrivono UML), non arriveranno mai a svolgere il loro vero lavoro. Viceversa, l'insieme dei diagrammi di BON sta in una sola pagina (lo so, in quanto li ho riprodotti nel capitolo sull'analisi nella seconda edizione di "Object-Oriented Software Construction"). Il metodo diventa quindi un aiuto, non una aggiunta di ostacoli allo sforzo di sviluppo. I concetti di base - uniformità, contratti, reversibilità, l'uso corretto delle gerarchie, relazioni cliente-fornitore, le attività del ciclo di vita del software - seguono tutti da buoni principi di ingegneria del software. Possono essere appresi rapidamente e applicati al solo compito che importa veramente: capire il problema e costruire rapidamente una soluzione di qualità.
Non è giusto, peraltro, caratterizzare la programmazione ed i linguaggi di programmazione come "di basso livello". Questo potrebbe essere vero se usassimo il Basic, il C++ o Java, ma una buona notazione di programmazione può essere usata per le attività di più alto livello. Cosa può esserci di più alto livello che la nozione di classe differita4 e di invariante di classe in Eiffel? Leggendo un documento di alto livello scritto in Eiffel, si può comprendere cosa stia descrivendo in pochi minuti, senza neanche rendersi conto che si sta imparando una nuova notazione. Si passa invece a discutere i veri interrogativi nel dominio del problema: qual è la massima temperatura nella fornace, possono esserci più interruzioni pubblicitarie consecutive in uno show TV, dobbiamo avere la stessa spaziatura in tutte le linee di un paragrafo, qual è la massima inclinazione orizzontale per il razzo, e così via. Questo è il tipo di informazione che dobbiamo esprimere in un documento di analisi - indipendentemente da ogni considerazione implementativa. UML non permette di esprimerla; Eiffel o BON lo consentono. Ora, quale chiameresti di più alto livello?

CP:
Ci sono altre ragioni per usare BON invece di UML?

BM:
È veramente difficile vedere quali benefici una compagnia possa trarre da UML (a meno che, ovviamente, non sia una società di consulenza che tratta UML).

CP:
Poco fa hai menzionato il tuo libro "Object Oriented Software Construction"5. So che la seconda edizione sarà presto disponibile. Cosa c'é di nuovo per chi ha già letto la prima edizione? E perche chi non l'ha letta dovrebbe procurarsi una copia della seconda?

BM:
La seconda è completamente differente e io spero di gran lunga migliore. È molto più completa, con capitoli su concorrenza, persistenza, molte parti metodologiche (come: trovare le classi e gli oggetti, usare bene l'ereditarietà, gestire gli errori, insegnare i metodi, il processo di sviluppo, l'analisi ad oggetti, eccetera), ed anche typing, molti design pattern, gestione delle eccezioni, ereditarietà multipla e molto altro.
Anche le parti che rimangono dalla prima edizione sono state complessivamente migliorate. Il libro è in due colori, ed è corredato da un CD che contiene l'intero testo con hyperlink, in formato Adobe Acrobat, e un completo ambiente Eiffel. Sono 1300 pagine e mi auguro proprio che possa servire come riferimento per la tecnologia ad oggetti per molto tempo.

CP:
Guardando al futuro, il calcolo concorrente e distribuito sarà sempre più importante. Ho una certa familiarità con il tuo modello SCOOP (Simple Concurrent Object-Oriented Programming)6, che ritengo sia molto elegante nel suo minimalismo. Tuttavia, non pensi che proprio questo minimalismo possa allontanare alcuni "veri programmatori" che vogliono avere "il controllo della situazione"? Ad esempio, la sincronizzazione basata sulle precondizioni è molto elegante, ma come gestisci i time-out, fondamentali nella programmazione di sistemi reali? Inoltre, un meccanismo run-time come il Concurrency Configuration File è veramente così buono da attrarre chi lavora su architetture a parallelismo massiccio, o è solo orientato verso architetture distribuite con una granularità relativamente grande?

BM:
Mi fa veramente piacere vedere la profondità con cui conosci il mio lavoro! Non credo ci siano contraddizioni tra l'avere un meccanismo semplice ed uniforme, e fornire delle possibilità supplementari per persone con particolari necessità. I time-out fanno ora parte del framework SCOOP: infatti, uno degli esempi dettagliati nella seconda edizione di Object Oriented Software Construction, nel capitolo sulla concorrenza, usa i time-out in modo intenso per implementare dei meccanismi di watchdog.
Il Concurrency Control File è un modo elementare per legare il modello SCOOP con architetture fisiche concorrenti, ma altri modelli sono possibili, specialmente per le architetture con parallelismo a granularità fine. Il modello è molto aperto sotto questo punto di vista.

CP:
Per concludere, tu sei uno dei pochi ricercatori che ha intrapreso una carriera di successo come imprenditore e manager, pur continuando a fare un eccellente lavoro di ricerca. Come sei riuscito a vivere in entrambi i mondi? Guardi costantemente alla "vendibilità" della tua ricerca, o cerchi più che altro di rendere pratica la tecnologia avanzata, o che altro?

BM:
Ti ringrazio per la tua valutazione. È vero che ho vissuto sia nel mondo accademico (anche in una breve permanenza all'Università di Milano un paio di anni fa) che nel mondo degli affari. Non c'é una vera necessità di avere una doppia personalità, perché gli aspetti sono complementari.
Anche da una prospettiva accademica, il vero test del successo nell'ingegneria del software è, a mio avviso, vedere se qualcuno, da qualche parte, apprezza abbastanza le tue idee da applicarle nello sviluppo di un progetto software, quando il successo della sua compagnia e la sua stessa carriera dipendono da esso. Senza questa verifica, non puoi neppure sapere se le tue idee sono buone o meno. È fin troppo semplice proporre ogni tipo di concetto che sembra buono sulla carta: chiunque sa farlo. La sola cosa che importa, alla fine, è se quei concetti porteranno al successo nello sviluppo di software sotto i normali vincoli della produzione industriale: non abbastanza denaro, non abbastanza tempo, concorrenti sleali, clienti impazienti. Le sole idee importanti sono quelle che aiutano in questo contesto.
Ecco perché io spendo essenzialmente tutto il mio tempo, ora come ora, lavorando con (o per) i clienti di ISE. Io vedo il mio compito come quello di assicurarmi che in nostri clienti abbiano successo nei loro progetti. Il resto, incluso il riconoscimento accademico ed il progresso scientifico, diventa una naturale conseguenza. Ma lo scopo principale è di permettere ai nostri clienti di avere successo nei loro progetti. I benefici del business guidano tutto il resto. Uno dei benefici di lavorare in un campo così interessante è che spesso ci si rende conto che ciò che è buono per gli affari, è buono anche per la scienza.

Note:
1) I template del C++. In alcuni linguaggi, come Ada, vengono chiamati generic. [back]
2) Ulteriori comunicazioni dell’ESA sembrano però mettere in dubbio questa affermazione, spostando la responsabilità più che altro sulla gestione del progetto. [back]
3) Business Object Notation. Un metodo di analisi e design centrato sui contratti software. [back]
4) Concettto analogo ad una classe astratta in C++ o ad una interfaccia Java. [back]
5) In Italia la prima edizione è stata tradotta da Jackson, con il titolo "La costruzione del software object oriented". [back]
6) Si veda ad esempio Communication of the ACM, settembre 1993. [back]

Reader's Map

Molti visitatori che hanno letto questo articolo hanno letto anche:

Biografia
Carlo Pescio (pescio@acm.org) svolge attività di consulenza in ambito internazionale nel campo delle tecnologie Object Oriented. Ha svolto la funzione di Software Architect in grandi progetti per importanti aziende europee e statunitensi. È incaricato della valutazione dei progetti dal Direttorato Generale della Comunità Europea come Esperto nei settori di Telematica e Biomedicina. È laureato in Scienze dell'Informazione ed è membro dell'ACM, dell'IEEE e della New York Academy of Sciences.