[plt-scheme] Re: plt-scheme type of language

On Fri, Dec 11, 2009 at 5:00 PM, Raoul Duke <raould at gmail.com> wrote:
>> I think the "for variables" bit is what is considered bad, not the
>> more general concept of dynamic binding (which is good). To say
>> nothing of delimited control, etc as addressed in that paper.
>
> ah! thanks.
>
> fwiw, i'm definitely on the side of "talk about the wrong stuff, too".
>  arguments such as there's too much wrong stuff to discuss is, to my
> ears, unfortunate in that i think it is blocking off a useful route to
> teaching, and is also potentially stifling of new ideas. since i am
> not myself a teacher i can say that ideally a teacher should be able
> to / not be afraid of allowing some, but not too much, drift. of
> course how much is subjective.

To use the above example, if students are learning about programming
languages, they are just learning for the first time what variable
bindings really mean and how to implement them.  Trying to throw
lexical and dynamic binding in at the same time, and make a meaningful
comparison, and evaluate it in the context of both implementation and
pragmatic programming, is overload.  Once the students have a few
interpreters under their belt with lexical binding, maybe they can
look back and see how dynamic binding would have impacted the
implementation.  Once they've written a few interesting programs using
recursion and/or higher order functions, maybe they can look back and
see how dynamic binding would have impacted the design.  Before that?
They lack a lot of context that gives insight into the issue.

In general, it's very hard to present a convincing argument for
"computing X the Y way is *right*, and computing X the Z way is
*wrong*", when your students are still struggling to figure out what X
is, what right and wrong are with respect to X, and (early enough in a
curriculum) what computation even means.  It is generally necessary
first to address what X is, and use Y (the right way, to the best of
the teacher's knowledge) as a tool for that.  Later, when X and Y are
well understood, Z can be introduced and compared.  But comparing Y
and Z up front is really tricky, and "later" must often fall to
another class because X is not the only topic to squeeze into a
semester.

I think the "wrong stuff" can be fit in.  But in course 1, you can't
fit in much if any "wrong stuff".  In course 2, you can evaluate the
"wrong stuff" from course 1, and so on.  "Wrong stuff" is a deeper
insight, and comes well after "right stuff".  For instance, in course
1, you can teach students how to write programs that don't raise
errors.  By course 2, you might be ready to introduce the idea of
errors, and either discuss correctness formally or introduce
exceptions.  The topics work themselves in, but it's a progression.

And sometimes, of course, you find out what you thought was the "right
stuff" was actually the "wrong stuff".  (Course 1: learn to write
bubble sort.  Course 2: learn to never, ever write bubble sort!
[Course N: learn that sometimes, you really should write bubble
sort!])

--Carl