What are the kinds of software that are not advisable to be developed using Python?

[Steven D'Aprano]

On Sun, 09 Feb 2014 06:17:03 +0100, Skybuck Flying wrote:

> "
> I got to know about Python a few months ago and today, I want to develop
> only using Python because of its code readability. This is not a healthy
> bias. To play my own devil's advocate, I have a question. What are the
> kinds of software that are not advisable to be developed using Python? "
> 
> Anything that needs to be super reliable.

Obvious troll is obvious.

Okay, I'll bite. What evidence do you have that programs written in 
Python are more bug-ridden or less reliable than programs written in 
other languages? Your own poorly written, buggy software doesn't count as 
evidence. Hypothetical arguments based on "it stands to reason" or 
"everybody knows" that static-typed compilers catch more bugs don't count 
either. Let's see some hard, reliable statistics.


> My experience so far with Python versus Delphi has shown that Python
> requires way more time to debug than Delphi.

I'm sorry to hear that you aren't yet fluent at reading, writing and 
debugging Python code. While it's true that somebody can write hard-to-
debug code in any language, in general Python's ease of us, dynamic but 
not too dynamic nature, and powerful introspection makes debugging quite 
easy.


> The reason for this is the interpreter versus the compiler.

Which interpreter is that? Do you understand that Python has a compiler? 
There's even a "compile" built-in function which compiles source code at 
runtime, ready to run it whenever you like.


> Delphi's compiler will catch many bugs in branches that have not been
> executed or tested.

Only if you write many bugs. You can't catch bugs that aren't there *wink*

But seriously, Delphi's compiler will catch a tiny subset of all possible 
bugs, namely, those which can be recognised by static type-checking. 
While that's useful, it doesn't happen for free. The cost is that Delphi, 
like Pascal, is a lot less flexible, and a lot more tightly constrained 
by the need to keep the compiler happy. Although Delphi does have type 
inference, it is apparently quite limited, which means you're writing a 
lot more boilerplate code declaring types compared to Python.


> While Python's interpreter will mostly catch bugs in executed and tested
> branches.
> 
> Most of the code that has not been executed yet could contain bugs and
> even syntax/typos/non declared variables and so forth.

Deary deary me, you've just exposed yourself as somebody who doesn't 
actually know much about Python. Non-declared variables? Python doesn't 
require declarations for variables.

Nor can syntax errors hide in code branches that haven't been run. (Well, 
technically they could, if you use eval or exec.) But for normal code, it 
is checked for syntax errors during the compilation phase, all at once.


> Which means that the entire Python program will have to be re-executed
> from the start to ultimately end up in branches that were not executed
> the last time.

That's certainly true. But the same applies to Delphi. Type errors and 
syntax errors are only a tiny subset of all the possible errors. You can 
have off-by-one errors, logic errors, out-of-bounds errors, network 
errors, database errors, file system errors... Delphi can't check for 
those at compile time. No matter how clever the programmer or the 
compiler, code that hasn't been run and tested cannot be trusted to be 
correct. As Donald Knuth said:

    Beware of bugs in the above code; I have only proved it 
    correct, not tried it.


> This way of debugging will require many many many many many many many
> many runs of the same Python program before it's somewhat debugged.

And if your Delphi code doesn't have just as many many many many many 
many many many runs, it won't be debugged either.


> This is time lost in the debugging phase.
> 
> Having said that... time is gained in the programming phase thanks to
> it's shortened syntax.
> 
> However there is more... Python may lack some technical language
> elements like, call by reference, and perhaps other low level codes,
> like 8 bit, 16 bit, 32 bit integers which play a roll with interfacing
> with hardware.

Call by reference is a means to an end, not an end to itself. Apart from 
that, all those things you say Python "may" lack, it actually has.


> Types of software which would not go onto my python list: operating
> systems, drivers, perhaps also virtual machines and even compilers,
> python slow execution speed hampers that as well.

Agree with the first three. Not so much the last one. Perhaps you have 
heard of PyPy? It's not just an optimizing Python compiler, but a more 
general compiler-building tool.



-- 
Steven