I liked this part about thinking of your codebase as a database: "Now close your eyes and imagine your codebase like a database - some imaginary glowing networ

I liked this part about thinking of your codebase as a database: "Now close your eyes and imagine your codebase like a database - some imaginary glowing network floating in cyberspace - and then imagine your ‘program’ as a ‘query’ of sorts that zaps around this network." This is similar to what you get with logic programming languages like Prolog: A Prolog program is itself like a database, in that you define facts and rules that you can use to define the relations you want to express, and which themselves can also be readily inspected and reasoned about with the same mechanism. For example, we can define the predicate member/2 to state under what conditions an element occurs in a list: member(E, [E|_]). member(E, [_|Es]) :- member(E, Es). And then we can use the relation to ask queries about what is true: ?- member(X, "abc"). X = a ; X = b ; X = c ; false. And we can also inspect the definition itself, using clause/2: ?- clause(member(A, B), Body). B = [A|_A], Body = true ; B = [_A|_B], Body = member(A,_B). This ability to readily reason about the code itself is very attractive to analyze and rewrite the code. I also like the premise of the article: "Software complexity is starting to outpace the human ability to keep track of things." And indeed: There is hope that several kinds of problems we are facing today can be avoided if we are able to more easily reason about the code itself. For example, by running the code "hypothetically" and analyzing its consequences, we may be able to automatically detect certain classes of errors and failures before they happen in practice. For instance, I often think about software problems such as those described in https://en.wikipedia.org/wiki/British_Post_Office_scandal https://en.wikipedia.org/wiki/British_Post_Office_scandal, and wonder: Can they be avoided by analyzing the software itself in better ways, and by writing it in such a way that we become able to "ask" the program itself: "Can such a problematic case even arise in practice?" Thus, in analogy to querying a database, we could pose and resolve questions about computations and their logical consequences.