Whatever you save in avoiding having to write "sum = add(l, r)" is not worth allowing programmers to bitshift file handles[1], divide file path objects[2], or subscript objects to launch a process[3].

[1] https://en.cppreference.com/w/cpp/io/cout

[2] https://docs.python.org/3/library/pathlib.html

[3] https://pypi.org/project/plumbum/

C++ "bitshifts" (yes, but it's just a symbol in this context) make no real difference to me. It was type safe when it wasn't easy to be back in the day, everyone knows exactly how they work - it's never shot me in the foot (whereas the real meat of the design has, independently of how the composition is expressed syntactically).

The others are more sus but you can make a bad API out of anything.

Rewriting (say) a load of calculations as a tree of sum pow exp etc. is just a huge burden - a codebase I work on has a formula that takes up about 6 lines for example, outputted by mathematica: total pain to to translate to function calls.

> The others are more sus but you can make a bad API out of anything.

Yahhhh but there's something about operator overloading that is like catnip to clever programmers. Ah ha, file paths have slashes, and the divide operator is a slash! Clearly I should use the divide operator to append paths segments together! I'm so clever! Ah ha, << looks kinda like an arrow I guess, so we can use it to, uh, pass data between objects, I guess. I'm so clever...?

It's irresistible. We have abused it and we must give it up for the good of all.

Just because some library writers abuse language features, that doesn't mean everyone else who uses those features correctly should be punished.

[2] pathlib

I quite like that one but I'd be willing to give it up for the hobgoblin of my little mind.