So, basically Sturgeon's law, where 80% of everything is crud, and now we got a huge crud heap, but also lot's of shining gems besides it? I'm not that sure ab

So, basically Sturgeon's law, where 80% of everything is crud, and now we got a huge crud heap, but also lot's of shining gems besides it? I'm not that sure about that, mostly because I'd say that the actual quality of something is orthogonal to the featuritis exhibited quite often. For one, all the shiny new features of something might actually be very good. And a change breaking compatibility might be the good design choice - getting it right the first time or having to drag Sisyphos' rock along for eons shouldn't be the two possible outcomes. It's a trade-off, especially when you consider the other 80/20 split here, where 80% use only 20% of features, but different 20%... In our days of easy release cycles (just tag a release, finish a sprint etc.) and easier communication (issue trackers, emails, social media) and contribution (open source, pull requests), we're just upstreaming more workarounds and library additions that would've happened in your local projects. I have an easier time accepting this in libraries. They're malleable, maybe even ephemeral objects you handle when working on your project. Maybe a bit loosey-goosey these days, never mind the tendency to hop between frameworks/libraries, but well, we never got our true component system where you can just extend existing libraries that then remain untouched. But languages operating in the same way still rubs me the wrong way. I'd prefer to have a more solid foundation, not mutating turtles all the way down. But after C++ unleased the feature genie, it's hard to put it back into the bottle again.