Ideas for an SICP'?
Benjamin L. Russell
general these days, what with the R5RS vs. R6RS schism and the
movement toward formalizing this schism in the upcoming R7RS. To make
matters worse, MIT has abandoned Scheme, 6.001, and the recursive
approach to problem-solving in favor of Python, C1, and the
libraries-focused approach.
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_Temp_2),
still stands out in my memory as (then (in the early 1990's))
illustrating the significance of Scheme as a tool to teach
programming:
>... compare the treatment of material and
>exercises within this book with that in any first-course text using
>Pascal. Do not labor under the illusion that this is a text digestible at
>MIT only, peculiar to the breed found there. It is precisely what a
>serious book on programming Lisp must be, no matter who the
>student is or where it is used.
This paragraph advanced the notion of SICP, as a book using Scheme to
teach computer science, as a universal pedagogical programming
textbook, regardless of who the student was or where the textbook was
used. The choice of Scheme as the vehicle for teaching computer
science in SICP helped greatly in promoting the use of Scheme in
teaching programming and introductory computer science, which, in
turn, exposed many new students to the existence of this unusual
language.
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?
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Peter Keller
> Scheme looks like it could use some new killer factor to distinguish
> itself from Python and other programming languages.
Scheme, I believe, would seriously benefit from the addition of language
level parallel / threading concepts--multilisp's future is an example. I
don't mean a library, but actual physical syntax or environments. Lifting
the parallel constructs into the language would allow *much* better compiler
analysis and debugging tools to be written.
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. :)
> 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.
Sadly, I don't think that role exists. The reason is that people, when
confronted with a new language, expect to buy some o'reilly book on it
or go to the web and find the definitive resource for the language and
all of its (vast) libraries. They expect to write a library and have it
work with the language anywhere they go. Scheme simply doesn't have that.
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.
> 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?
I would say that the most powerful thing scheme really has to offer are
macros and control abstraction. Both of them aren't treated as well as
they could be in any text book, nor explored to unseen vistas. Google made
billions on map/reduce, which is like page 12 in any book on functional
programming. What awesome things live in the next 200 pages? In the
future, average people will have dozens of powerful networked CPUs in
their house, and 8 year olds will wonder if they can build something out
of them.
Give them something to dream about and a means by which it can be reached.
-pete
Benjamin L. Russell
wrote:
>It would appear that history is
>teaching us that you can't have a beautiful language and a working
>language at the same time.
While integrating a beautiful language and a working language is
difficult, I don't believe that it is impossible. One of the major
problems with Scheme, as you explained, is the lack of multi-core
support. Another problem is the dearth of libraries.
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],
> Most programmers have been shown limited ability to
> correctly handle multitasking regardless of the coding model. IMO, to
> be maximally useful, both task creation and task distribution should
> be as automated as possible. Ideally, the programmer should write
> code as if for a uniprocessor and the language runtime system should
> handle parallelizing and distributing computation automatically.
I agree with Neuner; as an example, one time I was speaking with a
Java programmer, who distinctly mentioned that he thought that
programming in Java was easy, except for threading.
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:
> The module system is basically a way to tell the linker how to
> construct programs from parts. Rather than invent a new language to
> do this, it's possible to build the linker such that the programmer
> can insert code to control aspects of the linking process. Such code
> could do _more_ than the current module system does, and because of
> the added expressivity, it could do so more concisely in many cases.
> For example, I sometimes use a trivial module system in which names
> starting with "%" are local, and all other names are exported. This
> is a trivial program to write, and doesn't depend on the details of
> the names, but it can't be said at all with the proposed module
> system.
This is just one possible solution to the library problem which also
would not need to be ugly.
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/b80fdc7a1bdf5af6>.
[2] Hanson, Chris. "R6RS Ratification Vote." R6RS.Org. 6 Jan. 2008. 15
Oct. 2009. <http://www.r6rs.org/ratification/results.html#X78>.
[3] Hickey, Rich. "Clojure - concurrent_programming." Clojure -
concurrent_programming. 2009. 15 Oct. 2009.
<http://clojure.org/concurrent_programming>.
Peter Keller
> wrote:
>
>>It would appear that history is
>>teaching us that you can't have a beautiful language and a working
>>language at the same time.
>
> While integrating a beautiful language and a working language is
> difficult, I don't believe that it is impossible.
I don't believe it is impossible either, but I do believe the scheme
community (and many other language communities) doesn't know how to do it.
> 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.
I concur that the solution could look nice. Compiler analysis could go very
far in producing good quality code free of the usual threading issues.
> As described by George Neuner in the thread "A question regarding a
> thesis." on comp.lang.functional [1],
>
>> Ideally, the programmer should write
>> code as if for a uniprocessor and the language runtime system should
>> handle parallelizing and distributing computation automatically.
>
> I agree with Neuner; as an example, one time I was speaking with a
> Java programmer, who distinctly mentioned that he thought that
> programming in Java was easy, except for threading.
I also agree, I think either threading should be compiler determined, or
a very high level construct.
> 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?
That last statement is the interesting one. In a sense, why didn't the
work in Clojure happen in Scheme instead? Why did Clojure become its
own language?
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.
-pete
Tom Lord
false belief:
On Oct 14, 9:03 am, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:
> Sadly, I don't think that role exists. The reason is that people, when
> confronted with a new language, expect to buy some o'reilly book on it
> or go to the web and find the definitive resource for the language and
> all of its (vast) libraries. They expect to write a library and have it
> work with the language anywhere they go. Scheme simply doesn't have that.
> 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.
I think that that's mistaken (about the lessons of history).
I don't think that the design of the language plays much of a role
here.
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.
-t
Peter Keller
[snip]
> 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.
I cannot deny that you make a compelling argument.
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.
Later,
-pete
Aaron W. Hsu
<psi...@merlin.cs.wisc.edu> wrote:
> 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.
I believe that the multiple implementations of Scheme is a strength, more
than a weakness. What is lacking is a way to promote cooperation between
these Scheme systems. Descot is a project that I am working on to promote
this kind of collaboration between systems, in such a way that it doesn't
mess with them. Work has already been done in a public protocol and
metalanguage for describing Scheme code so that multiple repositories can
share data. I will soon release a Beta version of 1.0.0 Descot once some
portability and build issues are cleaned up. Some work has also been
suggested that will make Descot a package description format that allows
each portable Scheme library accessible in a Scheme's native module
language. This will work mostly for relatively portable code, but in
actuality, this isn't as hard as people make it out to be.
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
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
Peter Keller
> On Sat, 17 Oct 2009 16:58:54 -0400, Peter Keller
> <psi...@merlin.cs.wisc.edu> wrote:
>
>> 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.
>
> I believe that the multiple implementations of Scheme is a strength, more
> than a weakness.
I'm not asking this to simply argue, but I'm very curious. Why do
you think it is a strength? From my perspective, it encourages work
duplication. How many different implementations of basically the same
library exist across the scheme implementations? I could go and actually
tabulate the information, but it is pretty clear that it happens commonly.
> What is lacking is a way to promote cooperation between
> these Scheme systems. Descot is a project that I am working on to promote
> this kind of collaboration between systems, in such a way that it doesn't
> mess with them. Work has already been done in a public protocol and
> metalanguage for describing Scheme code so that multiple repositories can
> share data. I will soon release a Beta version of 1.0.0 Descot once some
> portability and build issues are cleaned up. Some work has also been
> suggested that will make Descot a package description format that allows
> each portable Scheme library accessible in a Scheme's native module
> language. This will work mostly for relatively portable code, but in
> actuality, this isn't as hard as people make it out to be.
As an example of my point that multiple implementations of scheme cause
us trouble: What would you have worked on if you didn't have to write
Descot--which if we just had one Scheme implementation, would have been
totally unecessary. (Please understand I'm not disparaging your work
at all!)
Thank you.
-pete
Ray
> 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
Ray
> Benjamin L. Russell <DekuDe...@yahoo.com> wrote:
>> Scheme looks like it could use some new killer factor to distinguish
>> itself from Python and other programming languages.
>
> Scheme, I believe, would seriously benefit from the addition of language
> level parallel / threading concepts--multilisp's future is an example. I
> don't mean a library, but actual physical syntax or environments. Lifting
> the parallel constructs into the language would allow *much* better
> compiler analysis and debugging tools to be written.
True, but so far the interaction between call/cc, particularly
call/cc with dynamic-wind, and multithreading has been, err,
boisterous, ranging occasionally to violent. No matter how
you do it there are reasons why you can argue it was done wrong.
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.
> 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.
The edit/run/debug cycle in a massively parallel application has
an implicit publish-and-distribute-new-code step. This is
interesting because it provides access to the machine's capabilities
to downloaded code. It needs to be securely locked down, or else
the system becomes a massively-parallel spam-sending farm the
instant a black-hat comes along. Locking it down, in fact, is
too important to be left out of the spec or left up to implementers
to do each in their own way.
> 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.
Research doesn't make the cut into the standard unless it has
become a built-in, useful, and frequently-used part of one or
preferably several fairly major implementations, demonstrated
to work well in concert with other language constructs.
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.
Bear
Ray
> 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?
I think that before such a book can exist - and use scheme -
scheme itself has to have several properties which it does
not now have.
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.
Bear
Aaron W. Hsu
> Benjamin L. Russell wrote:
>
>> 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?
>
> I think that before such a book can exist - and use scheme -
> scheme itself has to have several properties which it does
> not now have.
The "Little" books by Friedman, et al. are great books for teaching
programming. The Reasoned Schemer provides an avenue for teaching logic
programming in a way that is easy, simple, and actually makes it useful.
That is, you can use Logic programming when you want to throughout
functional programs, without having to make the whole program a Logic
program written in some special Logic programming language.
> 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.
This is already possible in the three major Scheme implementations I
associate with major Universities: MIT Scheme, Chez Scheme, and PLT
Scheme. At Indiana, we use Chez Scheme to teach graphics programming to
first year students. They get to draw pictures on the Screeen. We also
have an interface to robots that we can use to teach programming that way.
Scheme is used to run the backend services to many of the basic functions
provided to the students. I don't think it's a question of whether Scheme
is "capable" enough of doing these things. It's a matter of how they are
educated. Students who never see that Scheme can do these things, won't
understand it. Students who realize that Scheme can do this stuff now must
understand why the language matters to their paycheck. Unfortunately, many
of the students coming into Computer Science aren't here for Computer
Science: they're here to get a job making money with computers. They don't
see how they can make money with Scheme, so it doesn't appeal to them. Of
course, this is wrong, but how does one help the student to understand how
they are benefiting?
> 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.
The problem is that many classes never even teach modularity, even though
it could be done easily enough. The pressure seems to be to avoid teaching
those things until the second semester or thereafter, and very often, the
students won't see Scheme again until they hit their advanced classes,
where they are left without any idea how to use Scheme to build larger
projects. I think teaching good large-scale software organization with
Scheme has many benefits, and it doesn't matter whether you use R6RS
libraries or other module systems.
> 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.
I think that we should move away from the paradigm that OOP is the end all
and beginning of all decent programming practices. Yes, students need to
understand OOP, and they should get exposure to different implementations
of doing it, but at the core, it is more important to teach them how to
utilize it within the context of a system that is not centered around it.
OOP should be a component of the C.S. curriculum, not a foundational
principle. When I say OOP here, I mean the "Enterprise" buzz word.
Teaching simple good object based abstraction is foundational, but this is
different than OOP as commonly understood. Students should learn to see
OOP as something more flexible, useful, and less central to computing than
they are usually told.
> 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.
One problem is when to teach this stuff. Scheme could easily be used to
teach all of these concepts, but at some point, students need to see how
to program in other languages as well. I don't think you can fit all of
this effectively into a single semester class, and probably not even two
semesters. I can see using Scheme the first year of programming, but after
that, classes need to start using other languages in addition to Scheme. I
like the idea of keeping Scheme as a central point of reference, but we
still need to make sure that students understand a wide spectrum of
programming languages.
Dirk van Deun
: 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.
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').
Dirk van Deun
--
Ceterum censeo Redmond delendum
Benjamin L. Russell
Deun) wrote:
>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.
While pedagogically sound, the problem with this approach is that
there are at least two distinct groups of students: the
mathematically sophisticated, non-GUI-oriented group who are mainly
interested in mathematical abstraction and who would probably be
satisfied with this approach, and the non-mathematically-sophisticated
GUI-oriented group who are mainly interested in multimedia
applications and who would probably not pursue another course after
taking one with this approach. Ideally, an introductory course needs
to satisfy both groups; this requires demonstrating, not just
describing, GUI events, and such demonstration does require graphics
(and preferably sound (or music) as well).
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?
>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').
It is interesting that you mention Tetris; precisely one of the most
interesting Scheme-based applications that I helped write (using
GUI-based libraries provided by the instructor) in one course audited
in college was entitled "Schemetris." In the mid-term assignment that
required writing that program, students were grouped in pairs, given
libraries to handle the GUI-based details of the implementation, and
given a specification of what to write. I remember spending roughly
three full days (nights, actually, since my partner and I were both
nocturnal) on this assignment, in which my partner worked on the logic
and more detailed specifications of the modules for the program, and I
wrote the modules themselves. We used principles of data abstraction
in refining the modules for using the given GUI-based libraries in
creating a fun Schemetris application as a team (pair, actually)
project. At the end of this fun project, we had a working Schemetris
application which we could play, using color graphics (the only
missing component was sound, but this was because the Sun Sparc
workstations that we used lacked sound functionality, and not because
of any intentional lack of emphasis on sound (or music)).
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
[1] Hudak, Paul. _The Haskell School of Expression._ New York:
Cambridge University Press, 2000. <http://www.haskell.org/soe/>.
Peter Michaux
> Maybe what we need to do is to scuttle all scheme implementations,
Many Scheme implementations are written and maintained (at least for a
while) by researchers. It would be counterproductive in the long run
to ask researches to abandon their research.
> except what is believed to be the strongest one, and then focus our
> energies on it
If one implementation was significantly better than the others then
natural selection would have chosen a winner already. Perhaps as
interest in Scheme dwindles, it will only be possible to maintain one
implementation. That may be the necessary situation to make a single
Scheme flourish.
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.
> 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.
JavaScript's killer app was browser scripting. JavaScript was built to
solve that business problem.
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.
> R7RS shouldn't be a document, it should be a single open source reference
> implementation!
A reference implementation is usually a slow beast where the clarity
of the implementation is more valuable than the speed of execution.
Peter
tivrfoa
for Scheme.
Probably other universities will follow MIT and switch too (for Python
or any other).
Does someone has links explaining this switch. I found these links:
http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python
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/6-189January--IAP--2008/CourseHome/index.htm
http://muckandbrass.com/web/display/~cemerick/2009/03/24/Why+MIT+now+uses+python+instead+of+scheme+for+its+undergraduate+CS+program
> Sadly, I don't think that role exists. The reason is that people, when
> confronted with a new language, expect to buy some o'reilly book on it
> or go to the web and find the definitive resource for the language and
> all of its (vast) libraries. They expect to write a library and have it
> work with the language anywhere they go. Scheme simply doesn't have that.
Good point. Some languages are good, but don't have sufficient
support. It's hard to find
stuffs (tutorials, libraries, forums) in Scheme, Erlang and others.
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 =)
I think that any higher order programming language can be used for
intro courses. So why I would use a
language that is not used for real programming if I can use one that
is used?
I know almost nothing about Python, but one is that Python doesn't has
macros. But how important are macros?
Here is a comparison between Python and Lisp: http://norvig.com/python-lisp.html