A lot of people start out with shells and end up being unable to understand how to construct a switch or adder in logic gates. A shell is a great tool but shouldn't be a crutch.
A lot of people start out with shells and end up being unable to understand how to construct a switch or adder in logic gates. A shell is a great tool but shouldn't be a crutch.
At the same time, I know that's extremely unreasonable to expect. I guess for the shell and editor, you can argue you ought to understand it stripped of abstractions, since it's actually the level you're working at, while most people don't work at the logic gate level.
The usefulness of knowing the whole stack has diminishing returns though.
It can be helpful in a large company where I can make connections that others can’t, but in a small company it’s less relevant unless I were solely focused on one specific connection (say, how machine learning using math as designed in an ALU inside a CPU or GPU is ludicrous—go analog and get four orders of magnitude speed up, all that time waiting for carry bit propagation, yuck!)
Your time is probably better spent learning to be a good generalist or specialist in your field, rather than knowing inside so many layers of abstraction.
It doesn't go all the way down to the physics of semiconductors, but it goes down to logic gates and all the way up to tetris (there's a related course/website called nand to tetris: https://www.nand2tetris.org/)
If you want to go further down, check out Jeri Ellsworth's old videos where she built a transistor at home: https://www.youtube.com/watch?v=w_znRopGtbE
It starts at boolean logic and works up to a web browser and then some other stuff.
Edit: It's a high level covering of each topic of course, it does have to fit in a book. It's ~444 pages.
cf. https://www.pbs.org/show/crash-course-computer-science/
No, it won't give you the level of understanding that an actual comp sci/engineering degree will (after all, it's just a couple dozen ~10 minute videos), but it does touch on all the major concepts and through the series builds on concepts presented earlier.
However, that's exactly the path every Electrical & Electronics Engineer classically took.
Most people in my class ended up at the top of the stack (operating systems and software engineering) since the jobs are more numerous and the pay is better.
We could also make the opposite argument for any level of abstraction: can you really say that someone who buys apps for their iPhone and runs them is less of a programmer than someone who actually programs? If programming is just getting a job done, and being a good programmer is just picking the right tool to get the job done...
The real question is pragmatic, not theoretical. Does your dependence on a tool sometimes make easy things impossible or encourage misunderstandings about lower level processes that lead to bugs or inefficiencies? Is it simply too big or expensive to run in all of the places you might want to program? Does the tool make up for that lack of flexibility with increased productivity? Those are real questions that you can ask about any specific tool (including the shell.) It doesn't mean anything to ask them about tools in general, and the idea that sacrifices and benefits must all come out even in the end is just the law of averages.
Perfect world, you know everything.
In reality, you can't and don't need to. Knowing some shell stuff will be useful for most if not all programmers.
I think my chances of ever understanding what Symbiflow does are quite small, but that is a shortcoming on my side :D
And even if I do, I have to learn semiconductor fabrication next!