"So new languages with different abstractions come along and things are simpler to do in it. That simplicity is then used to build even more complex things, which then expose how the abstractions doesn't work in the formerly new language."

This is true for mathematics, but not in the same way for computer languages, because we haven't unlimited computing power and memory space.

Yes, with a more abstract language you can solve a problem easier on the implementation, source code side.

But with every abstraction you're loosing flexibility, because to get an abstraction you're putting the lower parts in a concrete combination. Thus every abstraction has it's costs.

Yes, you could use two computing languages, one for the performace/memory critical part, and one for the other parts of the programm. But in practise it's not that easy to combine the two.

There's a reason why people are still using C/C++.

> But with every abstraction you're loosing flexibility, because to get an abstraction you're putting the lower parts in a concrete combination.

I don't think this is true. You might lose some, you might get some, in a different place, with greatly lowered brainload.

Or are you going to argue that lisps are less flexible than C?

C is more flexible on the performance and memory usage side.

That's my point. Abstractions are great, I love Lisp and Haskell. The problem of more complexity isn't completely solved by using better abstractions, because you still need to look at the performance and memory usage, as long we have a limit there.

Note that I didn't state that there would be MORE abstraction, only that it would be DIFFERENT abstractions.

You can have different abstractions compared to what C has and still retain the granularity of control you want.

"Note that I didn't state that there would be MORE abstraction, only that it would be DIFFERENT abstractions."

That doesn't makes sense. What should be a different abstraction of C? If you've an other syntax for the C pointer arithmetic it's still the same abstraction.

If you can do still the same things, then it's still the same abstraction. You can only combine multiple abstractions in one language, but I think that's not a good idea.

"You can have different abstractions compared to what C has and still retain the granularity of control you want."

I don't think so, because you would add the complexity of both, the higher abstraction parts and the C parts. You would generate a language which is harder to master than their component parts.

are you arguing that lisps are easier than c?

No, though I don't even see how you could disagree.