7 ms·

OCaml's Wings for Machine Learning

108 points by musha68k 1y ago

evacchi 1y ago
so finally someone is actually putting ML in ML
- deleted 1y ago
  [deleted]
cube2222 1y ago
Fingers crossed, though I’m not holding my breath for anything taking a sizable bite out of Python in the area of ML/DL. OCaml seems to be a lovely language based on my limited experience with it. It’s a pity it’s not more popular.
- lawnchair 1y ago
  Terrateam is hiring ;)
behnamoh 1y ago
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 1y ago
  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 1y ago
    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.
    - behnamoh 1y ago
      > 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.
      - toolslive 1y ago
        I'm going to be sarcastic _and_ on topic (you baited me): yeah, like how python completely solved concurrency & parallelism.
      - sidkshatriya 1y ago
        > 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. OCaml cared about concurrency (e.g. Lwt, Async are old libraries that provide concurrency -- they didn't need multicore Ocaml). OCaml didn't care so much about true _parallelism_ in threads until recently. Parallelism was to be obtained via processes and not threads in pre OCaml 5.0. True parallelism in threads is available in OCaml >= 5.0 Python is actually trying to go multicore too ! OCaml however beat it to the punch. The strengths of Python are elsewhere though, a topic for another day.
        jimbokun 1y ago
        > Python is actually trying to go multicore too ! OCaml however beat it to the punch. This is debating the relative finishing places of the two runners finishing last in the marathon after most of the other runners have already gone home and had their dinner.
deredede 1y ago
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 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).
- UncleOxidant 1y ago
  Wasn't there something about Owl being "concluded" about a year ago because the 2 developers no longer had time for the project? Is Raven the successor to Owl?
  - deredede 1y ago
    It was, but then they changed their mind apparently https://discuss.ocaml.org/t/owl-project-restructured/14226 https://discuss.ocaml.org/t/owl-project-restructured/14226 Too early to tell what it will lead to. > Is Raven the successor to Owl? That's what I am wondering too (especially with the name), but I couldn't find a reference to Owl in the repo.
FrustratedMonky 1y ago
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.
- greener_grass 1y ago
  A small community but some things going on: - https://github.com/dotnet/TorchSharp https://github.com/dotnet/TorchSharp - https://github.com/DiffSharp/DiffSharp https://github.com/DiffSharp/DiffSharp - https://github.com/fsprojects/Furnace https://github.com/fsprojects/Furnace - https://github.com/plotly/Plotly.NET https://github.com/plotly/Plotly.NET
- rybosome 1y ago
  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 1y ago
    It’s a true shame F# isn’t more popular. It’s a great language/runtime combination for doing work quickly, correctly.
- nextos 1y ago
  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.
toolslive 1y ago
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.
- neonsunset 1y ago
  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.
- bb1234 1y ago
  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 1y ago
    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.
- nathan_compton 1y ago
  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.
  - pletnes 1y ago

108 points by musha68k 1y ago

evacchi 1y ago

so finally someone is actually putting ML in ML

deleted 1y ago
[deleted]

cube2222 1y ago

Fingers crossed, though I’m not holding my breath for anything taking a sizable bite out of Python in the area of ML/DL. OCaml seems to be a lovely language based on my limited experience with it. It’s a pity it’s not more popular.

lawnchair 1y ago
Terrateam is hiring ;)

behnamoh 1y ago

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 1y ago
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 1y ago
  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.
  - behnamoh 1y ago
    > 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.
    - toolslive 1y ago
      I'm going to be sarcastic _and_ on topic (you baited me): yeah, like how python completely solved concurrency & parallelism.
    - sidkshatriya 1y ago
      > 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. OCaml cared about concurrency (e.g. Lwt, Async are old libraries that provide concurrency -- they didn't need multicore Ocaml). OCaml didn't care so much about true _parallelism_ in threads until recently. Parallelism was to be obtained via processes and not threads in pre OCaml 5.0. True parallelism in threads is available in OCaml >= 5.0 Python is actually trying to go multicore too ! OCaml however beat it to the punch. The strengths of Python are elsewhere though, a topic for another day.
      - jimbokun 1y ago
        > Python is actually trying to go multicore too ! OCaml however beat it to the punch. This is debating the relative finishing places of the two runners finishing last in the marathon after most of the other runners have already gone home and had their dinner.

deredede 1y ago

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 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).

UncleOxidant 1y ago
Wasn't there something about Owl being "concluded" about a year ago because the 2 developers no longer had time for the project? Is Raven the successor to Owl?
- deredede 1y ago
  It was, but then they changed their mind apparently https://discuss.ocaml.org/t/owl-project-restructured/14226 https://discuss.ocaml.org/t/owl-project-restructured/14226 Too early to tell what it will lead to. > Is Raven the successor to Owl? That's what I am wondering too (especially with the name), but I couldn't find a reference to Owl in the repo.

FrustratedMonky 1y ago

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.

greener_grass 1y ago
A small community but some things going on: - https://github.com/dotnet/TorchSharp https://github.com/dotnet/TorchSharp - https://github.com/DiffSharp/DiffSharp https://github.com/DiffSharp/DiffSharp - https://github.com/fsprojects/Furnace https://github.com/fsprojects/Furnace - https://github.com/plotly/Plotly.NET https://github.com/plotly/Plotly.NET
rybosome 1y ago
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 1y ago
  It’s a true shame F# isn’t more popular. It’s a great language/runtime combination for doing work quickly, correctly.
nextos 1y ago
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.

toolslive 1y ago

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.

neonsunset 1y ago
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.
bb1234 1y ago
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 1y ago
  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.
nathan_compton 1y ago
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.
- pletnes 1y ago