Does Python really follow its philosophy of "Readability counts"?
bdesth.quelquechose at free.quelquepart.fr
Sun Jan 18 16:49:51 CET 2009
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.
> 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
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
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
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
More information about the Python-list