1: Simple is better than complex.
2: Beautiful is better than ugly.
3: Readability counts.
Winners across many markets seem to get the importance of simplicity. Compare the Google homepage to the Bing homepage. The dashboard of a Tesla to that of a Volkswagen. Remember how hardcore lean Facebook's UI was compared to MySpace?
https://arstechnica.com/science/2020/10/the-unreasonable-eff...
I assume you're referring to https://en.wikipedia.org/wiki/Expression_problem . The Ars article rambles on for many paragraphs about a barely-sensible analogy that actually makes the concept harder to understand. But given that your apparent purpose is to proselytize for Julia I suppose it's adequate.
But really, you could have just said that Julia implements multiple dispatch. And people have been making do without in many different languages for decades.
> arising from its use of class-based object orientation
The language uses nothing of the sort. Unlike Java, you can write any number of globally-accessible classes in a source code file (including zero). Blame the authors.
Also, you don't even need classes to get polymorphic dispatch in Python. Check out `@functools.singledispatch` from the standard library.
> (but can’t escape insanity such as ",".join(["a", "b"]))
This is perfectly sane. As has been rehashed countless times, the method is on the "joiner" string because that way it automatically works for every iterable without duplicating code.
Thanks for the entertaining comment.
Python's object-orientation is based on objects. Hence "everything is an object" being taken seriously, reifying many things as objects (intrinsically, without a "reflection" library) that cannot be seen that way in many other languages (notably Java). For example, functions, modules, classes themselves, exception tracebacks, stack frames...
And hence the inability to describe instance members directly in the class body: because that's where members of the class (which is an object) are described. Including the methods of the class — which as written are just ordinary functions (which are also objects) that happen to be attributes of the class. The methods (which are also objects) are created on the fly when a function in the class is looked up via the instance. And those objects can be stored for later use.
This is what object orientation is supposed to be. Languages like Java are instead class-oriented. You are constantly forced to think about writing classes in order to use objects — you constantly use objects, but you pay for it in class syntax. (Meanwhile, there are non-object primitives.) In Python, you never have to write a class, yet you constantly use objects despite yourself (and "unboxed values" are never accessible from Python).
Much existing library code is needlessly rigid and complex, even when supplying simple functionality. This is encouraged by Python’s mechanism of method specialization, which uses single dispatch and class objects. An attempt to re-use methods from a library leads to the expression problem.
Dude!
You think a touch screen tablet replacing all the knobs and tactile buttons is actually a step forward?