Re: [Scheme-reports] WG1 Scheme as a language for CS1 Jeronimo Pellegrini (09 May 2011 03:12 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 John Cowan (09 May 2011 16:57 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Jeronimo Pellegrini (09 May 2011 18:06 UTC)
Re: WG1 Scheme as a language for CS1 Arthur A. Gleckler (09 May 2011 18:10 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Jeronimo Pellegrini (09 May 2011 18:34 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Andy Wingo (09 May 2011 21:56 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Ray Dillinger (11 May 2011 03:14 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Alaric Snell-Pym (10 May 2011 09:00 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Alaric Snell-Pym (10 May 2011 08:54 UTC)

Re: [Scheme-reports] WG1 Scheme as a language for CS1 Jeronimo Pellegrini 09 May 2011 03:12 UTC

On Sun, May 08, 2011 at 06:45:11PM -0700, Vincent Manis wrote:
> The small version of R7RS is supposed to be suitable as a teaching language. Now that the draft has been out for review for a few weeks, I feel ready to comment on the degree to which the WG1 language meets that requirement.
>
> My criterion is: would the WG1 language be usable, unaugmented, for about 80 hours of instruction taking a student from essentially no background in programming and computer science to writing and testing substantial multi-module programs using interesting data structures?  Similarly, could someone use a book that used only the WG1 language to learn programming on their own? (Disclaimer: I once co-authored an introductory computer science text that used Scheme. That was getting on for 20 years ago, I have no intention of doing it again.)

Incidentally, I am working on a text that uses Scheme.
It goes from zero to multithreading,  through all of syntactic
abstraction, continuations, and everything else -- up
to threads and networking. I try to show both how to *use*
and how to *build* the concepts (it's not an introductory
course).

The only missing feature from WG1 for me was TCP/IP (cannot even
be built on top of anything else) and threads (can be done with
continuations, but there's no standard WG1 API to mimic, and
I can't do multicore).

But then I'm OK with using whatever WG2 standardies (even if I
show how to build a threading system, I'll also show the standard
API)

I don't think I'd use WG1 scheme exclusively for teaching,
even if I was teaching Introduction to programming. There
will always be something from WG2 Scheme I'll probably want to
use (and it would be impossible to come up with a separation
of WG1/WG2 features that works out well for every possible
instructor or user).

So, if there are no RNGs, threads or sockets in WG1, I'll take
them from WG2 Scheme (they're not *different* languages after all).

> 2. [The controversial issue] WG1 has already taken a vote and decided not to include random number generation in the language. I very respectfully disagree with that decision, and this is my opportunity to say why I think that the WG should revisit its decision.
>
> First, the need for the facility. We all, of course, like to play games. A standard early exercise in my introductory programming courses was Matching Pennies, aka Coinflip. This takes something like 20 lines of code, and is a coherent, interesting (for five minutes or so) application, where beginners can see an entire program that does something useful. In later years, I tended to think that a completely redesigned CS1 course ought to use nothing but games as its domain (running a SE training program for a videogame development company can have that effect on you), rather than the WG1-forced rule of banishing games almost completely.

Building one is not that bad. I've included in my text:

1) A linear congruential generator (the quick-and-dirty one). Yes, not
   good for simulations, much less crypto, but OK for learning how to
   implement blackjack or some dice game (by the way, it's cool to show students
   how to make a biased dice or other non-uniform toys :-).
   The important thing at this point is to make clear that "this only works
   for our litlte games"

2) After covering vectors, there's multiply-with-carry, which is a bit harder
   but not that much -- and this one works fine for non-crypto applications,
   and this *also* should be clear to the student.

3) As an optional exercise, Blum-Micali. Not included in the text because
   it doesn't make much sense withtout understanding *why* one would
   use such a slow generator.

> I believe that a very basic facility for generating random numbers is essential in a core language.

I'd say it would be convenient for a first programming course, although not really
essential (it can be built on top of current-jiffies, although the quality of
a system clock could be questionable for seeding the RNG).

> I further believe that, if WG2's random number facilities provide all the features found in SRFI-27 (or maybe even more features), many casual users of random numbers will prefer a more spartan API. The proposed facility therefore serves a purpose even in a WG2 implementation, just as both (READ port) and (READ) do in core Scheme.

Agreed...

> Second, the proposed API. This is taken from Dartmouth BASIC (the 1968 edition), and should cause no surprise to anyone. There is an optional module basicrandom, which hides a pseudorandom number generator that approximates a uniform distribution, and exports the following.

> (... RANDOMIZE! & RANDOM-REAL API described here)

> Third, the rationale. I'd be curious to know if anyone has read this far in the message :)

Someone did. :-)

> Names are given for attribution only, and refer to messages on the WG1 mailing list last November. No claim is made that the persons cited agree or disagree with the corresponding quoted text as of now.

> `If I'm understanding correctly (medium probability :-) the dispute, apart from whether to say anything at all about randomness, is between the complexity needed to get it exactly right for complicated uses and the simplicity to make it usable by people like me. This could be resolved by specifying a simple interface on top of the complicated one, and putting the whole thing in a module.' (Brian Harvey).
>
> YES!!!!

>   Objections:
>
>     - `For the record, I don't think we need randomness in WG1. A user can roll their own, given good integers etc. Yes, they can do it wrongly. But the same argument applies to all sorts of algorithms. I have textbooks full of algorithms that, at first sight, are overcomplicated, but fix all sorts of subtle problems in the 'obvious' approach (if there even is one). Why are random numbers special?' (Alaric Snell-Pym)
>
>     Answer 1: Why is SQRT special? NUMBER->STRING? APPEND? *?

The same is true for complex numbers, but there are instructors who will
implement those (complex API, SQRT, NUMBER->STRING etc) as examples
of procedures :-)

>     Answer 2: Something a student will want to use within 3 hours of starting to learn Scheme ought to be built into the language.

I think it's OK to have RANDOMIZE! and RANDOM-REAL.
But I would object to excluding the time-related procedures. It's OK to
have a simple random numbers API, but it would be really sad to not
be able to show how to build "unpredictability" into simple games without
having to resort to the "(RANDOM-REAL)" black-box.

Besides that, I think it's important to let the user seed the RNG
(not force, just let). First, because one can easily reproduce the behavior
of a program using the same seed; second, it becomes very clear to who'
s learning that he's not generating any *truly* random numbers.

And the easiest seed for didatic purposes is a clock.

J.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports