abstraction isn't inherently a bad thing, it's what gives us the tools to reason at a higher level. It's leaky abstractions that are the problem.

Proper abstractions are supposed to compress large bundles of information into a smaller set of [broad] concepts, which then imply all the large sets of details they're abstracting away. High level languages are pretty good abstractions on top of raw assembly code for example, because you don't have to think about what the assembly for your java code is going to look like, it's already implied that it's going to work.

As for react, I'm also not a huge fan, but that's because it's still a relatively leaky abstraction that comes with a lot of the same baggage as plain js+html+css. Especially when compared to a fuller abstraction like Elm[0]. But even that's still lacking a complete abstraction of html/css stuff. And that's not even taking the leaky abstractions on the backend side of the equation into account:

http://haskell-web.blogspot.com/2014/04/towards-deeper-integ...

[0] http://elm-lang.org/

I think where a key abstraction was lost was when JavaScript became the language you had to compile to if you wanted to do web development. Biggest hope I see on the horizon is WebAssembly, which has support of many big players but I've heard very little on it recently.

Ref: https://medium.com/javascript-scene/what-is-webassembly-the-...

But then you still have the following hack offenders:

* DOM,

* HTML Layout,

* CSS,

* A small variety of crappy events ( onDomLoaded ),

* a fairly rubbish heavyweight communication layer ( AJAX )

* Keyboard bindings that never work cross app, never cross platform

* Accessibility ??

* No idea of the energy impact of your code

* No ability to do queries on important device metrics ( energy consumption, clipboard, user presence, login / logoff, single sign on )

* History management and back button mess

Abstractions make things more complicated? I think you're missing the basic definition and purpose of abstractions. So how do you define "almost"?

I think the correct term is complex. Abstractions make things more complex, as there are more moving parts. This normally leads to complications when trying to debug some obscure error that you will get when the project gets bigger. At that point you feel for calling on some ancient deity to spite the developer who decided to use this framework 6 months, until you remember that you proposed it as replacement for the last pile of abstractions to hide the failings of the platform. (Yes there is plenty of sarcasm in here :P )

Which is more complex - an apple or an internal combustion engine?

Tis a trick question. The actual complexity experienced by humans depends on the job they are trying to do with the object. If you are a botanist/arborist driving to work, then clearly it is the apple. If you are a mechanic on your lunch break, then clearly it is the engine.

Inherent complexity is often ignorable, but bugs can and will sit anywhere. So, yea the fact an apple is vastly more complex than an engine is not always relevant, but when it is relevant you have real issues.

Bugs are much more likely to be in the apple.

A good abstraction hides complexity without adding major tradeoffs. Presumably an abstraction makes it easier for a developer to reason about what is going on.

It's true that abstractions can lead to a lot of trouble when they are failing to work correctly. But when they are good they add a lot of good value. When did you last have to debug a system call, because you couldn't open a file? There are really good, old abstractions that no one thinks about anymore, since they're just really good.

A framework in web development is of course another matter, where complexity can sometimes be staggering. I believe that the lifecycle of React components is really nice. Instead of initialising X things you can think about how a single component will change over time.

There are endless examples of good and bad abstractions, I guess. But at the end of the day, we have to choose abstractions when we need them to reason about what we're doing, despite adding more points of failures.

After all, if an abstraction just enables us to think faster and more clearly about a problem, AND allows us to write less code, that means that less bugs will be in the final product, assuming that the density of bugs is constant. ;)

I'm glad you added the qualifier "almost" because, even in low-level C, you're typically sitting on about 4 layers of abstraction:

C -> ASM / byte code -> machine code -> primitive CPU operations

That's what I'd call a good abstraction. You can write in c, debug in c and very rarely (if ever) be forced to know what the lower layers are doing.

All these javascript and css transpilers however, they force you to know the higher level, the lower level and many of the intricacies of how one translates to the other.

Abstraction is the foundation of modern modern computer science. I mean would you prefer writing in assembler rather the a higher level programming language ?

Maybe?

The dillema is that you need to understand the low-level aspects in order to understand the abstractions.

The problem that haunts me -and a lot of other hackers I presume- is that we have this urge to understand every little detail of the systems we design. Nothing is good enough.

The other problem is that by using arcane and primitive tools we limit ourselves in the ability of producing real work. As with everything in life, we need to make the distinction between tinkering and doing real work.

If all we do is tinker, very little gets done :).

PS: I just read the satire Real Programmers Don't Use Pascal [1], my comment could be highly biased from that.

[1]: http://www.pbm.com/~lindahl/real.programmers.html Bonus: Here is a little bookmarklet I wrote for styling unstyled html pages for easier reading.

  javascript:(function() { document.body.style.maxWidth='700px'; document.body.style.margin='0 auto'; document.body.style.lineHeight='1.5'; document.body.style.fontSize='20px';} )();

So I assume you write all your programs without the benefit of an operating system then.

Didn't HN have a thread where someone wrote a CMS site in assembly? It sounds crazy, but if it can be done, someone will do it.

Yes, you can do it, but the drawbacks are huge and obvious.