On Jun 13, Brian Harvey wrote:
> > Just *how* many more decades should students be "urged"?  How many
> > more buffer-overrun-like diseases should the world of programming
> > suffer for this kind of thinking to finally go the way of the
> > GOTO?
>
> (1)  This repeated reference to buffer overruns is what we in my
> youth used to call redbaiting.  Lisp programmers don't /have/ buffer
> overruns.  And it's not because Lisp tied anyone's hands -- it's
> because Lisp provided something equally flexible, equally
> expressive, easier to use, and overrun-safe: the linked list.

No, this was not baiting, red or any other color.  I case you missed
this in Matthew's post:

  Chez Scheme Version 6.1
  Copyright (c) 1998 Cadence Research Systems

  > (define l (list 1 2 3 4 5))
  > (map (lambda (x) (set-cdr! (cddr l) 5)) l)

  Error: invalid memory reference.
  Some debugging context may have been lost.

This means that the usual compilation strategy would lead to
segfaulting code -- and that's as good as buffer overruns.  But this
is still missing the point: the naive `map' code which I'm sure you've
shown students countless times is just plain *broken* when pairs are
mutable.  Even if you avoid "unsafe" declarations in your compiler and
therefore enjoy the usual type safety, you still have an
unaccounted-for error case -- so yes, the scheme process will not
crash, does it make any difference for me if it left my bank account
empty?

> (2) How many decades:  I would say aleph-null of them.

I should have said *merely* urged.  If you still hold on to
aleph-null, then I can only feel sorry for the students.

> Functional programming is a great thing, partly, as you say, because
> it's thread-safe and more generally bug-resistant.  But for many
> tasks, stateful OOP is more natural: simulations, window systems,
> etc.  One of the things I admire in Scheme is that it isn't rigid
> about how to program.

In the parts that you conveniently didn't quote I said *explicitly*
that I'm not advocating abolishing mutation.

> > Say that I write software for *your* bank, and I do that in Scheme
> > -- it's a wonderful system that is immediately successful, and I
> > open it up for 3rd-party plugins.  Would you be happy to know that
> > my API passes on your bank account as a structure made of mutable
> > pairs to these plugins?
>
> I don't want my bank to open my account to third party plugins no
> matter how bulletproof the software is!

Replace "plugins" with "libraries".  You can't expect any piece of
software to be written by a single person.

> [earlier]
> I will confess to believing that Scheme users are smarter than
> average. :-)
> [...]
> 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?  Is the point here to *deliberately* keep
Scheme away from mass use and on-line applications like facebook?

> > (ML and Prolog are not pure.  The combination of the ML, the
> > Prolog, and the Haskell communities is likely bigger than the Lisp
> > community.  I can't guess what the ratio is, but there are most
> > definitely much more than "a tenth of the usership of Lisp".)
>
> I admit I don't have statistics about this, but are you including
> elisp programmers in your count?  [...]

There are very few Emacs-Lisp *programmers*.

> > One straitjacket that I don't want to be forced to wear is the
> > huge amount of work I have to do to get robust code written when
> > pairs are mutable.  Another straitjacket I don't want to wear is
> > the illusion that "assuming the list doesn't change" is good
> > enough for real code.  I want Scheme to allow me to be free of
> > these things, not some chaotic "here's a cpu and some wires, you
> > can do whatever you want with it now" thing.
>
> Oh, please.  This is really dishonest rhetoric.  "Straitjacket"
> doesn't mean "anything I disagree with."  It means someone telling
> me that the thing I want to do isn't good for me, and eviscerating
> my toolkit to make it hard for me to do it.

The straitjacket is me being forced to write either nearly obfuscated
code if I want it to be safe, or give up this safety.

> You find it easier to write robust code when pairs aren't mutated?
> Great!  You absolutely have my permission never to mutate pairs in
> your code.  I promise never to design a language feature /for the
> purpose of/ making it hard for you to program in your preferred
> style.

I'll repeat the code here:

  (define (map f l)
    (define (loop l)
      (if (null? l) '() (cons (f (car l)) (loop (cdr l)))))
    (if (list? l)
      (loop l)
      (error "poof!")))

This code does note mutate pairs.  It is still broken.

> [...]  But why do you have to destroy Scheme for me?

Do you see that this question can go both ways?  Or am I now
disqualified from expressing my opinions?

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

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