SICP or HTDP?

A non-programmer wants to learn. Which do I show them: SICP or HTDP? Or does trying to teach them SICP in MirandaHaskell (for the syntax & pattern matching) make more sense?

Learn programming with K&R C and go climb a wall of dicks.

*grabs dicks*

SICP, then K&R, then it's up to you. HTDP is optional before SICP if you don't feel you can tackle SICP, but frankly, I found its contents quite redundant fi you plan to read SICP.

>>1
So you want to scare them off of programming by showing them things that aren't at all like programming?

SICP if he's smarter, HtDP otherwise. Also, K&R before or after.

>>1
How does overloading them with syntax help them when reading SICP? How does making them argue with a type checker help them?

K&R sounds like car

>>8
My other K&R is a SICP.

my other anus is gnus

>>4
Make sense. This is someone with no experience with programming at all, but she's a scientist and very good at math.

>>7
Because often the syntax makes more sense to people familiar with mathematical notation. Prefix isn't hard to learn, but (a+b) == (c*d) is still more straightforward than (= (+ a b) (* c d)).
Similarly,
sum term [] = 0
sum term x:xs = (term x) + (sum term xs)
shows the algorithm more clearly than
(define (sum term sequence)
  (if (null? sequence) 0
      (+ (term (car sequence))
         (sum term (cdr sequence))))).

I'm a fan of Scheme. It has some serious advantages over ML-type languages. However, in terms of being able to clearly express an algorithm to people familiar with math but not Lisp, the ML family usually wins.

>>11
she
scientist
very good at math
no

>>11
Let's assume I agree with you on the syntax point. What about the type checker issue? If I may quote every Haskell user with a blog
once I've battled with the type checker my program is usually correct.
Bullshit, I know. But if they don't have experience in programming then every inconvenience when it comes to producing runnable code matters.
I would also claim that lazy evaluation more difficult to build a mental model of, but SICP is fully functional for the beginning anyway (I'd assume HTDP is similar)
There is also  the issue of reading a book in one language while trying to code in another. It can be both fun and educational, but not for a beginner. If you do want to use Haskell, why not use a different book?

>>13
Type signatures can be a hurdle. It took me quite a while to get them. However, (1) they aren't necessary for most of the simple programs a beginner would be writing, and (2) I think they also lead to more quickly understanding the underlying structural similarities of algorithms. I also don't think they're any more difficult for a non-programmer to learn. Furthermore, in simple* programs the complaints of the type checker can be more informative than the errors you run into in a dynamic language.

Trying to learn programming from scratch by reading a book in one language and writing programs in another is indeed a terrible idea. In that case I'd either have to find a good Haskell (or ML family) book targeted at beginners (unlikely) or essentially re-write the code in SICP or HTDP as we go along. The second option would be a pain, but worthwhile if it made the rest of the task easier.

_________________
* The type checker can be hellaciously uninformative once you get beyond toys.

>>13
>>14
Haskell also has the advantage of being free from such annoyances as and being defined as a macro (and therefore not first class). If you're used to Scheme then you've long-since worked around them, but they can be real stumbling blocks for a beginner.

In a lazy language, you don't have to resort to hacks to avoid unnecessary evaluation.

>>15
lazy evaluation is a hack

While it's true that lazy evaluation gives you various useful properties, in eager languages, it makes no sense to have the short-circuiting AND as a function, because functions mean each argument is evaluated (non short-circuiting and is a function). Of course, having a macro wrap the arguments into lambdas would allow you to emulate lazy evaluation quite easily in Lisp, and there's many libraries and utility functions which show how to do it (simple force/delay takes a dozen lines or less to implement in CL).

I actually wonder what practical advantages lazy evaluation usually buys if forced on the entire languages. I usually just use it explicitly only when I need it in Lisp, but I should probably learn me a Haskell someday. (From Haskell's parents, I only know ML).

>>15
Haskell programmers conveniently forget that it has "eager" points just like lisp has its "lazy" points. The difference being, as far as I can tell, that there is no way to add new ones to Haskell.

>>11
Hey cool, let's try it out!

import System( getArgs )

mysum term [] = 0
mysum term (x:xs) = (term x) + (mysum term xs)

main = do
  [arg] <- getArgs
  putStrLn $ show $ mysum id [1..read arg]

~ $ ghc test.hs
~ $ ./a.out 10
55
~ $ ./a.out 10000
50005000
~ $ ./a.out 1000000
Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize -RTS' to increase it.

Meanwhile in Scheme:

> (sum values (iota 1000001))
500000500000

What are you going to tell the student? ``Oh, Haskell is lazily evaluated so the stack and memory use is practically impossible to figure out and will trip you up in even the simplest cases.''?
The Haskell code resembles a mathematical function definition, but it doesn't clearly describe the algorithm i.e. the steps taken to arrive at the result. Pattern matching is another cause of this.
But I'm sure you're a fan of Wadler's ``Why Calculating is Better than Scheming'' and believe that adding lots of magic and syntactic puke will help people learn fundamental CS concepts.

>>11
Conflating pattern matching and syntax.
You don't have to have a million bizarre syntactic quirks to implement pattern matching.

>>14
I want to mention that there is a book called "Simply Scheme" that is designed to teach what SICP does in an easier way. The author adds some Logo like syntax to Scheme to make some syntax concepts easier to understand.

>>17
I actually wonder what practical advantages lazy evaluation usually buys if forced on the entire languages.

Sometimes you want lazy evaluation; sometimes you don't. Some languages are strict by default and let you tell them to be lazy. Some languages are lazy by default and allow you to be strict.

I'd rather this not devolve into a Lazy vs. Strict debate, because that really isn't the point. ML is probably more or less equivalent to Haskell for my purposes.

>>18
...there is no way to add new ones to Haskell

seq can be used just as any other function. Is that not a good enough building block?

>>19
Hey cool, let's try it out!

That's a good argument against using Haskell as an ENTERPRISE QUALITY language, but as a teaching language I don't think it's a huge deal.

>>20
You don't have to have a million bizarre syntactic quirks to implement pattern matching.

I'd rather not implement pattern matching at all.

>>21
Logo

I had forgotten about Logo. That's actually the first language I ever programmed in! I'll check it out.

The Haskell Road to Logic, Maths and Programming might work out for her coming from a non-programming/ math background. Sure it's not going to teach you the fundamentals of computer science, but for somebody coming from a math background it teaches how to elegantly program proofs using haskell.

The Haskell Road to Logic, Maths and Programming teaches you to love naming variables tersely.

>>12
Do not be so quick to discount his post, Tyrael.  After all, she could be Russian.