[plt-scheme] Re: Apparent inconsistencies between original spirit of RnRS and R6RS [Fw: Ann: Sketchy LISP, Third Edition]

On Thu, 7 Aug 2008 10:51:38 +0100, "Noel Welsh"
<noelwelsh at gmail.com> wrote:

>2008/8/7 Benjamin L. Russell <DekuDekuplex at yahoo.com>:
>> One of the main reasons that I preferred Scheme over Common Lisp
>> was the succinctness of Scheme, caused precisely by the lack of
>> libraries.  One of the main reasons that I stopped studying Java was
>> precisely the huge growth in libraries...
>>
>> I have an ominous feeling of dark clouds approaching....  I just hope
>> that Scheme doesn't become the kind of monstrosity that Java and
>> Common Lisp have become, requiring constant flipping through huge
>> library reference manuals just to use. ...
>
>I don't understand this argument.  Either your program benefits from
>libraries or it doesn't.  If it does why wouldn't you use them, and if
>it doesn't why wouldn't you just ignore the libraries?  For example,
>if you were writing an image processing program in Java you'd be
>bonkers to not at least look at the Java image API.  You might then
>decide it doesn't fit your needs or is too hard to use, but I don't
>see how this can become a criticism of the language.

Okay; after some further discussion on comp.lang.scheme, I discovered
that R6RS, unlike Common Lisp, allows the language to restrict the
imported libraries so as not to import those that are undesired, so
this is not a concern with R6RS in its present state.

My worry concerned my experiences with Common Lisp.  When I was
starting out in my first course in Computer Science, which used both
Common Lisp and Scheme (and a one-page translation chart, labelled
"Common Lisp for Schemers," written by the professor, Drew McDermott,
to let us do the exercises in SICP in Common Lisp if we preferred),
back in fall of 1990, we used, if I remember correctly, a reference
manual for Franz Lisp that was over a thousand pages long that
documented the available libraries.

Being new to Common Lisp, I was afraid of namespace collisions, and
didn't know how to avoid them yet, so I kept thumbing
through this huge reference manual every time I defined a new function
to ensure that the following conditions held:

1) I wasn't reinventing any functions that already existed, and 

2) I wasn't redefining any reserved words.

Because I was still new to Common Lisp, I thought that all existing
function names were reserved words, and was afraid that renaming an
already-existing function would cause a naming conflict.  (It turns
out that this worry was apparently well-founded, because there is
apparently a specific section in chapter 11 that prohibits redefining
the operators of the package CL.)

Because the level of this course was still introductory, some of the
other students actually told me that I could probably have done the
assignments faster by just ignoring this book and coding all the
elementary functions myself.  Further, some of these students told me
that some of the existing functions were inefficient, and that I could
probably rewrite them myself to work faster, so that there was little
reason to use these functions.  These statements caused even more
confusion, because I didn't know enough yet to distinguish between
inefficient and efficient functions just by looking at their code.

This book caused a lot of confusion for me in this class, because I
was still new to Common Lisp and didn't know enough reserved words to
be able to avoid namespace collisions easily, so I spent about ten to
fifteen minutes flipping through the book every time I redefined a new
function.  I couldn't escape the feeling that using such a huge
reference for an introductory course was a mistake.

When a later course switched from Common Lisp to Scheme, which had a
much smaller community standards document, I was elated:  Both the
namespace and the set of included functions was much smaller, so I was
finally free to concentrate on the algorithms themselves, rather than
searching through a thick reference manual to avoid reinventing the
wheel and encountering namespace collisions.

While libraries are definitely a benefit for professional programmers,
I believe that they can actually be a hindrance in an introductory
course in computer science, because of the following reasons:

1) They shift the focus from thinking about the underlying algorithms
to looking up libraries, and 

2) They can cause confusion for some beginner-level students who do
not know enough reserved words to avoid namespace collisions easily.

For beginners, keeping the language simple helps immensely.  In
particular, it helps to keep the student focused on algorithms, rather
than libraries, and to keep from having to worry about namespace
collisions.  I just hope that the changes in R6RS will still allow
beginning students who use R6RS to focus not on using libraries and
avoiding namespace collisons, but on applying language-independent
programming concepts creatively.

-- Benjamin L. Russell