Scheme looks like it could use some new killer factor to distinguish
itself from Python and other programming languages.

One of the first paragraphs that I read about Scheme in SICP, in the
Forward by Alan Perlis (see
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-5.html#%_chap_Te...),
still stands out in my memory as (then (in the early 1990's))
illustrating the significance of Scheme as a tool to teach
programming:

But with Scheme replaced by Python at MIT, this special role of Scheme
as the vehicle for teaching sophisticated students of computer science
has been greatly diminished.  Arguments against SICP as being too
difficult for an introductory textbook notwithstanding, the presence
and usage of that textbook contributed greatly to the significance of
Scheme as a tool in teaching introductory computer science.

It seems that SICP could use a replacement.  What is needed is an
alternative textbook to use Scheme in a role that cannot be fulfilled
by such languages as Python, in order to foster creativity and
originality in programming for future freethinking hackers.  In
addition, such an alternative textbook would need to be actively used
by leading educational institutions of introductory computer science
in raising a new generation of future Scheme hackers.

Does anybody have any suggestions for a plan that could lead to the
birth and growth of such an alternative leading textbook?  Many
programmers tend to be strongly influenced by the first textbook that
they encounter in learning programming; whether that language is
Scheme or Python could have great effect on the future influence of
such languages.  The SICP phenomenon has been done once; why not give
rise to a new SICP' phenonemon?

Multi-core computers are here to stay, and, as someone who works in the
distributed computing field, it is surprisingly simple for a scientist
to get a few thousands computers together to perform some work in any of
the three private, public, or military sectors. Making that as simple a
possible to write and debug would seem a natural evolution for scheme.

From a perspective of R7RS, I suppose it would be nice of the vast amount
of language research developed under scheme (or frankly, other languages)
was actually brought to fruition under a standard.

If the schism is codified, then literally return to R5RS or ERR5RS for the
simple language, and start standardizing more of the larger language and
putting more lessons from the research commuinity into it.  If, after a
while the larger language splits off fully as another language entirely,
well, scheme acted like a crucible for a (hopefully) successful language,
we should rejoice, and start again. :)

The community sees this, and the SRFIs and R6RS libraries were responses,
but the community is still in denial. It would appear that history is
teaching us that you can't have a beautiful language and a working
language at the same time. We want it so badly, that we're willing
to make a language standard which includes two languages--one clean,
and one dirty.

Any role that we could have, our nature destroys.

Give them something to dream about and a means by which it can be reached.

However, if multi-core support were added in such a manner as to be
transparent (i.e., with invocation automatic and invisible, so that
processes would not need to be manually threaded, and programs making
use of such support would be at least mostly indistinguishable from
programs not making use of such support), then the result would not
need to be ugly.

As described by George Neuner in the thread "A question regarding a
thesis." on comp.lang.functional [1],

Furthermore, regarding the problem of adding libraries, Chris Hanson
proposed an alternative to the module system of R6RS in his statement
outlining his reasons against ratification [2], as follows:

Clojure [3] is one example of a programming language that is
syntactically and semantically similar to Scheme which is not ugly (at
least in my opinion), and which provides solutions to both problems.
If Clojure can solve these problems, then why not Scheme?

-- Benjamin L. Russell

[1] Neuner, George. "A question regarding a thesis." Online posting.
27 May 2009. 15 Oct. 2009. <news://comp.lang.functional>. Also
available at
<http://groups.google.co.jp/group/comp.lang.functional/msg/b80fdc7a1bd...>.

[2] Hanson, Chris. "R6RS Ratification Vote." R6RS.Org. 6 Jan. 2008. 15
Oct. 2009. <http://www.r6rs.org/ratification/results.html#X78>.

From The Clojure authors rationale page:

-------------------------
# What about the standard Lisps (Common Lisp and Scheme)?

    * Slow/no innovation post standardization
    * Core data structures mutable, not extensible
    * No concurrency in specs
    * Good implementations already exist for JVM (ABCL, Kawa, SISC et al)
    * Standard Lisps are their own platforms

# Clojure is a Lisp not constrained by backwards compatibility

    * Extends the code-as-data paradigm to maps and vectors
    * Defaults to immutability
    * Core data structures are extensible abstractions
    * Embraces a platform (JVM)
-------------------------

After looking at the above, plus the differences between Clojure and
the rest of the Lisps, one could reasonably argue that Clojure *is*
an evolution of Scheme.

The author of Clojure decided it was easier to create a brand new
language, name it something else, and diverge himself from the "Scheme"
name--even though it is scheme in spirit. Maybe it was because noone is
able to define what it means to be "Scheme"? If we were able to really
define it, we wouldn't continuously say scheme is missing something. :)

Clojure's definition appears to be the implementation itself.
To him, this is advantageous since it is unlikely that varient
Clojure implementations will arise and compete with his "standard"
implementation. Hey, it worked for perl/python/ruby/php/etc....
so why not try it?

For the purposes of the original topic of this thread, a new SICP
should be aware of the ways human beings write functional codes and
the functional design patterns involved--and IMHO, especially the
control/macro abstractions/patterns. People shouldn't discount Clojure
just because it isn't scheme simply because Clojure may provide a
control modeling mechanism which is naturally better than what Scheme
provides. Just because it wasn't invented here doesn't mean lessons
shouldn't be learned from it.

What made SICP powerful was the algorithmic and mathematical ideas behind
the modeling in the code--not that SICP happened to be in scheme. Someone
could translate SICP into ML and it would be just as powerful.

In SICP, scheme's syntactic reflection, lexical closure, and higher
order functions, was the means by which it could innately express the
original ideas. I believe any successor to scheme (even scheme itself,
e.g., R7RS) should always have those ideas as a fundamental base.

If there is to be a successor to SICP, then it should push those
mathematical ideas much, much farther. The first question is, what are
those mathematical constructs, the second is, will there be a language
available that easily *and innately* expresses those complex ideas....

Thank you.

On Oct 14, 9:03 am, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:

Here is what I think has happened and will continue to happen
indefinitely unless we find new strategies for fixing it.  This
is similar to what you are saying, but different in some key
ways:

People grab those other, popular languages so often because
they have libraries and add-on C and C++ libraries for
a large number of commercially valuable kinds of programming.

Let's look at the history of Perl, for one example:

Even very early on Perl had rich support for string processing.
It had support for subprocess management and for signal handling.
It had support for sockets.

For those reasons it was a natural choice for writing the first
generation of CGI handlers.

Because it was used for that generation of CGI handlers, it
was natural and inevitable that people would quickly write
libraries for various network protocols, for parsing and
manipulating email, and for processing HTML.   While many of
these libraries (that I've sampled) are less than tidy,
because so many people needed them they improved and
achieved an "80% solution" level quickly.

Python came onto the scene largely emulating the core Perl
feature set and making it, if anything, easier to build C
or C++ bindings for this or that.   It had a charasmatic
leader, a Euro-US rivalry stake, and some early commercial
successes and quickly caught up with and in some ways overtook
Perl.   (Tcl had tried to do what Python did and ran into
problems that I think boil down to mistakes in the language
design combined with an (in retrospect) dubious business
strategy for commercializing it.  It's still heavily used
but is very much a niche language, I think.)

Prototype based object systems (which Scheme should have
no trouble providing) gained popularity and so we got
Javascript and later Ruby.   Javascript gained popularity
mainly because it was built in to browsers.  Ruby, mainly
because of Rails.

All those languages (and Java, too) "grew" because they
came to the market with some essential features already in
place, but more importantly because:

Lots and lots of people get paid to build and extend
systems in those languages.

Think about how that worked:  hackers could say "Hey boss"
or "Hey investor... look what I prototyped quickly using
the parts already lying around."  And that generated jobs
where part of the job description is to build and contribute
more libraries and more C / C++ bindings.

Scheme has almost nothing like any of that.  There
are almost no jobs.

The closest approximations to what is (was?) needed
can be found in the work of Olin Shivers  on his regexp
library and SCSH - work that is widely almost entirely
ignored and now languishes in the sleepy S48 world.

String handling in Scheme is anemic.  There is no
standard way to so much as open a socket.  There is no
widely used DOM implementation.  Writing C / C++ bindings
is, more often than not, a pain in the butt.

It's not absolute but to a first approximation the only
people paid to work on Scheme are academics who generally
speaking aren't in the business of solving business problems.

For goodness sake it wasn't until 2008 -- *2008* -- that we
got a SRFI for accessing *environment variables*.  Can you
imagine?

The only thing that propel Scheme into a growth phase and
possibly even "popularity" is a truly killer app atop a
solid implementation.   We need a (lucky, successful) "moon
shot" project that winds up generating jobs.   Dicking around
with the language standard isn't going to do the trick.

In fact, I've come to think that dicking around with language
standards is actually going to be a regressive force with
respect to the success of Scheme.   It is time consuming
and a lateral, not a forward move.

It would be better (but expensive - who would pay for it?)
for a pair of implementation teams to go off in their own
direction and not wait for the community as a whole to agree.
They need killer app projects to establish their priorities
and implementation chops to improvise in response to need.

The main product I see (via watching this newsgroup) that people write in
Scheme are other Scheme compilers. While it might be possible to write
a "killer app" which is also a compiler, it is not that probable--says
the person attempting to do exactly this. :)

Maybe what we need to do is to scuttle all scheme implementations,
except what is believed to be the strongest one, and then focus our
energies on it--porting libraries from other implementation, making the
compiler better and writing additional libraries for it.

We can't write a killer app if we don't have a solid foundation, we can't
get a solid foundation if we keep breaking it apart by having our work
split across different implementations.

R7RS shouldn't be a document, it should be a single open source reference
implementation!

Of course, the probability of this happening appears to be the same
as a suitcase full of unmarked hundred dollar US bills spontaneously
appearing before me. But, you never know.

Along those same lines, I'm working on a portable sockets library that  
will hopefully be a decent proof of concept that Schemers should just  
start writing code now; they don't have to wait for one single  
implementation, and waiting will only be worse.

        Aaron W. Hsu

Thank you.

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.

That said -- the more one writes in a functional style (that is,
without using exclamation points in scheme) the more implicit
parallelism there is for the compiler to find.  It's easy,
except for I/O, to write in a purely-functional style in scheme.

I would love to see parallellism better expressed by the language,
so, right now, what viable examples do we have?  To name a few
parallel lisps....  

Multilisp, Xplore, Schemik, Crystal, CL1, Termite Scheme,
Paralisp, Concurrent Scheme, STING, Qlisp, Butterfly,
Erlisp, Distel, Dreme, NeXeme, Quantum, DMeroon, Transpive,
Schematic, Mul-T, Symmetric Lisp, NetCLOS, EDS Lisp,
Parallel Lisp, *Lisp, pLISP, BaLinda Lisp, PaiLisp, and
Wraith Scheme.

The majority of these are either dead languages that only
ever had a tiny community of users in the first place, or
research projects that never had a community of users.  
Still, there are a few exceptions like Wraith with small
but still-active communities.  When you look at them all,
it is hard to find much commonality in their respective
parallelism extensions.  And it is even harder to find
examples of users using them to solve problems, or
comparisons of the merits of different models.  

In short;  There's a lot of material on parallel lisps
out there and somebody needs to do the work of reading
it all, putting working implementations side by side,
writing code in each, comparing approaches and critically
assessing their strengths and weaknesses.  We're past
the point of "This demonstrates that a parallel dialect
of lisp can exist and may even be practical" - that's
been done dozens of times.  But we still haven't even
really started to address questions like "so which are
the best ways to do parallelism in lisp?"

And there's probably still a lot of original design work
to do too; the extant examples, despite their number,
emphatically *do not* include provisions for many of
the ways parallelism can be expressed.

Firstly, you have to figure out this; why are scheme macros
and call/cc not covered in most SICP courses?  If you choose
not to cover those two features, then there's no reason not
to be using, eg, Python for your course.

Secondly, the language used in such a text must not appear to
modern perceptions of the purpose of computing devices to be
a toy.

That means it must provide facilities which do the things
computer owners see as relevant to the purposes of their
computers.

At the very least it has to be able to handle GUI elements,
draw pictures on the screen, and manage network connections.
These are now the means by which people interact with
programs, as fundamental as command-line or REPL I/O was
when SICP was written.  Many of the students reaching college
today have never seen a command line.  Those who have,
mostly associate it with very primitive (toy) programs,
system configuration, and systems which have gone
horribly wrong.

Also, it has to fit in with the paradigm of software
engineering (programmers working together in groups), which
is now vastly more important, both in free/opensource hacking
and in professional software development, than it was when
SICP was written.

Software engineering means, at the very least, well-defined
means of separating large systems into modules with well-defined
interfaces.  In scheme's current module system, there are subtle
phase issues and gotchas with macrology, and I think that is
probably a disqualification to some; it makes the modularity
more complicated than one instructor can explain to fifty
students in fifty minutes of class time plus a two-hour
reading&homework assignment.  

Software engineering also means a standardized method of doing
object orientation.  Indeed, the most frequent paradigm for
separating modules is to separate code referring to different
object types.  In scheme we have closures (and now records)
and can use them as objects, but closures (or records) by
themselves do not provide many of the OO features that students
will need to learn about to use other languages.

CLOS does, though, and there are already tinyCLOS and SOS for
scheme. When SICP was written, you could teach students about
OO by showing them how to implement OO from scratch.  But OO
written from scratch by each student is fundamentally hostile
to software engineering needs, because when that happens you
get modules that are incompatible for reasons unrelated to the
modules' purposes, and software engineering, with opportunistic
module reuse, only works if the modules that *can* be compatible
*are* compatible.

So in the new text, I'd teach how to make records using closures,
then how to build an OO system using those closure-derived records,
as SICP does, - and then I'd switch immediately to tinyCLOS or
SOS or something like that, point out the (scheme!) implementation
of it in an appendix to the book, and use it for everything from
that point forward.

Those (ability to do "basic computer things" like handle network
connections and GUIs, and unqualified support for software
engineering needs) are now fundamental requirements to get in
the door and be considered a "real" programming language.  Only
if you have those things covered, and can explain pretty rapidly
how to use them, will students (or instructors!) even be
interested in your means of program control and organization.

Finally, I would consider any text that doesn't introduce parallelism
and constructs like threads, locks, queues, etc, as probably already
irrelevant.  SICP didn't have to cover that, but a new text to take
its place certainly does.  I don't even know if you can still buy
a single-core computer.  I know I haven't for years.  Even my
cheap little netbook has a dual-core CPU in it.

        Aaron W. Hsu

: That means it must provide facilities which do the things
: computer owners see as relevant to the purposes of their
: computers.

: At the very least it has to be able to handle GUI elements,
: draw pictures on the screen, and manage network connections.
: These are now the means by which people interact with
: programs, as fundamental as command-line or REPL I/O was
: when SICP was written.  Many of the students reaching college
: today have never seen a command line.  Those who have,
: mostly associate it with very primitive (toy) programs,
: system configuration, and systems which have gone
: horribly wrong.

It is true that SICP comes from a REPL age and that that age has
passed; but I do not think that a new SICP needs to actually do GUI
stuff.  The main difference between the REPL and the GUI age is not
graphics, but event handling.  In the REPL age, "the system" took care
of handling events (keyboard events being about the only ones relevant
for SICP), putting values so obtained in a buffer, so that they
could be used asynchronously by the REPL and by input-processing-output
type programs.  Events are completely abstracted away.

It would seem to me that the addition of a chapter that makes events
explicit would be enough to bring SICP to the modern age.  It could
for instance show how to make a tetris style game with ascii
characters, ansi escape sequences and timer and keyboard events, and
competely avoid dealing with GUI details.  It would however deal
with the problems introduced by concurrency.  The student will see
that the examples generalize to mouse events, network events etc. and
that a fancy GUI just involves more work and more encyclopedic
knowledge (which should *not* be taught in SICP').

As an example, one book on another language, Haskell, that does
attempt to integrate mathematical abstraction with a focus on
multimedia is the book _The Haskell School of Expression_ (a.k.a.
"SOE") [1], by Paul Hudak.  I myself have read part of the book, and I
find the book extremely interesting, although I do think that it still
shares some of the difficulties of SICP (specifically, it assumes a
certain level of mathematical sophistication of the reader as well as
specific knowledge of certain topics (such as trigonometry) that are
taught before college, but which are sometimes forgotten by the time
the student reads the book; perhaps the book could have included an
extra chapter on mathematical prequisites, including material on
assumed trigonometry for some of the proof exercises)).  Nevertheless,
I believe that the approach pursued by SOE offers certain benefits
over that of SICP; at minimum, it motivates those
non-mathematically-sophisticated GUI-oriented students to pursue
further study of the underlying principles behind the overlying
behavior in order to use those principles in developing their own
(multimedia) applications.

Perhaps this thread should be renamed "Ideas for a Scheme version of
SOE?" instead?

When the project was over, I felt exhausted, but fulfilled.  In fact,
it was the success of this very project that motivated me not to
abandon programming after college, but to continue to pursue it
(albeit as a hobby in the context of functional programming language
theory--but that is a different issue).  The project demonstrated how
abstract concepts in computer science can be used in creating an
entertaining, modular multimedia application as part of a group
project using borrowed libraries.  At least some of these elements
seem to be the very components missing from most courses that
exclusively use SICP.

Curiously, the course that used this approach was the very course that
had used SICP when taught by a different instructor, so it showed that
this approach could work as an alternative.

-- Benjamin L. Russell

I think what is needed is a hopeful monster: a Scheme-like language
with significant mutations that sets it apart from all existing
Schemes. Clojure could fall in this category.

http://en.wikipedia.org/wiki/Hopeful_Monster

I think a new Scheme-like language may be best served by not having a
language specification and having a mildly unstable feature set. This
would discourage attempts at other implementations. Alternately large
funding for one implementation could allow that implementation to
dominate in efficiency and marketing. Either way, the language would
have a focused community with an obvious canonical implementation
which is desirable for any business evaluating a language for use.

No matter what, the future of Scheme or Scheme-like languages is
likely outside the Scheme standards organization.

Ruby's killer app was Rails. Rails was built to solve a business
problem.

Erlang's killer app was telecom. Erlang was built to solve that
business problem.

To get a killer app, someone needs to build either a framework for
Scheme or a new Scheme-like language to solve a new business problem.
That new business problem needs to be something many other people also
need to solve.

Does someone has links explaining this switch. I found these links:
http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme...
http://lambda-the-ultimate.org/node/3312
http://www.amk.ca/diary/2006/11/mit_to_try_python_for_introduc.html
http://danweinreb.org/blog/why-did-mit-switch-from-scheme-to-python
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science...
http://muckandbrass.com/web/display/~cemerick/2009/03/24/Why+MIT+now+...

Gary Cornell in the book Core Java 2 - Volume I wrote:
The success of a programming language is determined much more for the
usefulness of its support system,
than the elegance in its syntax.
I don't know if he used these words, because my book is in Portuguese.

Well, each language has its objectives. Scheme is good for teach
programming concepts, so I think it
is well suited for intro in programming courses. I know that because
I'm watching CS videos from
Berkeley University and it is really very good.

The teacher, Brian Harvey, said in the first class:
"Welcome to Computer Science 61A, the best computer science course in
the university. That's not because I teach it,
it's because of this book [then he showed SICP], which is the best
computer science book ever written."

hehe great words =)