Comment by vegabook | Hacker News Reader

Comment by vegabook | Hacker News Reader

This language seems to punch above its weight. There seem to be a lot of postively rated submissions on Ocaml on HN, though the comments secions are inevitably quite light. I wonder if there should be a greater effort to learn it. I personally am enrolled here: https://www.france-universite-numerique-mooc.fr/courses/pari....

I know it is not accepted form to post "adverts" here but in this case I'm sticking my neck out as I think/hope this language may well be on the cusp of a second chance, after a peak then trough in 2005-2014, as judged by my googling around. I know for a fact that some super clever people seem really to be pushing the boundaries with this. JS-of-ocaml, mirage os, Coq, Jane Street core. Seems more practical than Haskell. Anti-disclosure: I have nothing to do with any of the Ocaml people. I'm just interested.

My interest has been piqued by R, after being a Python scientific computing programmer. R has some really neat functional constructs and I'm keen to dig further. I have been quite struck by how much one can achieve in a single line or two of code in the functional style.

I highly recommend checking it out. The great thing is that it's not the fancy features that (pushing the boundaries) that make it a good language. The core of ML is the real gold. I content that it would be a good choice as a default programming language for most programmers.

If you are coming from Python, ML is going to seem pretty weird. The code doesn't look too different but the compiler will be yelling at you a lot. Press on. (As a big fan of Python,) my feeling is that with Python it's easy to start programs and with OCaml (ML) it's easy to finish them.

If you are learning ML, in the beginning try to avoid using fancy features and really avoid non-functional features (i.e. mutable variables). These have a place but most of the time aren't needed. Using them gets in the way of learning this new great style.

I've heard good things about Real World OCaml (haven't read it myself - came out after I'd learned the language).

One warning. Some functional programming materials (books, tutorials, etc) can be way too theoretical. However this has changed a lot in recent years.

The language itself isn't rocket science. If whatever you're reading isn't a good fit, try to find something else.

Yes it seems to attract a high-end CS crowd - there's lots of graduate-level CS assumption going on in some of the tutorials. But one of the things I really appreciate is the REPL ("toplevel") which let's you hack around and mess with examples in an interactive way. So good for a compiled language.

Much better in this regard than Haskell, though. Being impure and eager makes the most die-hard academics go for Haskell instead.

Ocaml stuff seems to be a bit more down to earth in my experience. As long as you stay away from GADTs :)

> I content that it would be a good choice as a default programming language for most programmers.

Strongly agree. I now write all of my everyday “glue code” in F#, and use C# for the low-level algorithmic/library stuff. This is directly opposed to the received wisdom, but I find that it works far better (although I think in ML no matter what language I’m using).

My theory as to why this works is that designing and writing robust “line-of-business apps” is really tantamount to designing and implementing a protocol, which, in turn, requires writing something like a parser or recognizer, and it just so happens that ML is really good for writing parsers and recognizers.

> my feeling is that with Python it's easy to start programs and with OCaml (ML) it's easy to finish them.

I’m stealing this.

I have had a quick skim (10 - 15 minute reads at a random points, until I have time to read it properly) of Real World Ocaml.

So far it looks great, and is very pragmatic and also covers useful tools for working in Ocaml (imho that should be in every modern specific programming language book, but it probably will date faster the rest of the book).

For quick overview go through: http://learnxinyminutes.com/docs/ocaml/

And: https://realworldocaml.org/v1/en/html/a-guided-tour.html

If you're a Haskeller: http://blog.ezyang.com/2010/10/ocaml-for-haskellers/

> The core of ML is the real gold.

I think that's the thing that keeps me interested in OCaml and is making me interested in F#: the core ML language is not very complex, and it can carry you a long way before you start requiring advanced features. I wrote a few compilers in OCaml using only the core language and very simple modules (basically just signature + struct, no functors) and the end result was very easy to read and modify. I think very few languages can make a similar claim: either the language doesn't get you all the way and you need external help (e.g. C and its pre-processor) or overshoots into too much complexity (e.g. C++).

ML is not a language for all tasks (I am learning Rust for those times when OCaml is not appropriate), but I think that ML languages could be used beneficially in many more applications today.

I try and read/comment on all of the OCaml articles that surface here. I've been learning the language for a few months now and I'm having a blast! I'm hoping we can carve out a niche in the infrastructure space for OCaml. It's a really approachable language for the ML family! I hope it grows.

Here's a couple of books I'm enjoying so far:

Think OCaml/How To Thinke Like A (Functional) Programmer - http://greenteapress.com/thinkocaml/thinkocaml.pdf (same author as all the other awesome Think X books!)

Unix Systems Programming in OCaml - http://ocaml.github.io/ocamlunix/

People also say really great things about Real World OCaml but I haven't had a chance to go through it yet.

I also recommend the notes for L28[1] - Advanced Functional Programming at Cambridge. They might be a little hard to follow, but they are extremely insightful and teach concepts that may be difficult to learn elsewhere

[1] https://www.cl.cam.ac.uk/teaching/1415/L28/materials.html

Indeed, very complete set of slides. Thanks a lot.

I first started using ocaml (f# actually and then re-wrote it in ocaml) for writing a simple interpreter to generate java code from mysql schema tables to deal with hibernate boiler plates etc. The code was much succinct than a comparable parser written in say antlr. That was my first introduction to typesafety helping me move forward. Specially, when coming back to the code, the compiler will scream at you for either not handling all the patterns that matched or adding new ones that didnt exist yet and needed to be changed. I went away from OCAML towards Haskell because a coworker convinced me to switch: also haskell seems to have a better support for multicore architectures. Of course, my applications are more web/networking apps, crud, websites etc. So i could have gone either way. The one difference i find when programming with Haskell as opposed to ocaml is that in ocaml, my instinct would be to write a little interpreter(or a quasi quoter). In Haskell, I still think that template haskell is a necessary evil, therefore, do it only when I really know what I am doing. I found this link to be quite helpful: http://pleac.sourceforge.net/pleac_ocaml/

Reading the pleac pages, it's amazing how javascript is getting close and closer to ml. It's all going back to its roots since js was quite {scheme} so it's not that surprising but still a joy to see.

Module.foo (fun (x,y) -> ...) ...

JavaScript and ML couldn't be further apart.

There still far away from each other but js is getting closer. Emphasis on functions, proper scoping, patterns for bindings, IIRC TCO is in ES6, even if it's a small step is already a huge one.

It's still not a typed calculus, but types will be mainstream soon. my 2 cts bet.

Jane Street uses Ocaml professionally in a financial trading application. Here's an excellent write-up on why they chose it, its advantages, examples in action, and a few limitations.

https://queue.acm.org/detail.cfm?id=2038036

Esper Tech is another one using it and wrote up why here:

http://tech.esper.com/2014/07/15/why-we-use-ocaml/

Esterel also used it to develop a highly-assured code generator for DO-178B-certified software. That's one of the toughest projects you can do and it made it easier.

http://www.researchgate.net/publication/220802806_Certified_...

Hope this helps to show its practical value. I've always thought Ocaml's design had some of the best compromises between how we'd like it in theory vs getting things done.

The project I've been involved with at Red Hat uses OCaml in a very procedural, imperative, workaday way. We purposely don't use fancy functional stuff, except in the very few cases where it makes sense. We also freely link to C code in the same programs.

These are programs used by large numbers of generally unaware real world users. Why would they need to know - from the outside they look and behave like C binaries.

Anyway, for some big open source projects written in OCaml, take a look:

https://github.com/libguestfs/libguestfs/blob/master/v2v/v2v... https://github.com/libguestfs/libguestfs/tree/master/sparsif... https://github.com/libguestfs/libguestfs/tree/master/resize https://github.com/libguestfs/libguestfs/tree/master/builder https://github.com/libguestfs/libguestfs/tree/master/sysprep

Do yourself a favor and check out Julia before settling for R.

It's a good language but I really struggle to see why you'd choose it over Haskell. You may not need the fancier types yet, but in Haskell they'll be there for when you do, whereas in OCaml you reach the infuriating position where you know exactly what you want to do but you can't quite express it in this language without repeating yourself several times over. I guess if you've never used higher-kinded types maybe you don't miss them?

/Scala myself, but that's a slightly different niche.

Functors => higher-kinded types

yeah but I'm dead scared of the stories I've heard about indeterminate execution time in certain cases. For my real-time production use case this would be a deal breaker. Am I misguided?

It's a risk - but then it's a risk in OCaml too. How real-time are we talking? I've seen Haskell used in videoconferencing and it performed very well.

There's at least one financial firm that chose Haskell and presented good results from it. Galois works miracles with Haskell left and right. So, there's a slow build-up of momentum in that direction. I'm hesitant to use it due to the learning curve. I have a feeling I could probably get productive in Ocaml faster than in Haskell. I figure I would learn them in that order.

Not sure if that's true as I use neither and only did minimal functional programming in LISP. I mostly do an imperative style along lines of Cleanroom methodology. I'd like to hear veterans' opinions as to whether Ocaml's learning curve would be easier on imperative programmers than Haskell.

You'll probably be fine either way, IMO - OCaml has a lot going for it, it's fast and incredibly quick to compile, and has a pretty straightforward execution model. Haskell is not quite the same (different evaluation strategy, different ways of organizing your programs), so there's a bit of associated overhead there, and for a beginner it can appear daunting.

The most important part of these languages is really how they try to enhance your abilities to write modular programs. You might be surprised to find out languages from the 1970s and 1980s have better abstractions (e.g. functors/modules) than some designed today. :)

But fundamentally I think some of it will come down to personal choice and aesthetics at some level; e.g. I really like Haskell's syntax (principled, block structured with no semicolons) and I really like laziness in general, because it makes it really easy to 'float out' and refactor code. OCaml has a much better module system, a very fast compiler, and is very well designed and thought out IMO. None of those are dealbreakers - it's just a matter of picking your poison.

Appreciate the insight. This one line though...

"You might be surprised to find out languages from the 1970s and 1980s have better abstractions (e.g. functors/modules) than some designed today. :)"

...is uniquely appropriate as I've been amazed by and posted so much old work on forums that there's little that surprise me. Far as abstractions, I think Ten15 (below) was most interesting I found given its potential as an integrator. Burroughs Architecture, IBM System/38, Wirth's layered design of Lilith, Genera LISP's developer flow... the best attributes of these still haven't been matched imho by modern work. Still worth remembering and factoring into one's next project if possible.

http://www.mca-ltd.com/martin/Ten15/introduction.html

Things I like for Ocaml over Haskell:

* Predictable performance; No need to worry about space leaks. * The module system is pretty nice. * Named/optional function parameters. * Being able to write filthy imperative code without needing to use monads for everything. :)

Reply on news.ycombinator.com