| For now: - Teaching new programmers how to use ML, and OCaml in particular. - Keeping consistent formatting rules among a large team or project and automating that within your editor. - Benefiting from the comprehensive pattern matching checks provided by the OCaml compiler. - Benefiting from faster compile times of `ocamlc`, or faster native execution time of `ocamlopt`. - Benefiting from Merlin, and the new version of Merlin with support for Reason - I cannot overstate how important Merlin is to my daily development. Soon: - Having conventions for forming namespaces within packages. - Making it easier to share and connect many small packages into a a larger application, and develop those packages locally. - Having "just works" support for the REPL, so that it's one fast command to start the REPL with all your dependencies loaded and autocomplete would just work. - Having a "just works" debugger loader that maps all of your source files and compiled artifacts so you can instantly start debugging your app. |
It's been a while, but taking a look at this comparison of SML and OCaml again:
http://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html
It feels a bit like you've landed in some strange neither-or space for Reason? I'm not sure if it would make sense to bend OCaml into being a subset of SML or not (I know there are some differences, just not sure how much those require different syntax, or if they do) - but did you consider moving more toward SML?
I can see the reasoning between going from <> to != and <- to = (there are more programming languages, and more programmers now, than ever before, and whatever the merits of using = for comparison, almost all other languages in common use now have it as an assignment operator (even if it is still a source of bugs a la: "if(a=0) ...")).
It's exiting times with Elixir and Lisp Flavoured Erlang for Erlang, and now Reason for OCaml (and to some extent various dialects, languages and DSLs for Javascript, like typescript, coffee script and JSX for React).