> The moral of the story is that in formal systems, how you express problems impacts what problems you can solve. An interesting exercise many programmers don'

> The moral of the story is that in formal systems, how you express problems impacts what problems you can solve. An interesting exercise many programmers don't do but should is to program purely in paradigms other than imperative OOP. The solutions you come up with are very different when you don't have objects, for loops, and if statements in your language's vocabulary. Try writing a real program in Prolog or SQL. Not just database calls to retrieve data, but an actual full app with a UI and user interaction and network calls and all the rest. You will likely feel like a novice programmer if you haven't trained your brain to think in set operations like union, join, intersect, etc. When everything in your program is a set instead of a stateful objects, you do set operations over them instead of method calls. That's uncomfortable and disorienting at first. As for the article, I didn't get much from it past the bit I quoted. FWIW that PG quote is fully out of date; I do not associate Python with programmer competency. The first thing I ask when a programmer says they know Python is "What other languages do you program in?", because I've come across far too many Python programmers who can't tell a stack from a heap. YMMV