Monday, October 03, 2005 

Blogging as Destructuring

I've been an author for several years now, with more than 100 papers published in trade and academic journals. I've also published a "traditional" book (my "C++ Manuale di Stile", in Italian) and I'm slowly working on my free book "UML 2 Manuale di Stile" (again, in Italian). For a few years I also published a newsletter on C++ ("C++ Informer"). In the last few months, I've also been "publishing" here in the blog. There is a tremendous difference between the two experiences, and blogging is the ultimate destructuring of writing. There is no expectation (on the author's and readers' side) of thoroughness, completeness, even relevance. This allows a much faster flow of ideas. If a blog is irrelevant, people will stop visit. That's it, clean and simple.
Looking back, I see that over the years I've accumulated tons of ideas, drafts, diagrams, etc that never took shape as an article (or book). We have natural expectations about printed articles, that requires a huge overstructuring of the presented material and therefore a huge amount of collateral work. For instance, I've dozen of examples of bad user interaction in the real world, similar to what I discussed in Natural Form Filler. However, the effort required to bring this (possibly interesting) material to a publication-grade level is just too big, and possibly unjustified.
Things get worse if you plan to submit your works to top-notch publications. If you never had this experience, I can highly recommend reading The long and winding road: getting papers published in top journals by John Mingers. I hope you'll see the inherent inefficiency of a process born out of good intentions (quality assurance) but oh so obsolete. This inefficiency results in long delays before concepts are disseminated, and also in selective prevention of radically new concepts being disseminated. Of course, people are starting to notice. An interesting article in Communications of ACM, August 2005, proposed a different approach to sharing research results, similar to an open source project ("Sharing Research in the 21st Century: Borrowing a Page from Open Source Software", by Donald E. Hardaway).
I won't hold my breath :-). So, while I'm not giving up about "traditional" publishing, I guess for a (long) while I'll use the blog as my favorite media, and enjoy the freedom of destructuring :-).
Comments:
Il passo successivo o per meglio chiamarlo the next generation blog sarebbe quello di fornire un mezzo comodo per i commentatori di proporre nuovi spunti od idee senza per forza di cose ricorrere ad un commento :-)) ad uno degli argomenti pubblicati senza per questo dover mettere su un proprio blog antagonista, ma contribure ad arricchire quelli pre-esistenti (un periodo così lungo non lo si leggeva dalla pubblicazione de Il male oscuro di Giuseppe Berto :-)
 
Aspettando il blog prossimo venturo...

...mi riaggancio ad un articolo apparso su Punto informatico che cita un e-book di Stephen Arnold. Leggendo qualche notizia qua e là, in tempi non sospetti, mi ero fatto anch'io la stessa idea. Che Google insomma potesse un giorno fagocitare Microsoft :-) Certo, ora che è stato scritto forse Bill starà un po' più in campana (Se già non lo è - vedi mosse tipo MSN Search et similia -). Come già ho scritto da altre parti, nulla è immutabile, neanche l'impero romano è durato all'infinito... Il fatto è che per Microsoft non scorgo ancora il punto di flesso e l'apice è ancora molto lontano, almeno a giudicare dall'andamento trimestrale di cassa in cui puntualmente denuciano fatturato e dividendi sempre in crescita in barba al tentennare globale.

Staremo a vedere e se non ci vedremo... accenderemo la luce!
 
Personalissimi pensieri sparpagliati sullo sviluppo del software - continua

Visto che il blog è fatto per lasciarsi raccontare, ne approfitto per mettere nero su bianco (css permettendo ;-) altri concetti, sperando di non abusare della pazienza ed ospitalità di Carlo (il quale farà bene a redarguirmi se trova innopportuno il mio martellante intervento :-)

Stamane vorrei sfiorare un poco il debugging. Si dice che generalmente si passa il 20% del tempo a scrivere codice ed il restante 80% a metterlo a punto. Qualcuno più pessimista (o realista?) arriva a dire 5% e 95%. Io credo che la variabilità sia massima e dipenda da progetto a progetto come pure dall'esperienza e capacità dei soggetti coinvolti.

Una buona analisi dovrebbe tener lontano un sacco di problemi in fase d'implementazione. D'altra parte l'estro e la creatività del programmatore possono fare la differenza con soluzioni che arrivano prima al sodo rispetto ad altre; che prestano meno il fianco a debolezze; che lasciano spazio o imbrigliano meglio i casi particolari.

E per non restare nel campo dei voli pindarici alias elucubrazioni mentali vorrei citare qualche aneddoto personale.

Premetto subito che nella mia già citata ventennale esperienza di programmatore (non ho cominciato presto: sono vecchio!) sono stati veramente molto pochi i casi in cui tutto ha funzionato al primo colpo. Ovviamente non si parla d'interi programmi, ma solo di funzioni, procedure, porzioni di codice che dovevano fare una certa cosa ed hanno cominciato a farla da subito senza troppi aggiustamenti per approssimazione successiva. Però qualche volta è capitato (e non mi riferisco a casi banali tipo printf("Hello, world!"); :-)).

Ad ogni modo quasi mai mi sono avvalso del debugger. Sapete, mi sono formato alla scuola del vecchio MS-DOS (2.1), quando non era infrequente fare con debug "load cs:100 0 0 80" e spulciarsi a mano il boot sector del floppy (a proposito, il virus 855 l'ho scovato così ancora prima che salisse agli onori della cronaca (si parla del lontano 1992 ;-)).
Anche adesso, quando creo un nuovo progetto con Visual Studio .NET 2003, la prima cosa che faccio è rimuovere la configurazione "DEBUG" per lavorare solamente in release mode. Forse mi sono abituato più a prevenire i problemi che a curarli (modestamente) e quindi, se proprio è necessario, per togliermi dai pasticci il più delle volte ricorro ad una semplice MessageBox(GetActiveWindow(),"sei qui","",MB_OK);

Sarà capitato a tutti di doversi incaponire su una porzione di codice e non riuscire a capire proprio perché non gira... Non sono molti i casi che hanno passato la notte fra quelli che posso annoverare (sempre modestamente). Uno di questi merita menzione.

All'epoca manutenevo un CAD bidimensionale scritto in MS-Pascal. La keyword "WITH" è comoda per non dover ripetere nelle strutture il nome della struttura stessa, diversamente dal C/C++. Esempio:

with struttura do
begin
(...)
x := xxx;
y := yyy;
(...)
end

(perdonate se non ricordo l'esatta sintassi del WITH dato che non lo uso da 12 anni!)

mentre invece in C/C++ si farebbe

struttura.x = xxx;
struttura.y = yyy;

Orbene nelle mie intezioni, x e y dovevano essere due variabili globali poste erroneamente nel corpo dello WITH.

Causa minore esperienza e malizia, ci sono volute più di 24h per venirne a capo e continuare a credere che i fantasmi non esistono.

Non ho altro da aggiungere, per il momento.
 
Pur proveniendo dalla vecchia scuola che assemblava a mano :-), l'idea di rinunciare agli strumenti di debug mi pare diminuisca sensibilmente la nostra efficienza. Ovviamente alcuni problemi si devono prevenire, altri diagnosticare a suon di log, altri pero' si sistemano molto piu' rapidamente con il debugger.
Per quanto attiene il "with", per quanto mi riguarda e' una "falsa comodita'", che rischia di rendere il codice meno leggibile. In generale, riusare un nome ad un diverso livello di nesting apre la porta a futuri problemi di manutenzione. Ci sarebbe da scrivere qualcosa di piu' su questo argomento, che fa sempre parte della progettazione di un linguaggio di programmazione pensato per l'uso nel mondo reale e non per giocattoli. Le mie ultime due domande nell'ormai vetusta Intervista a Niklaus Wirth andavano in questa direzione, ma ci sarebbe molto altro da dire...
 
Post a Comment

<< Home