3 ms·
You can ask these same questions about a lot of things we use every day. Do you have deep knowledge of how your car works, or just a superficial understanding o
by 5teev 15y ago
You can ask these same questions about a lot of things we use every day. Do you have deep knowledge of how your car works, or just a superficial understanding of the basics to keep it running? How about your refrigerator? Household plumbing? Your computer? And how deep is "superficial"?
Another question to ask yourself is, "If it breaks, could you fix it?" And what is fixing it? Swapping parts, fiddling with function params, without knowing exactly what went wrong at a deep level? Paying someone to fix it for you? Is it "understanding" to know whom to pay for what repair?
I believe it is possible to have a thorough understanding of every aspect of every tool we use, but this would tend to limit the extent most of us would build up from it, as time spent learning these fundamentals is no longer available for deriving from them. If we assume humans have limited time and capacity for understanding what already is, it's by necessity that we use certain inventions as black boxes in order to build from them.
Or maybe the question is, "Should you be able to build your own toaster?"
http://www.ted.com/talks/thomas_thwaites_how_i_built_a_toaster_from_scratch.html http://www.ted.com/talks/thomas_thwaites_how_i_built_a_toast...
- hackinthebochs 15y agoThe difference between appliances and tools we physically use and programming tools is that the abstraction for physical tools is necessarily as simple as possible. Cars being one of the most complex tools we interact with, it still has a very basic and well defined set of abstractions to learn. Software tools on the other hand have a way of spiraling in complexity. We're so good at using physical tools because this simplicity allows us to learn their use on an unconscious level, ie. muscle memory. The take home here is that we need to radically simplify the programmming tools we use. Unfortunately the trend towards frameworks rather than libraries is moving in the wrong direction.
- true_religion 15y agoIn the context of the tool analogy, you're right: we should pick libraries and not frameworks. However, many software projects are complex machines---and like real world machines they're made of parts. It'd better then to have a framework because the framework assures you that all these parts ought to work together, or at least have been designed to a certain abstract standard. Imagine building a car but rather than being able to order Ford-fitted parts or Toyota-fitted parts, you'd just get generic parts that you then have to machine yourself in order to make work. Every part, every screw, everything. It'd take tens times as long as if you only had to machine rare parts (e.g. a 1965 engine block to fit a 1973 model frame).