On Mar 6, 2022, at 11:08, Jeffery Mewtamer <mewtamer@gmail.com> wrote (offlist):
Perhaps I'm biased on account of having learned to program under the Object-oriented paradigm, but I'm curious why you count that as a con of Python.
tl; dr - personal preference, plus concurrency issues.
I apologize for submitting such a long-winded (and arguably off-topic) response, but:
- implementation choices can affect end results
- my desired end result is more accessible apps
By way of background, I started programming around 1970. I adopted modular and structured programming syntax as soon as I could, but never found object-oriented programming (OOP) to be all that compelling. I recognize that it can solve some problems quite nicely, but I think that it (and inheritance, in particular) can easily be overemphasized.
Over the last decade, I've started using functional programming (FP) approaches and techniques, mostly in the context of Elixir. There are assorted things I like about FP, including the improved ease of reasoning about code. As Michael Feathers says:
Object oriented programming makes code understandable by encapsulating moving parts. Functional programming makes code understandable by minimizing moving parts.
I can't offer an attribution, but some wag observed (roughly) that:
Structured programming answers the question "How did I get here?". Functional programming answers the question "How did my data get into this state?".
Avoiding mutable state is a relatively minor benefit in most sequential programming, but it's a major benefit in concurrent programming. Controlling the sharing of mutable state seems to be the biggest challenge (and source of error) in writing thread-based code. The Python documentation, for example, lists a variety of ways to deal with this:
Concurrent Execution
https://docs.python.org/3/library/concurrency.html
Note: Python offers process-based concurrency, but this appears to rely on OS processes, which have high overhead in both compute time and memory space. Also, it provides no safety net, such as the "supervision trees" that are used in Elixir to provide fail-soft behavior. So, it may not be a good fit for performance- and reliability-sensitive infrastructure (e.g., high-volume web servers).
Bringing the discussion back to OOP, the practice of hiding implementation inside objects can hide unsafe thread behavior. José Valim, the creator of Elixir, ran into this problem as a member of the Rails core team. They were trying to make Rails thread-safe and had to dig into each library's code to unearth problematic practices. Indeed, this was his initial motivation in developing a new language.
Distributed applications are inherently concurrent; also, current processor and system architecture trends both emphasize concurrency. So, using a programming model (objects combined with threads) which is inherently unsafe seems like a poor choice for this project.
Totally on board with it being whitespace sensitive being a con, which makes it nearly unusable in my opinion, ...
Whitespace sensitivity is obviously a problem for the visually impaired, but it can also set up any programmer for failure. Here are some examples, for consideration: