Abstraction: A Critical Analysis
I’m not convinced by the Java concept of abstraction. The analogy goes as follows: a Java class is like a car, you do not need to know all of the intricate workings of the fuel injection, suspension, and steering in order to make the car work. Thus, you only need to know the gas, brake, and basic signaling mechanisms in order to make the car work as intended. I disagree. Abstraction stifles flexibility and usability in the real world and creativity and innovation in the programming world.
Let’s say your car’s fuel line ices up in the winter. With your basic knowledge of the user interface (the interior controls of the car), you have little or no ability to make a diagnosis. However, if you knew more about the car, you would recognize the chugging sound, realize there is ice (and possibly water) in the line, and that you need to add a de-icer. Knowledge of the car increased the usefulness - instead of being stranded on a roadside, you could add some de-icer from your trunk and continue on your way (assuming everything went right). Similarily, in the initial years of programming progress would have been impaired (much as our poor user by the side of the road) if everyone had simply learned the interface of programming. In order to make changes and improve the technology, programmers understood the architecture all the way down to machine code. This allowed them to not only to push the current technology of the time to the limits, but to perceive new and better ways to do the old things. Computing is not currently at a limit, simply at the threshold of the current methods (processing dies and methods are approaching physical limits). The more people we have ascending the ladder of abstraction, the less innovation and more “boxed in” our innovations become. True, twenty years plus of experience may have produced the x86 chip structure - but why stop there? Why accept that architecture as the most basic - as a ladder of abstraction not worth descending - and ultimately stagnate?
Some would say the point of abstraction is for beginners, that the concept is only so the novice can learn things and implement them quickly. I agree that abstraction has its time and its place, I myself use it quite regularly when revising the backend of this site in PHP. I do not understand how the eregreplace command works in PHP. However, if I were a large site administrator and I was stuck by the metaphorical side of the road with a hanging server, I might research and discover that the “Perl-compatible” syntax pregreplace is faster. Understanding how the original eregreplace command worked in the first place and therefore being aware of the alternatives would have saved time and money from the beginning. The information of _why things work is invaluable.
People are declared “experts” in a language far too quickly. Mastering syntax, efficient logical structure, and robust design is, I believe, only the beginning (and a claim I would not make on any language - including English). If abstraction were given less emphasis and the value of a lower-level understanding reinforced more, innovations would be given a more friendly environment to enter into.