Owl: OCaml Scientific Computing | Hacker News Reader

Owl: OCaml Scientific Computing

ocaml.xyz

89 pointslnyan17 comments

I remember reading a blog around 2010 or so about someone listing "desiderata" for a scientific computing language - including Matlab, Python(?), etc. - and then settling on OCaml.

A functional language for data analysis and computation is certainly favorable. However in the meantime, Julia seems to have taken off so I wonder where OCaml stands in this space, also given its limitation with concurrency.

A limitation taken care of with the upcoming 5.0 release.

Finally.

OCaml already got multicore merged.

The OCaml concurrency issue is mostly off the table now that multicore has been checked in. That said, Julia was designed from the ground up for this space so it's way ahead of OCaml here even with OWL and it's tough to see how OCaml would catch up (saying this as someone who has used both and really likes OCaml).

I wasn't aware that ahrefs was supporting Ocaml projects.

Jane Street obviously comes first to mind. Good to see more companies develop the ecosystem. It used to be a very niche, esoteric language.

I discovered Ocaml whilst learning Isabelle and suddenly fusing OOP and functional programming seemed elegant, whereas Scala had made it seem scary.

I’m curious if anyone knows what approach Owl takes to making sure float arrays, complex arrays, etc. are unboxed. (Or if it leaves them boxed.)

Scientific computing libraries in languages like Python generally represent the array itself as a "boxed" native language object, but internally the numbers are represented by a true contiguous array. I would be surprised if Owl did it differently.

I guess that’s pragmatic but having native arrays and “scientific arrays” be totally different incompatible things is just so unsatisfying.

I don't know if OWL rolls its own thing, but there is a "numeric nd-array" type in the standard library in ocaml [1]. In any case "native arrays" in ocaml or other are dynamic vectors, so it wouldn't make any sense to build numeric arrays on top of that. And in ocaml you're probably using inductive lists or trees more than dynamic vectors.. So it's not really "unsatisfying": different datastructures for different needs.

[1] https://v2.ocaml.org/api/Bigarray.html

So just for reference, OWL is using Bigarray under the hood for dense array. OWL seems to be doing all the things right, great deal of modularity and abstractions but compiling everything down to the most efficient representations.

Kinda disappointed that the web version of the book isn't available anymore.

How similar is OCaml to F#?

Very

Disclaimer: I have more exposure to F#, and am very early in OCaml journey.

They are similar because F# pretty much completely borrowed the OCaml syntax when it was created. There have been many syntactic enhancements since and F# that most people write nowadays (the light syntax) is a quite bit different from OCaml though they remain similar.

The bigger differences are around the type system & modules. The F# team doesn't seem to have enough power to sway the direction of CLR, so OCaml features that didn't cleanly map to C# constructs or hinder interop with other dotnet languages (like parameterized modules, structural typing etc.) were not adopted in F#.

Also from my early exploration OCaml binaries seem to be a lot smaller and the compiler a lot faster.

This is not a criticism of F#, I have found that the combination of lightweight syntax, computation expression syntax, access to both dotnet and javascript ecosystems (fable) and the great tooling (ionide) to result in a very productive experience for day to day work, though FP enthusiasts tend to scoff at lack of higher level abstractions. Looking forward to exploring OCaml more over the next few months.

2nd Cousins?

When F# first came out it was OCaml syntax on dot net runtime. But much like C# starting as MS's Java, it quickly grew away from that starting point.

Haskell had a bout of popularity when F# was young so it picked up a Haskellish syntax and workflows.

These days there is an obvious ancestry with OCaml but not that close.

Very similar. Initially, F# was an attempt to port Haskell to .NET. This was part of the so-called Iron project to port many languages to .NET to test out the ability of the CLR to host different languages. Haskell was too difficult of a match for .NET, so they switched to OCaml. At the beginning, F# was actually compatible with OCaml, but it has since diverged becoming its own language.

I don't have much experience with OCaml, but I suspect F# is the easier one to setup and get going in. It's my understanding that OCaml has issues being setup on Windows. (This may be an out of date understanding.) Since F# is installed with .NET now, all it takes is for one to install the .NET SDK and then you have F#. This makes it very easy to install F# on basically anything.

Here is The Early History of F# by Don Syme, the creator of F#.

https://fsharp.org/history/hopl-final/hopl-fsharp.pdf

While the ecosystem isn't as great as it could be, F# is by far my favorite language. I do not know of a language that hits better sweet spots.

Reply on news.ycombinator.com