While in general I agree with the fundamental issue in this post, I can't help but think each time that people, when they write lists like this, write down the things they themselves know very well. And then call those 'indispensable for all programmers out there'. Yet every single list is different, because everybody encounters different specific details in their careers. I guess the only conclusion is that, in the end, these specific details aren't that important after all. But I do understand that it's hard to admit that - I spend years to get to the relatively detailed level of understanding of the win32 api that I have, yet it's mostly useless now already, and will only get more useless with time. The irrational part of me is bothered by that too.
He says They don’t seem to grasp that one must understand the native environment you’re working in before going ahead and writing a program to run within it.
I thought, or maybe you don't grasp that one need not understand it first, or in many cases, at all.
That is the whole point of abstractions after all.
If I had to write my entire operating system from scratch everytime I wanted to get something done I'd find a different profession.
However, I don't think that's the point being reached. Somewhere out there exists a magical corpus of knowledge that every programmer should be able to memorize from heart. And then there's the world we live in now where you have a corpus of knowledge you do know and can build upon. Somewhere in between is a practical subset of knowledge that should be common but some feel isn't being represented well. The debate rages about what that suitable subset is.
What I think most people who bring this argument up fail to realize is that the full corpus of knowledge that embodies all of programming is far too large for a single programmer to understand. Good abstractions can be trusted to hide the unnecessary details. Great abstractions shouldn't mean piss-poor performance (and should infact provide just the opposite). They also get out of your way (or you avoid using them) when working in the problem domain where your "low-level" knowledge is more useful for the optimizations you can provide to your code.
I'm just not as OCD as some programmers. Yet I can still get good work done. I don't think I could do it without useful abstractions.
Comments
While in general I agree with the fundamental issue in this post, I can't help but think each time that people, when they write lists like this, write down the things they themselves know very well. And then call those 'indispensable for all programmers out there'. Yet every single list is different, because everybody encounters different specific details in their careers. I guess the only conclusion is that, in the end, these specific details aren't that important after all. But I do understand that it's hard to admit that - I spend years to get to the relatively detailed level of understanding of the win32 api that I have, yet it's mostly useless now already, and will only get more useless with time. The irrational part of me is bothered by that too.
He says They don’t seem to grasp that one must understand the native environment you’re working in before going ahead and writing a program to run within it.
I thought, or maybe you don't grasp that one need not understand it first, or in many cases, at all.
That is the whole point of abstractions after all.
If I had to write my entire operating system from scratch everytime I wanted to get something done I'd find a different profession.
However, I don't think that's the point being reached. Somewhere out there exists a magical corpus of knowledge that every programmer should be able to memorize from heart. And then there's the world we live in now where you have a corpus of knowledge you do know and can build upon. Somewhere in between is a practical subset of knowledge that should be common but some feel isn't being represented well. The debate rages about what that suitable subset is.
What I think most people who bring this argument up fail to realize is that the full corpus of knowledge that embodies all of programming is far too large for a single programmer to understand. Good abstractions can be trusted to hide the unnecessary details. Great abstractions shouldn't mean piss-poor performance (and should infact provide just the opposite). They also get out of your way (or you avoid using them) when working in the problem domain where your "low-level" knowledge is more useful for the optimizations you can provide to your code.
I'm just not as OCD as some programmers. Yet I can still get good work done. I don't think I could do it without useful abstractions.