It looks like there's a follow-up to this blog post. Although I can't seem to figure out how to get to it, the link is broken http://rubyhacker.com/blog2/...
Interesting followup. Not sure if I agree that the situation is analogous, though. The boundaries between the tool smiths and the tool consumers is a lot thinner when it comes to software. Take...
Interesting followup. Not sure if I agree that the situation is analogous, though. The boundaries between the tool smiths and the tool consumers is a lot thinner when it comes to software. Take JavaScript for example. One can start out as a consumer of JS frameworks, and over time build up knowledge of fundamental JavaScript and the problems that frameworks try to solve. A couple peaks at any of the million open source repos, a few google searches for guides, and one can figure out how to write a JS framework of their own. This goes for any programming language, really. HLC (to use his term) and CS speak the same language, literally. But EE and low level software don't relate the same way. I don't think being good at OS level programming leads to an understanding of how to structure chips.
I feel that it comes back around to the idea that a lot of modern software development revolves around connecting 3rd party libraries together. Which isn't a bad thing in and of itself. Why waste...
I feel that it comes back around to the idea that a lot of modern software development revolves around connecting 3rd party libraries together.
Which isn't a bad thing in and of itself. Why waste time writing your own software to reinvent the wheel when it's already been done for you? It just leads to a lack of understanding of the underlying functionality.
I agree with that statement, I just disagree with the analogy to EE vs CS. If you are curious and delve into sources, you can go from gluing things together to understanding the fundamentals. But...
I agree with that statement, I just disagree with the analogy to EE vs CS. If you are curious and delve into sources, you can go from gluing things together to understanding the fundamentals. But I'd argue it's harder to go from understanding CS fundamentals, to understanding EE fundamentals.
It looks like there's a follow-up to this blog post.
Although I can't seem to figure out how to get to it, the link is broken http://rubyhacker.com/blog2/http://rubyhacker.com/blog2/computing/0071-ok-its-not-really-a-lost-art/index.htmlInteresting followup. Not sure if I agree that the situation is analogous, though. The boundaries between the tool smiths and the tool consumers is a lot thinner when it comes to software. Take JavaScript for example. One can start out as a consumer of JS frameworks, and over time build up knowledge of fundamental JavaScript and the problems that frameworks try to solve. A couple peaks at any of the million open source repos, a few google searches for guides, and one can figure out how to write a JS framework of their own. This goes for any programming language, really. HLC (to use his term) and CS speak the same language, literally. But EE and low level software don't relate the same way. I don't think being good at OS level programming leads to an understanding of how to structure chips.
I feel that it comes back around to the idea that a lot of modern software development revolves around connecting 3rd party libraries together.
Which isn't a bad thing in and of itself. Why waste time writing your own software to reinvent the wheel when it's already been done for you? It just leads to a lack of understanding of the underlying functionality.
I agree with that statement, I just disagree with the analogy to EE vs CS. If you are curious and delve into sources, you can go from gluing things together to understanding the fundamentals. But I'd argue it's harder to go from understanding CS fundamentals, to understanding EE fundamentals.