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

[Bruno Desthuilliers]

Russ P. a écrit :
(snip)
> Wait a minute. Aren't the guy who just took me to task about the
> definition of functional programming? So the definition of functional
> programming is written in stone, but the definition of OO programming
> is written in smoke?

Well, actually, the answer is mostly "yes". Functional programming is 
based on a (mathematical) theoretical ground about calculation (google 
for Alonzo Church and lambda calculus), while OO is originally nothing 
more than a way to implement finite state machines with an imperative 
language. OO *is* imperative programming (which is itself also well 
defined).

> 
> Just for the record, I really don't care much about the definition of
> OO programming. I brought it up only because someone tried to claim
> that "enforced" encapsulation

data hiding.

> is a terrible idea. Well, as far as I
> can tell, the majority of OO "programmers" (and software engineers,
> software architects, 

playing buzzword bingo ?

etc.) seem to think otherwise. Maybe they are
> wrong -- but I seriously doubt it.

The first OO languages (at least the second one - Smalltalk) used 
data-hiding to clearly emphasize the "black box" nature of objects and 
the use of messages as the main (only in the case of Smalltalk) support 
for control flow. Remember than by that time, lost of programs where 
still mostly relying on *global* state changes. IOW, it has a strong 
educative value then...

Following "OO" languages - mostly C++ and Java - kept this "rule" like 
it was a sacred cow (but mostly forgot about the more important points 
of 'everything is an object' and message-passing as main control flow). 
Then everyone started considering this as "fundamuntal", and here we are 
years later with one more cargo cult, when years of experience prove 
that it's not - at least from a practical POV.

Once again, the important point is that there's a *clear* distinction 
between interface and implementation, and that you *shouldn't* mess with 
implementation. 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 ?

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

> Not
> every door needs a lock, but certainly some do.

You only need locks when you don't trust your neighbours.