Re: [Scheme-reports] Mutable Pairs

[Eli Barzilay <eli@x>]

On Jun 14, Brian Harvey wrote:
> > Perhaps I can summarise his argument ('tho he's welcome to tell me
> > I misrepresent him!) as "Let's make mutability more explicit, so
> > that only things we have requested mutability for can be mutated,
> > to reduce the chances of unexpected accidental mutation"?
> 
> We already have that.  Mutators have an exclamation point in their
> name.

The problem is not in the mutators, it's in the fact that I get *all*
pairs as mutable by default.  And following your suggested guidelines,
not only do I get that by default, I get that as the only choice -- so
if I want to use immutable lists, I must implement my own (or use
given but still segregated type).  Obviously, the PLT experiment shows
that this goes the other way too: if the default is immutable pairs,
then mutable ones are incompatible.  So the obvious question is which
side is the convenient one to use -- and what should the default be.
These days, having your most fundamental type be mutable-by-default
seems anachronistic to me.  (I can definitely understand legacy issues, and
conservative standards -- it's *arguing* for making all your primitive
data mutable by default that is anachronistic.)


> I think that /is/ a misrepresentation of his argument.

No, it was a fine summary.


> A better one would be "let's make it really inconvenient for
> programmers to use mutation

Didn't I mention about 3 times now that I use mutation as often as
anyone?  It's the guarantees of immutable data that seems much more
important (I*M*O) to have available in a convenient way -- since I
need those guarantees *far* more frequently than I need mutable
values.  Not only is this my own experience -- it's also what I see in
most scheme code, and in most scheme teaching materials.  Here's a
thought experiment (which could be made concrete enough): assume that
you *don't* have the status quo option of assuming that your pairs
don't change -- how much class material do you need to revise to adapt
for this?  Now, assume that pairs are immutable, and there's only
single-cell mutable boxes -- how much class material needs to be
revised for this option?

[My guess is that you'd prefer to go on with that status quo.  I tried
it, and I found myself increasingly viewing this as sticking my head
in the sand: either showing code that is half-true and hiding the
problems, or mumbling something about "real code" being more
complicated than what I'm showing.]


> so that we can push them toward what we, the Real Experts, have
> decided is the One Right Way to program."

Do you really have to go down to this level?  Please go back over what
I wrote, and you'll see that I wrote about my experience with this as
a *user* of the language -- not as its all-knowing designer.  Even
more than that, I wrote this bit (which you also didn't quote):

| I was originally skeptical about going with immutable-by-default
| pairs in PLT

To make it more explicit for you: if it was *my* choice to go with
immutable pairs or not, then I would *not* have done it.  So please
stop with these derogatory big-brother analogies...


> I'm in the middle of reading a book about the battle between Robert
> Moses and Jane Jacobs about city planning in New York.  Moses, too,
> Knew Better how people should live their lives, and so he built huge
> master plans, mostly involving bulldozing people's houses to put in
> highway onramps.  Jacobs wanted to listen to the people who actually
> lived in the neighborhoods and do planning to help them meet their
> own goals.  An eerie resonance to the current debate.

...such as this one.  They're just wrong.  *My* posts were all made as
a *user* of the language, and *your* posts are all made as its
*designer*.  And I'll make this more explicit too: I came here to
speak as one of "the people", and you're the architect who refuses to
listen.  Eerie indeed.


On Jun 14, Brian Harvey wrote:
> >> I am one of those people who'll never have a Facebook account,
> >> and it's not because I don't trust the technical merit of their
> >> code.
> >Um, how is this relevant?
> 
> I guess you don't follow the news -- Facebook is having huge public
> relations problems just now because people have finally caught on to
> the way they make information about their users available to
> businesses for basically malevolent purposes.  I don't want my bank
> to behave that way.

(Yes, I know about that, and given that this is not the result of bugs
I fail to see the relevance.)


On Jun 14, Brian Harvey wrote:
> > (But if the above is correct
> > and you never use it with any functions except your own then it
> > doesn't matter -- but then what's the point of using scheme.)
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> And here we get to the heart of the matter.  What is Scheme for?  If
> everything other than industrial programming is useless --
> education, for example -- then indeed we should have a straitjacket
> language to support teams of 500 lousy programmers.

What I understood from David is that when he uses `map' in his code,
he will never pass it a function that is not his too.  In my view, one
of the biggest points of Scheme is that it has first class functions,
and crippling this feature by making it applicable to my own functions
only seems like a major setback.  For example, if I follow that, then
a programmer writing a gui-framework will not have callbacks, since
those are calls to untrusted code.  If this is a correct understanding
of his point (which I very much doubt, hence the parentheses), then
enough linguistic power is lost, and using Scheme has a much lower
advantage.  This had no relation to teams of 500 programmers, lousy or
not.  (BTW, nothing in what I said changes whether I'm part of a team
of 500 lousy programmers, but I wrote it based on my own private
experience.)


> My students will end up being better programmers if they develop
> good judgment.  If they learn in a language that exercises the
> judgment for them, that weakens their education, because they learn
> to lean on the language to make their decisions for them.

Seems that I need to repeat this a fifth time:
- I do *not* use a language with no mutation,
- I do *not* advocate a language with no mutation,
- I do *not* want a language with no mutation,
- I do *not* teach a language with no mutation.

Therefore, I *still* have a choice -- and I *still* need good
judgment.  The only difference is in what the language uses by
default, and currently (RnRS) Scheme is guessing wrong in >99% of the
cases, and it makes it extremely hard for me to correct it.


> Take data abstraction.  Scheme lets you define abstract data types.
> It also lets you not define abstract data types.  The students who
> learn to do the former spend less time debugging.  This is a
> learning experience.  If Scheme forced you to define abstract data
> types, programs would arguably be safer, but students would learn
> less.

Irrelevant.  ("Take Racket.  It lets you use immutable values.  It
also lets you use mutable values. ...")

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports