D'autres personnes ont appliqué DAG aux données, mais je pense que c'est au moins aussi applicable (sinon plus) au code. Mahbubur R Aaman mentionne cela, donc c'est vraiment plus un additif à sa réponse qu'une réponse complète en elle-même.
Il me semble que tout programme informatique impératif est dépourvu de boucles infinies (grâce à @AndresF.) Est un graphe acyclique dirigé (DAG). Ce qui signifie que les chemins possibles d'exécution du code sont dirigés (d'abord ceci, ensuite cela) et acycliques (ne formant pas de boucles infinies). Il s’agit d’un graphe car le chemin d’un code significatif est rarement aussi simple qu’une liste ou un arbre.
J'ai travaillé chez XSLT pendant peut-être 4 ans. J'ai eu beaucoup de difficulté à expliquer pourquoi ce n'était pas un bon langage de programmation à usage général, mais DAG en est la raison. Plus précisément, XSLT est un langage piloté par les données. Vous définissez des fonctions (oui, au sens de la programmation fonctionnelle) mais vous n'appelez pas nécessairement ces fonctions à partir de votre code. XSLT définit plutôt une combinaison de sélection et d'itération des nœuds d'un document XML d'entrée. Cela permet à la structure des données d'entrée de déterminer quelles fonctions sont appelées et dans quel ordre.
C'était très intéressant et très cool jusqu'à ce que votre programme rencontre une condition de données que vous n'avez pas testée à 02h30 et que vous deviez vous réveiller pour la réparer. Lorsque vous laissez les données définir le DAG, la définition du DAG devient alors toutes les conditions d'entrée possibles, qui sont inestimables pour toute application métier non triviale. ils sont inimaginables.
Au début, je pensais que la programmation fonctionnelle n'était peut-être pas un DAG car l'ordre d'exécution n'est parfois pas clair ni même pensé par le programmeur. Mais un programme fonctionnel définit des dépendances. En fait, le caractère déclaratif de la programmation fonctionnelle pourrait être considéré comme ne définissant que les dépendances (a ^ 2 = b ^ 2 + c ^ 2) sans spécifier l'ordre d'exécution (peu importe que «b» ou «c» soit carré au début , tant qu’ils sont tous les deux carrés avant d’être additionnés).
Mais si la programmation fonctionnelle peut être délibérément vague en ce qui concerne l’ordre des opérations à un niveau détaillé, elle est extrêmement claire en ce qui concerne les dépendances. Ce sont les caractéristiques mêmes qui le rendent si sujet à la concurrence. Dans tous les cas, il y a toujours un graphe de chemins dans le code, et ce graphe est toujours dirigé (les dépendances doivent être évaluées avant les tâches dépendantes), donc je pense que DAG s'applique également dans ce cas.
Belle question - merci de poster!