Everything happens for some reason if we want to be pedantic.
I think the point was that some things do not justify their complexity. Especially if you discount inertia.
Trivial example: the creat function could have been named create. That's one more thing folks just have to know and the reason for it isn't much better than "just because".
>I think the point was that some things do not justify their complexity. Especially if you discount inertia.
Again, can you provide an example? Because like you implied, tools like node.js and npm, were made with a purpose. They are professional tools made for professional programmers to solve commercial problems. They aren't made for beginners and novices to teach them about programming concepts. Their complexities stems from the fact that they need to support all kinds of deployment and runtime use-cases and can't be too opinioned on how they should be used.
>Trivial example: the creat function could have been named create
It's a trivial example, but a valid one. Those sorts of "it works great as long as you remember..." things are complexity, often unneeded. There are more severe examples of this involving frameworks with assumptions being too hardcoded (or softcoded!) as well.
Some are essential complexity, sure. But many aren't.
Oh come on. You're complaining about a function name (created decades ago) in a system level language as an example of 'needless complexity'. That's not complexity - that's just a quirky name kept around for backwards compatibility. By the way if you don't like 'creat' or find it difficult to use then don't use 'creat' use 'open' with the relevant flags. Any complexity around C programming does not come from this ... Honestly.
I have yet to see someone actually point out a good example of needless complexity in programming - something that the blog author is complaining about that apparently you agree with but cannot come up with a single reasonable example.
Which part is over-complicated for no reason?