Python's "easy to use" is just a lie, https://github.com/satwikkansal/wtfpython
The common lisp CFFI module is nothing short of Python's.
But, I know, people hate to put their `(` in front of their function names, and people hate to omit `,` between there function arguments.
There are many design errors in Python, of course. But most "wtfpython" things don't actually affect people using the language -- they're engineered to identify funny compiler optimizations and floating-point peculiarities. The real problems of a language aren't usually the kind of thing demonstrated in a couple-line snippet. Though there are exceptions.
Most languages are easier than C++, and many of them are faster than Python.
Plenty do though. I've passed that page onto co-workers a lot, back when the list was smaller, and almost every time they've found something on the page that explains a bit of weirdness with Python that they'd just dismissed as buggy behavior and avoided touching.
The ones I remember them mentioning:
https://github.com/satwikkansal/wtfpython#-mutating-the-immu...
https://github.com/satwikkansal/wtfpython#-beware-of-default...
And I multiple times I've had to explain the difference between references / shallow copy / deep copy to bootcampers, which falls under https://github.com/satwikkansal/wtfpython#-a-tic-tac-toe-whe...
Shallow/deep copies is an unavoidable part of having mutable data. The main alternative way to handle mutation is a fancy type system like Rust's, which is not an acceptable tradeoff for new programmers.
It was nothing of the sort; the claims would have landed on deaf ears if Perl didn't genuinely suffer maintainability problems due to that approach.
> dubious claim's of sigils (`@$`) hurt readability
AIUI the (admittedly limited) scientific data that exists supports that.
> But once Python had the ecosystem going, it brought back `@`, `{}`, numerous `_`, fanciful `:=`. And, of course, there always is more than one way to do it in Python.
You present this as some kind of bait-and-switch, but it's nothing of the sort; no-one's happy about the use of @ or := (I don't know what you're talking about regarding {} or _), but they were least-bad compromises for things that were felt to be needed. Multiple ways to do something is still seen as a bad thing - "There should be one-- and preferably only one --obvious way to do it" is the standard Python phrase, acknowledging that having only one way is an aspiration that can't always be fulfilled.
> Python's "easy to use" is just a lie
Nonsense. Like every language it's accumulated some warts, but it's still the language beginners find easiest to learn and teachers find easiest to teach.
> But, I know, people hate to put their `(` in front of their function names, and people hate to omit `,` between there function arguments.
Wow, way to conform to the Lisp stereotypes. If the problems of Lisp were actually that superficial, don't you think there'd be someone who'd produce a Lisp with a more familiar syntax and reap the popularity gains? Is every single Lisper really too haughty to make a trivial syntax change?
I believe that the overwhelming factor of why something does or does not become popular is simply chaotic luck.
In an alternate history where Python was designed exactly the same, but a butterfly at Guido's desk flapped his wings slightly differently, Python would have been obscure.
This seems to me a bit like saying, "That color isn't cerulean, it's blue." Describing the specific instances of serendipity that have led to Python's continuing success doesn't imply that it wasn't dumb luck. It's just a way of saying, "Here's an interesting bit of dumb luck."