Tell HN: Everything's Abstracted and No One Knows What's Going On

This post is a bit all-over-the-place, but I'll bite. I used to share this belief once. The only gains to be had from intimately understanding underlying structures are to be found in performance optimizations. You don't model a problem space by thinking in terms of what values go into what registers. If that were the case, we'd all be writing web applications in Assembly. Abstractions help us to reason out a solution without getting lost in implementation details. As Dijkstra puts it [0], "In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise." This is why the whole idea of Domain Specific Languages is so interesting. Any loss in flexibility is more than compensated for by the gains made in expressiveness when you can treat low level entities as black boxes.

[0] "The Humble Programmer" - http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340....

I haven't read the whole lecture yet, but you kind of flipped my whole argument on its head. Well done.

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 :)

Look, if you actually understood what an abstraction means, you and the rest of these guys (JoelsSpolsky, I'm looking at you) wouldn't even be pulling the "mightier than thou REAL PROGRAMMER" argument.

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.

Sounds like you have had a bad day, so I won't hold this too much against you.

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.

It's not that I had a bad day, is that you used the age-old "REAL PROGRAMMER" argument, which is and remains, annoying since the 70's.

Me? I write in machine code – in 'raw, unadorned, inscrutable hexadecimal numbers. Directly.

http://www.ee.ryerson.ca/~elf/hack/realmen.html

I was not saying there is such a thing as a "real programmer." I am not sure where you're getting that from. I was merely attempting to spur some debate surrounding the recent trends towards very superficial "innovations" being put forth by many on Hacker News. I am not saying I have the answers to any of these questions. And, I don't think I am better than anyone for thinking a particular way. I just want to learn and try to understand the world around me. That's it.

What makes you think you can't be truly innovative by using somebody else's construction? There are new things to be done by building off of somebody else's work or by starting from the ground up. If you attempt the latter, you can almost be sure that your work will be less fruitful, unless you have some truly unique perspective.

"The only gains to be had from intimately understanding underlying structures are to be found in performance optimizations."

Or, you know, being able to effectively troubleshoot when something breaks or when abstractions leak.

Thanks. Hadn't thought of that.

Abstractions acts as a cognitive tool for you to think about problems and solving them. Whole human civilization is based on abstractions. Numbers are themselves abstraction, other notations based on numbers uses numbers to create other abstractions and so on.

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.

"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."

What 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.

Sorry. I don't mean you should not use any abstractions. I am saying that you must understand what's happening below those high level abstractions to be able to come up with truly innovative solutions to problems. We should definitely continue using abstractions.

"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."

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.

Pretty sure this gets me downvoted to hell, but...

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?

I know what you mean, all I really need is a keypunch, a FORTRAN IV compiler, and a beer.