On 3/6/2022 10:46 PM, Rich Morin wrote:
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:
It is harder but if you want to work with sited co-workers you need to
work with identation.
The advantage that I see in Python or alike languages, is that
indentation is required and thus makes your code "working" and visually
appealing at the same time! :)
Or the code needs to be automatically prettyfied before committing to a CVS.
adhering to conservative standards (PEP8, POSIX ... (splitting lines
insmaller chunks, 80 chars max, use of whitespace)) takes more time to
learn but makes the code more accessible for everyone.
--
John Doe
