Are the critiques in "All the things I hate about Python" valid?

[Chris Angelico]

On Sat, Feb 17, 2018 at 3:54 PM, boB Stepp <robertvstepp at gmail.com> wrote:
> On Fri, Feb 16, 2018 at 10:05 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>
>> He blithely conflates “weakly typed” (Python objects are not weakly, but
>> very strongly typed) with “dynamically typed” (yes, Python's name
>> binding is dynamically typed). Those are two, orthognal dimensions to
>> describe a language.
>>
>> All the assertions about “strongly typed” should instead be read as
>> “statically typed”. I do not think the author understands the
>> differences, nor the trade-offs involved, in the weak–strong dimension
>> nor the static–dynamic dimension.
>
> I should have caught the "weakly typed" error.  But I was too
> distracted by his "type safety" train of thought.  And this is one I
> am still puzzling over:  Are statically-typed languages inherently
> "safer" than properly implemented dynamically-typed languages?  I can
> see the advantages of catching type errors at compile time versus run
> time.  And with the relatively recent introduction of type hints to
> python, I was wondering if this was indeed a perceived,
> need-to-correct weakness by the python devs?  But I have seen myself
> the advantages of being able to rebind identifiers to differently
> typed objects than what they started out being bound to.  So I do not
> have enough knowledge to properly evaluate software safety or
> robustness in terms of how a language is typed.

No, they're not inherently safer. There's no way for the language to
guarantee that your code is bug-free. But we all know that all code
has bugs in it - and that the sooner you find a bug, the easier it is
to fix it. So we have a variety of tools that help us to detect bugs:

* Syntax highlighting
* Linters (eg "unused local variable")
* Warnings of various forms
* Type checkers
* Naming conventions (eg using plurals for collections)
* Clear and consistent indentation
* Unit tests
* Automated test running as part of CI/CD
* Machine-readable documentation (eg 'assert')
* Etcetera

Each of them helps you to catch bugs before they get out into
production. None of them makes one language "safer" than another.
They're all tools that can help you, but sometimes one tool's benefit
overlaps another's to the extent that it's not worth the effort.
That's why most of them are optional.

If type checking is of value to you, use it! If you think it's a
pointless waste of time, ignore it! It's not hurting you.

>> A strong hint is in the complaint about the Global Interpreter Lock.
>> This is a property of only one implementation: the CPython
>> implementation. It is a known limitation and many people have worked for
>> many years to ameliorate it; it is unclear whether the author knows of
>> anything done in recent years (the only specific information cited is
>> for 2012; a reminder, that's *six years ago*, a aeon in platform
>> development).
>
> This is another of my big technical weak spots.  I currently believe
> that doing concurrent and asynchronous programming is a difficult
> chore in any language, but I have yet gotten to the point of where I
> know enough to start struggling myself with these forms of
> programming.  I do know from some of my books that there are ways
> despite the GIL to handle these types of programming problems with the
> current CPython implementation.  But I do not know enough to evaluate
> how well or poorly python can make use of multicore processors.

Asynchronicity and concurrency are hard. Getting your head around a
program that is simultaneously doing two things is inherently tricky.
Anything that simplifies this (such as providing atomic and
thread-safe operations on high-level data structures) will make this
sort of work FAR easier. That's what Python gives you. CPython's
current implementation (with the GIL) is reasonably easy to
conceptualize, and requires very few other locks to make everything
work sanely; all attempts to remove the GIL from CPython have involved
other tradeoffs, usually resulting in significant performance
penalties on single-threaded code.

GIL or no GIL, CPython *does* support threads, and they are incredibly
useful. They just don't automatically allow you to use multiple CPU
cores. That's all.

ChrisA