Può * qualsiasi * attività del programma essere espressa senza stato?

Risposta breve: sì. Secondo Wikipedia, l'equivalenza di lambda calcolo alle macchine di Turing come modello universale di calcolo è stata mostrata nel 1937 da Alan Turing. Il modello computazionale di una macchina di Turing è quello che si ha in mente quando si parla di programmazione imperativa o di stato, e il calcolo lambda è una formalizzazione matematica di "pura programmazione funzionale".

Si conviene che ogni modello efficace di calcolo sia in grado di eseguire gli stessi calcoli di una macchina di Turing e viceversa. Questa è chiamata Tesi di Church-Turing . Questa congettura, tuttavia, non può essere dimostrata, a causa del termine più o meno intuitivo "efficace modello di calcolo" (forse qualcuno inventerà un nuovo modello in futuro?)

In qualsiasi sistema dinamico, lo "stato" è ciò che rende il tuo regalo influenzato dal tuo passato o futuro (la freccia di il tempo non è un problema matematico, solo un vincolo fisico).

Se hai qualcosa da "ricordare" o che dipende da ciò che hai fatto, hai uno stato.

Un sistema senza stato non è "dinamico": è solo una funzione combinatoria. Quello potrebbe non avere uno stato, ma - per produrre risultati diversi - ha bisogno di uno stato per essere in qualche modo fornito.

Ora, a seconda del modello di calcolo cui ci si riferisce, uno stato può essere rappresentato esplicitamente (sotto forma di variabile) o implicitamente (sotto forma di "indirizzi di ritorno").

quando fai fna(fnb(x)) stai dando uno stato a fnb che a sua volta produrrà uno stato per fna. Ciò è dovuto al fatto che x esiste prima che venga chiamato fnb (quindi, deriva dal proprio "passato").

Non si tratta di "stato attuale" o "stato non esiste". È un mater di "I care" o "I do not".

Stato indica la capacità di rispondere a uno stimolo presente in un modo che dipende dagli stimoli passati, non solo in base allo stimolo presente.

I programmi puramente funzionali sono solo funzioni. Quindi per le applicazioni pratiche il programma puramente funzionale immette una coppia (old_state * present_stimulus) e genera una coppia (new_state * present_response). È necessario un "looper" esterno e di stato per attendere lo stimolo successivo e propagare lo stato.

Un programma puramente funzionale non ha uno stato intrinseco e non può essere utilizzato direttamente per le applicazioni pratiche.

Quindi il programma orientato allo stato no può essere sostituito con un'implementazione diversa puramente funzionale e senza stato.

Puoi evitare lo stato mutabile esplicito fino a quando non devi interagire con il mondo esterno.

In JavaScript affinché il tuo programma abbia effettivamente un effetto al di là dei cicli del processore, devi modificare l'oggetto Dom o Window e queste API sono stateful. Ma suppongo che potresti creare un wrapper che ha passato gli oggetti Dom e Window come parametri al codice JavaScript, e poi ha ricevuto un nuovo Dom / Window come output. Ciò isolerebbe il codice JavaScript dallo stato mutabile.

Ovviamente si sta ancora affidandosi allo stato, dal momento che la finestra del browser e il DOM sono di stato per natura. Qualsiasi applicazione interattiva è intrinsecamente basata sullo stato, ma è comunque possibile strutturare il codice in modo tale da ridurre al minimo lo stato esplicito.

Una domanda diversa è se è una buona idea. Persino Haskell, che è un linguaggio funzionale puramente funzionale, include la monade "stato", che consente di simulare lo stato mutabile. Questo mostra che lo stato mutevole esplicito a volte è davvero un modello desiderabile.