risorse | semplice o facile?
Dalla Treccani:
Nell'esaminare la differenza di significato tra semplice e facile, Hickey[1][2] pone l'accento sull'oggettività insita nella semplicità – in quanto proprietà “strutturale” – e la soggettività della facilità – in quanto legata alle peculiari abilità dell'individuo. Una cosa semplice lo di per sé, e può purtuttavia risultare facile per qualcuno, difficile per altri.
A titolo d'esempio, Hickey cita il costrutto della variabile: un concetto facile da assimilare – il mutare delle cose nel tempo è un aspetto ben noto della nostra natura –, ma non semplice da gestire, perché fonde la nozione di valore con quella di tempo. Buona parte degli errori della programmazione procedurale sono riconducibili ad una variabile che assume, in un certo istante di tempo, un valore errato.
Sempre dalla Treccani:
Un sistema complesso è un sistema costituito da un insieme di diversi componenti, ed è per definizione “non-semplice”. Qualunque sistema non banale è per forza di cose complesso. Ciò che rende un sistema complicato è la difficoltà di comprenderne il funzionamento. La complessità è dunque una proprietà oggettiva del sistema – è l'opposto della semplicità –, mentre l'essere complicato è una caratteristica soggettiva.
Non potendo esimersi dal costruire sistemi software complessi, è doveroso limitarne la complicatezza.
Nel corso del suo intervento Hickey elenca una serie di complicazioni del dominio dello sviluppo di sistemi software, citando per ognuna di esse gli aspetti base che, essendo interlacciati, le rendono tali; prosegue quindi proponendo un'alternativa più semplice, indicando, di volta in volta, quale strumento software può risultare utile. Buona parte di quell'elenco è riportato qui sotto:
| complicato | semplice | |||
|---|---|---|---|---|
| entità | aspetti interlacciati | entità | strumento | |
| stato | tempo, valore | → | valore | const |
| oggetto | stato, valore, identità | → | valore | const |
| metodo | stato, funzionalità | → | funzione/messaggio | funzioni pure |
| ereditarietà | tipi | → | polimorfismo | typeclass(1), protocol(2) |
| switch | molteplicità di chi, cosa | → | polimorfismo | typeclass(1), protocol(2) |
| ciclo for | cosa, come | → | insiemi | funzioni di libreria(3) |
| attore | cosa, chi | → | coda | funzioni di libreria |
| if | perché, computazione | → | regole | funzioni di libreria |
| ORM | tutto! | → | linguaggi dichiarativi | SQL, LINQ, … |
| inconsistenza | - | → | consistenza | transazioni |
La “deriva” funzionale è ben evidente. Il perseguimento della semplicità secondo questi canoni ha comunque un suo prezzo: un interessante articolo[3] dimostra che per una certa categoria di problemi, la migliore delle soluzioni che fa uso di sole strutture immutabili ha un'efficienza pari a O(n log n), mentre quella che fa uso di oggetti modificabili ne ha una pari a O(n).
(1) cfr. Haskell
(2) cfr. Closure
(3) ad esempio la list-comprehension di Python
Pagina modificata il 29/08/2012