The distinction was clear to me with the first example. A book could teach me how to implement memory caches and addressing (builder) or could teach me the impact of programming against memory caches by controlling my memory addressing.
I agree that’s what I took out of it as well. The builder perspective is learning to design and implement from first principles, which isn’t very practical according to the author because most of the information will not be used in day to day programming.
The perspective the author is arguing for is understanding the principles behind how systems under the hood impact day to day programming.
An example: you don’t care about how transistors work, unless you want to understand rowhammer. One theory I heard is: it works because small transistors get their electricity leaked away to bigger transistors that are reading out memory millions of times. Another: you don’t care about creating a game in assembly (hello Rollercoaster Tycoon!), but you do want to be able to read assembly with regards to do compiler and/or performance analysis.
I wonder whether people agree with my examples or disagree.
Agreed: theory doesn't matter - until it does. The implementation of abstractions doesn't matter - until the consequences of the implementation leaks out as observable behavior.
I think you could take the authors' example and use it to argue the other way. They say that, in this case, the important thing for a programmer to know is which of two patterns of memory access is faster, not why it is so, and, up to a point, this is reasonable. If, however, you try to do a complete education along these lines, you will end up with thousands of rules to memorize, with little rhyme or reason, and all of them having a bunch of corner cases where they don't apply and priority rules about which takes precedence. In my experience, understanding why things are the way they are is the key to remembering how they are, and in recognizing which issues are relevant to a particular case.
This reminds me of an article I read recently about science's replication crisis: if you don't have a theory, it said, any outcome is plausible [1].
Of course, it would be difficult to understand hardware and OS design if you had no idea what they were used for, but I do not think that is an actual problem in current CS curricula.
Good headline. The article would have been more interesting if it had played up the contrast between two perspectives, the way you framed it, instead of spending all its time on the programmer's perspective.
The distinction is that teaching how to build a car from scratch (builder) doesn’t teach you how to drive it any better (programmer). The proposal is to teach programming with “assume you have a car/compiler/filesystem” instead of always starting from first principles.
I think a curriculum based upon alternating between builder and programmer would be the best of both worlds. Just one perspective only would be incomplete
I like it. It's a valid critique of perspective.