I’m teaching OCaml to a few high school students who only have a senior (“AP”) Java background. I’m not re-inventing the wheel; much of the teaching material comes from the Cornell CS3110 course. And a couple students are interning with me, so I’m highly motivated to track down the newcomer problem spots. So far the problems have been:
- Explaining the need for
eval $(opam env)or the equivalent on Windows. - How to fix
Unbound module XXX. Which is related to … - What
(libraries xxx)corresponds to what Opam package. - Almost every time they wrote a
dunefile something went wrong. This has been “fixed” so far by writing a tiny, task-oriented intro to Dune. Which is related to … - Almost all of the documentation for OCaml libraries is API-level documentation. For example, the regular expression re library has very good API-level documentation, and it has some examples. But the quantity and comprehensiveness of the examples aren’t sufficient to help a newcomer. So I’ll be teaching a tribal-knowledge trick: looking at a library’s unit tests in its source code. If only test code was automatically included in the documentation!
I’m sure at some point we’ll run into some Windows OCaml problems as well (every high school student in my Seattle metropolitan area uses Windows for their home PC).
In contrast to all the above environmental problems, the OCaml language itself has been relatively easy to understand (so far!). I think that is because we can write substantial programs in OCaml without having to know much advanced OCaml (honestly, how often do we need first-class modules and GADTs?). That is in contrast to other languages like Rust where advanced understanding is needed for even trivial programs.