Mark Down!

Ho sempre pensato che l’informatica fosse la branca della scienze MM.NN.FF. più razionale. Voglio dire se scrivi 2+2 e il risultato è 5, il processo per arrivare a determinare dove sia la discrepanza tra attesa e realtà è abbastanza pedissequo.

Però dove tre o più umani decidono in “commissione” o più semplicemente un Program Manager ardimentoso si lancia all’avventura, si può assistere a risultanti interessanti o addirittura spettacolari.

La storia delle mode dei “formati” è un esempio lampante, chiarissimo, cristallino.

Venti anni fa, svariati scienziati dell’informazione riuniti in un consorzio (W3C), hanno messo a punto sulla carta uno dei più popolari formati “standard”, l’XML. La spinta per l’XML veniva dall’interoperabilità, obiettivo glorioso e nobile. Se dobbiamo far parlare il sistema XYZ di Pinco con il sistema ABC di Pallo, un formato comune è necessario. L’idea di usare un consorzio esistente (il W3C appunto) buona. Partire da un formato pre-esistente passabile: immagino che qualcuno abbia pensato che si potesse usare tanta di quella conoscenza pregressa nel parsing dell’HTML per produrre strumenti pensati per processare l’XML. E poi formati su sformati e protocolli basati su XML come se stesse per arrivare la fine del mondo: SOAP, XSLT, XSD, XPath, XQuery, ecc.

A questo punto qualcosa di bizzarro: Visual Studio .Net ha bisogno di un nuovo formato per i file Solution/Project? XML! Office ha bisogno di un nuovo formato per i file? XML!

Fin qui quasi tutto ok: Visual Studio ha potuto usare una delle tante API(*) disponibili per fare il parsing e XML era già pronta, ottima scelta ingegneristica. Usare XML per Word ed Excel significa maggiore interoperabilità, perfetto.

Dopo qualche anno è arrivato JSON, nato com’è dall’esigenza di un servizio WEB di mandare dati ad uno script Javascript; con l’XML lo script dovrebbe fare il parsing dei risultati, con JSON invece no. Qualcuno ha pensato, ovviamente, di standardizzare anche se c’era ben poco da fare e - ovviamente - una cappella:

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn’t. ( fonte ) (**)

L’aspetto spettacolare specifico di questa istanza è che Visual Studio abbia deciso di usare JSON per i file di soluzione/progetto. SENZA. NESSUN. MOTIVO. TECNICO. (***) Perché? Voglia di seguire una moda? Nell’informatica?

La decisione, in virtù anche della cappella sui commenti, era così palesemente sbagliata, che si son dovuti ricredere e tornare al buon vecchio XML.

Duemilaequalcosa, alla ribalta arriva MarkDown. L’idea è quella di codificare in formato testo un sottoinsieme di formati di formattazione del testo: grassetto, sottolineato, corsivo, ecc. e al tempo stesso preservarne la leggibilità da parte di un umano. Lanciata la moda è partito l’inseguimento, quello dei Missoni dell’informatica che, anche laddove il requisito di leggibilità umana non sia assolutamente necessario, hanno cominciato ad adottare ed abusare tale formato.

Morale della favola oggigiorno si può assistere alla totale irrazionalità di soluzioni che, per servire HTML ad un browser, pur partendo già da HTML, decidano di convertire il tutto in MarkDown.

O forse sto semplicemente diventando vecchio e facilmente irritabile.

-quack

(*) nota storica: partendo ovviamente da quella sbagliata
(**) siccome i commenti possono essere usati per turpiloquio, li aboliamo da qualsiasi linguaggio?
(***) l’obiettivo di JSON è di essere fruibile facilmente da un browser

P.S. ironia della sorte, questo post purtroppo per ora è scritto in MarkDown, ma questa è un’altra storia.