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

[Russ P.]

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? Why leave to
coding standards and company policy what can be encoded right into the
language? Why leave to humans (who are known to err) what can be
automated relatively easily? Isn't that what computers are for?

>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++. 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!

> > 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. The second is whether data hiding provides any net 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.
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.

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

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!

So let's take the airplane example. Boeing and its contractors
probably has hundreds of programmers working on millions of lines of
code. 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. An FMS programmer could perhaps
decide to change the parameters of the engine controls, for example.

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? Wait a minute. You yourself have
stated several times that those stupid library developers can never
predict what the client will actually need. So some FMS guy named
Bruno decides that he knows better than the engine group what a
certain engine parameter should be. Or he decides that his code needs
to know the value of that parameter, so he just goes ahead and reads
it. No harm done, eh?

But wait a minute. Half the programmers did the same thing, and now we
have a spaghetti mess on our hands. So now management needs to
implement a costly, bureaucratic program to find all such accessing of
private data and correct it -- before a disaster occurs in flight. So
they have meetings and assemble a data-hiding enforcement team that
meets twice each week and constantly looks over every programmers
shoulder.

Wait a minute, wouldn't enforcement of data hiding by the programming
language be preferable to a huge bureaucratic program? I sure think
so. And thankfully, so does Boeing and anyone else who has a clue
about large-scale software production.

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!

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

Also, have you ever heard the expression "locks keep honest people
honest"?

I spent *way* too much time on that post. I really need to quit
spending my time refuting the baloney that passes for wisdom here.