Approfitto della riflessione su blackbirdblog sull’idea che meno è più per infilarci un pippone delirante .

Il post di cui sopra è molto XP in alcuni punti. YAGNI è la prima cosa che salta in testa, ed il secondo paragrafo fa venire istintivamente alla mente il grafico del costo del cambiamento
cost change curve

peccato la parte finale sul design a priori :)

Ad ogni modo, quello che viene da chiedermi è: qual’è l’assenza che risulta un vantaggio?

Per prima cosa, il codice duplicato. Aver letto Object Oriented Software Construction mi ha segnato sostanzialmente per due motivi: primo mi ha probabilmente abbassato la vista, secondo mi ha fatto riflettere sul fatto che molti assunti da programmatore si basano su presupposti sbagliati.
In particolare, l’idea che la programmazione difensiva, del tipo “lo so che questa funzione riceverà sempre in input numeri tra 1 e 9, ma fammici mettere un controllo che non si sa mai” sia basato sul concetto fondamentalmente assurdo del non potersi fidare del resto del codice (cosa che ovviamente è risolta dal design by contract, per meyer, come ogni problema del mondo).

Allora ogni ridondanza è male, ed un design corretto non ne presenta nessuna? Mi pare che il DRY principle sia quasi sempre valido e che il codice migliore sia sempre quello non scritto. E però, non sono in grado di capire chiaramente quand’è che riesco davvero ad applicarlo.

Siccome sto trafficando con Nitro e Rails di recente, ci infilo un confronto.

Rails segue massicciamente l’idea che le convenzioni siano preferibili alle configurazioni esplicite. Nitro, d’altro canto, impone pochissime restrizioni, così da permettere uno sviluppo molto più spontaneo.
Quindi, ad esempio, mentre il primo vuole una gerarchia complessa di directory e sottodirectory, il secondo se ne frega e chiede solo di mettere un require.

Qual’è l’approccio davvero less?
È vero, rails non vuole che tu metta una riga di codice in più, ma pretende molto di più in fatto di gestione del progetto.
Quando si segue una convenzione si ha un vantaggio evidente, ma ad un certo punto diventa impossibile tornare indietro senza uno sforzo notevole.
Penso ad esempio a tante tradizioni in Unix, come gli script di init; il sistema tipico di linux è subottimale, ma come fai a cambiarlo oggi se tutti i programmi del cosmo ci si appoggiano sopra e tutti o quasi lo seguono?

D’altronde, Nitro permette di creare un progetto anarchicamente. Non ti va di mettere le viste in una cartella precisa? Vai sereno.
Vuoi mettere tutti i modelli in un unico file tanto sono 5 righe ognuno? Perfetto.
Solo che tutte le volte che uno va a mettere mano nel codice di qualcun’altro non sa che pesci pigliare, in quanto tutto è stato organizzato in un modo ad hoc.

Non mi pare ci sia un meno chiaramente… beh.. minoritario.

Per le interfacce grafiche sembra più semplice, è ormai assodato che le convenzioni sono buone ed utili se sono ben note e largamente condivise, basta dare un’occhiata a cose come questa. Ma in questo caso che fine ha fatto il less, ho una marea di regole!

Altro esempio: gestione della memoria implicita o esplicita.
Un appassionato sviluppatore C++ cercherà subdolamente di convincermi che la garbage collection è chiaramente un più da evitare. Uno sviluppatore python insisterà nel sostenere che il dover gestire la memoria è chiaramente un più da evitare.

E persino la sintassi! Buona parte dei Lisper e degli Smalltalker saranno perfettamente in grado di dirvi quanto sia meglio avere meno sintassi, e dalla loro hanno linguaggi immutati da decenni. Ma buona parte dei rubyisti e dei pythonisti saranno dell’opinione , che è meglio avere meno estremismo, e dalla loro hanno decisamente più mindhsare. I perlisti plausibilmente sostengono che less può essere meno o più a seconda della versione di perl.

E poi i servizi web. del.icio.us non fa praticamente nulla, è chiaramente less. Ed è combinabile con un fottio di altre cose, il che lo rende more, e l’assunto sembra funzionare. Ma poi, cavolo devo considerare che è c’è molta più roba da usare insieme a del.icio.us per avere funzionalità più ricche, come dimostrano i milioni di mashup, ed allora mi diventa di nuovo more.

Insomma ho serie difficoltà a capire cos’è meno o più, il che al primo anno di specialistica in ingegneria è preoccupante. Di una cosa sono però sicuro, che è meglio dormire more e quindi vado a nanna. Sempre che non mi convinca a provare il sonno polifasico .