Perché è meglio non fare affidamento sul cambiamento di stato?

ci sono almeno tre grandi vantaggi in cima alla mia testa:

1. rende i programmi più simili alle espressioni matematiche. In matematica, x non cambia, semplicemente non sai cosa sia finché non risolvi l'equazione.

2. Alla fine, c'è è cambiamento di stato (dopotutto, è così che il computer funziona a basso livello); ma è limitato dalla lingua a luoghi specifici. ciò consente al compilatore enormi opportunità di spostare il codice per ottimizzarlo, poiché sa che non cambia nulla da cui dipende l'altro codice.

3. Il codice concorrente non ha bisogno di sincronizzarsi per accedere ai dati che non cambiano, quindi la concorrenza è migliorata, sia nei sistemi di memoria condivisa SMP (tutti i sistemi multicore di oggi), sia nei cluster vagamente legati.

Ecco un altro vantaggio: accoppiamento ridotto. Se hai un codice come:

 function doStuff(x) { return x + y;}

e altrove hai:

 function doOtherStuff(x) { y++; return y + x;}

quindi le due funzioni dipendono implicitamente . Non c'è un modo semplice per dire che chiamare doStuff è influenzato chiamando doOtherStuff . Senza lo stato mutabile, dovresti rendere esplicita la connessione.

Naturalmente, questo non è un problema con lo stato mutabile all - il problema è con lo stato pervasivo mutabile. La vera soluzione è quella di avere l'immutabilità di default e un modo per "marcare" e vincolare lo stato mutabile nel punto in cui ne hai bisogno.

Una risposta semplificata è: quando vedi un nome in un linguaggio puramente funzionale, sai qual è il valore associato con una semplice ricerca della sua definizione. Se hai variabili mutabili, puoi solo dire quale delle varie assegnazioni è stata eseguita per ultima, quindi devi anche analizzare il flusso di controllo, che a sua volta potrebbe essere condizionale, lasciandoti con molteplici possibilità. Per ottenere un'esplosione esponenziale devi solo considerare che gli RHS dei compiti dipendono essi stessi da variabili, quindi devi analizzarli in modo ricorsivo.

La linea di fondo nell'analisi precedente è che è insostenibile senza commenti che spieghino l'intento, le invarianti e la semantica: possono essere difficili da interpretare e potrebbe essere difficile verificare che la semantica sia rispettata nel codice reale.

Questa risposta è fondamentalmente un'espansione del punto 1 di @ Javier.

Penso che sia anche una spiegazione della popolarità del regime OO fraudolento: con OO lo stato mutabile è incapsulato il che rende l'analisi molto più semplice localizzando le mutazioni in una certa misura e permettendo un'espressione molto più robusta e la verifica di la semantica.

Avendo notato che la programmazione funzionale non è la risposta. La risposta corretta è un sistema che supporta sia la programmazione induttiva (funzionale) che quella coinduttiva (procedurale), quindi gli strumenti giusti possono gestire sia la programmazione stateless che quella stateful. È solo che la teoria costruttiva (funzionale) è ben consolidata mentre la teoria della gestione dello stato è ancora agli inizi.

Come autore di Siege , un DBMS scritto in Haskell, alcuni potrebbero chiamare la mia vista sullo stato mutabile in conflitto. Spero di mostrare il contrario.

Lo scopo dello stato mutabile è descrivere lo stato corrente in cui si trova un sistema. Supponiamo che tu abbia un blog e che sia back-end da un database, il database descriva i post che hai sul tuo blog nel momento in cui quale lo si interroga. Quanti post esistono al momento?

Confrontalo con uno stato immutabile che viene usato per comunicare fatti. Quanti post c'erano il 12 agosto?

I fatti sono facili da ragionare, lo stato mutevole no. Tuttavia, lo stato mutabile non è un cattivo effetto impuro che dovrebbe essere bandito dalle nostre menti; spesso ne abbiamo bisogno per convivere nel mondo mutevole in cui viviamo, abbiamo solo bisogno di usarlo con parsimonia.