"La programmazione reattiva è programmata con flussi di dati asincroni." è vero?

8

Leggevo della programmazione reattiva e ho trovato questo articolo L'introduzione alla programmazione reattiva che ti mancava la citazione che ho inserito nel titolo della domanda:

Reactive programming is programming with asynchronous data streams.

ma questo mi confonde un po '. Ad esempio, l'esempio più comune di programmazione reattiva di cui ho sentito parlare è un foglio di calcolo che ha valori calcolati.

Che cosa c'è asincrono o richiede flussi in quel caso? Capisco che forse i valori calcolati potrebbero essere implementati con un flusso, ma hanno davvero bisogno di essere? Non potrebbero anche essere realizzati con gli ascoltatori di eventi?

    
posta m0meni 28.04.2016 - 00:59
fonte

1 risposta

7

The most common example of Reactive programming that I've heard about is a spreadsheet program that has computed values.

Personalmente, penserei a un foglio di calcolo più come un ibrido tra la programmazione funzionale e di flusso di dati, ma posso vedere come si può pensare in modo reattivo.

What's asynchronous there or requires streams in that case?

C'è un flusso asincrono di azioni dell'utente. Il flusso (s) sono i valori che l'utente inserisce nelle celle. Ogni volta che l'utente modifica un valore di cella, questo è un nuovo valore nel flusso.

Couldn't they also be made with event listeners?

Sì.

Tutto potrebbe anche essere fatto con gli ascoltatori di eventi. La programmazione reattiva è ancora "solo" completa di Turing. Tutto ciò che puoi fare con la Programmazione Reattiva, può anche essere fatto con Ascoltatori di eventi o Continuazioni o Richiami o ... Gli ascoltatori di eventi e la programmazione reattiva sono due modi per modellare l'asincronia. Entrambi possono modellare le stesse cose. I sostenitori della programmazione reattiva non sostengono che possono modellare cose che altri non possono. Sostengono che la programmazione reattiva può modellare (almeno alcune cose) meglio di altri approcci.

Gli stream sono uno strumento utile per pensare alla Programmazione Reattiva, a causa di una ragione importante: familiarità.

In Interactive Programming, il singolo concetto più importante sta iterando su una collezione. È una delle prime cose che si impara quando si impara a programmare. Il metodo each e il Enumerable mixin in Ruby, l'istruzione foreach in C♯ e la IEnumerable / IEnumerator coppia di interfacce in .NET, il for loop aumentato e il Iterable / Iterator coppia di interfacce in Java, il Traversable trait in Scala, iteratori e loop in C ++, tu lo chiami. Le raccolte e l'iterazione sono estremamente importanti e tutti sanno come farlo.

Gli stream ti consentono di riutilizzare tutta quella conoscenza inquadrando Programmazione reattiva in un'impostazione molto simile a iterare su una raccolta, con solo due differenze: invece di tu estraendo un elemento dalla raccolta quando tu vuoi, la collezione ti spinge un elemento quando esso vuole. Questo è tutto. Tutto il resto rimane lo stesso.

In realtà, la relazione è molto più della semplice familiarità. Esiste in realtà una profonda relazione matematica tra i due: Reactive Programming with Streams è il doppio teorico della categoria di Programmazione interattiva con collezioni. Il Pattern soggetto / osservatore è il doppio teorico della categoria del Pattern Iterator.

È stato Erik Meijer a scoprirlo e l'ha usato con enorme effetto su .NET. Ha derivato meccanicamente la coppia di interfacce IObservable / IObserver semplicemente stupidamente doppiando IEnumerable / IEnumerator . Il fatto che siano duali significa che puoi letteralmente semplicemente scambiare i tipi di parametri e restituire i tipi dei metodi senza nemmeno dover pensare a quello che stai facendo.

E la cosa veramente interessante è che i duali sono ancora strettamente correlati nella struttura, e molte cose che funzionano per la cosa originale funzionano anche per il doppio. In .NET, ad esempio, IEnumerable / IEnumerator formano una monade che può essere utilizzata con LINQ. E si scopre che IObservable / IObserver anche forma una monade, e quindi può anche essere usato con LINQ esattamente nello stesso modo in cui IEnumerable / IEnumerator può. In altre parole, inquadrando il problema della programmazione reattiva in termini di flussi, è possibile utilizzare gli stessi esatti strumenti per la programmazione reattiva a cui si è già abituati da Programmazione interattiva. Puoi letteralmente scrivere la stessa query LINQ indipendentemente dal fatto che tu stia eseguendo un'iterazione su un array o iscrivendoti a un flusso di eventi.

Mappare, piegare, ridurre, flatMapping, filtrare, trasformare, partizionare, unire, dividere, ... Gli stream sono esattamente come mappare, piegare, ridurre, flatMapping, filtrare, trasformare, partizionare, fondere , divisione, ... collezioni.

Questo è il potere degli Stream. Ti permettono di almeno di pensare come se stessimo ripetendo le raccolte e con alcune librerie intelligenti, persino scrivi codice come faresti con le raccolte.

    
risposta data 28.04.2016 - 02:34
fonte

Leggi altre domande sui tag