A question about Ocaml

I want to learn Unikernel and working with Xen hypervisor.
How about Ocaml job positions?
I guess the language is hard to learn or maybe hard for me!!!
Is it a good language for beginners?

And MacOS, since it supports many of the same tools

Some good books are listed here: https://ocaml.org/learn/books.html

It doesn’t sound like you are a beginner at programming, but if you are, maybe OCaml from the Very Beginning would be a good start.

If you have been programming, but are completely unfamiliar with functional programming, you’ll need to learn to think about programming in a new way–but it is a fun and useful new way! That is probably the biggest challenge for some people with OCaml. (Also, the syntax is unusual these days, but if you wanted to do web programming, you could try ReasonML, which is OCaml with a more familiar kind of syntax.) Anyway, you might want to try Real World OCaml. If it seems too difficult because the way of thinking seems strange, you might want to temporarily switch to an easier book on functional programming such as OCaml from the Very Beginning or (my personal favorite) The Little Schemer by Friedman and Felleisen. Real World OCaml is a few years old, but there is a beta or alpha version of a new edition with updated tools and libraries: https://dev.realworldocaml.org/toc.html

Other good sites to check are OCamlverse and the main OCaml language site.

Here is one way in which OCaml is easier than other statically typed languages such as Java: In OCaml, you don’t have to write type information all over your code, so your code is more informative and less noisy. Type information goes in a separate file from the main source code. However, you don’t even have to provide any type information, usually, if you don’t want to do that. I love this feature. OCaml does type inference, so the compiler will almost always figure out the types of all of your variables and functions, and tell you if you are using something incorrectly, and you will usually learn quickly if the compiler can’t figure it out. Most people document their types by writing type statements in a separate file, though.

Also, if you’re interested, OCaml has an excellent library Owl for linear algebra, statistics, and other numerical programming work that is still under development but that is pretty mature in many areas.

How about job positions?
What are you doing with Ocaml?

@Hack3rcon OCaml is popular in Finance: Bloomberg, LexiFi, SimCorp. I think these companies are well represented in this forum :wink:

Check out LexiFi’s clients page: https://www.lexifi.com/clients/

I’m not speaking for LexiFi, but I think it would be fair to say that each of their clients has a number of people working with OCaml day-to-day.

I think you might want to have some … skepticism about the possibility of using Ocaml at any job you might have. It’s true that there are a few companies (and even a couple of large ones) that use Ocaml heavily. But unless you intend to limit your job horizons to those companies, the world is pretty anti-Ocaml. I say this as a career-long Ocaml bigot and implementor of Coq V5.10. I also spent 20 years in enterprise computing, and never, not once, since I encounter ML or any of its creche siblings. Once I convinced a group to write a product using Ocaml; the next version was rewritten in another language (I forget which).

It’s like arguing that “DB2 is a great relational database” in 1998 [it really wasn’t grin]: it doesn’t matter if it is or if it isn’t: most companies don’t use it, and most DBAs don’t know it, and that’s a vicious circle that is very difficult to break. So it didn’t go anywhere on Linux/Unix/Windows.

I guess what I’m saying is: learn and use Ocaml. Yes. Do it because ir makes you a better and more careful programmer. Because it makes you faster and more effective at writing code. But don’t expect that your employer will allow you to write code in Ocaml. If you end up at a company that uses Ocaml, count yourself very, very lucky.

7 Likes

From what little I see about this, it sounds like it covers OCaml as distributed, not an alternate set of libraries and extensions. That sounds like a plus, a feature that unfortunately isn’t common to all the widely recommended introductory material.

I don’t know ReasonML, but I wonder if its familiar syntax is any benefit to someone struggling with the concepts. If you’re learning something somewhat radically different from what you’re used to, does it help if it’s superficially similar?

I can only offer my seconding for The Little Schemer – and also second the idea of learning the (somewhat different) way of thinking inherent in functional programming. It isn’t obvious, and until you can really do it well, you can’t truly exploit the power of Ocaml (or other functional languages). It’s worth learning, seriously.

2 Likes

I know that makes sense, and I think you’re right, for many programmers, but my gut feeling is that for some people at some stages of learning a new language, little hurdles make a difference. With a new language, you can get a lot of mileage from guessing and experimenting if you have appropriate experience. Syntax is part of that. If you’ve made a commitment, or you’ve got a lot of experience, then you work through the unfamiliarity, with syntax or whatever it is. If you’re just trying a language as an experiment, you might not bother if it seems frustrating. I could be wrong. It’s partly based on hearing people complain about parentheses in lisps, and seeing lisp code with one parenthesis per line. If you do that, the language will be unpleasant. If you feel uncomfortable with OCaml syntax, maybe it’s an unpleasant experience at first. I may be overgeneralizing. (I teach in a non-CS field, and I think a lot about little things that can help students when they find themselves swimming in the deep end. Might not apply here.)

However I think I was wrong to suggest ReasonML for someone new to OCaml. There are no ReasonML books afaik, most libraries use OCaml syntax, and ReasonML syntax may still be changing. (It did recently.) So at this stage, learning ReasonML on your own means learning both syntaxes, which seems like a bad way to learn, unless you have the right sort of experience for that or people who will help you. (Folks in the ReasonML forums may have a different view.)

1 Like

This is (surprisingly maybe) a deep observation. I first heard it from Guy Steele in 1994 he was giving a talk on what I’ll call “syntactic backward-compatibility”.[1] He had a bunch of examples from language evolution, where back-ward compatibility (or lack thereof) was important for language adoption. Of course, what we didn’t realize, was that he was starting to work at SUN on a new language, Java. And that that language would catch on mostly because of precisely these sorts of syntactic backward-compatibility niceties. I mean, it wasn’t compatible with C++ at all. But it had this superficial look, of being compatible with C++, and that was enough. Shockingly, that was enough.

It’s a pity there aren’t books (yet) based on the ReasonML syntax, I guess. I fully expect newbies to come to Ocaml thru that syntax, eventually.

[1] You might say, he was trying to scream “It’s the curly-braces! It’s the curly-braces, stupid!” but he was contractually obliged not to. Ha!

2 Likes

I always found the syntax difference to be a strength for learning actual functional programming.

If you try to learn something new and it looks too similar to something you already know it’s natural to take it for that thing and use it as such.

It’s perfectly possible to simply bang imperative statements in OCaml and stick to procedural programming — what seems to be hyped as “functional programming” these days.

But then one entirely misses the opportunity to learn to program with values, not statements.

For programming with values you want to have a syntax that favors defining expressions, not statements — ML-like syntaxes gives you that, curly braces syntaxes usually do not.

5 Likes

Thanks @keleshev for the shout-out :slight_smile: ! Indeed at LexiFi all development is done with OCaml, ranging from native Windows UI apps, to web apps (via js_of_ocaml), to server/database software, to compilers and DSLs.

Cheers,
Nicolás

native Windows UI apps

May I ask what library you use? (If it’s not a secret).

No, it is not a secret :slight_smile:

We use CSML (https://github.com/LexiFi/csml – but note that Github is down at the moment; see also original announcement https://inbox.ocaml.org/caml-list/48CFD2D6.9030700@lexifi.com/), a high-level binding generator between .NET and OCaml which was developed at LexiFi to bind native Windows APIs (eg WinForms) that we then drive directly from OCaml. As .NET has its own GC, some care is required so that it plays well with OCaml’s GC. It uses OCaml objects to expose .NET classes.

Having said that, nowadays we are migrating more and more to web technologies, using gen_js_api (https://github.com/LexiFi/gen_js_api): we embed web UIs directly inside the native desktop apps using CEF (https://en.wikipedia.org/wiki/Chromium_Embedded_Framework). This has the advantage that we can use the same code to deploy on the desktop and the web.

Cheers,
Nicolás

I’ve started to learn OCaml less than 6 months ago and I’ve been learning it during my free time. Maybe it helps to to share my experience here:

  • it’s been a bit challenging to change my thinking towards functional programming after almost 20 years of doing mainly C, C++, Java and Javascript with strong OOP focus.
  • I’m starting to be more confident with OCaml and at the same time I feel I’m writing better code also when using other languages (job-wise writing mostly Kotlin)
  • nowadays when using other languages, I’ve started to have these moments of frustration, because I have to write silly tests to make sure everything is correctly connected (OCaml compiler is simply awesome when it does so much for you, even though it is a bit painful in the beginning)
  • most of the architecture thinking and models I can still apply in OCaml world and I think my thinking has improved here by getting better on avoiding side-effects and shared state
  • I suppose I went a bit extreme, but reading Bartosz Milewski’s Category Theory for Programmers helped quite a lot with understanding OCaml’s functors
2 Likes

A few ReasonML books:

1 Like

Oh, that’s actually great! I didn’t know these existed. But then again, since I DGAF about syntax, lexing etc (it’s all the same, just squint mang) I never look for these things. But for sure, for sure, for sure, I am dead certain that this is the avenue to bring a lot of new users to Ocaml. That’s what happened with Javascript, and a big part of why Javascript kicked Java’s butt.

I’m happy that I was wrong.

1 Like

I concur with this, even outside of the context of functional programming (I agree ML-esque syntax is more pleasant for functional programming, no wonders newer languages like e.g. Idris and PureScript are in the same tradition, unlike Scala). But for me it was easier to learn logic programming in Prolog than doing the same in miniKanren which is based on Scheme, a language I already knew at that time. Same with Factor, I found it easier to pick it up using its syntax than a Java-esque translation of it could ever be.

But it seems that most programmers prefer syntactic familiarity and prefer to use frameworks and libraries using lots of magic under the hood than to use languages where such functionality is built-in.

(Case in point, dependent typing in Idris vs Haskell)

Anecdotally, I heard that it is, indeed. It’s not that it’s familiar, it’s just that curly braces and parentheses around arguments really help see what is a function name, what is an argument name, and where blocks begin and end. It’s something people visually rely on a LOT when orienting themselves in unfamiliar code bases.

1 Like