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

[Bruno Desthuilliers]

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
>> implementation.
> 
> 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
> language?

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
> properties!

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
> Python.

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
> code.

And ?

> 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 
verse, please.

> 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
> Bruno 

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 
a psychorigid language that C++ and Java are even looser than Javascript 
in comparison). Perhaps will it light a bulb for you.

>>> Not
>>> 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 
computer.

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
> honest"?

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.