Visual FoxPro: il passato e il futuro del linguaggio di programmazione di Microsoft

Visual FoxPro è ancora valido nel 2023? Ha senso sviluppare software con Visual FoxPro nel 2023? Queste, e molte altre, sono alcune delle domande più frequenti tra i diversi colleghi programmatori e/o imprenditori che sono ancora legati a questo ottimo ma datato ambiente di sviluppo.

In questo articolo non pretendo di dare una risposta definitiva a questa domanda che è troppo soggettiva, ma analizzerò i pregi, i difetti ed i limiti che questo sistema oggi possiede. Prima, però, mi soffermerò brevemente su qualche cenno storico per chi non sa di cosa parliamo.

Introduzione: che cos’è Visual FoxPro

Visual FoxPro, detto anche FoxPro ed abbreviato come VFP, è un linguaggio di programmazione data-centrico che supporta la programmazione procedurale e quella orientata agli oggetti. FoxPro è stato sviluppato nel 1984 dalla Fox Technologies ed acquisito da Microsoft nel 1992.

Dopo l’acquisizione, il linguaggio ha cambiato ufficialmente nome in Visual FoxPro: la versione 3.0 sviluppata da Microsoft supportava soltanto i sistemi operativi Windows e Mac (con interfaccia visuale), abbandonando definitivamente il supporto a DOS e Unix (interfaccia testuale). Dalla versione 5, invece, il supporto divenne esclusivo per sistemi operativi Windows.

Microsoft ha portato avanti il progetto fino al 2004 con la pubblicazione della versione 9 dell’ambiente di sviluppo. Qualche anno più tardi, nel 2007 per esser precisi, l’azienda di Redmond ha deciso di abbandonare lo sviluppo di FoxPro, garantendone il supporto tecnico standard fino al 2010 e quello esteso fino al 2015.

FoxPro, come detto sopra, è un linguaggio data-centrico: questo vuol dire che è stato sviluppato specificatamente per lavorare con i dati e per manipolare i database. Nativamente l’ambiente di sviluppo include un suo database relazionale che, grazie all’algoritmo Rushmore, migliora di molto le prestazioni su archivi pesanti.

Differenze con Visual Basic 6

Visual FoxPro e Visual Basic 6 sono due linguaggi di programmazione ed ambienti di sviluppo molto diversi tra loro, sia per funzionalità che per caratteristiche. Possiamo riassumere le principali differenze in:

• Visual FoxPro è un linguaggio orientato ai dati, Visual Basic agli oggetti.
• Linguaggio di provenienza: Visual FoxPro è un linguaggio di scripting basato su xBase, Visual Basic si basa sul BASIC.
• Gestione database: Essendo VFP creato originariamente come sistema di gestione dei dati, include tantissime funzionalità avanzate per la loro gestione quali l’indicizzazione, la generazione di query, di report, etc… Visual Basic supporta alcuni database esterni ma non possiede caratteristiche ed ottimizzazioni per la loro gestione.
• VFP, grazie all’algoritmo Rushmore, ha prestazioni elevate quando devono gestire grandi quantità di dati. Visual Basic, invece, è appena sufficiente a parità di quantitativo di dati.

Oltre queste quattro differenze, all’atto pratico l’ambiente di sviluppo non differisce di molto: entrambi hanno un disegnatore visuale con finestre, trascinamento oggetti e definizione di eventi, classi e metodi. Se proprio vogliamo trovare una differenza sull’IDE, possiamo certamente dire che realizzare un eseguibile da un progetto è molto più semplice e veloce con Visual Basic rispetto a Visual FoxPro. Questo solo per l’immediatezza dell’operazione: mentre in VB basta compilare il progetto, in VFP è necessario creare un file sorgente di partenza e gestire gli eventi (lettura e cancellazione).

Entrambi i sistemi supportano la programmazione ad oggetti, l’utilizzo di componenti Active-X e dll.

I maggiori impieghi di FoxPro

FoxPro è stato utilizzato maggiormente per lo sviluppo di applicativi desktop per la realizzazione di software gestionali e di contabilità ma anche per la produzione, la distribuzione e il settore sanitario. Il suo punto forza è stata la portabilità: sorgenti di applicazioni scritte in xBase e/o Clipper, potevano essere eseguiti con pochissimi interventi in FoxPro, risparmiando tempo e denaro nello sviluppo e l’aggiornamento di software. Ancora oggi sono tantissime le applicazioni commerciali, anche di un certo rilievo, sviluppate in Visual FoxPro.

Qual è l’erede di FoxPro?

Il diretto erede di FoxPro, secondo Microsoft, è sempre stato Lightswitch ma anche lui è stato abbandonato qualche anno dopo la sua distribuzione (2010-2015). Molti sviluppatori FoxPro sono rimasti fedele alla suite Visual Studio, migrando le loro applicazioni a VB.NET e/o a C#. Altri hanno cercato rifugio in sistemi R.A.D. come Real Basic (oggi conosciuto come Xojo).

Il passaggio da Visual FoxPro a C# è meno doloroso di ciò che si pensi. Per chi è agli inizi, può utilizzare questo piccolo manuale che, in poche pagine, illustra le differenze tra le operazioni effettuate nei due linguaggi, con esempi e spiegazioni.

Il manuale di cui vi parlo è: FoxPro to C#: A developer’s handbook.

L’ho acquistato qualche anno fa e mi è stato molto utile per poter applicare procedure e metodologie di VFP in C#.

Chi cerca un sistema di sviluppo unico con database incorporato e cross-platform può valutare, invece, WinDev della PCSoft: sebbene sia diverso da VFP, possiede diverse similitudini quali: database integrato, gestore report, query, ottimizzazione per software gestionali, etc…

Com’è classificato oggi VFP?

Nel 2005, secondo il TIOBE Programming Community Index, VFP è entrato nella classifica dei primi 20 linguaggi di programmazione più utilizzati. A Giugno 2006 è salito alla posizione 12. Oggi, nel 2023, è situato alla posizione 21. Un risultato niente male per un sistema di sviluppo oramai fermo ufficialmente da circa 16 anni.

Sebbene molti hanno migrato i loro software su altri linguaggi e/o sistemi, tantissimi altri restano ancora legati a FoxPro a causa del suo impiego nello sviluppo di software attualmente in commercio: realizzare un software, specialmente se di grandi dimensioni, necessita di mesi, se non anni, di sviluppo e di investimenti economici.

VFP ancora utilizzato, ma si può fare tutto?

Assunto che in un sistema di programmazione è possibile fare quasi tutto, in un modo o nell’altro, in Fox abbiamo alcune limitazioni. Quella più grave, in questi ultimi anni, è la mancanza del supporto per schermi touch: l’impossibilità di poter effettuare lo scroll di una griglia è una lacuna che difficilmente si potrà risolvere se non con stratagemmi che fanno storcere il naso agli standard dell’usabilità. Più che vedere i pro e contro di utilizzare Visual FoxPro oggi, vediamo semplicemente i contro ed alcune tecniche per superarli.

Interfaccia grafica e funzionalità varie possono essere sempre ricostruite via codice o mediante l’utilizzo di componenti esterni active-x e/o librerie dll.

Un grosso aiuto arriva dalla fantastica libreria Chilkat che offre innumerevoli oggetti per la comunicazione con webservice, la manipolazione dei file (Json, xml, etc..), hashing e il crypt, e tantissimo altro. L’aspetto grafico, invece, può essere affidato alla libreria di CodeJock che include i più moderni layout grafici per form, toolbar ribbon, etc…

Un altro aspetto importante è la grande community che non si è mai fermata in questi anni: sto parlando, ovviamente, di VFPX e di tutti i progetti, librerie e componenti gratuiti che è possibile scaricare ed utilizzare nei propri progetti.

I maggiori limiti di Visual FoxPro

Assodato che possiamo replicare le funzionalità oramai native dei nuovi ambienti di sviluppo con componenti terzi (acquistati o sviluppati in proprio come dll), restano alcuni problemi oggettivi di cui si deve esser coscienti:

• Se si utilizza il database nativo con tabelle DBF, vi è un limite per tabella per dimensione di file: il formato DBF adoperato è limitato a 2GB di peso per file. Il limite è imposto proprio sul formato in quanto, nati negli anni ’80, si pensava che quello fosse un quantitativo massimo perfetto per una tabella. Ovviamente, oggi, sappiamo benissimo che non è così!
• Performance elaborative: sebbene sui dati locali sia velocissimo, su alcune elaborazioni VFP è molto lento e la situazione non cambia su sistemi a 64bit visto che sia l’ambiente di sviluppo che gli eseguibili compilati sono solo a 32bit.
• Non esiste alcuna tipologia di multi-tasking e/o esecuzione di processi in thread.
• Non vi è alcun supporto per dispositivi mobile.
• Il supporto per applicativi web è oramai obsoleto, lacunoso e soggetto a rischi di sicurezza.
• Se si utilizza un database alternativo come mySQL è bene sapere che il supporto di connessione tramite ODBC può essere effettuato solo con driver a 32bit.

Come ultimo vi è la problematica che, essendo un linguaggio obsoleto, è difficile trovare programmatori che sappiano programmare in FoxPro. Difficile trovare programmatori senior ed impossibile per i programmatori junior che non sanno nemmeno della sua esistenza!

Qualche tempo fa, scrissi un articolo su come utilizzare la libreria Active Visual FoxPro per la realizzazione di applicazioni e siti web con IIS. Se vi interessa, potete leggere l’articolo: Come utilizzare il proprio codice Visual FoxPro sul web con ActiveVFP.

Considerazioni personali finali

È arrivato il momento, come si suol dire, di “tirare le somme”. Personalmente ho utilizzato tanto e continuo ad utilizzare Visual FoxPro come ambiente di sviluppo ma, da qualche anno, non è più la mia preferenza principale. Uno degli utilizzi che preferisco e che ancora utilizzo molto è la realizzazione di piccoli script per gli automatismi e le pianificazioni.

Da diverso tempo preferisco basare la scelta dell’ambiente di sviluppo ed il linguaggio sulla base di ciò che devo sviluppare. FoxPro ha avuto un ruolo importante nella storia dell’informatica ma i suoi limiti, oggi, rendono difficile la realizzazione di applicazioni che soddisfino a pieno le esigenze e/o richieste dei clienti. Troppo spesso si deve scendere a compromessi per alcune problematiche.

Oggi, Windows ci consente ancora di eseguire applicativi a 32bit, quindi possiamo ancora sfruttare quest’ottimo, sebbene obsoleto, linguaggio di programmazione. è bene considerare, però, che in futuro potrebbe non esserlo. Se si inizia un progetto nuovo o la realizzazione di un applicativo, conviene farla direttamente in un sistema moderno per assicurarsi almeno la compilazione a 64bit. Meglio ancora se possibile la compilazione cross-platform!