mutability, namimg, ... (was Re: Choosing a programming language as a competitive tool)

[Alex Martelli]

"Isaac To Kar Keung" <kkto at csis.hku.hk> wrote in message
news:7ig0egimic.fsf at enark.csis.hku.hk...
    ...
> 50".  This is all the problems with mutability.  C and C++ don't have big
> mutability problems, because you can express the former nicely.

Sorry, but I disagree -- and while my personal opinion may not matter
much, I do have some examples with which to back it up:-).  Mutability
is NOT just an issue of mental-model, and C++ DOES have mutability
problems, since mutability inhibits "normal" notions of IS-A.

One of OO's FAQ's is "why can't I have a square IS-A rectangle"?!
Answer: you can, EXCEPT for mutability.  What breaks Liskov subst.
here is the typical mutator-method "setSide" or however you name
it.  In a language with immutable data, such as Haskell, Erlang,
and so on, IS-A holds perfectly here, of course, as it does in
mathematics, with its inherently immutable objects.

A similar issue is, "if Banana IS-A Fruit, why Bag-of-Banana *NOT*
IS-A Bag-of-Fruit?!".  Answer: it's mutability's fault.  One thing
you can do to Bag-of-Fruit is stick an Apple into it (mutating it).
You can't do that to a Bag-of-Banana (it would break its invariant
of all items being Banana).  Sorry folks, it's _either_ mutability
OR covariance here (and for all containers besides Bag).  C++ gives
up covariance, other typesafe-mutable-objects OO languages do worse
by giving up _correctness_ at this point (runtime type errors due to
covariance become possible in a supposedly compile-time typesafe
language -- Java and [once -- dunno 'bout now] Eiffel fall into
this specific trap).

Again, a classic FP language, with its immutable objects, will
never bite you in this way... Python _softens_ the bite by not
pretending to be compile-time typesafe, and specifically allowing
class changes at runtime for an object with constant identity --
your Square can be-a Rectangle (class Square(Rectangle):) if
you don't mind a self.__class__ = Rectangle in the setSide
mutator method... as long as all client-code is hip about that
too, of course (doesn't assume a test of isinstance that once
was satisfied will remain satisfied just because it's the same
object... it USED to be a Square, but now isn't one any more...
mutability does require "type" [class] mutability, and it's easy
to trip up by forgetting that...).

> list.  Yes, good naming of concepts makes it easy to start off, but once
you
> are here for a few days, the naming really doesn't matter unless it is
> really very bad.

Oh, if it's bad enough it can end up helping, because of its
incongruity which makes it hard to forget -- the human mind
is funny that way, at times.  I think the widespread keywords
"break" and "continue" are such examples of egregiously bad
naming (and for once Perl with "last" and "next" had a better
idea), for example.  Particularly when moving from Fortran,
the idea that suddenly 'continue' is NOT any more the exact
equivalent of a Python 'pass' -- a do-nothing statement that
just continues onwards, and acts as a useful place-holder --
but is in fact a "goto start-of-loop", IS mind-boggling... yet
people don't forget that once learned.

So, basically, I agree it's mostly a transient problem _in
practical terms_ for most people (if one used a certain language
or system just *occasionally*, the 'transients' might, I guess,
return over and over again, depending on the individual).

>     Alex> I opine that most of Python's lexical choices are just fine,
>     Alex> "list" being the only one to which I raise mild objections...

Heh, here I was forgetting my objections to 'break' and (especially)
'continue' -- but then, it IS a while since I moved from Fortran to C,
so I guess the transient nature of such problems is confirmed:-).


Alex