I think the article picks the wrong pure / impure dichotomy. Much more interesting to me is the split between people who want to abstract the application domain and people who want to engage with it. To the former, a CRUD app is a CRUD app. To the latter, CRUD is still a useful framework, but it’s just a tool that’s subordinate to a bigger purpose. Or take game dev; the decision to go deep on game engine design can be driven by your opinions about shipping versus tinkering, or it can result from having a game in mind and picking the best way to realize its mechanics. CS attracts a lot of abstract thinkers, and CS degrees reinforce the abstraction of the application domain, so I find that a lot of programmers take it as a point of pride that they don’t engage with it.
It’s probably clear where my sympathies lie here, so I’ll balance that by saying something nice about abstraction: it really can help you see the problem more clearly. It’s a great tool to avoid solving the same problem over and over again. Just make sure you’ve correctly identified the problem first!
> the split between people who want to abstract the application domain and people who want to engage with it
That sounds like the classic dichotomy of Theoria and Praxis.
> The philosopher Aristotle held that there were three basic activities of humans: theoria (thinking), poiesis (making), and praxis (doing).
> Corresponding to these activities were three types of knowledge: theoretical, the end goal being truth; poietical, the end goal being production; and practical, the end goal being action.
I can see these aspects exist within an individual, and as a group such as the academic field and practical culture of computer science.
There's a temptation toward theory building, elaborate architecture and systems, abstraction for the sake of it. The field is richer for it, but it's also a risk of distraction and source of incidental complexity.
The call to action, to return to the making at hand. Working with the material, applying the ideas in practice, keeping what works and throwing out what doesn't. Learning through doing. Sometimes the solving of a problem or need is achieved first, then the pattern is recognized, the ideas and theory to explain why it works.