Linguaggi complicati e linguaggi semplici

 BLOG di Paolo Borzini

Linguaggi complicati e linguaggi semplici

Ogni tanto torna fuori la solita discussione.
C# e Swift sarebbero linguaggi “seri”, mentre BASIC e LiveCode sarebbero linguaggi “semplici”, quasi figli di programmatori minori ;-)
Secondo me, il punto non è questo.
La vera differenza non è tra linguaggi nobili e linguaggi della plebe. È tra due filosofie opposte di programmazione.
Da un lato ci sono linguaggi come C# e Swift che sono pensati per progetti grandi, team numerosi, codice che deve durare nel tempo e passare attraverso molte mani. La loro rigidità ha uno scopo ben preciso ed è quello di spostare il più possibile sul compilatore il compito di fermare gli errori prima che il programma venga eseguito.
Dall’altro lato ci sono linguaggi come BASIC e LiveCode, che seguono una tradizione diversa. Privilegiano accessibilità, rapidità e libertà espressiva oltre che alla leggibilità del codice.
Questo però non significa assenza di controlli. Esistono BASIC compilati, quindi perfettamente in grado di segnalare errori in compilazione. Anche LiveCode non è affatto cieco se sbagli certi nomi o commetti errori, ti avvisa.
Il punto quindi non è “linguaggi che controllano” contro “linguaggi che non controllano”.
Il punto è un altro, spesso si pensa che la difficoltà di Swift o C# stia nella sintassi ovvero parentesi, tipi, regole.
A mio avviso non è lì il problema principale, la difficoltà vera è spesso nella complessità nominale.
Per fare cose normali, in certi ambienti moderni devi maneggiare nomi lunghi, tecnici, gerarchici. UIViewController, UITableViewDelegate, CLLocationManagerDelegate e via così.
In LiveCode, e in buona parte dei BASIC classici, molte operazioni si esprimono invece con parole brevi e dirette. put, get, answer, open, close.
A parità di logica, è più facile sbagliare a scrivere un nome da venti caratteri che in uno da quattro.
L’autocompletamento aiuta, certo ma non cambia il fatto che un vocabolario enorme aumenta la possibilità di sbagliare.
Qui sta il punto interessante, nei linguaggi come C# e Swift, gli errori di battitura vengono intercettati subito. Ma è anche più facile commetterli, perché il lessico è molto più vasto e pesante.
Nei BASIC compilati, o in LiveCode, molti errori vengono comunque segnalati. Ma il vocabolario più contenuto riduce già in partenza una parte dell’attrito.
Quindi la differenza non è tra sicurezza assoluta e caos totale.
La differenza è tra un linguaggio che ti impone un forte carico nominale e poi ti protegge da quel carico, e un linguaggio che cerca di ridurlo a monte.
Martin Richards lo aveva scritto chiaramente nel suo libro, che custodisco gelosamente, 
"BCPL, the language and its compiler".

“The philosophy of BCPL is not one of the tyrant who thinks he knows best and lays down the law on what is and what is not allowed; rather, BCPL acts more as a servant offering his services to the best of his ability without complaint, even when confronted with apparent nonsense. The programmer is always assumed to know what he is doing and is not hemmed in by petty restrictions.”

Che tradotto in italiano diventa così più o meno:

"La filosofia di BCPL non è quella di un tiranno che pensa di sapere tutto e detta legge su ciò che è permesso e ciò che non lo è; al contrario, BCPL agisce più come un servitore che offre i suoi servizi al meglio delle sue capacità senza lamentarsi, anche di fronte a evidenti assurdità. Si presume sempre che il programmatore sappia cosa sta facendo e non viene limitato da meschine restrizioni."

Questo è il cuore del problema, da una parte c’è il linguaggio-tiranno, che impone regole perché non si fida fino in fondo del programmatore.
Dall’altra c’è il linguaggio-servitore, che parte dal presupposto opposto, il programmatore sa quello che sta facendo.
Non esiste il migliore in assoluto
Sarebbe sciocco dire che una delle due filosofie è sempre superiore.
Su progetti enormi, con molti sviluppatori e manutenzione lunga, i linguaggi più rigidi hanno un senso di esistere fortissimo.
Su progetti piccoli, personali o da artigiano informatico, quella stessa rigidità può diventare solo una complicazione inutile. E lì i linguaggi più leggeri e diretti mostrano tutta la loro forza.
La scelta tra C# e Swift da una parte, e BASIC o LiveCode dall’altra, non è solo tecnica ma è una scelta filosofica.
Da una parte c’è il compilatore-tiranno, che protegge ma impone.
Dall’altra c’è il linguaggio-servitore, che semplifica ma ti lascia più responsabilità.
Non si tratta di decidere chi ha ragione una volta per tutte e quando scegliamo un linguaggio, non scegliamo soltanto una sintassi.
Scegliamo che rapporto vogliamo avere con la macchina.

Paolo Borzini