4 ms·

Because: 1: Simple is better than complex. 2: Beautiful is better than ugly. 3: Readability counts. Winners across many markets seem to get the importance o

by mg 1y ago

Because: 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?

maleldil 1y ago
Tesla's dashboard is not simple. Having a touchscreen for everything instead of physical buttons is a travesty.
leephillips 1y ago
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.
        1y ago
reddit_clone 1y ago
>The dashboard of a Tesla to that of a Volkswagen Dude! You think a touch screen tablet replacing all the knobs and tactile buttons is actually a step forward?

by mg 1y ago

maleldil 1y ago

Tesla's dashboard is not simple. Having a touchscreen for everything instead of physical buttons is a travesty.

leephillips 1y ago

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.
      - 1y ago

reddit_clone 1y ago

>The dashboard of a Tesla to that of a Volkswagen Dude! You think a touch screen tablet replacing all the knobs and tactile buttons is actually a step forward?