I've been programming for a long time now, close to 40 years. Back when I first learned programming "top-down programming" was the rage. This essentially means you take your top-level functionality, and break down that into steps, each of which become its own module, and you keep decomposing each step into substeps unto you have code.
There was a particular Zen, a flow, about top-down programming. You roughly knew the next thing you should work on, and the conceptual stack of things you had to remember were tracked easily by the stack of procedure names.
This is fairly close to what the author is talking about. "OO design" has been a disaster, but as a basic tool of coupling data with behavior, it works fine. If a class happens to match a real-world thing, well that's just a coincidence. A programmer's job is to get the computer to do what you want, not somehow model the world.
At the same time, the right abstraction can make all the difference. While tactically, my process is very similar to the author's, what turns workmanlike code into true craft is finding the right concept that dramatically reduces cognitive burden on the programmer.
In that 40 years, you will have seen all sorts of things come to the fore and then fade back into the background as the next "big" thing comes along. What most have not seen is that these are tools that we can use to solve the problem-space problems placed before us. The point about abstraction and choosing the right abstraction for the problem at hand requires each of us to be able to communicate clearly with the problem domain subject matter experts and understand what they need from us.
Understanding what kinds of abstractions are available to us and how to apply is important. There is a proviso however, and this is where even though two problems may seem to be similar and could be usefully use the same abstraction, one must understand the problem space ramifications of those abstractions as the divergences can often come back and bite you.
Over the decades, many tools have been developed and each of them has some use in our toolbox, whether it be top-down design, bottom-up design, refactoring, objects, values, functional programming, assembly programming, static typing, dynamic typing, etc., etc., etc.
They do not have universal application, unless of course, your favourite is a hammer and everything is a nail. These tools allow us to solve different kinds of problems in a less laborious way.
If anything, the last forty years has shown me that, as a whole, each generation of programmers is unable to learn from the previous generations. We get so caught up in our various wars over which languages or techniques are the bee's knees that we often forget that we are supposed to become craftsmen and craftswomen, able to solve the problems placed before us using whatever tools are available.
Each of us will have favourite tools, but we had all better be prepared to be competent and pick up whatever tools we are given and solve the problems before us.
Agreed. Something that got lost in the JavaEE world was that design patterns are there to make the problem easier to solve by leveraging the solution to a similar problem. Instead, many JavaEE programs are just class after class after class all starting with the same prefix and having some new verb attached to the end like "Manager"
>A programmer's job is to get the computer to do what you want, not somehow model the world
This so exactly mirrors an ongoing debate in cognitive science. Programmers and philosophers should be talking about representation versus affordances and situated cognition. Actually I suppose the same thing goes back to Chomsky vs Skinner.
I think C++ classes and templates are incredible for data structures.
In the java world, people try to make their entire program out of data structures, even complex data transformations, and unfortunately it ends up being a disastrous case of square peg in round hole.
What also helps immensely is the fact that C++ supports free functions. Free functions + templates allows for generic logic which is separated from the data they operate on, something Java doesn't allow in any remotely easy way. Yes, there are utility classes with static functions, but that is just horrible.
There was a particular Zen, a flow, about top-down programming. You roughly knew the next thing you should work on, and the conceptual stack of things you had to remember were tracked easily by the stack of procedure names.
This is fairly close to what the author is talking about. "OO design" has been a disaster, but as a basic tool of coupling data with behavior, it works fine. If a class happens to match a real-world thing, well that's just a coincidence. A programmer's job is to get the computer to do what you want, not somehow model the world.
At the same time, the right abstraction can make all the difference. While tactically, my process is very similar to the author's, what turns workmanlike code into true craft is finding the right concept that dramatically reduces cognitive burden on the programmer.