Does Python really follow its philosophy of "Readability counts"?

[Bruno Desthuilliers]

Russ P. a écrit :
> No one ever claimed that a programming language, no matter how
> rigorous, can eliminate all bugs. All a language can do is to reduce
> their rate of occurrence.
> 
> The Ariane fiasco was not a failure of Ada per se but rather a failure
> of people using Ada. 

Almost right.

> They attempted to re-use software written for one
> rocket for another without proper testing. No language can prevent
> that sort of error.

Now this is plain right.


> We can argue forever about the usefulness of language-enforced
> restriction of access to private data and methods. I have no doubt
> whatsoever that it is very useful at least for the extreme cases of
> very large, safety-critical systems.

And my POV is that it's just plain useless.

> If you don't think access to
> private data needs to be restricted for control of strategic nuclear
> arsenals, for example, I think you're crazy, but that's just my
> opinion.

If you think that this kind of access restriction makes softwares 
controling strategic nuclear arsenal any safer, then *you* are totally 
crazy. As *you* stated above, "no language can prevent this kind of error".

> The only reasonable question in my mind is where the line should be
> drawn between systems that should have enforced restrictions and those
> that can rely on coding standards and voluntary cooperation among
> programmers.

The only reasonable question in *my* mind is whether you think it's 
better, specially for safety-critical stuff, to hire people you can 
trust or to rely on technology.

> A while back, I read something about the final integration of the
> flight software on the Boeing 777, which was written mainly in Ada.
> The claim was made that this integration took only three days, whereas
> normally it would be expected to take more like three months with a
> less rigorous language such as C++.  The reason for the simplified
> integration is that Ada enforces interfaces and prevents access to
> private data and methods.

C++ does it too. Or at least, that's a very common "claim" about C++.

> Apparently such enforcement can improve the
> efficiency of software production -- and that's not just in "theory."

My own experience is that too much rigidity in a language only leads to 
more boilerplate code and more workarounds (design patterns anyone ?), 
IOW more accidental complexity, hence more space for bugs to creep in.

My very humble (no don't say it) opinion about this is that what's 
important is how you handle and manage the whole project (including both 
technical and non-technical aspects), not the technology used (which 
might be relevant - I of course wouldn't use Python for anything 
real-time - or not - most of the monstruogigantic "entreprise" software 
written in Java would work just as well in Python or any other decent 
language).

No technology will prevent human errors - I think this point is clear, 
and that we both agree on it. OTHO, some technologies can at least help 
reducing the opportunities for human errors - and I think we also agree 
on this. Now the point is : *how* can a given techno helps wrt/ this 
second goal. Here you have two philosophies. One is that you'll reduce 
errors by improving simplicity and readability, and by promoting trust 
(whithin the team), sense of responsabily, and communication. The other 
one is that you'll reduce errors by not allowing those stupid 
code-monkeys to do anything that *might* (according mostly to unproved 
assertions) be "dangerous" - hence promoting distrust and 
irresponsability, and adding quite a lot of accidental complexity. BTW, 
do you know the by far most common Java idiom ? It's named the 
"do-nothing catch-all exception handler". As an excercise, explain the 
reasons behind this idiom, and it's practical results.

As a last point : I certainly don't think Python is perfect in any way, 
*nor* that it's the appropriate tool for each and any project. I just 
disagree with you on your assertion that Python is not ok for large or 
critical projects because of it's "lack" of language-enforced access 
restriction.