OCaml's Wings for Machine Learning
48 comments
·April 30, 2025toolslive
TJSomething
My issue with REPLs is that they're often too transient. Sometimes I make a mistake on step 2 that I realize while iterating on step 10 of exploring some data. Then I need to iterate on step 2 a little, taking advantage of the ability to easily just run some of the calculations. Once I've got that, I can run the whole notebook again and make sure all my intermediate graphs look good.
abathologist
OCaml has utop, down, and the unadorned ocaml top-level.
nathan_compton
I hate em. They make people write bad code and using them for interactive development is much worse than using a REPL. I cannot understand what people see in them.
nsingh2
My workflow is to keep the notebook as thin as possible, and concise enough to fit in my brain. I explore the problem space and write some functions and data structures directly in the notebook, but as soon as I can, I refactor them into separate modules that I then import.
If I don’t, the notebook quickly becomes bloated, I start getting paranoid about stale cells and lose track of what I'm actually trying to do.
Ideally the notebook’s sole purpose is interactivity, as kind of a quick-and-dirty frontend when it's not worth it to write an actual frontend, everything infrastructural gets moved out.
pletnes
I use my IDE when I care about the production code, but I prefer notebooks when I’m just using code to understand data through visualization and statistics.
It drives me nuts that some people see this as «either or».
Linqpad is another and different take on data-driven environments. As is various «SQL admin» alternatives.
patagurbon
They’re great for teaching. But I agree for actual work.
bb1234
I don't like them either. I find it hard to articulate why I don't like them. I definitely have experienced problems with them where they get into some state where the cell results are incorrect. Then, if I restart the kernel and run the cells again, I get the correct result. But I don't like them for reasons other than this one, and cannot explain why. I prefer the ipython REPL to the notebook.
sahilagarwal
Its a bit of nostalgia for me. It took a bit of work to understand ipython when I first started as a programmer, but that effort helped me in the long run. Using ipdb for breakpoints was a game changer in my first job.
And it also was a good way to get comfortable with using terminal.
Using notebooks removes all these learnings. I dislike it because it makes for less confident programmers in the long run.
neonsunset
Me too, I just write .fsx scripts instead (F# interactive), it works nicely together with Plotly.NET. And can crunch / parallelize well if you want to do something over many files.
deredede
This looks interesting, it's great to see more machine learning efforts in typed languages.
I'm a bit surprised to see no mention of Owl (https://github.com/owlbarn/owl an older project for scientific computing in OCaml that was resurrected recently), I wonder how they compare.
The Raven README mentions:
> We prioritize developer experience and seamless integration.
so maybe that's one difference — I used Owl on a course project about a decade ago, and while it got the job done, I remember the experience being rather painful compared to Numpy (even though I was more experienced with OCaml than with Python at the time).
behnamoh
OCaml surprises me—it's old enough to be mature in terms of features and libs, and it's got a small but enthusiastic community, but every time I tried to convince myself to OCaml I found myself more drawn to Haskell and Elixir.
giraffe_lady
I like ocaml for the things other people like go for. It's a grimy roughneck language. Not a lot of fun to play around with or explore ideas but in my experience codebases written in it are stable and age well, easy to maintain.
Elixir vs ocaml I use both languages but for such completely different things I don't even think about a comparison. Elixir is for when the problem I have suits beam's strengths.
noelwelsh
Its unfortunate the cleaned up syntax never took off, and that OCaml dropped the ball on multicore for over a decade. If OCaml had decent multicore around 2010 or so the current programming language langscape could look very different.
StopDisinfo910
Python had no multicore during the same period and that never prevented it from becoming successful. Plus, Ocaml always had descent solution for concurrent I/O. The absence of multicore is a complete red herring in why Ocaml isn't more successful.
Ocaml issue never was the syntax which is completely fine. The current syntax is actually a lot nicer that what Facebook proposed. Ocaml issue is not being a USA-born project nor having a significant marketing push in English.
Plus, Ocaml always was too far ahead of its time (including now with its effect system). First, you have the functional approach which was already very unfamiliar for most. Then, you have to add module level programming on top which is still very unfamiliar to most. Just look at this comment page and people thinking Ocaml is not fun to use or less interesting than Haskell, it's trully sad.
Multicore has added the extremely promising effect system but that's once again a step too far for most current developers.
In a lof of way, Ocaml is to programming language what the Pixies are to rock music. Everyone who felt deeply in love with it went on to write a language of their own. Some got really successful.
behnamoh
> Its unfortunate the cleaned up syntax never took off, and that OCaml dropped the ball on multicore for over a decade.
It just shows the mindset of its devs was a little behind the realities of the industry, or they simply didn't care about concurrency.
In comparison, I like how Python always tries to be on top of things by exploring new PEPs.
giraffe_lady
Yeah though iirc they did have to rewrite the runtime to get multicore so who knows what sort of tradeoffs they'd have had to make to have had it be like that from the beginning. A lot of what made it good (to the extent it was) in the 2000s was you got a very sophisticated type & module system and a fast compiler without giving up any runtime performance compared to its peers. I don't know if that would have been achievable with its dev resources alongside multicore early. I don't know that it wouldn't either though. Just a big what if all round.
I suspect a larger or at least comparable limitation was essentially pretending windows didn't exist for uh like thirty years. If you knew what you were doing you could cross compile for it but it was not easy. Getting a dev environment running on windows was basically impossible until like five years ago.
The syntax idk I don't have strong feelings about it. I initially recoiled like everyone else of course, but to me style and naming conventions are almost as important and on that front ocaml's are also among the worst in the world lol. Once you get used to it it's kind of endearing how fucked up it is.
FrustratedMonky
Is anybody building things like this using FSharp? It seems like FSharp would have more of the ecosystem for machine learning and AI, than OCaml, yet with the functionality of OCaml.
StopDisinfo910
F# is a nice language if you want to use the dotnet ecosystem but it’s basically Ocaml without anything that makes Ocaml interesting (parametrised modules).
rybosome
As it happens, I’ve been thinking about a library I’d like to develop in F# as an exercise to learn the language.
I have a hand-rolled proxying inference framework written in Python that is similar in purpose to something like LangChain but much more stripped down, less abstraction. Similarly to many other Python tools, it leverages the reflective capabilities of the language to do things like ask LLMs for responses conforming to a data class, or pass native Python functions as tools. Best of all, it relies on native Python constructs like docstrings to provide additional context to the inference APIs, making clean and well documented code a secondary programming model in a sense.
Perhaps it’s vanity, but at least in Python I find the resulting code quite elegant. I became curious what it would be like to port this to other languages, and surprisingly found that F# would, to my eyes, end up with the most lovely analogue.
Even languages I expected to be expressive and terse, like Haskell, couldn’t express the same ideas as understandably yet concisely as F#.
nickpeterson
It’s a true shame F# isn’t more popular. It’s a great language/runtime combination for doing work quickly, correctly.
greener_grass
A small community but some things going on:
- https://github.com/dotnet/TorchSharp
- https://github.com/DiffSharp/DiffSharp
nextos
F# has bindings to Infer.NET, by MS Research, which is incredibly good for some classes of probabilistic models and very mature.
In particular, it shines on very large models or where fast quasi real-time inference is required.
Am I the only one who doesn't like notebooks ?
I don't want to write code in a browser. For python you have something like ipython which allows you to have an interactive experience, while also allowing you to have your favourite editing environment. For ocaml, surely there are also repls that provide this kind of thing.