> On Mar 6, 2022, at 11:08, Jeffery Mewtamer <mewta...@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: - leading whitespace The problem here is that spaces and tabs are both whitespace, but they can have different semantics. FWIW, Whitespace is an amusing programming language based on this issue: https://en.wikipedia.org/wiki/Whitespace_(programming_language) The language design problem is that the different semantics can cause ambiguity. Make (the Unix build tool) allows leading whitespace, but requires tabs to be used at the start of rules; using spaces instead is a common (nay, classic) error. YAML avoids the problem by simply disallowing leading tabs. Python allows spaces and/or tabs to be used as leading whitespace. IIRC, the behavior of these combinations is controlled by the configuration of the computer, editor, etc. So, software portability can become an issue. In any event, any reader of the code may well be confused as to what is the intended behavior. - trailing whitespace Various languages (e.g., C, Falcon, Make, Mathematica, Python, Ruby, sh) allow use of a backslash at the end of a line to indicate continuation: if a line ends in a backslash, the code is continued onto the following line. However, this introduces the possibility of a mysterious syntax error. If there is whitespace between the backslash and the newline, continuation is invisibly suppressed. Some text editors allow non-printing characters to be displayed, and I presume that most screen readers also support this feature. However, I suspect that most users leave this turned off. So, the problem may be difficult to recognize. - Rich Morin
