Altre persone hanno applicato DAG ai dati, ma penso che sia almeno altrettanto applicabile (se non di più) al codice. Mahbubur R Aaman menziona questo, quindi questo è più un addendum alla sua risposta che una risposta completa da sola.
Mi viene in mente che qualsiasi programma per computer imperativo che sia privo di loop infiniti (grazie a @AndresF.) è un Dyc (Directed Acyclic Graph). Significa che i possibili percorsi di esecuzione del codice sono diretti (prima questo, poi quello), e aciclici (non si formano loop infiniti). Sono un grafico perché il percorso attraverso qualsiasi codice significativo è raramente semplice come un elenco o un albero.
Ho lavorato in XSLT per forse 4 anni. Ho passato un brutto periodo cercando di spiegare perché non era un buon linguaggio di programmazione generico, ma il DAG è la ragione. In particolare, XSLT è un linguaggio basato sui dati. Definite le funzioni (sì, nel senso di programmazione funzionale) ma non chiamate necessariamente queste funzioni dal vostro codice. Piuttosto, XSLT imposta una combinazione di selezione e iterazione attraverso i nodi di un documento XML di input. Ciò consente alla struttura dei dati di input di determinare quali funzioni vengono chiamate e in quale ordine.
Questo è stato molto interessante e molto interessante finché il tuo programma non ha riscontrato una condizione di dati per cui non hai eseguito il test alle 2:30 del mattino e hai dovuto svegliarlo e sistemarlo. Quando si lascia che i dati definiscano il DAG, la definizione del DAG diventa tutte le possibili condizioni di input, che per qualsiasi applicazione aziendale non banale sono oltre incalcolabili; sono inimmaginabili.
All'inizio pensavo che la programmazione funzionale potesse non essere un DAG perché a volte l'ordine di esecuzione non è chiaro, o addirittura pensato dal programmatore. Ma un programma funzionale definisce le dipendenze. In effetti, la natura dichiarativa della programmazione funzionale potrebbe essere pensata come la definizione di sole dipendenze (a ^ 2 = b ^ 2 + c ^ 2) senza specificare l'ordine di esecuzione (non importa se 'b' o 'c' è al quadrato prima , purché siano entrambi squadrati prima di essere aggiunti insieme).
Ma mentre la programmazione funzionale può essere deliberatamente vaga sull'ordine delle operazioni a livello dettagliato, è squisitamente chiara sulle dipendenze. Queste sono le caratteristiche che lo rendono così suscettibile alla concorrenza. In ogni caso, c'è ancora un grafico di percorsi attraverso il codice, e quel grafico è ancora diretto (le dipendenze devono essere valutate prima delle attività dipendenti), quindi penso che anche DAG si applichi lì.
Bella domanda: grazie per aver pubblicato!