Hacker News new | ask | show | jobs
by wwweston 4152 days ago
> Abstraction is dangerous

True statement. Of course, it's more or less true, depending on how much the abstraction you're using leaks. Few (if any) abstractions completely encapsulate complexity, almost all will leak. But there's a range. Some abstractions elegantly cover a modular portion of your problem space and do it so well you only rarely have to think about what's going on under the hood (and will even produce effective clues as to what's going wrong when something does go wrong). Some abstractions awkwardly cover only part of a modular portion of your problem space, require a high intellectual down payment to even start to use, have gotcha cases that chew up performance or even break things, and require continual attention to what's going on just to keep development going.

Most are probably in between.

I think this is what JWZ is talking about in his famous "now you have two problems" assessment of regular expressions. I don't read him as saying "regular expressions suck," I read him as saying anything but tools from the high end of the abstraction quality spectrum means now you have two problems: (1) the problem you started with (2) the problem of keeping the model/details of how the tool works in your head. Regular expressions are arguably in the (maybe high) middle of the spectrum -- they may not cover your case well (ahem, markup) and they can send your program's performance to hell or even halt it if you don't know what you're doing.

Now, they're also broadly useful enough in all kinds of development that the benefits go up with the costs and so they're probably worth investing in anyway, as part of a suite of other parsing tools/techniques. So I'm not bringing the topic up to bash them.

But to take us back to the topic, I might be bringing it up to question the ROI of popular JS frameworks, which, as far as I can tell, are generally not at the the high end of the abstraction quality spectrum, don't have the broad usefulness of regular expressions to recommend them, and may not even survive longer than a handful of years.

1 comments

No, it's not a true statement. It's fundamentally wrong. Because if abstraction is dangerous, we should all be laying out transistors by hand instead of writing code.

People get so comfortable with their familiar abstractions that they forget they're still abstractions.

Taking the article as an example, even his "less abstracted" examples are absurdly abstract, and I doubt anybody here can really say for sure how they work completely, underneath all the abstractions. That's a good thing, because it lets us get things done and express ideas in hardware-independent ways.

Abstractions are dangerous - if you abstract wrong, your code is potentially worse than the unabstracted version since it is easy to impose an abstraction where there is none, but a poorly abstracted component is harder to correct.
ANYTHING done wrong can be dangerous,abstraction or not. The problem isn't abstraction but "poor code",whatever it means. spec writers chose to go with the DOM,which is a poor API and it led to things like DHTML because DOM just sucked. It was clearly not made for what devs are doing with the web today,thus the need to abstract a bad API with a framework or a library.

I bet you don't write web apps adding DOM nodes to the DOM document.You're already using an abstraction if you're using any DHTML api.But you didn't know that.