How coding in Python is bad for you

Steve D'Aprano steve+python at pearwood.info
Mon Jan 23 20:55:50 EST 2017


On Tue, 24 Jan 2017 08:55 am, BartC wrote:

> On 23/01/2017 17:34, Chris Angelico wrote:
>> On Tue, Jan 24, 2017 at 4:24 AM,  <breamoreboy at gmail.com> wrote:
>>> The article is here http://lenkaspace.net/index.php/blog/show/111
>>
>> I would respond point-by-point if I thought the author had a clue.
> 
> I thought points 1 to 4 were valid, in that the assertions were true.

Assertions can be true and still nonsense criticisms.

"Oh my gawd, this car goes forward AND backwards!!! What a pile of guano!"

What he's describing as flaws in language are seen by many as strengths of
the language. Not only can Python go forward and backward, it can turn
around corners as well!

The author seems to want a B&D language which will force him to do The Right
Thing™ whether you want to or not. He seems to care about a very narrow
definition of correctness, and doesn't mind how many weeks or months it
takes him to write the code, or for that matter, how many years it takes
him to learn how to write the code in one of his preferred languages:

"...it takes years to build up a sense of what is good and what is bad
coding practise"

The reason why Python has become the #1 language for scientific computing is
that for most such programmings, the extra level of safety you (allegedly)
get from heavyweight C++ and Java style coding frameworks is unjustified.
You're not building a nuclear reactor. With Python, you can get reliable
*enough* code quickly, rather than bulletproof code that takes you forever.

Or I should say, *allegedly* bulletproof. There's no actual reliable,
objective evidence that coding in Java or C++ leads to actually more
reliable code, rather than just the false sense of security that because it
was *really really hard* to get the compiler to accept your code, it must
have been protecting you from all sorts of bad things. Maybe it was, maybe
it wasn't.



> Point 5 (memory leaks) I haven't experienced.

I suspect he's using memory leak in the sense, if you hold onto data
forever, the memory used by that data will never be available for re-use.

Reading his post, I get the impression he's the sort of programmer who
believes in never, ever, ever, ever re-using a variable, so he might do
something like:

raw_data = collect_raw_data()  # generates 10GB of data
data_after_step_one = massage(raw_data)
data_after_step_two = process(data_after_step_one)
...
sorted_data = sorted(data_after_step_ten)

and then wonders why he's running out of memory. "That's a memory leak!"

But perhaps not. Maybe he's just using a lot of badly written C extensions
that do leak memory. Or maybe he's one of the unlucky few who have stumbled
across genuine memory leaks in the interpreter, but hasn't bothered to
report it as a bug or upgrade to a version where it is fixed.

Or maybe he's just mistaken. Or lying.


> Point 6 (libraries depending on libraries...) is probably true in other
> languages too.

"I must have installed at least 30 libraries"

Really? 30? As many as that? You poor thing.


> Point 7 (Python claiming to be general purpose) I don't have an opinion
> about.

Python is an object-oriented language which encourages multi-paradigm coding
styles: OOP, functional and even procedural. The underlying data model is
based on objects, but that doesn't imply that you must or even should write
all your code in an OO style.

I suspect this guy is just a Java or C++ bigot.

I have nothing against those who like to program in Java or C++, that's
cool. I have my opinion on the languages themselves, but that's often a
matter of personal taste. But when somebody says:

"For example, encapsulation, one of the basic principles in OO is
non-existant in Python."

as he does, that's a form of the "no true Scotsman" fallacy. He is asserting
that *his* (probably taken from Java?) definition of encapsulation is the
only one. And that's why I call him a bigot. In a figurative sense -- the
author might be the sweetest, most open and unprejudiced guy in the world
when it comes to skin colour or religion for all I know.

https://en.wikipedia.org/wiki/Object-oriented_programming#Encapsulation




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.



More information about the Python-list mailing list