Je pense que c’est dans The Mythical Man Month que Frederick Brooks introduit le premier cette distinction fondamentale.
En caricaturant un peu, le programme c’est petit et proche de la fonction mathématique : ça prend un input, ça génère un output, ça n’a ni utilisateur ni développeur concurrents, ça n’a pas d’état interne, et son exécution ne dépend ni des précédentes ni des suivantes.
En vrai un programme c'est génial parce que c’est très simple par nature. Ce n'est d'ailleurs par pour rien que les partisans de la programmation purement fonctionnelle invitent à rester le plus largement possible dans ce paradigme lors des développements. Si tout est fonction mathématique on évite une sacrée complexité accidentelle.
Manque de bol, et c'est aussi à Brooks qu’on le doit, une pure fonction mathématique n’a que peu d’intérêt parce qu’elle n’a de sens que dans un tout plus grand qu’elle. Que quand on quitte l’accidentel (l’implémentation) pour regarder l’essentiel (l’objectif).
Or cet essentiel est toujours au service d’un système. Ce dernier a DES états. DES interactions. De la concurrence. DES exceptions. Des développeurs. Des programmes. Des données. Des objectifs. Des conflits. De la latence. Des retards.
Dans le combat permanent pour combattre la complexité, l’abstraction et les mathématiques sont nos alliés. En observateur de mon secteur il m’a toujours paru étrange qu’on y préfère les trucs & astuces.
P.S. En bases de données, il n'y a qu'un seul modèle qui a une fondation solide : le relationnel (donc #SQL). Ne pas l'utiliser c'est se mettre une balle dans le pied face à la complexité.