7

mi chiedevo circa i benefici della programmazione stateless, e trovato qualcuno che ha condiviso la mia domanda: Advantages of stateless programming?vantaggi della programmazione stateful?

come ho letto attraverso le risposte, però, mi ha fatto curioso circa la domanda Converse. quali sono i vantaggi della programmazione stateful? sembra che ci sia un sacco di attenzione sul codice stateless di recente, ma sono diffidente nei confronti delle tendenze.

sembra che stateful (cioè imperativo) programmazione stessa potrebbe prestarsi a certi scenari meglio stateless (cioè funzionale) programmazione e desidero essere maggiormente in grado di riconoscere che i problemi possono essere risolti mediante programmazione stateful.

+0

Penso che la tua domanda sia una domanda leggibile al suo interno, tuttavia è necessario migliorarla: rimuovi l'ultimo paragrafo (è soggettivo) e cerca di indicare attivamente quale tipo di risposta ti aspetti. –

+1

perché questa domanda è stata chiusa, mentre la domanda inversa (collegata a sopra) non era? – ericsoco

+0

@JohannesRudolph - annotato e modificato. – ericsoco

risposta

6

Ci sono solo alcuni casi in cui vi sono vantaggi non discutibili per un modello di programmazione basato sullo stato mutabile e condiviso rispetto a un modello di programmazione stateless immutabile. Un settore in cui la mutabilità può portare enormi vantaggi è nel consentire agli algoritmi di lavorare sul posto. Il wiki haskell ha un ottimo esempio sull'implementazione di quicksort: http://www.haskell.org/haskellwiki/Introduction#When_C_is_better

Per riepilogare, quando non si consentono modifiche alla memoria degli elenchi, è necessario creare una copia ordinata di esso. Lo stesso vale per quasi tutti gli altri algoritmi che modificano alcune strutture dei dati, ad es. un albero AVL.

In generale, i linguaggi di programmazione funzionale tendono ad essere più ricchi di memoria rispetto ai loro equivalenti imperativi. Oggigiorno la memoria è a buon mercato, tuttavia la larghezza di banda è cruciale e le velocità di memoria non aumentano proporzionalmente all'aumento della potenza della CPU. Va notato, tuttavia, che il modello di esecuzione di Haskell consente al Compiler di eseguire alcune ottimizzazioni ottimali, anche per quanto riguarda l'utilizzo della memoria e i modelli di accesso. In una certa misura, ciò può compensare gli svantaggi teorici.

1

La leggibilità è fondamentale. Mi piace la programmazione funzionale (attualmente sono abbaiato con un clojure), ma lo stato è come funziona il mondo. Non è un caso che il paradigma Object Oriented sia più popolare del funzionale o di qualsiasi altro tipo di programmazione. OOP e programmazione procedurale sono la via di minor resistenza per i nuovi programmatori. La maggior parte delle persone comprende intuitivamente l'idea di un oggetto come qualcosa che cambia stato (può essere in movimento, o cambia colore, ecc.) Piuttosto che il combinatore Y che aiuta con la ricorsione.

+0

Non so se lo compro. Dopo tutto, una delle ragioni per cui sono "il percorso di minor resistenza" è perché i linguaggi OOP sono già così popolari, nel senso che hanno più tutorial, più strumenti, più IDE, più tutto. Ma la popolarità non significa semplicità concettuale. – thedayturns

+0

Concordo con questo per alcune lingue (un OOP ben implementato è molto bello). Il mio punto era che la gente pensa in stato. Il mondo stesso è solo una macchina a stati finiti. – semisight

+3

"lo stato è come funziona il worl" - un'ipotesi filosofica altamente speculativa. Si potrebbe controbattere: "La meccanica matematica e quantistica è come funziona il mondo (e in certe circostanze sembra esserci stato)". – Ingo

1

Lo stato è importante. Ogni bit in questo universo ha uno stato, è lo stato che definisce come si comporta un sistema, lo stato rende il sistema dinamico e utilizzabile, ma dato che lo stato è così importante è anche importante che questo stato sia accessibile e manipolato. Non sarebbe bello se un essere umano potesse manipolare lo stato di un altro umano (lo stato come un contenuto nel cervello di un essere umano). La mia vista sullo stato è che dovrebbe essere reso esplicito e non dovrebbe essere qualcosa che è disseminato nel codice e diventare molto implicito che è difficile sapere in quale stato è il sistema e quale parte del sistema è responsabile per quale parte dello Stato. Lo stato dovrebbe essere controllato in modo tale da poter facilmente dire che questa parte dello stato del sistema è gestita da questo modulo e solo da questo modulo.

In qualsiasi programma FP del mondo reale avrà sempre 2 parti, una che è stateless che sarebbe il core algoritmo ecc. E un'altra parte che manterrà lo stato del programma.