Tag: Study-HTDP

In problem 9.5.5, I knew I wasn’t understanding something. I thought that I had followed the recipe, yet I couldn’t solve the problem. That alone was a red flag indicating that I most probably did not follow the recipe!
In this discussion everyone helped me to see what I was missing. The thing was that I was missing something about recursion, the fact that you can figure out what you need to do by combining this thing with the rest of the things.
To specific, the step that I had skipped was literally taking the expected data and using that to determine the combination that needs to occur within the program body. Before, my approach had always been to solve “the whole problem” at once for the recursive step. Following the recipe, you can much more easily see what you are missing.

In problem 10.1.9, I wanted to force a problem to be recursive when it really wasn’t. Matthias and Carl helped me see the difference here in the discussion that followed. Here are some notes:
Matthias:

In HtDP, the word “natural” is a technical word. It means
if your INPUT data definition has a self-reference in the Nth clause for the Kth field then your template has a recursion in the Nth cond clause for the Kth field.
Try this:
An RD is one of:
— ‘doll
— (cons RD empty)
Problem: design a function that counts the number of cons layers around ‘doll.

Carl:

what’s so recursion about it? To be less cryptic, if you read your purpose statement, and apply it to the recursive call, does it make sense? Are you really solving a smaller instance of the same problem, or are you just solving a smaller problem? The former is recursion; the latter is not (and suggests either inlining or a helper function).
For future reference, what I described is a way to tell after the fact whether what you wrote makes sense as recursion, but what Matthias described is the part of the design recipe that tells you whether to use it or not before you even start. Focus on what he said (and what’s in the book) for figuring out how to apply recursion, and you’ll find you can always answer what I asked with “yes”.

Originally posted here:

You can check for error messages on your functions by using:
(check-error (fun arg1 … argn) “fun: <err message>”)
See also: here

Originally posted here:

In DrScheme you can comment out code either using semicolons or by using a “box”.
The way that it works is that you:
1. Select the code you want to put in a comment box.
2. Go to the Scheme menu and select Comment Out With a Box.
You may find this particularly useful when you get to the structure template definitions in chapter 6. It makes them much nicer to write, read, and maintain.

This post illustrates a interesting point about the language:

1. Functions must take at least one argument

In the data-driven world, namely MATH, there is no notion of a definition defining anything other than a translation of something into something else. Interesting.

When you work on your exercises, you can leverage DrScheme to make it easier to find particular functions or bits of homework by using the definitions dropdown. I posted on it here:

Here is how I implement exercises. I say implement, because I am concerned here with a coding detail, *not* design recipes.
DrScheme has a nice feature in the top-left side of the window (roughly) called the “definitions dropdown”. Using this dropdown you can see all of the names you’ve got defined in the Interactions area.
So for example if you had entered (define x 10) in the Definitions are then you would see an entry in there that says “x”. You can leverage to make keeping track of your exercises easier. This is what I do, I keep all of my exercises in the same file as long as it makes sense to do so, and as part of that before every exercise I add something like this:
(define 2.3.2 true)
That tells me:
1. What my answer was for the exercise.
2. Whether or not it is finished.
That is how I keep all of my exercises in the same file and still have it make sense since each exercise creates any number of definitions!

Originally posted here:

Most of us here are already programmers, or want to be. All of us are going to give up time to work through HTDP. It is a sacrifice. How do we know what will happen? Well, we don’t.
I think of this first group as being an experiment. We’re going to find out what works and what doesn’t, we’re going to figure out who might like something like this more than others, and most importantly we’re going to get a good sense of what one learns on this path.
What I can tell you is that HTDP has excellent reviews, an excellent track record in schools around the world, and most importantly excellent authors who are really dedicated to teaching. That last part
is particularly important. It was written by teachers, not programmers. They know how to teach; most of us don’t!
For me, that, combined both with my interest, and what I’ve seen so far in the book, is enough.
This isn’t a learn programming in 21 days scam, fluff book on the latest fad language, or the extended sermon of someone who makes his money by talking and not doing much else.
This is an experiment, for programmers, and, I think it is going to pay off pretty well.

Based on what I’ve seen so far, we are all learning a lot about: programming, communication, and culture. It is true, it is an experiment; the notion of good and bad are less important here, everything we are learning, painful or pleasant, is very valuable.