Programmazione asincrona in linguaggi funzionali

Tutta la tua logica è valida, tranne che penso che la tua comprensione della programmazione funzionale sia un po 'troppo estrema. Nella programmazione funzionale del mondo reale, proprio come la programmazione orientata agli oggetti o imperativa riguarda mindset e come ci si avvicina al problema. Puoi ancora scrivere programmi nello spirito della programmazione funzionale mentre modifichi lo stato dell'applicazione.

In effetti, devi modificare lo stato dell'applicazione per fare effettivamente do . I ragazzi di Haskell ti diranno che i loro programmi sono "puri" perché avvolgono tutti i loro cambiamenti di stato in una monade. Tuttavia, i loro programmi interagiscono ancora con il mondo esterno. (Altrimenti qual è il punto!)

L'enfasi sulla programmazione funzionale "senza effetti collaterali" quando ha senso. Tuttavia, per programmare in tempo reale, come hai detto tu, devi modificare lo stato del mondo. (Ad esempio, rispondere agli eventi, scrivere su disco e così via.)

Per ulteriori informazioni sulla programmazione asincrona nei linguaggi funzionali, ti invito vivamente a consultare i flussi di lavoro asincroni di F # modello di programmazione. Ti permette di scrivere programmi funzionali nascondendo tutti i dettagli disordinati della transizione dei thread all'interno di una libreria. (In un modo molto simile alle monadi di stile Haskell.)

Se il "corpo" del thread calcola semplicemente un valore, quindi generare più thread e averli calcolare i valori in parallelo è ancora all'interno del paradigma funzionale.

Questa è una domanda affascinante. L'interpretazione più interessante è, a mio avviso, l'approccio adottato in Clojure e spiegato in questo video:

link

Fondamentalmente la "soluzione" proposta è la seguente:

• Scrivi la maggior parte del tuo codice come funzioni "pure" classiche con strutture di dati immutabili e senza effetti collaterali
• Gli effetti collaterali sono isolati tramite l'uso di riferimenti gestiti che controllano le modifiche soggette alle regole della memoria transazionale del software (cioè tutti gli aggiornamenti allo stato mutabile avvengono all'interno di una transazione isolata corretta)
• Se osservi questa visione del mondo, puoi vedere "eventi" asincroni come trigger per un aggiornamento transazionale dello stato mutabile in cui l'aggiornamento è di per sé una funzione pura.

Probabilmente non ho espresso l'idea chiaramente come altri hanno fatto, ma spero che questo dia l'idea generale - fondamentalmente sta usando un sistema STM concorrente per fornire il "ponte" tra pura programmazione funzionale e gestione asincrona degli eventi.

Una nota: un linguaggio funzionale è puro, ma il suo runtime non lo è.

Ad esempio, i runtime di Haskell comportano code, multiplexing dei thread, garbage collection, ecc. Tutto ciò non è puro.

Un buon esempio è la pigrizia. Haskell supporta la valutazione lazy (che è il default, in realtà). Si crea un valore pigro preparando un'operazione, è possibile quindi creare più copie di questo valore ed è ancora "pigro" purché non sia necessario. Quando il risultato è necessario, o se il runtime trova un po 'di tempo, il valore viene effettivamente calcolato e lo stato dell'oggetto pigro cambia per riflettere che non è più necessario eseguire il calcolo (ancora una volta) per ottenere il risultato. È ora disponibile attraverso tutti i riferimenti, quindi lo stato dell'oggetto è cambiato, anche se è un linguaggio puro.

I'm confused as to how this "no side-effects" philsophy works with asynchronous programming. By asynchronous programming I mean ...

Questo sarebbe il punto, quindi.

Un suono, nessun effetto collaterale è incompatibile con i framework che dipendono dallo stato. Trova un nuovo framework.

Lo standard WSGI di Python, ad esempio, ci consente di creare applicazioni con effetti collaterali.

L'idea è che i vari "cambiamenti di stato" siano riflessi da un ambiente di valori che può essere costruito in modo incrementale. Ogni richiesta è una pipeline di trasformazioni.

Avendo imparato l'incapsulamento da Borland C ++ dopo aver imparato C, quando Borland C ++ mancava di template che abilitassero i generici, il paradigma di orientamento agli oggetti mi metteva a disagio. Un modo un po 'più naturale di calcolare sembrava filtrare i dati attraverso i tubi. Il flusso verso l'esterno aveva un'identità separata e indipendente dal flusso di input immutabile verso l'interno, piuttosto che essere considerato come un effetto collaterale, cioè ogni fonte di dati (o filtro) era autonoma dagli altri. La pressione del tasto (un evento di esempio) vincolava le combinazioni di input degli utenti asincroni ai keycode disponibili. Le funzioni operano sugli argomenti dei parametri di input e lo stato incapsulato dalla classe è solo una scorciatoia per evitare di passare esplicitamente argomenti ripetitivi tra piccoli sottoinsiemi di funzioni, oltre ad essere precisi del contesto associato che impedisce di abusare di tali argomenti da qualsiasi funzione arbitraria.

Aderire rigidamente a un paradigma particolare causa l'inconveniente di occuparsi di astrazioni che perdono, per es. i runtime commerciali come JRE, DirectX, .net sono i proponenti orientati agli oggetti di destinazione. Per limitare l'inconveniente, le lingue optano per monade sofisticate dal punto di vista accademico come Haskell o supporto flessibile multi-paradigma come F # alla fine ottenuto. A meno che l'incapsulamento non sia utile in alcuni casi di utilizzo dell'ereditarietà multipla, l'approccio multi-paradigma potrebbe essere un'alternativa superiore ad alcuni, a volte complessi, schemi di programmazione specifici del paradigma.