5 ms·

Owl: OCaml Scientific Computing

89 points by lnyan 4y ago

deleted 4y ago
[deleted]
forgotpwd16 4y ago
Kinda disappointed that the web version of the book isn't available anymore.
hatmatrix 4y ago
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.
- pjmlp 4y ago
  A limitation taken care of with the upcoming 5.0 release.
  - carlmr 4y ago
    Finally.
- nobody0 4y ago
  OCaml already got multicore merged.
- UncleOxidant 4y ago
  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).
yaseer 4y ago
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.
xupybd 4y ago
How similar is OCaml to F#?
- superlopuh 4y ago
  Very
- lf-non 4y ago
  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.
- stonemetal12 4y ago
  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.
- bmitc 4y ago
  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 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.
StefanKarpinski 4y ago
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.)
- nerdponx 4y ago
  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.
  - StefanKarpinski 4y ago
    I guess that’s pragmatic but having native arrays and “scientific arrays” be totally different incompatible things is just so unsatisfying.
    - lapinot 4y ago
      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 https://v2.ocaml.org/api/Bigarray.html
      - lapinot 4y ago
        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.

89 points by lnyan 4y ago

deleted 4y ago

[deleted]

forgotpwd16 4y ago

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

hatmatrix 4y ago

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.

pjmlp 4y ago
A limitation taken care of with the upcoming 5.0 release.
- carlmr 4y ago
  Finally.
nobody0 4y ago
OCaml already got multicore merged.
UncleOxidant 4y ago
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).

yaseer 4y ago

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.

xupybd 4y ago

How similar is OCaml to F#?

superlopuh 4y ago
Very
lf-non 4y ago
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.
stonemetal12 4y ago
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.
bmitc 4y ago
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 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.

StefanKarpinski 4y ago

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

nerdponx 4y ago
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.
- StefanKarpinski 4y ago
  I guess that’s pragmatic but having native arrays and “scientific arrays” be totally different incompatible things is just so unsatisfying.
  - lapinot 4y ago
    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 https://v2.ocaml.org/api/Bigarray.html
    - lapinot 4y ago
      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.