risorse | are patterns a language smell?
Ci arrivo con appena 15 anni di ritardo. È infatti nel 1996 che Peter Norvig pubblica un articolo[3] dove sostiene che ben 16 dei 23 pattern individuati dalla Gang Of Four sono invisibili o comunque di più semplice implementazione in Lisp (e in Dylan). L'integrazione dei pattern aumenta l'espressività del linguaggio stesso, che a sua volta permette di scrivere codice più comprensibile, per l'assenza di codice «infrastrutturale» – codice relativo al dominio della soluzione anziché a quello del problema. Da qui l'implicazione «uso dei patterns ⇒ linguaggio inadeguato».
Il tutto ha avuto origine dalla lettura del post di Jeff Atwood[1] che elabora l'idea di Norvig affermando:
Perhaps later languages will include many design patterns as standard features.
Si tratta in sostanza dello stesso fenomeno che negli anni 60/70 ha originato i linguaggi della programmazione strutturata: i pattern più utilizzati dai programmatori assembly, come ad esempio la realizzazione dei cicli for, while/do e repeat/until con i salti condizionati, o il passaggio dei parametri attraverso lo stack, sono stati integrati nei nuovi linguaggi. Chi durante gli anni 80 si dilettava a scrivere programmi in Sinclair BASIC, certamente ricorderà il pattern usato per sopperire all'assenza dell'operatore ELSE nella clausola IF-THEN(-ELSE):
10 IF <CONDITION> THEN GO TO 60 20 REM 30 REM ELSE BRANCH 40 REM 50 GO TO 90 60 REM 70 REM THEN BRANCH 80 REM 90 REM END OF IF STATEMENT
L'articolo di Atwood cita poi un intervento di Paul Graham[2] sulla superiorità del Lisp rispetto agli altri linguaggi (per quanto lungo, è di facile e divertente lettura, infarcito com'è di perle come «any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp»), che si conclude con la considerazione:
When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.
Pagina modificata il 25/11/2011