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ì 🙂

Se l’XML non vi è mai piaciuto e JSON non vi sembra una soluzione adeguata, Protobuf potrebbe essere la soluzione che aspettavate.

L’idea interessante è quella di generare delle classi (ad esempio in C++) che forniscono un accesso estremamente comodo attraverso setters e getters (anche se io avrei fatto una scelta diversa) e integrazione con le funzionalità del linguaggio (come gli stream di IO) e contemporaneamente estremamente efficiente in termini di parsing (realizzato infatti ad hoc per il singolo schema)  e memorizzazione (direttamente in strutture del linguaggio).

Da molti punti di vista un approccio di questo tipo è la soluzione ottimale nel caso in cui si abbia a che fare con dati con una struttura omogenea e nota a priori, la cui manipolazione ha un peso significativo per l’efficienza del sistema nel complesso.

Non sono un fan dell’XML, ma non posso non notare che una soluzione del genere è implementabile anche con XML (e viene nei fatti usata da tempo ad esempio da gSOAP), ma non con JSON che manca di uno standard di definizione degli schemi. Rispetto a XML però non so dire quali siano i vantaggi: semplicità nella generazione delle classi nel linguaggio scelto ? Efficienza nella rappresentazione dei dati (utile ad esempio per ridurre la banda in caso di trasmissione) ? Efficienza comunque nel parsing (anche se ad hoc per schema) ? Non saprei, presto per dirlo, ma se dovesse servirmi qualcosa del genere, darò sicuramente un’occhiata più approfondita a questa libreria.

Servizio lanciato da DZone, Refcardz è in pratica una raccolta di pratici riferimenti su temi specifici (da Spring a GWT, dal formato Atom alla costruzione dei plug-in di eclipse).

Mi ha fatto pensare ad una sorta di bignami dell’era digitale…. ti chiedi se possa servire davvero a qualcosa. Mah forse per certi argomenti estremamente specifici, tipo “Shortcuts in NetBeans 6.1”, potrebbe avere un senso…. per il resto non mi pare.

Spesso le tabelle sono molto utili per rappresentare in modo visuale delle informazioni complesse, ma rappresentabili in qualche modo su un piano (bidimensionali) e discritizzate. Ovviamente la discretizzazione dev’essere sufficiente a focalizzare il significato delle grandezze, ma tale da non comprometterne il significato. E quasi sempre la vera difficoltà è scegliere il piano di rappresentazione e l’entità della discretizzazione.

Le competenze di un programmatore sono una di quelle cose che (per eccesso di complessità) si rischia di considerare non formalizzabili in una qualche forma rigorosa… ed in buona misura sono convinto che così sia. Non per questo non è apprezzabile lo sforzo di qualcuno che prova a determinare un piano e una discretizzazione per il problema in esame. Con l’obiezione che ha troppi valori (sia in x che in y), alcune idee mi sembrano interessanti.