Campioni della Community

Credo che il discorso di @bobon123 (come d'altronde quello del post originale) vada oltre lo specifico confronto tra le edizioni 3.5 e 5 per fare considerazioni generali. Non ha detto che un sistema più semplice è necessariamente migliore. Ha detto (e condivido) che esistono due tipi di semplicità: la "semplicità negativa", che è la negazione di quella che ha chiamato "complessità": semplificare togliendo contenuti, scelte strategiche, varietà di situazioni; la "semplicità positiva", che è la negazione di quella che ha chiamato "complicazione": semplificare senza togliere contenuti, scelte strategiche, varietà di situazioni, ma rendendo più agevole, diretta, intuitiva l'interfaccia verso quegli stessi contenuti, scelte, situazioni. Ha poi ammesso, credo (e anche qui concordo), che la quinta edizione, rispetto alla 3.5, ha sia una maggiore "semplicità negativa" che una maggiore "semplicità positiva". Quindi la scelta tra le due è opinabile, è appunto questione di gusti: ognuno di noi sceglierà se la maggiore complessità (cosa bella) della 3.5 vale la candela della sua maggiore complicazione (cosa brutta). Ha però concluso che non è corretto generalizzare asserendo che qualunque richiesta di maggiore semplicità sia necessariamente un sintomo di stupidità / instupidimento: è invece una richiesta perfettamente naturale e comprensibile, che andrebbe solo incanalata, da parte dei designer, verso una maggiore "semplicità positiva" anziché "semplicità negativa".

Mi devo essere spiegato proprio male, perché il punto del mio intervento era proprio che la complessità e profondità di un sistema è positiva, ma non è l'unico contrario di semplice. Vi sono sistemi inutilmente complicati, che non aggiungono niente alla complessità. Per rispondere anche a @Nyxator, non siamo necessariamente nei gusti. Sono assolutamente d'accordo che sia solo gusto scegliere tra un sistema poco complesso e poco complicato e un sistema molto complesso e molto complicato, e tutta la gamma tra i due estremi. A volte mi piace giocare ad un sistema meccanicamente invasivo e complesso, e quindi anche un po' complicato, a volte a giochi estremamente semplici o anche ruleless. Ma a parità di complessità, un sistema meno complicato è semplicemente meglio. Se riesco a rendere con poche regole semplici e chiare gli stessi trade-off strategici, il sistema migliora. Se riesco a rendere con un tiro di dado confrontato con un numero quello che altrove necessita di tirare dadi su tre tabelle, senza perdere in complessità strategica, il sistema migliora. C'è il gusto, e c'è la teoria del game design. Andare all'essenza del gioco e eliminare quello che è inutile non vuol dire semplicemente eliminare il più possibile. As simple as possible, but not simpler. L'esempio con la scrittura credo aiuti. Un buon testo, che spieghi bene e convinca chi legge, è un testo lungo o un testo corto? Un testo complicato e con parole difficili, o un testo grammaticalmente semplice e con parole facili? Questione di gusto! Il testo lungo e difficile può rendere concetti più complessi e tutte le sfumature in modo più preciso, ed è appunto gusto decidere se ne valga la pena. Ma se riesco a rendere lo stesso concetto con meno parole e frasi più semplici, senza perdere in precisione e sfumature, è sicuramente un vantaggio. Io tendo sicuramente a essere prolisso qui sul forum, proprio perché non spendo il giusto tempo per ridurre e semplificare. Ma credo che sia facile vedere come questo post potrebbe essere scritto in modo molto più efficace spendendo una mezz'ora a asciugarlo e togliere il superfluo. È invece solamente gusto discutere se vi sia stata riduzione della complessità tra 3.5E e 5E, o se preferisco il rapporto complessità/complicazione di 3.5E o 5E. Ma sul principio generale, esplicitato anche nell'esempio finale che una feature o un'icona in più in un'applicazione sia sempre meglio, credo si possa parlare con tutta l'oggettività che permettono le scienze soft.

Sono davvero in totale disaccordo con questo post 🙂 Si confondono quattro contrari di "semplice": "complicato", "complesso", "ricco", e "difficile". Non sono la stessa cosa: voglio un software o un sistema ricco e complesso, ma non lo voglio complicato o difficile da usare. Einstein ha detto* che un modello deve essere As simple as possible, but not simpler. Più semplice possibile, ma non tanto semplice da perderne il senso, la complessità emergente. Semplificare, sintetizzare, togliere il grasso e lasciare il muscolo, trovare il modo più diretto per far funzionare una meccanica, è la chiave per rendere esplicita la complessità del sistema, la ricchezza di opzioni, ma togliendo tutte le parti superflue che aggiungono solo complicazione inutile e annacquano il gioco. Creare un sistema semplice (non complicato, non difficile) ma non-semplice (complesso, ricco) prende tempo ma migliora il prodotto: lo distilla. Non bisogna fare l'errore di pensare che scrivere tanto, fare più regole per gestire ogni aspetto, così come mettere più opzioni in un software, prenda necessariamente più tempo che scrivere meno o mettere meno regole e meno opzioni. Può essere ovviamente: qualcosa può essere semplice nel senso di non complicato, non difficile, ma anche non complesso e non ricco. Ma non è necessariamente il caso. Ne è la prova questo mio post, lungo tre paragrafi, che diluisce e basta la citazione di sette parole di Einstein* e la rende meno efficace. Per forgiare quelle sette parole, è stato speso sicuramente molto più tempo e talento che per scrivere questo mio post. Finisco con un'altra citazione, di Pascal, che termina la lettera al cugino (mi pare) con Questa lettera è più lunga delle altre perché non ho avuto tempo di farla più breve. * Non ci sono prove in realtà che abbia detto proprio questa elegantissima frase, pare sia una efficace sintesi giornalistica di Roger Sessions di un pensiero meno chiaro e conciso: Einstein scriveva bene, ed era molto arguto, ma non era il suo talento principale.