Matthias Felleisen wrote at 05/28/2012 11:17 AM:
But as I keep emphasizing when I teach this material, map& fold& filter and
friends *are* loops and we teach you how to write your own loops first so that you
understand what they are and can write your own when everything else fails. BUT one
thing I know is that you can't legislate out bad habits :-)
Oh, I wasn't speaking of undergrad education; you guys have an immensely
better understanding of what works for that.
I'm concerned here with people coming to Racket as an experienced
programmer or otherwise outside of your undergrad curriculum, many of
whom simply aren't going to work their way through HtDP before diving in.
Here's what I think is becoming a typical scenario:
1. Our protagonist, an experienced programmer, comes to Racket, reads
through the Guide, and skims the Reference on the train.
2. Protagonist sees the fancy "for"* constructs, and figures that it the
way to do things.
(I suspect that some contributors to #2 are: (a) in other languages
protagonist knows, newer generalized iteration/enumeration/etc.
constructs are generally preferred to their lower-level precedents in
the same; (b) from reading the documentation, the fancy constructs look
powerful, and the assumption is that this is the powerful Racket way to
do this thing protagonist has already conceptualized; and (c) when
protagonist posts or lurks on the email list, they see beginners asking
questions about how to do something and being offered answers that
combine these fancy constructs.)
3. Protagonist proceeds to program in 'idiomatic' Racket, using these
fancy constructs. Protagonist might never get the introduction to some
of the basics that s/he would've, had protagonist come to Scheme
descendants 10 years earlier.
4. Protagonist encounters problem for which these conveniences, and the
'idiomatic' way they've been using the conveniences, is not a good fit:
(a) it has limits they don't know how to work around; or (b) how they're
combining constructs is not as fast as they expect.
5. Protagonist asks about this problem they're having, and someone says,
"Oh, you have to not use those features that everyone has been telling
you to use since you started, and instead do it this other way that
might hurt your brain a little if you weren't taught it from the
start"... it might sound like the person is telling them "Don't use the
actual language; instead use this inline assembler" (implying that the
language isn't fast enough or flexible enough). When I think the truth
is more that we're showing them the core language and model -- which is
a very nice high-level language and model -- rather than the
conveniences spread thinly atop that.
One funny thing is, if/when I finish my book -- which is supposed to be
"professional" perspective stuff that's complementary to the existing
Racket manuals -- there will probably be at least one chapter that goes
back to ancient stuff like how to use list-processing primitives with
recursion, which I believe used to be the *only* thing many students
were taught about Lisps in "academic" classes in school. :)
Neil V.
____________________
Racket Users list:
http://lists.racket-lang.org/users
