Does Python really follow its philosophy of "Readability counts"?
bdesth.quelquechose at free.quelquepart.fr
Sat Jan 17 20:49:38 CET 2009
Russ P. a écrit :
> On Jan 15, 12:21 pm, Bruno Desthuilliers
> <bdesth.quelquech... at free.quelquepart.fr> wrote:
>> Once again, the important point is that there's a *clear* distinction
>> between interface and implementation, and that you *shouldn't* mess with
> If you "*shouldn't* mess with the implementation", then what is wrong
> with enforcing that "shouldn't" in the language itself?
Because sometimes you have a legitimate reason to do so and are ok to
deal with the possible issues.
> Why leave to
> coding standards and company policy what can be encoded right into the
Because human are smarter than computers.
> Why leave to humans (who are known to err) what can be
> automated relatively easily? Isn't that what computers are for?
Error is human. For a real catastrophic failure, it requires a computer.
>> But what, some people think programmers are stupid, and
>> so they hire stupid programmers, so they need b&d languages to protect
>> stupid programmers from themselves - which just doesn't work, since
>> *nothing* is idiot-proof. Heck, how many Java "OO" programs with dumb
>> getter/setter pairs for _each and any_ attribute ?
> Hey, I share your distaste for Java and C++.
I'm not talking about the languages by themselves, but about the gap
between what they pretend to promote and how they are usually used.
> All those "setters" and
> "getters" are a kludge. I think Python "properties" are a major step
> forward here. Just for fun, I checked to see if Scala has properties.
> Guess what? Not only does it have them, but they are generated
> automatically for all member data. That's even better than Python
Oh yes ? "Better", really ? So it's better to have a language that
automagically breaks encapsulation (requiring an additionnal level of
indirection) than a language that do the right thing by default ? I'm
afraid I missed the point ???
>>> As I said before, enforced encapsulation may not be appropriate for
>>> every application, but it is definitely appropriate for some.
>> No. It is appropriate for dummy managers hiring dummy programmers. The
>> project's size and domain have nothing to do with it.
> Let me try to be very clear here. We are dealing with two separate but
> related issues. The first is whether data hiding should be added to
No need to add it, it's already there : every name that starts with an
underscore is hidden !-)
> The second is whether data hiding provides any net benefit in
> *any* language.
If it doesn't provide any benefit in Python, then it doesn't provide any
benefit in any language.
> As for whether data hiding should be added to Python, I am not arguing
> one way or the other. I am merely saying that it is worth considering.
It is not.
> Whether it can be added without screwing up the language, I don't
> know. If not, then so be it. That just limits the range of domains
> where Python is suitable.
That's just plain stupid.
> As for whether data hiding provides a net benefit in any language, it
> certainly does for large programs and for safety-critical programs.
> For large, safety-critical systems, it's a no-brainer.
Only if you fail to use your brain. Now, except for regurgitating the
official OMG prose, do you have *anything* to back these claims ? Python
is older than Java, and there are quite enough man/years of experience
and Python success stories to prove that it *just work*.
> I think data
> hiding can also provide net benefits for medium-size and even smaller
> programs, but lets just consider large programs, so I can shoot down
> your argument that data hiding provides no benefit.
C'mon, make my day...
> I like to use the example of the flight software for a large
> commercial transport aircraft, but many other examples could be given.
> How about medical systems that control radiation therapy or
> chemotherapy? How about financial systems that could take away your
> retirement account in 1.5 milliseconds. Or how about the control
> software for the strategic nuclear arsenals of the US or Russia? When
> you consider the sea, air, and land-based components, I'm sure that's
> one hell of a lot of code!
And ? Such systems have been written (and quite a lot are still running)
with languages way more permissive than Python. You know, languages like
C or assembly. Until you understand that *no technology is idiot-proof*,
you'll get nowhere in "software engineering".
> So let's take the airplane example. Boeing and its contractors
> probably has hundreds of programmers working on millions of lines of
> If they believed you, they would abandon enforced data hiding,
> and programmers would have much more discretion to screw around with
> code that they don't work on directly.
Yes. And ?
> An FMS programmer could perhaps
> decide to change the parameters of the engine controls, for example.
Why on earth would he do something so stupid ?
> To prevent that sort of thing from happening, the management could
> decree that henceforth all "private" variable names will start with an
> underscore. Problem solved, eh?
Certainly not. The only way to solve such a problem is to fire this cretin.
> Wait a minute. You yourself have
> stated several times that those stupid library developers
Where did I say that library developpers where "stupid" ? Chapter and
> can never
> predict what the client will actually need.
Now this is a well known fact - applied to "generic" libraries. Nothing
to do with project-specific libraries. Straw man.
> So some FMS guy named
Fine, personal attack now. Man, beware, this is not going to help you
make your point.
(snip remaining braindead fantasy).
> Now, let's talk about a data access violations in the nuclear missile
> launch software. Oh, yes, I'm sure the leading underscore convention
> is more than sufficient! Wake up, dude, and quit spouting bullsh*t!
Please educate yourself and learn about why Ariane 5 crashed on it's
first flight, due to an error in a module written in ADA (which is such
in comparison). Perhaps will it light a bulb for you.
>>> every door needs a lock, but certainly some do.
>> You only need locks when you don't trust your neighbours.
> Yeah, if you live in Nome, Alaska.
Brillant. You obviously failed to understand the differences between
"software engineering" and real life. When it comes to computers, the
only doors I care closing are those which would let someone crack my
But FWIW, I never close my car. And, in case you don't know, it's
perfectly possible to access "private" members in Java (and, if you do
have access to the source code, in C++ too).
> Also, have you ever heard the expression "locks keep honest people
Yes. You don't wan't to know what I'm thinking of it.
> I spent *way* too much time on that post.
At least something sensible.
> I really need to quit
> spending my time refuting the baloney that passes for wisdom here.
I don't have any pretention to "wisdom" as far as I'm concerned, unless
you defined wisdom as thinking that experimental results have more
weight than theory.
More information about the Python-list