Tell HN: Everything's Abstracted and No One Knows What's Going On
Relatively speaking, there are a very few number of people who truly understand the underlying technologies, libraries, processes that are being run when they utilize abstracted interfaces. Those abstracted interfaces, by their very nature, remove functionality; or at least limit it. Abstraction targets the general purpose use; not every possible use or niche use.
Yes, abstractions are great at making complex tasks easy to implement reliably and quickly in most cases. But, I am not talking about most cases. I am talking about the need to innovate. To make truly innovative things, you must break those things down to their base components, and rearrange them at the core. You can't do that using high level abstractions.
Hacker News is filled with people whining about how innovative they would be if just given the chance. But, they just keep doing the same old, tired rehashes of the same things. Why? Maybe they aren't looking for the right problems to solve. Or, maybe they don't know what's really possible, limiting their ability to think of innovative solutions.
I guess the point I am getting at with all of this, is that perhaps we should all try a bit harder to try to understand what's really going on when we use those libraries and abstractions we have come to embrace so much.
15 comments
[ 5.4 ms ] story [ 66.1 ms ] threadWhat the? How did you even reach that conclusion? That's a fallacy. It's all an abstraction, all the way down to machine code, like it or not.
Things are worse than you say!
Everything is not just abstracted, but most things are abstracted half-assedly. And we've raised a generation of people where the majority (though not all) have learned only the half-ass abstractions.
The end result of all of this is personified in things like serious discussions about JavaScript being the "assembly language of the web".
ohgodwhy?
[0] "The Humble Programmer" - http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340....
I still think it's helpful from time to time to think a bit deeper about the details of what's actually happening below the top couple layers of abstraction, though :)
You know what debugging is? It's patching up the leaks in abstractions. Thus, we all think about what's behind the abstraction pretty much every working day.
Ya'll soap-boxing is annoying the fuck out of me.
I suggest you not take all of this so personally.
Have you read the lecture that okal posted the link to? It's from the early 1970's and speaks to the early days of when abstractions were first being implemented for computers in general. Perhaps it is you who does not understand what abstraction means.
Me? I write in machine code – in 'raw, unadorned, inscrutable hexadecimal numbers. Directly.
http://www.ee.ryerson.ca/~elf/hack/realmen.html
Or, you know, being able to effectively troubleshoot when something breaks or when abstractions leak.
The answer to the question is "follow the money".
People don't get paid to learn the inner workings of something. They get paid to do stuff that produces results even if they do it in the worst possible way. Except for a rare few companies (who usually are very good at what they do but are rare), the incentive to make things better does not exist.
The short and even medium term payout of deeply learning the inner workings of something is very small. The people who decided that are the ones with the cash and cash is what most people follow.
As far as coming up with innovative idea is concerned, if you start digging into abstractions and taking things apart at low level, you will be overwhelmed with so many concepts that you wont be able to see simple patterns and solutions and will be tied up in the complexity because of the limitations of human brain.
We build abstractions to overcome our brain limitations and still be able to innovate.