[hutzlibu]

"It's not a simple - just put more abstraction."

Of course not. It is about the right level of abstraction.

Abstracting all the details away, I do not need to accomplish the task at hand.

If done right, this also will not slow things down, rather the opposite. Imagine programming a button in assembler and opengl. There you have all the details (and power). But chances are, you will be way slower and with a worse result, because you have to focus on other details and not on the task at hand.

[salawat]

Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing.

At best, it allows you to defer the deeper reading for a time. You might not even have to do the deeper reading for this piece of functionality, but the time will come when you have to figure out where an impedance mismatch is.

This quest for abstraction is the most infantile attitude I straw to squash in ever developer I meet. If you aren't reading the code that your code depends on to work, you have no idea what you're actually doing.

[hutzlibu]

"Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing."

Erm, a beginner who wants to place a button that calls his defined method foo, really does not need to know about all the framework details to get the job done.

When I was a beginner, I was happy that I could place a button and link it with whatever with ease and it worked!

I simply did not needed to know about event loops, rendering algorithms, or internals of the framework. Now I happen to know quite a lot about it, because I designed a UI framework from scratch to solve a custom need.

But most use cases with UI are to display text, images and give text input and buttons. Ordinary programmers should be able to do that, without having to learn the graphic stack. Thats why we have frameworks. They just could be easier with better tooling.