[plt-scheme] Re: HTDP - evidently not for everyone.

On Fri, Feb 12, 2010 at 11:58 AM, Stephen Bloch <sbloch at adelphi.edu> wrote:
>> I wrote:
>>
>>> My textbook makes a point of giving, for each topic, a "worked exercise"
>>> followed immediately by an unworked exercise that's almost identical, then
>>> one that's a little more different, and so on.
>
> and Matthias replied:
>
>> .. which of course is the antithesis of HtDP. So perhaps you're just
>> trying to prove the subject line :-)
>
> Actually, I don't see how this is inconsistent with HtDP at all :-)
>

I have to echo Stephen, here. It seems to me that HtDP's points (and
it's possible I've completely missed them, even after all this time
teaching it) are

1. The form of the data informs the form of the functions that operate
on data. In other words, you can write templates that make the "stuff"
you have to work with visible in a way that encourages you to combine
it the right way to get what you want.

2. Abstraction is powerful. Realizing that you can make things more
general by factoring out things that are different and introducing
variables to represent them is one of the most fundamental skills of
computer science.

3. There is a right way to approach problem-solving: think about the
data's structure, make explicit what you expect to get and what you
plan to produce, write test cases before you try to write code, etc.

HtDP introduces functions in the text and then has exercises that are
something like those functions, but also different from those
functions. For sharp students, the leap from example function to
exercise function is usually doable. Stephen seems to be providing
stepping stones that lead students from the example function to
something substantially different without as big a leap.

Let me give you an example. I had students write my-reverse, which is
just the reverse function. Since the template already encourages them
to call (my-reverse (rest the-list)), they just have to figure out
what to do with the first element. Believe it or not, several of them
could articulate that they needed to "put the first element at the
end," but had no idea how to do it, even when I asked, "Well, how
could you do that?"

That's not terribly surprising until you realize that the problem
right before my-reverse was called put-at-end and took a symbol and a
list-of-symbol and did what you'd expect.

All of them felt stupid when I pointed at the previous function on
their screens, but feeling stupid when I told them "the trick" didn't
prevent them from missing it in the first place. Great programmers
have a remarkable intuition about how to jump these problem-solving
gaps, but solid programmers may not and may need more of the details
filled in. This is not unique to programming. I've been teaching some
middle school kids math to get ready for the MathCounts competition.
The hardest problems are sometimes orders of magnitude more difficult
than the exact same problem with an additional line drawn in the
diagram. The hard part is figuring out where to "draw the line". I
think HtDP gives people the opportunity to jump the gaps, but I don't
think it's inconsistent with HtDP to make the gaps less wide.

Then again, maybe I've missed the whole point.

Todd

P.S. Two of my former students, both college sophomores this year, are
doing really well in the internship hunt this year. One has already
been offered a spot at Google and the other has on-site interviews at
both Microsoft and Fog Creek Software, the home of Joel from Joel on
Software. Both started in HtDP, but took my AP class before I knew
about HtDC. These curricula have the ability to reach a huge range of
students--from these insanely smart ones to students who learn to
organize their thoughts for the first time because the computer makes
them.