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

Of course, PLT Scheme takes this particular belief directly to heart
and has a series of languages that grow with the student thru the
introductory course that, more than just being small, are designed
with the curriculum in mind. Here's a talk about it, if you're
interested:

  http://www.ccs.neu.edu/home/matthias/Presentations/ccsne.html

  http://www.ccs.neu.edu/home/matthias/Presentations/CCSNE/first%20year.pdf

And, just in case it wasn't clear from what was said earlier in this
thread, these languages are in fact libraries in PLT Scheme and yet
they enjoy the wonderful no-15-minute-flipping-required property. :)

Robby

On Fri, Aug 8, 2008 at 4:21 AM, Benjamin L. Russell
<DekuDekuplex at yahoo.com> wrote:
> 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
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>