How coding in Python is bad for you

[Christian Gollwitzer]

Am 23.01.17 um 18:24 schrieb breamoreboy at gmail.com:
> The article is here http://lenkaspace.net/index.php/blog/show/111
>

I don't agree with it (unsurprisingly), even though Python is not my 
favourite language in itself, but a viable compromise for many 
circumstances. Below is a point-by-point reply.

(BTW, Lenka Pitonakova is a lady of Slova origin, so we should refer to 
her as "she")

1. Having the code in shoehorned into a given structure is no guarantee 
for clean code. Look at messy Java inheritance diagrams with hundreds of 
Factory objects all creating themselves around the code that solves the 
real problem

2. It is true that the prototype of a function can be more descriptive, 
if it includes type information (such as "list", "dict" etc.). See 
https://www.python.org/dev/peps/pep-0484/ The documentation is needed in 
any case to understand, what the function does. Mandatory types do not 
prevent bad naming of the arguments.

3. Significant indentation has been discussed over and over, with no 
clear result. Humans need indentation to identify structure in a large 
chunk of code. Brace language programmers use auto-indenters to do that, 
Python uses the layout to deduce the code blocks. Both can fail; most 
notably, missing braces in if clauses lead to several security bugs in 
the past, while white space can be messed up more easily. So that's a 
standoff.

4. It's true that a strict compiler can find errors earlier. Most 
notably, Haskell detects many errors during compile time. Linters exist 
for that purpose in interpreted languages. Still no compiler can 
actually catch semantic errors, which means that automated tests are 
needed anyway.

5. This is wrong. Python does have a garbage collector, but it uses 
reference counting (CPython) - so in simple cases you know exactly how 
to release the memory held by big objects. Unless you use a flawed library.

6. There are even more bad libraries for C and Java. Writing interfaces 
to libraries that do not fit together is actually a much greater pain in 
these languages.

7. This is actually the same argument as 6. Bad programmers wrote some 
code, which you want to use. That is independent of the language, maybe 
in a more strict language the author wouldn't bother to give you the 
code at all! Scientific software was always horrible, previously people 
used impenetrable FORTRAN 77, thankfully they use Python now. Lack of 
encapsulation is a featurenot a bug.

	Christian