Stuff I would have mentioned: - some_code... where vs let... in some_code: these two constructs play a fairly similar role in Haskell. The problem with where i

Stuff I would have mentioned: - some_code... where vs let... in some_code: these two constructs play a fairly similar role in Haskell. The problem with where is that it lets you introduce the value of a binding AFTER using said binding. Ugh. - functions defined over several lines using pattern matching: I'm still not sure if it's a good idea or not, but I think overall a shorthand syntax like OCaml's "function" keyword (except less unfortunate) is better - pattern matching and guards are separated (try going back to Haskell after trying a language which combines the two..) -the absence of named and default arguments is an issue in a language like Haskell. This leads to many instances of "guess what the fourth argument here means"/"let's create a record type just for the arguments of this function" and elegant APIs such as function1, function1' and function2'' (good luck figuring out from the name only which function you need) - a much stronger focus on brevity (single-name variables all over the place, horrible ASCII DSL galore) than on legibility - I think the record situation situation improved since I stopped doing Haskell, but when I did, it was really a trainwreck (having to prefix the field names of all your records to prevent collisions is not a feature).