I have been teaching so-called advanced functional programing in OCaml for several years to “Bac+4” students (= first year of MSc) in a French grande école. Apart from the deep issue of being exposed to another way of thinking (w.r.t. programming languages featuring things such as pointers, imperative programming, OO design, untyped or explicitly-typed…), which is good, the more mundane but important issues for students I can think of are:
- a syntax that is not uniform for the most fundamental operation of the language: application. Function application is generally curried, data constructor looks like application (and semantically is kind of) but it looks uncurried, functor application uses parentheses, polymorphic-type application is postfix…
- when teaching GADTs, you can’t define a function as usual: introducing the
type a b . ...annotation forces to declare the function type, then parameters on the RHS of=, under thefunkeyword (this is unsettling for students) - no good history on namespaces,
openis too coarse andlet open Long_module_name inorLong_module_name.( ... ), something likeopen Long_module_name.( f1, f2 ...)would be nice - dune requires 3 files just to compile a basic file and launch utop
- dune utop is in fact quite long to launch utop (several seconds on my not-so-old laptop for a single ml file, without libraries apart from ppx_inline_tests)
- apart from the fact that ocamlformat is less and less customizable and a bit too opinionated in my mind, auto-formatting (which is quite good to show students how to format code) is not run if you haven’t a fourth file (.ocamlformat, even empty)
- by default, dune explores all the hierarchy upwards when you invoke it until finding a
dune-workspacefile. Needless to say, students often have buggy files everywhere in their hierarchy and then, forgetting to create a dune-workspace file, see dozens of errors that seem incomprehensible to them. (For people who discovered computers through the terminal, like me, notice that a lot of fresh students do not even know how to explore a file hierarchy graphically, let alone in the terminal! Blame smartphones and their search tools that incite students into seeing the file system as a blob rather than a tree, although CS students who lack curiosity w.r.t computers and OSes can certainly be blamed too.) - the default “dev” profile of dune treats warnings as errors, which is too strict for students (e.g. an unused variable, so common in student programs, yields a warning). But we can’t use the “release” profile because it switches testing off, and we encourage our students to test their code. So we must teach our students to update the dune-workspace file to add a specific clause
(env (dev (flags (:standard -warn-error -A)))), whose syntax no one can remember. -
dune runtestdoesn’t show anything if things go well, not even something like “all tests ok”, so students are a bit lost - VS Code, by far the most used tool nowadays, has a good OCaml mode, but still lacking: some code is often shown as badly typed while it’s correct (as can be checked by running dune build on the command-line); types shown by the plugin sometimes differ from those shown by ocamlc; the most important refactoring operation, namely renaming an identifier in context (= taking all sorts of binders into account) is AFAIK impossible; code formatting doesn’t seem to agree with
dune build -w @fmt --auto-promote -
eval $(opam env)is incomprehensible for students (and actually often needed) - the fact that there are several programs to get you running (mainly opam and dune), with different command-line syntaxes, although comprehensible, adds some unwanted complexity in the eye of newcomers
- finally, the elephant in the room: error messages are far better than they once were. But there are still some issues. The most frequent errors, apart from syntax errors (the location of which is always difficult), are type errors. I think terser, more emphasized (using colors and/or font weight), more to the point, messages could entice students to make the extra mile to try to understand their errors (instead of calling the teacher immediately). Also, I seem to recall that type errors in the context of modules and functors can be very long while in fact they resolve to a small mistake concerning only one function in a large module body. Finally, once again, the VS Code plugin typer does not always agree with the compiler typer…
It looks like most of these issues are actionable and could be addressed reasonably easily by tooling developers in the know.
(I’m not expecting anyone to implement a new, uniform syntax (item 1) but I would personally welcome this breaking change, together with a tool to convert the “old” syntax to the new one (I’m old enough to recall it already happened, although for smaller-scale changes).)