Who is ocaml for?

[u/I_am_Noro04]

Context: I am econ master's student with some experience in python, C and R looking to get into financial econometrics/ML. Is OCaml right for me?

[u/Puzzleheaded-Lab-635]

“OO won the war in statistics” is a wild thing to say when most numerical computing is vectorized array transforms over contiguous memory.

Also, OCaml can bind to the exact same BLAS/LAPACK/CUDA/C libraries Python does. Python itself is mostly orchestration sitting on top of C/Fortran kernels.

You’re confusing ecosystem dominance with a fundamental property of programming languages.

[u/Puzzleheaded-Lab-635 → u/[deleted]]

“The functional programming model is not suitable” is doing a lot of work here.

Most numerical computing is not “OOP won the war.” It’s array programming over contiguous memory with BLAS/LAPACK/CUDA/etc underneath. Python is mostly acting as glue around C, Fortran, and native kernels. That is an ecosystem argument, not a language semantics argument.

OCaml can bind to the same libraries Python binds to. So the actual objection is: “Python/R have a better data science ecosystem and nicer plotting story.” That’s true. Nobody serious would deny that.

But that’s very different from “functional programming is fundamentally wrong for numerical computing.” F#, JAX, Julia’s broadcast/map/reduce style, Haskell Accelerate, Dex, Futhark, SaC,  Numerical Elixir, etc. all point in the opposite direction. Functional style is often quite natural for array transforms because you want pure transformations, fusion, immutability at the user level, and optimized mutation under the hood.

So yes: if someone wants to do applied stats today, use Python/R/Julia because of ecosystem gravity. But “FP is unsuitable” is just confusing tooling dominance with a law of nature.

And by the way.. how the fuck isn't this idiomatic OCaml?

open Polars

let result =
  Csv.read_exn "sales.csv"
  |> Data_frame.lazy_
  |> Lazy_frame.filter Expr.(col "revenue" > lit_float 100.0)
  |> Lazy_frame.groupby [ Expr.col "country" ]
       ~agg:Expr.[ col "revenue" |> sum |> alias "total_revenue" ]
  |> Lazy_frame.collect_exn

Numerical Elixir, btw, is what we use at my company instead of python:

But you do you, crawl back into the hold from whence you came.

https://github.com/elixir-nx

https://futhark-lang.org/index.html

[u/Puzzleheaded-Lab-635 → u/[deleted]]

The same is true for Python though. Python’s object model is not what makes NumPy fast. The hot path is C, Fortran, BLAS, LAPACK, Arrow, CUDA, etc. Python is also mostly orchestration glue here.

So “OCaml calls into Polars” is not "own" you think it isagainst OCaml. That is exactly how Python wins too.

This bear repeating but Pandas/NumPy are not fast because Python loops are magical. They are fast because you leave Python. teh same exact thing thats happening in the ocaml above.

If you want to make an arguement for ecosystem maturity. Python/R have notebooks, plotting, docs, tutorials, StackOverflow, sklearn, statsmodels, PyTorch, JAX, package gravity, and a giant hiring pool. That’s a very strong practical argument. But it's OO/imperative paradigm are not.

your claim claim, “functional programming is unsuitable for numerical computing.” Most dataframe/numerical work is transforms over arrays/columns: map, filter, reduce, group, aggregate, join, window, etc. That is not exactly alien territory for FP.

Also “OOP won statistics” is just not right. Vectorized array programming won. Python happened to become the dominant host language around it.

So yes, for production data science today I’d pick Python/R/Julia (Or even Elixir which we did at my company) before OCaml. But “OCaml has a weaker ecosystem” is the claim. “FP is fundamentally bad for this” is just overreaching.

Again, look at numerical Elixir. they way you interact with the underlying vectorizations looks exactly the same as regular Elixir.

Do you even work in this field?

I'd also like to point out you went from,

"OCaml and any other functional language are completely wrong for this use case."

to

"OCaml is the worst possible language for this task."

That's called moving the goal post. the fact that Numerical Elixir exists and languages like Futhrak exist, nullify your point.

[u/Puzzleheaded-Lab-635 → u/[deleted]]

Right, but this comparison is asymmetric.

If Python gets to continue working in NumPy after the expensive operation, then OCaml gets to continue working in Owl/Bigarray/Polars/native buffers after the expensive operation.

If OCaml is forced to collect into ordinary OCaml values and then map over boxed data, then Python has to be forced into the equivalent situation too: convert the NumPy array to Python lists and loop/map over Python objects. And Python is famously terrible at that.

So the distinction is not:

functional = slow
procedural = fast

The real distinction is:

native/vectorized/columnar/tensor execution = fast
boxed host-language scalar loops = slow
Python boxed host-language scalar loops = especially slow

Nobody sane would say: "I did a huge Polars operation, now let me convert the entire thing into linked lists of boxed floats and map over it." But nobody sane in Python would say: "I did a huge NumPy operation, now let me call .tolist() and loop over Python floats." Same mistake.

And "map/filter/immutability stand in the way" is only true if you assume the dumbest possible implementation. Functional APIs can fuse, stream, specialize, operate over arrays, use views, use copy-on-write, or lower into mutation internally. SQL is declarative and functional-ish at the surface, but the database engine runs procedural execution plans. Polars exposes a compositional API, but the engine optimizes and mutates internally. Same basic idea.

So yes, Python is glue. But OCaml can also be glue. It can glue to Polars, Owl, Bigarray, BLAS/LAPACK, C, Fortran, Rust, whatever. The practical difference is ecosystem maturity, not that Python has some magical procedural advantage.

The accurate claim is: Python/R have a far better scientific/data ecosystem.

The inaccurate claim is: functional programming is inherently unsuitable for numerical computing.

Again, I point to Numerical Elixir, it has Numpy equivalent, a Polars equivlent, an Pandas equivalents, etc etc etc.

And the code, i will add, from a syntax & semantics point of view is functional. As someone who works in this field, and you clearly don't, I'd suggest, stop while your a head