Introduzione

There is no silver bullet

Così scriveva Fred P. Brooks, autorevole esperto di informatica, nel suo best seller The Mythical Man-Month. Questo libro del 1975 è ancora considerato una pietra miliare del project management e dell'ingegneria del software, frutto dell'esperienza dell'autore nello sviluppo del sistema operativo OS/360. Tradotto:

Non c'è una soluzione per tutto.

Vale per molti aspetti dello sviluppo software, inclusi i linguaggi di programmazione. Quindi perché discuterne, se già in partenza non c'è un linguaggio migliore in assoluto?

Perché ci sono alcune caratteristiche dei linguaggi che ritengo conveniente approfondire, con l'obiettivo di dare indicazioni utili, senza alcuna pretesa di trattare l'argomento in modo esaustivo.

Versatilità

Il mondo informatico è andato ampliandosi nel tempo fino a coprire uno spettro di applicazioni estremamente vasto, difficile da elencare con completezza:

• Applicazioni batch
• Applicazioni desktop (su Windows, Linux, MacOS)
• Applicazioni per dispositivi mobili (su Android, iOS)
• Applicazioni web (lato back-end, lato front-end)
• Altri tipi di applicazione client-server
• Applicazioni embedded

Quanti più di questi ambiti riesce a coprire, tanto più un linguaggio è versatile.

Paradigmi di programmazione

In ogni applicazione vi sono diversi fronti su cui muoversi: modello dei dati, algoritmi, I/O, interfaccia utente, interfacce con altri sistemi o dispositivi, etc.

Non ritengo possibile che con uno solo dei paradigmi di programmazione (di cui cito di seguito solo alcuni) si possa efficacemente coprire l'intero dominio:

• Object Oriented
• Functional
• Concurrent
• Event-driven

Un linguaggio che dia supporto alla programmazione in vari di essi può rappresentare un vantaggio.

Prevenzione degli errori

Uno dei modi di formulare la Legge di Murphy è il seguente:

Se qualcosa può andare storto, lo farà

Ecco alcuni atteggiamenti, i primi che mi vengono in mente, tra quelli che rendono più probabile l'avverarsi di questa profezia:

• Ora abbozzo il codice in modo che funzioni, alle rifiniture e ai casi limite penso dopo;
• Il verificarsi di questa condizione di errore è altamente improbabile;
• Non importa se non documento quello che faccio, ho un'ottima memoria;
• Non serve utilizzare un linguaggio che aiuta a prevenire gli errori; starò molto attento a non farne.

I primi tre punti sono più riferiti all'atteggiamento dello sviluppatore, e non mi dilungo. Cito solo, per il terzo, una battuta di fonte anonima: Quando ho scritto questo codice, solo io e Dio sapevamo cosa significa. Ora, dopo qualche anno, lo sa solo Dio.

Il quarto punto, invece, è attinente al linguaggio di programmazione, e specificamente a quanto la sua struttura sintattica sia d'aiuto nel prevenire determinate classi di errori; è questo che desidero maggiormente approfondire nel seguito.