Not all simplifications are abstractions. Not all abstractions are simplifications. But the pursuit of simplification is usually what motivates an abstraction.

Not all simplifications are abstractions. Not all abstractions are simplifications. But the pursuit of simplification is usually what motivates an abstraction. I don’t think that abstractions kill software, or civilization for that matter, but ill begotten abstractions in the name of short win simplifications, puts a drag on the flexibility and agility and approachability of either. Take syntactic sugar in just about any language. There’s usually a breaking point, where you can say the localized gain in simplification for this particular nuance is not worth how complex this tool (language) has become. People don’t make more mistakes in a syntax heavy language because of any particular element, but because using the tool well to solve complex problems just gets difficult (regardless of what a compiler might guarantee you). I look at the complexity that async and coroutines adds to my experience when programming anything “threaded like” in Kotlin compared to how I deal with the same sorts of problems in Elixir/Erlang and it’s just night and day difference. Both have abstractions/simplifications to the age old problem of parallel/async computing, but one (the former) just multiplies simplicities to end up with something complex again and the other has an abstraction/simplification that Just Works(tm) and really is simple.