Chiunque operi per lavoro o hobby nel campo dell’informatica, probabilmente condivide lo stesso rapporto di odio e amore verso i file in plain text : hanno innegabili vantaggi come la portabilità, la facile interoperabilità e la semplicità di creazione.
D’altra parte, risultano spesso difficilmente leggibili e poco versatile, non disponendo di opzioni di formattazione, nè quelle basilari come grassetti e sottolineature, nè più sofisticati come ad esempio il supporto di hyperlink.
Questi ultimi rimangono esclusività di editor di testi e di markup più sofisticati.
Negli anni sono stati fatti vari tentativi prendere il meglio di entrambi i mondi e unire la semplicità di file di testo alla versatilità del testo formattato: uno dei più popolari è Markdown, inventato da John Gruber e documentato principalmente in questa pagina.
Dalla sua nascita, Markdown è stato utilizzato in maniera molto ampia: come semplice metodo per pubblicare commenti, per scrivere file ReadMe e per documentare il codice con commenti inline .
Tuttavia questo strumento è oggetto di molte critiche, prima di tutto per alcune sue carenze.
Una parte della sintassi risulta ambigua nella pagina di definizione e l’implementazione originale di un interprete Markdown/HTML scritta in Perl — sempre da John Gruber — è risultato contenere numerosi bug.
Un secondo problema di questo progetto è il modo autoritario e decisamente poco aperto con cui Gruber pretende di gestirlo, con il risultato di avere poco o nessun coinvolgimento della comunità e relativa mancanza di progressi nel migliorare lo standard o il codice della sua implementazione.
Jeff Atwood ha chiaramente spiegato la situazione di Markdown in un suo interessante post nel 2009 che consiglio a tutti di leggere.
Lo stesso Atwwok nel 2012 è stato contattato da David Greenspan per standardizzare Markdown, per risolvere i suoi problemi di gioventù e per creare un progetto più collaborativo.
Per queste ragioni, i due hanno creato un gruppo di lavoro insieme a rappresentatnti di GitHub, Reddit, Stack Exchange, e dalla comunità open source : la storia di questa iniziativa è raccontata in un altro post su Coding Horror.
Il risultato di questo sforzo avrebbe dovuto essere una specifica, completa di esempi e implementazioni in C e JavaScript chiamata Standard Markdown con tanto di sito internet.
Visitando il sito internet, appunto, si viene reindirizzati all’ennesimo post di Atwook in cui l’autore (in maniera apparentemente cortese, ma in effetti strafottente) spiega come John Gruber, dopo aver inizialmente ignorato il loro progetto, si sia lamentato fortemente della scelta del nome e della decisione di registrare un dominio. Dopo uno scambio di email, Gruber ha reso chiaro che non avrebbe accettato nessun uso di “Markdown” per il nome del loro progetto: alla fine Atwood e il suo gruppo hanno optato per CommonMark una abbreviazione appunto della loro ultima proposta a Gruber, “Common Markdown”.
Tutto questo lungo racconto per dire che, finalmente, CommonMark è il tentativo più riuscito di standardizzazione di Markdown, che questo progetto ha un sito internet dove si può leggere le specifiche, discutere e scaricare il codice relativo.
Questa lunga e strana storia dimostra prima di tutto come NON dovrebbe essere gestito un progetto software, soprattutto negli anni in cui open-source e collaborazione sono diventati concetti cardini dell’informatica.
Dimostra anche come una buona idea, anche se ignorata o maltrattata, torni inesorabilmente a galla e, magari dopo anni, trovi sempre qualcuno abbastanza motivato e testardo da renderle giustizia.
Come ultima nota personale, aggiungo che mi piacerebbe iniziare a lavorare su una implementazione in .NET di CommonMark e di includerla in un progetto che ho iniziato qualche anno fa, senza dedicargli abbastanza tempo, cogliendo quindi l’occasione per rivitalizzarlo.
Lascia un commento