Benjamin L. Russell wrote:
> Does anybody have any suggestions for a plan that could lead to the
> birth and growth of such an alternative leading textbook?
The strength of SICP was that it taught many different paradigms
of program construction, using one language that could easily
express them all. That language happened to be scheme. For
some it was a magical and revolutionary experience to see.
But Scheme doesn't make programming "magical" anymore, doesn't
excite new students, because the machines now have a lot of
hardware and network capabilities that are now rightly
considered fundamental to their nature and purpose, and the
inability to use them in a particular language marks that
language as a crippled toy, regardless of its flexibility in
program organization. A computer isn't primarily a power
tool for logic and information processing any more. Nowadays
a computer is considered to be primarily a communications
device like a telephone, with some logic and information
processing capabilities. By this I mean that in the eyes
of most people who own computers, their computer without
access to the internet now has no more value than their
telephone when unplugged. Access to the internet *IS*
the purpose of the vast majority of computers.
We thought of computers as logic and information processing
tools, so It was enough, in our generation, to show novel
means of managing control flow, higher-order functional
semantics, and syntactic abstraction. It was amazing to
us that imperative, logic, functional, and object-oriented
programming didn't require explicit language support, and
that you could "just do" any of them in a language that
was flexible.
But nobody who's grown up with the web, and who thinks of
computers as being primarily communications devices, will
believe that that makes a language anything other than a
crippled toy if you can't interface with the hardware
capabilities of the machine, enabling you to do something
as "simple" as writing a web browser in it, managing network
connections, handling Graphical UI elements, and rendering
text and graphics on the screen.
As an aside, I have to point out that Tim Berners-Lee released
the HTTP protocol in December 1990 - which happened well before
the current crop of college freshmen were born. Usenet was
a going concern when their parents were highschool students,
and NCSA Mosaic came out and the worldwide web was popular
before most of them learned to speak or walk. And scheme
still has no standard means of managing network connections
or rendering anything on the screen. Python has these things.
Now, consider what Scheme's got that Python doesn't got.
It comes down to syntactic abstraction and continuations.
Courses based on SICP don't use them, so MIT had nothing
to lose by going to Python.
SICP doesn't use syntactic abstraction. In the first
edition, this was because Scheme didn't have them yet.
In the current edition .... well, here's the footnote
about macros from the current edition, page 373:
Practical Lisp systems provide a mechanism that
allows users to add new derived expressions and
specify their implementation as syntactic
transformations without modifying the evaluator.
Such a user-defined transformation is called a
/macro/. Although it is easy to add an elementary
mechanism for defining macros, the resulting
language has subtle name-conflict problems. There
has been much research on mechnaisms for macro
definitions that do not cause these difficulties.
See, for example, Kohlbecker 1986, Clinger and
Rees 1991, and Hanson 1991.
(Aside: "practical" lisp systems have them; the dialect
covered in the book does not. Students can and do draw
the obvious conclusion....)
And BTW, the namespace problems are only partially solved
by "hygienic" macros; other namespace problems rear their
ugly heads again the minute you have anything like a
module system with phase separations. Having recently
standardized a module system with phase separations,
scheme once more has problems with macros and namespaces;
python lacking our kind of macrology in the first place,
doesn't.
That leaves continuations - another feature of scheme,
according to http://people.csail.mit.edu/jhbrown/scheme/
"not usually covered in undergraduate classes" using SICP.
It's entirely true that if you're not covering macros,
Call/cc can't really be used to make programs any simpler.
The semantics of Call/cc are bizarre and surprising to
most, and if you don't wrap it in a macro that uses it
to express something more intuitive and reasonable,
people will not see value in it. Hence, in a course
not covering macros, it is almost a necessity to not
cover call/cc. SICP explains it, but most instructors
skip that section rather than getting bogged down in
questions about it that will suck up too much of their
valuable course time.
Anyway: Python has strengths that the current generation
of students finds relevant. Scheme has strengths that
were never taught in SICP courses anyway.
Also: modular organization of programs is now more
important than it was when SICP was written. Scheme
still doesn't do that as well as Python.
Bear