Tra il codice e la realtà

Una poco velata critica al C++ da parte di Linus Torvalds, mi ha portato a fare qualche considerazione sul C++ e più in generale sulle motivazioni delle scelte (apparentemente solo di natura tecnica) dei programmatori.

Devo premettere che sono di parte, visto che da molti anni utilizzo (con soddisfazione) principalmente il C++. D’altro canto ho comunque avuto a che fare nel corso degli anni con altri linguaggi, ambienti e procedure di sviluppo, in progetti molto diversi per numero di partecipanti, complessità e obbiettivi. Spero quindi di poter fare delle considerazioni non partigiane…. 🙂

Fondamentalmente io non concordo con Torvalds, ma paradossalmente concordo per certi versi con lui quando dice

I've come to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.

Semplicemente io non vorrei assolutamente nessun programmatore nel mio team che preferisse un qualsiasi linguaggio (ma anche tool o sistema operativo), in modo INCONDIZIONATO, non relazionato agli obbiettivi del progetto.

Questo non vuol dire affatto che la scelta non debba dipendere ANCHE dalle proprie inclinazioni personali o quanto meno dal proprio patrimonio di conoscenze (stando attenti a non infilarsi nelle profezie auto-avveranti di Carlo Pescio). Vuol dire semplicemente e molto banalmente che la scelta di un linguaggio, un tool o una metodologia da utilizzare deve dipendere dagli obbiettivi di progetto e non da valori pure apparentemente validi in generale.

Più in generale si tratta di una forma di dis-allineamento tra i VALORI del progetto (spesso ad esempio i tempi di rilascio) e quelli ritenuti tali dagli sviluppatori (efficienza, scalabilità, ma anche documentazione, copertura dei test di unità etc). E’ vero che spesso non è affatto facile capire quali siano i valori del progetto (anche per responsabilità del menagement) e che non è certo compito degli sviluppatori definirli, ma è sicuramente loro compito comprenderli e lavorare onestamente al fine di massimizzarli.

L’errore più comune è quello di scambiare strumenti con obbiettivi: un programma deve fare senza errori quello che gli utenti si aspettano, non avere la barra verde dei test unità sulla macchina degli sviluppatori. O aprossimarli con valori considerati sempre validi: ad esempio le prestazioni (cosa spesso non utile o magari da ricercare su piani molto diversi dell’ottimizzazione delle strutture base) o la flessibilità che viene intesa in termini estremamente tecnici (come magari la molto remota possibilità di utilizzare db server differenti), mentre ciò che sarebbe veramente utile è la flossibilità di reagire a cambiamenti delle spicifiche.

La cosa più interessante è che, paradossalmente, questi “errori di prospettiva” sono possibili SOLO a programmatori che abbiano un discreto grado di conoscenze e anche una certa dose di passione e che quindi potrebbero anche essere considerati dei buoni programmatori. Sicuramente però sarebbero dei pessimi team leader, quelli che Carlo Pescio chiama super-programmatori e che sono ottimi per portare a compimento il progetto che esiste nella loro mente (non quello che gli viene affidato).

In questo senso è più probabile che un super-programmatore usi il C++ piuttosto che il C ? Probabilmente sì, visto che è assolutamnete coerente con la sua psicologia utilizzare lo strumento più avanzato, innovativo e “potente” (qualsiasi cosa voglia dire). Ma a dire il vero (e per le stesse motivazioni) è più probabile che usi Java (o magari Ruby o Python) e che sia un patito di linux, dell’open source e soprattutto dell’extreme programming.

Nel merito delle caratteristiche tecniche del C++ rispetto al C o ad altri linguaggi invece è meglio che parli in un altro post… questo è già troppo lungo così 🙂