7 ms·
Builder vs. Programmer Perspective
- Noumenon72 8y agoGood 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.
- suyash 8y agoAgree, the article failed to prove the point. The distinction is still unclear to me.
- pandler 8y agoThe 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.
- deleted 8y ago[deleted]
- sfopdxnonstop 8y agoThe 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 like it. It's a valid critique of perspective.
- mettamage 8y agoI 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.
- walshemj 8y agoI would say that understanding first principals does for example set theory and SQL.
- mannykannot 8y agoAgreed: 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.
- mannykannot 8y agoI 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. [1] https://arstechnica.com/science/2019/02/the-replication-crisis-may-also-be-a-theory-crisis/ https://arstechnica.com/science/2019/02/the-replication-cris...
- Nevada-Smith 8y agoSheesh, take a look at their errata page: http://csapp.cs.cmu.edu/3e/errata.html http://csapp.cs.cmu.edu/3e/errata.html
- zerr 8y agoAny lecture videos based on this book?
- Lt_Riza_Hawkeye 8y agoYes: https://www.youtube.com/watch?v=wVNvEGe2UOA&list=PLPXsMt57rLtjNzxZBDg9xJB7KT83WStBO https://www.youtube.com/watch?v=wVNvEGe2UOA&list=PLPXsMt57rL...
- ninju 8y agoI think a curriculum based upon alternating between builder and programmer would be the best of both worlds. Just one perspective only would be incomplete