[plt-scheme] The perfect teaching language--Is this too much to ask for?

>> 5. I don't understand how your students can have test cases for each
>> function and NOT see that their functions are producing the wrong things.
>> Code excerpts would be helpful.
> Here's a common example with a single function:
>
> ;; A family-tree-node (ftn) is:
> ;; empty, or
> ;; (make-ftn ftn ftn symbol number symbol)
> (define-struct ftn (father mother name dob eyes))
>
> (define Carl (make-ftn empty empty 'Carl 1926 'green))
> (define Bettina (make-ftn empty empty 'Bettina 1926 'green))
> (define Adam (make-ftn Carl Bettina 'Adam 1950 'yellow))
> (define Dave (make-ftn Carl Bettina 'Dave 1955 'black))
> (define Eva (make-ftn Carl Bettina 'Eva 1965 'blue))
> (define Fred (make-ftn empty empty 'Fred 1966 'pink))
> (define Gustav (make-ftn Fred Eva 'Gustav 1988 'brown))
>
>
> ;; names: ftn -> list-of-string
> ;; consumes: a ftn
> ;; produces: a list of all names of people reachable
> ;;           from that ftn
> (define (names a-ftn)
>  (cond
>    [(empty? a-ftn) ""]
>    [(ftn? a-ftn) (append (names (ftn-father a-ftn))
>                          (names (ftn-mother a-ftn))
>                          (list (ftn-name a-ftn)))]))
>
> (check-expect (names empty) "")
> (check-expect (names Adam) (list "Carl" "Bettina" "Adam"))
>
> The total error you get for this is:
> append: expected argument of type <proper list>; given ""
>
> Students look at the three arguments to append, see two calls to names
> and a list. names's contract says it returns a list-of-string, so they
> have no idea what could be going wrong. No, they don't notice the
> inconsistency between the contract they wrote and the value of "" as
> both the answer to one of the cond branches and one of their test
> cases.

Hmmm.....I am sorry to say that I do not find this yelling for types
in a beginner's course. As a dedicated and caring instructor, I
suggest that you accept these "growing pains" students must go
through. Getting types right can be a tricky proposition for those
that are taking their first steps in programming. Let's think about
the whole process students go through to produce a working function.
There is that rather "giant" step of designing the function correctly
(giant eventhough HtDP makes it as easy as it can be) and there is the
other "giant" step of getting the syntax right. Do we want to pile on
top of these getting the types right? I think students are better
served without static types at the beginning. Let them run into
dynamic type errors and think through their design which is where the
focus should be. They can learn a lot from such errors and growing
pains. One of the valuable lessons may be that errors are usually in
the design. One of the bad habits they may not pick up is to simply
try to get a type "right" that allows the program to run. I have seen
my fair share of students that do not dare to change the types in
their programs, because "the program runs with them." Forget the fact
that they really have the design wrong and, therefore, the wrong
types.

If the above is not convincing, how about getting beginning students
to write typed programs for abstract functions that manipulate
compound data structures? How about getting the types right for
programs that use encapsulation? All of the sudden, types get in the
way of undertsanding fundamental concepts. Be careful for what you
wish for!

Just one more note, do you really like Python as a language for
beginners? Not only is it typed, but it has objects! Objects without
understanding abstraction is a recipe for developing poor programming
habits IMHO. I fully expect to get some noses out of joint with this
last comment, but it is meant to stimulate thought not controversy.

-- 

Cheers,

Marco