[ACCEPTED]-Haskell or Standard ML for beginners?-discrete-mathematics

Much as I love Haskell, here are the reasons 37 I would prefer SML for a class in discrete 36 math and data structures (and most other 35 beginners' classes):

• Time and space costs 34 of Haskell programs can be very hard to 33 predict, even for experts. SML offers 32 much more limited ways to blow the machine.

• Syntax 31 for function defintion in an interactive 30 interpreter is identical to syntax used in a file, so 29 you can cut and paste.

• Although operator 28 overloading in SML is totally bogus, it 27 is also simple. It's going to be hard to 26 teach a whole class in Haskell without having 25 to get into type classes.

• Student can debug 24 using print. (Although, as a commenter points 23 out, it is possible to get almost the same 22 effect in Haskell using Debug.Trace.trace.)

• Infinite data 21 structures blow people's minds. For beginners, you're 20 better off having them define a stream type 19 complete with ref cells and thunks, so they 18 know how it works:

  datatype 'a thunk_contents = UNEVALUATED of unit -> 'a
                             | VALUE of 'a
  type 'a thunk = 'a thunk_contents ref
  val delay : (unit -> 'a) -> 'a thunk
  val force : 'a thunk -> 'a
  

  Now it's not magic any 17 more, and you can go from here to streams 16 (infinite lists).

• Layout is not as simple 15 as in Python and can be confusing.

There 14 are two places Haskell has an edge:

• In core 13 Haskell you can write a function's type 12 signature just before its definition. This 11 is hugely helpful for students and other 10 beginners. There just isn't a nice way 9 to deal with type signatures in SML.

• Haskell 8 has better concrete syntax. The Haskell 7 syntax is a major improvement over ML syntax. I have 6 written a short note about when to use parentheses in an ML program; this helps a little.

Finally, there 5 is a sword that cuts both ways:

• Haskell code is pure by default, so your students are unlikely to stumble over impure constructs (IO monad, state monad) by accident. But by the same token, they can't print, and if you want to do I/O then at minumum you have to explain do notation, and return is confusing.

On a related 4 topic, here is some advice for your course 3 preparation: don't overlook Purely Functional Data Structures by Chris Okasaki. Even 2 if you don't have your students use it, you 1 will definitely want to have a copy.

We teach Haskell to first years at our university. My 53 feelings about this are a bit mixed. On 52 the one hand teaching Haskell to first years 51 means they don't have to unlearn the imperative 50 style. Haskell can also produce very concise 49 code which people who had some Java before 48 can appreciate.

Some problems I've noticed 47 students often have:

• Pattern matching can 46 be a bit difficult, at first. Students 45 initially had some problems seeing how value 44 construction and pattern matching are related. They 43 also had some problems distinguishing between 42 abstractions. Our exercises included writing 41 functions that simplify arithmetic expression 40 and some students had difficulty seeing 39 the difference between the abstract representation 38 (e.g., Const 1) and the meta-language representation 37 (1).

  Furthermore, if your students are supposed 36 to write list processing functions themselves, be 35 careful pointing out the difference between 34 the patterns

  []
  [x]
  (x:xs)
  [x:xs]
  

  Depending on how much functional 33 programming you want to teach them on the 32 way, you may just give them a few library 31 functions and let them play around with 30 that.

• We didn't teach our students about 29 anonymous functions, we simply told them 28 about where clauses. For some tasks this was 27 a bit verbose, but worked well otherwise. We 26 also didn't tell them about partial applications; this 25 is probably quite easy to explain in Haskell 24 (due to its form of writing types) so it 23 might be worth showing to them.

• They quickly 22 discovered list comprehensions and preferred 21 them over higher-order functions like filter, map, zipWith.

• I 20 think we missed out a bit on teaching them 19 how to let them guide their thoughts by 18 the types. I'm not quite sure, though, whether 17 this is helpful to beginners or not.

• Error 16 messages are usually not very helpful to 15 beginners, they might occasionally need 14 some help with these. I haven't tried it 13 myself, but there's a Haskell compiler specifically 12 targeted at newcomers, mainly by means of 11 better error messages: Helium

• For the small programs, things 10 like possible space leaks weren't an issue.

Overall, Haskell 9 is a good teaching language, but there are 8 a few pitfalls. Given that students feel 7 a lot more comfortable with list comprehensions 6 than higher-order functions, this might 5 be the argument you need. I don't know 4 how long your course is or how much programming 3 you want to teach them, but do plan some 2 time for teaching them basic concepts--they 1 will need it.

BTW,

# SML has a truly interactive interpreter 10 in which functions can be both defined 9 and used. In Haskell, functions must be 8 defined in a separate file and compiled 7 before being used in the interactive shell.

Is 6 inaccurate. Use GHCi:

Prelude> let f x = x ^ 2
Prelude> f 7
49
Prelude> f 2
4

There are also good 5 resources for Haskell in education on the 4 haskell.org edu. page, with experiences 3 from different teachers. http://haskell.org/haskellwiki/Haskell_in_education

Finally, you'll 2 be able to teach them multicore parallelism 1 just for fun, if you use Haskell :-)

Many universities teach Haskell as a first 15 functional language or even a first programming 14 language, so I don't think this will be 13 a problem.

Having done some of the teaching 12 on one such course, I don't agree that the 11 possible confusions you identify are that 10 likely. The most likely sources of early 9 confusion are parsing errors caused by bad 8 layout, and mysterious messages about type 7 classes when numeric literals are used incorrectly.

I'd 6 also disagree with any suggestion that Haskell 5 is not recommended for beginners starting 4 out with FP. It's certainly the big bang 3 approach in ways that strict languages with 2 mutation aren't, but I think that's a very 1 valid approach.

• SML has a truly interactive interpreter in which functions can be both defined and used. In Haskell, functions must be defined in a separate file and compiled before being used in the interactive shell.

While Hugs may have that limitation, GHCi 16 does not:

$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> let hello name = "Hello, " ++ name
Prelude> hello "Barry"
"Hello, Barry"

There's many reasons I prefer GHC(i) over 15 Hugs, this is just one of them.

• SML gives explicit confirmation of the function argument and return types in a syntax that's easy to understand. For example: val foo = fn : int * int -> int. Haskell's implicit curry syntax is a bit more obtuse, but not totally alien. For example: foo :: Int -> Int -> Int.

SML has what 14 you call "implicit curry" syntax as well.

$ sml
Standard ML of New Jersey v110.69 [built: Fri Mar 13 16:02:47 2009]
- fun add x y = x + y;
val add = fn : int -> int -> int

Essentially, SML 13 and Haskell are roughly equivalent. I lean 12 toward Haskell because I'm loving the list 11 comprehensions and infinite lists in Haskell. But 10 I'm worried that the extensive number of 9 symbols in Haskell's compact syntax might 8 cause students problems. From what I've 7 gathered reading other posts on SO, Haskell 6 is not recommended for beginners starting 5 out with FP. But we're not going to be building 4 full-fledged applications, just trying out 3 simple algorithms.

I like using Haskell much 2 more than SML, but I would still teach SML 1 first.

• Seconding nominolo's thoughts, list comprehensions do seem to slow students from getting to some higher-order functions.
• If you want laziness and infinite lists, it's instructive to implement it explicitly.
• Because SML is eagerly evaluated, the execution model is far easier to comprehend, and "debugging via printf" works a lot better than in Haskell.
• SML's type system is also simpler. While your class likely wouldn't use them anyways, Haskell's typeclasses are still an extra bump to get over -- getting them to understand the 'a versus ''a distinction in SML is tough enough.

Most answers were technical, but I think 10 you should consider at least one that is 9 not: Haskell (as OCaml), at this time, has 8 a bigger community using it in a wider range 7 of contexts. There's also a big database 6 of libraries and applications written for 5 profit and fun at Hackage. That may be an important 4 factor in keeping some of your students 3 using the language after your course is 2 finished, and maybe trying other functional 1 languages (like Standard ML) later.

I am amazed you are not considering OCaml 6 and F# given that they address so many of 5 your concerns. Surely decent and helpful 4 development environments are a high priority 3 for learners? SML is way behind and F# is 2 way ahead of all other FPLs in that respect.

Also, both 1 OCaml and F# have list comprehensions.

Haskell. I'm ahead in my algos/theory class 11 in CS because of the stuff I learned from 10 using Haskell. It's such a comprehensive 9 language, and it will teach you a ton of 8 CS, just by using it.

However, SML is much easier to learn. Haskell 7 has features such as lazy evaluation and 6 control structures that make it much more 5 powerful, but with the cost of a steep(ish) learning 4 curve. SML has no such curve.

That said, most 3 of Haskell was unlearning stuff from less 2 scientific/mathematic languages such as 1 Ruby, ObjC, or Python.