Years ago we taught programming using Scheme here at the University of
Bordeaux, and they still do in the Engineering School.  A few years
back, we replaced Scheme with Common Lisp.  It is now taught to the
fourth-year students.

My experience with teaching programming Scheme was that students
perceived it as not being credible.  They didn't buy the argument that
it is possible to have a fast implementation while at the same time I
couldn't point to one.  They also weren't convinced that Scheme is a
good language since it is small, but then each implementation adds
mutually incompatible extensions for things like object orientation.
And they couldn't understand why such a supposedly great language
couldn't be found in any commercial product whatsoever.

Perhaps your students are better than mine, but the ability to write a
simple implementation of Scheme in Scheme did not impress them,
probably because they had nothing to compare with.  In addition, for
an implementation to be useful, as opposed to be a pedagogical toy, it
would have to do quite a lot more, including optimizations that can be
quite messy.

At the end of the course, they were left with the impression that
Scheme is a language that is:

  - unreadable because it has lots of parentheses that serve no
    credible purpose,

  - slow, because it is always implemented in the form of an
    interpreter,

  - useless, since used only to implement itself, and has to be
    extended to do anything useful, and

  - not used for any real purpose, so irrelevant to their future as
    developers.

I found myself getting tired of spending a lot of time compensating
for these opinions.  I wanted to be able to give a clear answer to
most of the doubts that students may have about the language I chose.

In listening to myself arguing in favor of Scheme, I found that my
arguments didn't sound convincing, and decided to take a deeper look
at the reason why.  To make a long story short, I realized I wasn't
convinced myself.  Then I (re-) discovered Common Lisp a few years
ago.  I realized that it would provide answers to all of these
doubts.  I therefore started teaching a programming course based
entirely on Common Lisp.

Now that I use Common Lisp, things seem to work much better (at least
that is what I tell myself; perhaps some of my students reading this
can confirm or deny this).  

The parentheses are seen as a way for the CL programmer to think
directly about the internal representation instead of the surface
syntax, and doing that is a prerequisite for writing macros.  There is
no doubt about speed (we are using CMUCL).  The language has more
stuff than they have ever seen before, such as bitwise operations on
arbitrary-precision integers (beats C), CLOS (beats Java and C++),
macros (beats everyone), ratios, highly integrated complex numbers,
first-class functions, and more.  I can truthfully say that CL is used
in real applications (and difficult ones).

In addition, I can point to books (PAIP, Sonja Keene's book, Graham's
books) that solve real problems in a way that the recognize as a
substantial improvement of any methods they can imagine using
languages they already know and I can truthfully say that the authors
of these books are excellent programmers (as opposed to being just
university professors with no programming experience) having written
real-wold applications.

While I know that the majority of my students don't "get it" at the
end of my course (but the situation is no worse than in any other of
our courses), at least (I hope) they get the impression that
programming can be substantially improved by the use of Common Lisp,
even though they are not (yet) able to be part of such a task.  This
is a considerable improvement from Scheme.  In the end I hope (and I
have seen evidence of this) that when they are faced with a difficult
programming task later in life, they will remember that there is a
better way of doing it, and look back at the course, the teaching
material, and the books.

For those who read French, please consult my web page for the course
at:

http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/2001-2002/...

--
Robert Strandh

What a strange idea. I always thought Scheme was created before CL was
around! Am I wrong?

There is one point however that I do not understand. There is no class
system is specified for Scheme (though some implemations may have one). But
Scheme is very precisely specified and so such add-ons look ugly, because an
important part of the language is not specified at all. I think even if the
MIT guys who maintain Scheme think that class systems were not important
they should permit their students to decide for themselves whether they they
want to us classes. Maybe the (the professors) think that Scheme is only the
first step and later the students should move on to a real language anyway.
They (the professors) may think that students should learn algorithms first
and never mind classes which they will need for real work. I do not know and
i do not undertand this.

(BTW: I saw a photograph of you where you are *laughing*! Hard to believe to
judge from your postings.)

J.B.

  Do you have a picture of yourself thinking?  That could make me laugh.
  If you really want the irony to be complete, have you next of kin send me
  a picture of your body cut up into a thousands bleeding pieces arranged
  to spell out "cogito ergo sum".  Just thinking about it makes me laugh.

J.B.

Have you actually interned the last chapter of SICP? They start to strip away
the underlying Scheme: the target Scheme interpreter is implemented on a
simulation of a register machine. They then write a simple compiler which
produces instructions for the register machine and integrate it with the
interpreter. There is a decent discussion of GC.

It's clear to the SICP reader how to take the next steps: rewrite the code
generators to produce C or machine language; implement the primitives and
read/display.

Then a budding Lisp language hacker is ready for Queinnec's "Lisp in Small
Pieces."  Eric, language implementation is a hobby for most of us! There are
few _serious_ implementations of _any_ language.

It's not surprising that people get charged up enough to attempt an
implementation: they can see the end of the effort, which is not the case with
a production language like CL.

It's interesting that using Scheme doesn't detract from the exposition of SICM
any more than it does from providing an introduction to computer science (or
whatever you want to call the field ;) in SICP.

But it seems that the temptation to teach _all_ of CL once you start is
difficult to overcome.  The students end up not seeing the forest for the
trees.

SICP written in a subset of CL would look much the same, assuming you
sugared it up to provide for internal definitions.

*******************

A paper on the "Supercomputer Toolkit" as devised by Ableson et. al. and used,
among other things, to confirm the chaotic nature of the solar system by
simulating the next 100 million years:

http://citeseer.nj.nec.com/berlin94partial.html

The original code was written in Scheme, and it's an example of something
sizeable and sophisticated written in Scheme. They got a speedup of 38x by
optimizing and rewriting the lower levels in C, and another 37x going to
special parallel hardware. This effort was necessary to complete the
calculation in a reasonable time on late '80s hardware.

There was a popular book written about the Sussman/Wisdom "Digital Orrery." My
copy is packed away somewhere, and I apologize for not being able to give you
the reference.

The last two are really the same point. We agree that Scheme is not a
production language.  It was designed (pre CL) as a teaching and research
language. The reference I made in my previous post shows Scheme is more than a
toy.  However, it's a pretty strong point in favor of CL.

I suppose the students would really rather be learning something useful like
C++ or Visual Basic so they can quickly code up some GUIs :((

I didn't follow your comment in that Appendix on Local Definitions.  If (with
my poor French) I understand it correctly, you say that the CL

(let ((x 0))
  (defun F()
     ...))

is not possible in Scheme, but

(let ((x 0))
  (define (foo)
    x)
  (foo))

seems to work ok. Could you straighten me out?

The programming course in the engineering school that I referred to is
for beginners, although they are not directly out of high school (I am
not going to try to explain the French higher education system to
you), and the effect is the same as for more advanced students.  I
secretly plan to take over that course and replace Scheme by Common
Lisp.  I'll let you know what happened in a year or two.
--
Robert Strandh

The first point is taken care of by the part of the course about
macros.  I repeat the necessity for the programmer to think in terms
of the internal representation and not in terms of surface syntax.
The only way this can be done in practice is to have a simple
one-to-one correspondence between surface syntax and internal
representation.

Explaining this to the students takes away some of the resistance to
learning methods and languages that are not used in industry.  

However, the university students don't have this problem (being
ad-driven), or at least to a much smaller degree.  This is a good
thing.

I do plan to teach an introductory programming course using CL, but it
won't look like SICP.  In particular, I am not planning to emulate
classes using closures.  I would probably avoid some more advanced
features initially (CLOS, perhaps macros, packages, ...), and instead
concentrate on something like first-class functions and the
programming style that they facilitate.

  (let ((x 0))
    (defun f ()
      ...))

in CL defines a global function with x in its environment.  The way to
do that in Scheme (I claim) is:

  (define foo)
  (let ((x 0))
    (set! foo (lambda () ...)))

I guess you could do something similar to your idea, such as

  (define f
    (let ((x 0))
      (define (foo)
        ...)
      foo))

--
Robert Strandh

  But a university should reject anyone who is unable to deal with facts
  that run counter to their expectations, indeed all of their old beliefs.
  If there is anything that is worth learning at a university, it is that
  bringing expectations to one's research and rejecting information that
  does not fit them is Wrong.  In fact, few things you do can be worse if
  you really want to _learn_ something.  The first place new knowledge that
  might topple old beliefs can be expected to be found is at universities,
  so if somebody enters a university expecting to have their existing
  knowledge confirmed, as opposed to turned inside out and completely
  revised, they have wrong expectations about what a university is for.

| I secretly plan to take over that course and replace Scheme by Common
| Lisp.  I'll let you know what happened in a year or two.

  I look forward to it.  I find your "reports from the field" informative,
  maybe particularly since they tend to confirm my belief that Scheme hurts
  students.  :)

Things are complicated here in France by the fact that we are not
allowed to reject certain students.  

http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/Common/Str...

--
Robert Strandh

  I have to concede that such patience has significant merits, but that
  does not mean I possess it.  :)

| http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/Common/Str...

  Interesting.  I have recently been reading about cognitive dissonance¹,
  the theories about which I think explain how people deal with information
  that runs counter to previously held beliefs and how some people believe
  only the first thing they hear about something and thereafter reject any
  and all information that would contradict it because of the sense of
  conflict created by the contradiction.  To me, this explained why people
  believe that Lisp is interpreted and slow -- it was the first thing they
  heard about it.  This is also why I thought this community would find it
  at least somewhat interesting to have many people's first contact with
  "Lisp" through an encyclopedia be somewhat less concerned with spreading
  the old myths.

  It seems from this cursory exposition about performance-orientedness that
  those who "suffer" from it are very concerned with not being exposed to
  counter-information to _their_ first-learned techniques, whereas the
  perfection-oriented seek out counter-information that could improve what
  they know about the world.  It seems to me therefore that the coping
  strategy for cognitive dissonance is related to performance- or
  perfection-orientedness.

  I have long wondered if different programming languages appeal strongly
  to different personality types.  It appears to me that, e.g., Perl is the
  ultimate language for the performance-oriented and Common Lisp is much
  more suited to the perfection-oriented than, e.g., Scheme is, where
  "performance" is achieved in terms of how small the language can be made,
  how fast it can be learned, etc, so any intellectual curiosity that could
  make the language "bigger" (even if there would be a smaller language on
  the other side of some more research) would be rejected a priori.  For
  someone who wishes to "get started", Scheme appears to have a stronger
  appeal than Common Lisp, whereas those who are personally interested in
  becoming better programmers, as opposed to create the "perfect" language
  according to some one-axis metric, would choose Common Lisp.  This would
  explain another aspect of the difference between the communities and why
  I think bringing performance-oriented solutions into Common Lisp has been
  a serious detractor from getting _my_ job done.

  If I understand this correctly, 90%-solutions are no good if you are
  perfection-oriented, but are great if you are performance-oriented,

Have you been trying to encourage students to become
"perfection-oriented" long enough to tell us how many
production-oriented students actually respond?  That is, how many
recognize the need for change and then become enthusiastic about
learning and persistently curious about finding "the better way"?

--
--Ed Cashin                     integrit file-verification system:
  ecas...@terry.uga.edu         http://integrit.sourceforge.net/

--
Robert Strandh

(Thinking about cognitive diossonance (as mentioned in this
thread somewhere), it maybe is "trust yourself and your experience
of your life" and as such is again reduction of complexity...).

...only some thoughts from me... I think the thread here is too
big for going deeper into it.

I better use the time for learning scheme... :-)
(Lisp is planned for next year. :-))

--
--Ed Cashin                     integrit file-verification system:
  ecas...@terry.uga.edu         http://integrit.sourceforge.net/

Actually, the standard idiom for this in Scheme is simply:

    (define foo
      (let ((x 0))
        (lambda () ...)))

You only need "set!"s if you're going to create multiple closures
over shared variables:

    (define foo #f)
    (define bar #f)
    (define baz #f)
    (let ((x 0))
      (set! foo (lambda () ...))
      (set! bar (lambda () ...))
      (set! baz (lambda () ...)))

But that's admittedly ugly, which is why some Schemes provide a
multiple-value top-level define, e.g., MzScheme:

    (define-values (foo bar baz)
      (let ((x 0))
        (values
          (lambda () ...)
          (lambda () ...)
          (lambda () ...))))

In Common Lisp, of course, the original example extends trivially:

    (let ((x 0))
      (defun foo () ...)
      (defun bar () ...)
      (defun baz () ...))

-Rob

-----
Rob Warnock, 30-3-510           <r...@sgi.com>
SGI Network Engineering         <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy.         Phone: 650-933-1673
Mountain View, CA  94043        PP-ASEL-IA

;)