Storia dei compilatori xBase liberi

Verso la metà degli anni ’80 la scena informatica ha nella società Ashton-Tate uno dei suoi protagonisti indiscussi  tra gli sviluppatori di applicazioni gestionali, gli esperti e i semplici hobbisti. Con il DBIII, che è essenzialmente un database programmabile,  è possibile creare in modo semplice e intuitivo i propri archivi, ed anche scrivere delle procedure in un semplice linguaggio di alto livello, che permettono di gestire tali archivi. DBIII infatti disponeva di un suo linguaggio di programmazione dotato di decine di istruzioni specifiche per la manipolazione dei database. Era possibile quindi usare DBIII “direttamente” dandogli una istruzione alla volta, oppure per le operazioni ripetitive scrivere tali istruzioni in un file e poi far leggere tale file al DBIII, che le avrebbe eseguite sequenzialmente. Era anche possibile presentare dei menu di scelta e dare quindi in pasto ad utenti inesperti di programmazione dei veri e propri programmi gestionali completi, come per esempio una gestione ordini e fatturazione, inventari, gestione del magazzino ecc. In questo modo una impresa poteva acquistare il DBIII e poi incaricare un programmatore di progettare una intera gestione, magari scrivendo delle procedure ad hoc. Ben presto intraprendenti programmatori cominciarono a proporre queste gestioni bell’e pronte, o personalizzabili secondo le esigenze, ad un mercato in rapidissima espansione e praticamente vergine. All’epoca c’ erano poco software e pochi programmatori, quindi il DBIII, che era infinitamente più potente, efficace e semplice dei tradizionali linguaggi di programmazione, si trovò rapidamente ad avere la parte del leone. Ma c’erano un paio di inconvenienti. Le procedure scritte per il DBIII richiedevano per essere eseguite che DBIII fosse installato sul computer che le avrebbe eseguite, e DBIII costava se non ricordo male un milione e mezzo di lire (rapportato ad oggi, almeno tre o quattromila euro), inoltre le procedure erano dei semplici files di testo e qualunque furbastro avrebbe potuto copiarle e riutilizzarle per conto proprio di nascosto dal legittimo autore. Quello che successe nella realtà fu che quasi tutti avevano una copia pirata del DBIII e fioriva un mercato nero assai vasto di programmi trafugati dalle varie aziende. I nerds dell’epoca ebbero così la possibilità di impossessarsi di moltissimi programmi e di studiarseli in santa pace, senza contare la vasta (per l’epoca) letteratura sul DBIII che completava gli ottimi manuali che accompagnavano il prodotto (e di cui quasi tutti naturalmente avevano una fotocopia abusiva).

La Ashton-Tate si era sempre rifiutata di dotare DBIII di un vero e proprio generatore di applicazioni che svincolasse il linguaggio, ossia le procedure, dal DBIII vero e proprio. Sarebbe stato possibile cioè far generare a DBIII dei programmi eseguibili anche su computer su cui DBIII non era stato installato, creando un modulo direttamente eseguibile dal computer ma impossibile o comunque difficilissimo da “spacchettare” per capire cosa c’era dentro. Potevano, ma non vedevano l’interesse a farlo: avrebbero agevolato i programmatori ma a loro interessava solo vendere copie del DBIII, senza rendersi conto che ormai il DBIII doveva la sua fortuna proprio ai programmatori, e almeno una forma di offuscamento del codice o pseudocompilazione o criptazione era essenziale per tutelare il lavoro dei programmatori, che mal tolleravano di dover dare in giro il loro sudato codice in forma non protetta e liberamente copiabile. Il mercato stava cambiando, e sempre meno persone avvertivano la necessità di usare direttamente il DBIII, dato che la disponibilità di software già pronto era vasta e crescente, quindi l’obbligo di comprarlo si riduceva alla necessità di essere in regola con le licenze d’uso ma appariva come una specie di tangente salatissima che si doveva pagare ad Ashton-Tate per poter eseguire programmi scritti per DBIII.

Verso la fine degli anni ’80 un paio di società americane riuscirono a creare dei compilatori in grado di prendere le procedure scritte per il DBIII e trasformarle finalmente in programmi stand-alone che non necessitavano di nessun componente aggiuntivo per essere eseguiti: e fu la rivoluzione.

La Nantucket Corp. presentò Clipper, mentre l’altro prodotto che ricordo si chiamava Quicksilver. La spuntò Clipper, che era facilissimamente disponibile in versione “copia non ufficiale”, accompagnato da una essenziale ma completa documentazione, e dotato anche di alcune funzioni supplementari che rendevano ancora più potente il linguaggio, particolarmente un sistema per collegare Clipper al linguaggio C, rendendolo uno strumento potentissimo in mano sia al programmatore della domenica, che poteva compilare semplici procedure derivate dal DBIII, sia al vero esperto programmatore, che poteva sbizzarrirsi a fare qualunque tipo di applicazione.

La prima preda di Clipper furono i milioni di utilizzatori del DBIII, ormai quasi solo programmatori, che poterono finalmente distribuire i loro programmi in forma di eseguibile stand-alone, da cui era impossibile per l’utilizzatore risalire al sorgente (e quindi effettuare modifiche o aggiunte), e cominciò inoltre ad attrarre programmatori che abbandonavano i linguaggi tradizionali per passare al nuovo linguaggio. Clipper versione S87 era fatto straordinariamente bene. Consentiva di scrivere programmi in multiutenza, era solido come una roccia, quasi privo di bachi, efficiente e relativamente facile da imparare (soprattutto per chi proveniva dal DBIII). La sua parentela con il C non lo rendeva troppo esotico anche per chi proveniva da questo linguaggio, e come abbiamo visto questi programmatori disponevano di tutti gli strumenti per collegare Clipper proprio al C, per cui lo considerarono come una manna dal cielo.

La Nantucket fu acquistata all’apice del successo dalla Computer Associates, che era un colosso del software, quando aveva nel cassetto due prodotti più o meno pronti per il lancio, ossia la versione 5 di Clipper e Visual Object, che avrebbe dovuto costituire l’evoluzione di Clipper nel nuovo mondo informatico che si stava delineando e in cui mouse, finestre ed interfacce grafiche stavano prendendo il posto delle tristi schermate nere del DOS.

CA rilasciò in seguito la versione 5 di Clipper, che era in effetti una ulteriore rivoluzione: il linguaggio era stato reimplementato come un sottoinsieme di qualcosa di assai più vasto che prevedeva adesso anche una gestione ad oggetti, che nel frattempo si stava affermando come nuovo paradigma di programmazione. Il “qualcosa” era molto più chiaramente somigliante al C puro, sebbene conservasse la sua distinta identità. Apparve chiaramente la vera struttura interna del nuovo Clipper, ossia un insieme di centinaia di funzioni distinte, e di un “traduttore” che trasformava le classiche istruzioni DBIII nelle corrispondenti funzioni simil-C. La programmazione ad oggetti e la presenza di centinaia di nuove istruzioni facevano apparire come un piccolo sottoinsieme semplificato il tradizionale linguaggio DBIII, ed in questa fase molti programmatori rimasero costernati e perplessi. Devo ammettere che mi convertii alla nuova versione  di Clipper solo quando raggiunse la versione 5.2, e storcendo il naso.  Mi pare che fosse il 1991.

Nel frattempo Ashton-Tate aveva lanciato il DBIV, che ebbe poca fortuna, ed in seguito tentò di riciclarsi in ambiente Windows con il dBase 5, ma anche questo non ebbe grande successo ed alla fine fallì. Adesso dopo diversi passaggi Visual dBase sopravvive, sviluppato e commercializzato da una piccola società indipendente.

Il prodotto migliore dopo Clipper era probailmente Foxpro, che per certi versi era anzi anche meglio, e la versione per Windows, Visual Foxpro, era probabilmente la miglior implementazione del linguaggio dBase in tale ambiente. E’ in questo periodo quindi che si comincia a parlare genericamente di linguaggi xBase, dato che erano presenti diversi prodotti, tutti basati sul vecchio DBIII ma dotati di varianti e caratteristiche proprie. Il vero problema era comunque come riuscire ad adattare il linguaggio dBase al nuovo ambiente Windows-centrico.

Il linguaggio di Clipper e degli altri prodotti concepiti per l’ambiente DOS si rifà ad uno stile di programmazione che è molto diverso dal funzionamento di Windows (o di altre GUI). La necessità di gestire bottoni, finestre, magari anche più finestre contemporaneamente aperte nello stesso programma, e la necessità di dialogare con Windows portano ad un modello di programmazione chiamato event-driven, cioè pilotato dagli eventi, contrapposto alla programmazione tradizionale, detta procedurale, in cui ogni programma fa in genere una sola cosa per volta secondo una successione prefissata. dBase V e Foxbase avevano risolto a modo loro, tracciando la via e creando le loro versioni del nuovo xBase, dotate di estensioni per la programmazione ad oggetti e di tutta la parte grafica. CA aveva rilasciato Visual Object, il successore di Clipper, innovativo e promettente, sebbene alquanto astruso e pieno di bachi che lo rendevano quasi inutilizzabile.

Intervenne a questo punto Microsoft, che acquistò Visual Foxpro. La mossa apparve come il riconoscimento che Visual Foxpro era il miglior strumento xBase disponibile, e che Microsoft si era decisa ad entrare nell’arena dei linguaggi xBase dalla porta principale. Molti programmatori acquistarono Foxpro (me compreso) serenamente pensando che il linguaggio non sarebbe morto e nuovi rosei sviluppi sarebbero arrivati. Niente di tutto ciò. Ben presto la vera strategia di Microsoft si chiarì: aveva acquistato Foxpro solo per toglierlo di mezzo e indirizzare i programmatori verso le sue alternative proprietarie. Foxpro fu lasciato morire lentamente e attualmente non è più nel catalogo Microsoft. L’ultima release è del 2007.

Ma qualche temerario aveva cominciato a lavorare in modo indipendente su Clipper:  aveva visto la luce infatti Clip4win, estensione che permetteva di collegare Clipper all’ambiente Windows (non ricordo l’autore). All’incirca in quello stesso periodo un certo Antonio Linares, un forte programmatore C con buonissime conoscenze dei meccanismi interni di Windows e che si era innamorato di Clipper, scrisse a sua volta una estensione che chiamò Fivewin. La bellezza e la profondità di Fivewin stanno nella semplicità del linguaggio creato da Linares (e dal suo pard Francisco Pulpòn) per gestire l’ambiente Windows, nella perfetta integrazione delle sue estensioni nel linguaggio esistente e nella fondamentale qualità del suo lavoro. Anche se Fivewin aveva qualche baco, la qualità generale era molto buona ed il costo accettabile: il prodotto ebbe subito successo tra i programmatori.

Ma CA aveva nel frattempo quasi abbandonato Clipper, che rimaneva un compilatore a 16 bit in un mondo dove ci si avviava a grandi passi verso i 32 e poi i 64 bit, e cominciava a soffrire di limitazioni strutturali insormontabili. Fu così che Linares cominciò a sviluppare un compilatore indipendente compatibile con Clipper (e Fivewin naturalmente) in grado di affrontare le sfide del futuro. La sua visione fu grandiosa e lo sforzo personale probabilmente immenso. La grossa novità fu che Harbour (il nuovo compilatore) nasceva come progetto Open Source, cioè di libero utilizzo da parte di chiunque. L’ultima versione che CA rilasciò di Clipper è la 5.3b nel 1997. Le alternative per la comunità di programmatori xBase erano costituite da pochi prodotti proprietari piuttosto costosi, come Alaska xBase++, Flagship, Visual Foxpro e dBase V. Nessuno di questi prodotti sembrava però in grado di raccogliere l’eredità di Clipper. Inoltre il solo Flagship era multipiattaforma, ovvero disponibile sia per il sistema Windows, sia per Linux.

L’idea del compilatore Open Source coagulò un certo numero di programmatori e il sistema cominciò pian piano a prendere piede. Presto fu disponibile la versione per Linux, il che consente ad un programmatore di scrivere un programma e di poterlo compilare ed eseguire senza particolari modifiche nei due ambienti. Ad un certo punto la creatura si rivoltò al suo padrone, se così possiamo dire. Proprio perché era un progetto “libero” un gruppo di programmatori in disaccordo con Linares sulle linee da seguire nello sviluppo del compilatore si separò dal progetto originario dando vita a xHarbour, che sta per extended Harbour (2001). Di xHarbour esistono due versioni, una free ed una a pagamento, mentre di Harbour esiste solo la versione free. I due progetti, Harbour e xHarbour, hanno molto in comune dato che derivano dallo stesso tronco, ma le differenze ci sono e non sono poche.

La situazione attuale vede Harbour come un progetto più vasto e disponibile per molte diverse piattaforme, come Windows, Linux, Mac OS X, MINIX 3, Windows CE, Pocket PC, Symbian, iPhone, QNX, VxWorks, OS/2/eComStation, BeOS/Haiku, AIX (xHarbour supporta in pratica solo Windows e Linux). Mediante il contributo di molti programmatori indipendenti il linguaggio dispone oggi di numerose alternative anche a livello di GUI oltre al citato Fivewin (che rimane comunque nella sua posizione di preminenza) e può collegarsi a SQL server come Oracle, PostgreSQL, MySQL ecc. e sfruttare tutta la potenza degli attuali PC a 32 o 64 bit. Personalmente utilizzo entrambi i compilatori in ambiente Windows e il solo Harbour in ambiente Linux. Lo sviluppo è costante e la comunità di programmatori è in perenne contatto in tutto il mondo mediante forum tecnici di discussione e mailing list.