Comparing OCaml and Standard ML (opens in new tab)

That's certainly a pretty exciting presentation! Looks like a huge effort though... how much progress has there been since?

The netmulticore library [1,2] worked well for me. The style there is to spawn worker processes and pass messages between them. I'm not sure how popular that library got but that style of programming seems to be pretty popular among OCaml users who need it. Many projects use something lighter-weight or just roll their own (e.g. Parallel in Jane Street's ocaml-core looks pretty good [3]).

I certainly wouldn't mind if you could swap out the garbage collector (a la Java - where you can choose between a fast serial garbage collector and a parallel garbage collector). However, I don't think it's the right tool for many tasks.

[1] http://blog.camlcity.org/blog/multicore1.html

[2] http://projects.camlcity.org/projects/dl/ocamlnet-4.0.0test2...

[3] https://ocaml.janestreet.com/ocaml-core/109.24.00/doc/parall...

Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/

TBH I don't miss multithreading in OCaml, if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore. And you can program those kinds of applications quite nicely with Lwt or Async already.

Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper around libffi), or to generate C stubs.

Regarding OpenGL there is a new binding called 'tgls' for OpenGL 3.x/4.x (besides LablGL) that is mostly generated from the XML description of the OpenGL APIs.

Regarding Windows support I can't say much because I don't use it at all, but there was a new 'Self-containted OCaml distribution for Windows' called ocpwin-distrib posted to the ML recently. If you care about Windows support you should probably give them feedback on what is missing.

> For me the object system on Ocaml was just too much

What do you mean by that ? The current consensus about the object system in OCaml is "don't use it", even if there might be cases where it will describe your system better.

The standard library (both the real stdlib and Jane Street's Core library) don't use objects so you can pretty much ignore this part of the language if you want to.

I remember reading that book on my crossings over the tagus river in Lisbon, after we got introduced to Caml Light.

Time flies!

I don't have the code publicly available yet, but all the development will happen openly on GitHub. I estimate to prepare a minimal working compiler in the next weeks.

I've been thinking a lot about how to perform the parsing. I believe it's important to have a complete metaprogramming system (with code macros and quasiquotations) with all the basic language primitives defined in the language itself. So standard parsing with Menhir may not be ideal for this purpose. Instead, I've ported a simple top-down operator parsers (also known as Pratt parser) to OCaml, as described for example here[1]. This is the technique used by Douglas Crockford for the JSLint parser[2].

The core of the language can be seen as a simple compiler toolkit, that parses generic expressions and produces native OCaml AST. So for example even things like assignment (`=`) or function definitions are regular macros. This is one of the reasons I named the language "Meta".

There's another interessting language that inspired me a lot called Magpie[3] which uses identical approach (described in detail here [4]).

The main goal of the language is simplicity. OCaml is a very powerful language but programming in it requires some writing effort. I want the freedom and natural expressiveness of Clojure or Python combined with type security guarantees and modularity of OCaml.

I'm developing a large system for my startup in OCaml right now and plan to incrementally port it to Meta, which I think is important for dogfooding experiments, for support and commitment.

The syntax will look a lot like Julia (although I considered to just adopt s-expressions, languages like Elixir and Julia showed as that it's possible to be homoiconic (in some restricted sense) and still use regular syntax). I am still in research and only have defined basic language constructs like variable bindings, function definitions, type annotations, pattern matching and macros. If you are interested I can show you some examples.

What do you think about it? It would be nice to hear some early feedback.

[1]: http://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-e...

[2]: http://javascript.crockford.com/tdop/tdop.html

[3]: http://magpie.stuffwithstuff.com/

[4]: http://journal.stuffwithstuff.com/2011/02/13/extending-synta...

Good OCaml code is one of most readable in the category of static languages, I agree. But it's less "writable" than readable in my opinion. Of course you can get used to the syntax, but for me expressiveness and clarity of comprehension comes from both: simplicity of writing and reading.

Often I feel like there is a barrier between your thoughts and their execution which does not exist in Python or Ruby for example. When I switch from OCaml to Python it's like a breath of fresh air.

In conclusion I think common tasks must be syntactically abstractable. For example, I find working with standard data structures in OCaml annoying, as if I were programming in C. There are tons of syntax extensions for OCaml that try to fix these defects, but it only supports my claims.

What does this code do?

  if a > 0 then
    print_endline "a > 0" ;
    match a with
      | 0 -> print_endline "impossible"
      | 2 ->
        match b with
          | 0 -> print_endline "2, 0"
          | _ -> print_endline "2, not 0"
      | 3 -> print_endline "3, something"
      | _ -> print_endline "something, something"
  ;
  print_endline "done"

I think Opam is very cool because it simplifies OCaml development a lot, just like any language package manager does for its language.

With Opam I can deploy my code on different machines very easily by installing the right version of OCaml and library dependencies in just a few command, and it just works.

The problem with ocamlfind you are mentioning was just a temporary bug I think, I also encountered it, but it will be fixed real soon, see: <https://github.com/ocaml/opam/issues/1671> for instance.

> I have the impression that the OCaml world has seen a lot of changes recently with a lot of complexity added.

The first part of that is very true but the second part feels completely and utterly false to me. Where is this added complexity?

OCaml and OPAM were ridiculously trivial to set up on my system (via homebrew on a Mac) and OPAM 1.2, with many improvements, is due for release in the next few days [1]. Decent instructions are in the RWO wiki page [2]. The OPAM devs are responsive to bug reports and do a lot to maintain the health of the package ecosystem too.

If you're installing everything from sources then you're choosing to take on that burden and I wish you well but don't claim that more complexity is being added.

[1] beta announcement: https://opam.ocaml.org/blog/opam-1-2-0-beta4/

[2] https://github.com/realworldocaml/book/wiki/Installation-Ins...

I find 'ocaml switch' very useful (sandbox functionality). Also, you can add a repo for your local stuff very easily. The CLI is pretty nice and well-designed.

That was my biggest disapointment with "Real World OCaml", as the book requires OPAM to follow along.

Apparently it works with WOBI, an OCaml distribution for Windows. I haven't tried it though.

When on Windows I just go for F#.

> One thing I think F# got right is that it removed some of the "flexibility" in OCaml's syntax. For example, it uses significant whitespace to define scoping, which removed (in nearly all cases) the need for the 'in' keyword and lots of parentheses and semicolons. That may not sound like a huge deal, but it does greatly improve the readability of F# code (all other things being equal).

I must disagree. I once translated a significant (15kLOC) commercial OCaml code base into F# and took the opportunity to quantify the syntactic benefits as <3% by volume of code. The flipside is that F# misinterprets code pasted from the web, rendering most code on the web useless. That is a crippling deficiency of F# in my eyes and a major reason to go back to the superior OCaml solution.

Actually when F# was introduced, you could switch between both modes.

After voting the #light "on" became the default behaviour.

You can get the more compatible OCaml one with #light "off".