Some advice on ML from Matt Might, past TA for cs4240

On average, I find good, solid ML code does in one line what good, solid C code takes 10-20 lines to do. Morever, the ML code is usually much more readable.

Though this goes against their strongest urges at first, strongly discourage:

1. Side-effected programming.
   Instead, in the few instances where side-effects would have been "nice," pass around extra state variables. SML or MLton will be able to optimize away most any perceived performance impediments.
   
   Mixing side effects with functional programming produces bugs and debugging nightmares of scales students can't imagine. You can promise the class that a side-effect-free program that survives the ML type-checker with no warnings has a 99.9% chance of being correct and bug-free. This is the most astonishing feature of ML---that the type system catches almost all your bugs. [The ML type-system has O(2^n) worst-case complexity, so the compiler has a license to do a lot of thinking about the safety of the code.]
   
   
2. Loops.
   In ML as in all functional languages, the idiom of choice for iteration is recursion and tail recursion. Often, iteration can be done away with by using map, foldl, foldr and app.
   
   
3. Conditionals.
   if-then-else is not used nearly as much in ML as in other languages thanks to features like pattern matching. Pattern matching makes recursion much easier to write and to read and it makes things like complicated tree- and graph-walking rather trivial. If students are using lots of if-then-else, they're doing something wrong.
   
   

The above imperative instincts will get students in a lot of trouble in ML's functional world, so strongly encourage students to use:

1. The ML library.
   A lot of really common tasks are packaged up in the ML library, and most students discover this far too late.
   
   
2. Currying and thunking.
   ML has great support for currying and thunking, and it helps out all over the place.
   
   
3. Polymorphism.
   Polymorphism in ML avoid lots of code re-writing. Students should probably keep a personal library of polymorphic ML functions that they build up over the semester.
   
   
4. (Thoughtful) explicit typing.
   Even though ML is implicitly typed, debugging goes faster if at a few key points throughout, explicit types are added. The garbage coming out of the error messages from the compiler becomes much more readable when explicit types are present near the offending code. That said, overly typing the code makes the source bulky and unreadable.