Russ P. a écrit :
On Jan 15, 12:21 pm, Bruno Desthuilliers
<bdesth.quelquech...@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.
--
http://mail.python.org/mailman/listinfo/python-list
