3 ms·

The main reason I don’t like Python very much (besides performance) is that it makes what should be simple tasks complex due to the expression problem, arising

The main reason I don’t like Python very much (besides performance) is that it makes what should be simple tasks complex due to the expression problem, arising from its use of class-based object orientation. You can avoid some of the issues in your own programs (but can’t escape insanity such as ",".join(["a", "b"])), but as soon as you delve into a library of any complexity to make alterations, you’re mired in a morass of methods encased in classes inheriting from other classes, and nothing is straightforward. Discovering Julia, which solves the expression problem¹, was enlightening. Even if it were as slow as Python, I would still prefer it: it is simpler, more beautiful, and more readable. https://arstechnica.com/science/2020/10/the-unreasonable-effectiveness-of-the-julia-programming-language/ https://arstechnica.com/science/2020/10/the-unreasonable-eff...

zahlman 1y ago
> the expression problem I assume you're referring to https://en.wikipedia.org/wiki/Expression_problem 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.
- leephillips 1y ago
  https://docs.python.org/3/tutorial/classes.html https://docs.python.org/3/tutorial/classes.html Thanks for the entertaining comment.
  - zahlman 1y ago
    The fact that the tutorial included in the official documentation (which is quite comprehensive) covers classes (in chapter 9) hardly seems to diminish my point. 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).
    - leephillips 1y ago
      I see what you mean. So instead of claiming that Python employs class-based object orientation, I should have said something like: 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.
      - zahlman 1y ago
        Yes, the standard library has a lot of questionable design (some inspired by Java, some by C), and many programmers overuse classes. I'm a fan of (former core dev) Jack Diederich's talk, https://www.youtube.com/watch?v=o9pEzgHorH0 https://www.youtube.com/watch?v=o9pEzgHorH0 .

zahlman 1y ago

> the expression problem I assume you're referring to https://en.wikipedia.org/wiki/Expression_problem 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.

leephillips 1y ago
https://docs.python.org/3/tutorial/classes.html https://docs.python.org/3/tutorial/classes.html Thanks for the entertaining comment.
- zahlman 1y ago
  The fact that the tutorial included in the official documentation (which is quite comprehensive) covers classes (in chapter 9) hardly seems to diminish my point. 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).
  - leephillips 1y ago
    I see what you mean. So instead of claiming that Python employs class-based object orientation, I should have said something like: 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.
    - zahlman 1y ago
      Yes, the standard library has a lot of questionable design (some inspired by Java, some by C), and many programmers overuse classes. I'm a fan of (former core dev) Jack Diederich's talk, https://www.youtube.com/watch?v=o9pEzgHorH0 https://www.youtube.com/watch?v=o9pEzgHorH0 .