Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Draft of OCaml Scientific Computing book

discuss.ocaml.org

Post reply on HN
Print view View original

21–30 of 132 posts

Re: Draft of OCaml Scientific Computing book

#21

Post by pjmlp »

doteka wrote: post #9
G4BB3R wrote: post #7

Each year I think wether should I learn OCaml or not. What is the current state of multi-thread OCaml? Is that a game changer or just a cool feature? I can't understand why OCaml doesn't have mass adoption.

I think Rust kind of stole OCaml’s thunder. It has most of the same benefits, with a mostly familiar syntax and a lot of industry buy-in. And with recent versions, I never find myself fighting the borrow checker like I used to.

I rather have the productivity of a tracing GC.

I don't see Rust being the best option for anything other than low level systems code.

Re: Draft of OCaml Scientific Computing book

#22

Post by fluffything »

Skimming through this book, one thing i was constantly wondering, is how well does this ocaml framework use the hardware.

Leaving ocaml aside, the connection between scientific computing and hardware is the one thing I miss the most in "scientific computing" books and courses, because it sooner or later limits the science that any researcher doing scientific computing can do.

To give an example, earlier this week, one of our scientists was waiting 10 minutes between each interactive iteration of their data-set, so I was called to help, and the only feedback they gave was that "its slow", to which I replied "slow with respect to what? how fast are you expecting this to be and _why_?".

The answer to these questions is the difference between "maybe they just need a faster computer", "maybe they need a different algorithm", or even "maybe this problem cannot be solved today because computers this fast do not exist".

From their facial expression, it looked to me that they actually had never thought about any of this, probably because whatever they did before was always fast enough, but now this issue was limiting their science and they were lacking the bare minimum set of tools to even get proper help.

If you are doing scientific computing, chances are that the problems you are going to be dealing with are going to be getting bigger and harder as you advance in your career. For many scientists, the first problems will actually be big enough for the hardware to matter.

I wish scientific computing courses and books will at least provide the most basic tools to these scientist for them to at least be able to get meaningful help. Having someone on call for when this matters is quite expensive.

Re: Draft of OCaml Scientific Computing book

#23

Post by mseri »

7thaccount wrote: post #13
TallGuyShort wrote: post #10

I've never encountered a real OCaml project or anyone who uses it in my career (same is true for Haskell). I have assumed these languages are a hobby for CS academics and get used for pet projects by their devotees. Not that that's bad - they're interesting and the ideas are cool. I would just be afraid of locking myself into an isolated ecosystem that it's hard to hire experienced people for. Is anyone on HN actuall…

I'm not very familiar with the scientific landscape of Haskell or OCaml, but if you would allow an educated guess... Languages like R, Python, Matlab, and Mathematica have a LOT of built-in capability in this area to do symbolic and numerical methods and data analysis kind of stuff (large sparse matrices... etc). You can do a ton in the high level language without ever dropping down to C or Fortran. So a scientist ca…

I am part of Owl contributors/maintainers.

You are right that the ecosystem is small, and will likely be always behind Python, R and Julia. But considering how small the community around numerical methods in OCaml is, I think the work that went into owl and this book is incredible and may help raising awareness and growing the userbase.

I think one of our current limitations is the lack of a high quality, full-featured plotting library. There are some which are used for publication level plots, but they are nowhere near the experience of plotly, matplotlib, ggplot2 or julia's plots.

In any case, the community seems to be slowly growing already, so there is some hope. I think the best would be if we can start integrating it with SciML and similar projects.

Re: Draft of OCaml Scientific Computing book

#24

Post by chalst »

TallGuyShort wrote: post #10

I've never encountered a real OCaml project or anyone who uses it in my career (same is true for Haskell). I have assumed these languages are a hobby for CS academics and get used for pet projects by their devotees. Not that that's bad - they're interesting and the ideas are cool. I would just be afraid of locking myself into an isolated ecosystem that it's hard to hire experienced people for. Is anyone on HN actuall…

OCaml is the strongly-typed functional language that sees most serious use.

It's harder to do generic polymorphism in OCaml since the language has nothing like C++'s parametric templates or Haskell's type classes. It does have a very nice module system that has the required flexibility, but compared to these languages, I think it is clunky for the kind of genericity seen in scientific computing.

I think Julia has shown us that strong typing is not really needed for scientific computing.

Re: Draft of OCaml Scientific Computing book

#25

Post by 7thaccount »

mseri wrote: post #23
7thaccount wrote: post #13

Earlier quoted context omitted.

I'm not very familiar with the scientific landscape of Haskell or OCaml, but if you would allow an educated guess... Languages like R, Python, Matlab, and Mathematica have a LOT of built-in capability in this area to do symbolic and numerical methods and data analysis kind of stuff (large sparse matrices... etc). You can do a ton in the high level language without ever dropping down to C or Fortran. So a scientist ca…

I am part of Owl contributors/maintainers. You are right that the ecosystem is small, and will likely be always behind Python, R and Julia. But considering how small the community around numerical methods in OCaml is, I think the work that went into owl and this book is incredible and may help raising awareness and growing the userbase. I think one of our current limitations is the lack of a high quality, full-featur…

Thanks for the hard work! I always appreciate any contributors even if I have only used OCaml a few times.

I think y'all are definitely raising some awareness and I agree the lack of a plotting library is a major hurdle. You can always call out to GNUPlot from the terminal, but most folks probably don't want to do that.

Re: Draft of OCaml Scientific Computing book

#26

Post by mseri »

Tarq0n wrote: post #12
non-entity wrote: post #11

Earlier quoted context omitted.

I've talked to at least one persons who works on production Haskell applications, and Jane Street, a company that was discussed on HN just yesterday makes heavy use of OCaml, but yeah they're pretty rare and I suppose the people working with them are just lucky. I've heard particularly about the Haskell market that if you want a chance of competing for the few jobs available you have to be among the top-haskellers, b…

Jane Street being the only company that anyone ever mentions when discussing OCaml is even worse in my opinion. It means the ecosystem is going to be heavily driven by their needs, not to mention that banks tend to have idiosyncratic development cultures.

It is not the only one though. There are Ahrefs, Tarides, Tezos, Citrix (XenServer and a part of Xen are in OCaml), Inria, Facebook (for compilers, typecheckers and ReasonML), Bloomberg (was Bucklescript/ReScript, now at facebook though I believe).

There are also some academic projects with industrial uses. Directly to mind come Coq, Frama-C, Mirage and the Zélus compiler.

EDIT: added Inria and Frama-C

Re: Draft of OCaml Scientific Computing book

#27

Post by wtetzner »

G4BB3R wrote: post #7

Each year I think wether should I learn OCaml or not. What is the current state of multi-thread OCaml? Is that a game changer or just a cool feature? I can't understand why OCaml doesn't have mass adoption.

> I can't understand why OCaml doesn't have mass adoption.

The biggest problem with OCaml is the tooling (and Windows support is pretty rough). It is getting better, but it's certainly not as easy as using something like Cargo.

Re: Draft of OCaml Scientific Computing book

#28

Post by mseri »

7thaccount wrote: post #25
mseri wrote: post #23

Earlier quoted context omitted.

I am part of Owl contributors/maintainers. You are right that the ecosystem is small, and will likely be always behind Python, R and Julia. But considering how small the community around numerical methods in OCaml is, I think the work that went into owl and this book is incredible and may help raising awareness and growing the userbase. I think one of our current limitations is the lack of a high quality, full-featur…

Thanks for the hard work! I always appreciate any contributors even if I have only used OCaml a few times. I think y'all are definitely raising some awareness and I agree the lack of a plotting library is a major hurdle. You can always call out to GNUPlot from the terminal, but most folks probably don't want to do that.

Thanks for the kindness!

There is actually a GNUPlot backend for Owl. Works very well, but is a bit lowlevel: https://github.com/hennequin-lab/gp

Similarly, I use https://github.com/mseri/ocaml-gr but it is a safe lowlevel binding. I hope one day to have the time to wrap it into an interface similar to Julia's one.

Re: Draft of OCaml Scientific Computing book

#29

Post by brmgb »

Tarq0n wrote: post #12
non-entity wrote: post #11

Earlier quoted context omitted.

I've talked to at least one persons who works on production Haskell applications, and Jane Street, a company that was discussed on HN just yesterday makes heavy use of OCaml, but yeah they're pretty rare and I suppose the people working with them are just lucky. I've heard particularly about the Haskell market that if you want a chance of competing for the few jobs available you have to be among the top-haskellers, b…

Jane Street being the only company that anyone ever mentions when discussing OCaml is even worse in my opinion. It means the ecosystem is going to be heavily driven by their needs, not to mention that banks tend to have idiosyncratic development cultures.

JaneStreet is not the only user of OCaml.

Both INRIA and the CEA uses OCaml heavily (Coq, CompCert, Frama-C). Cambridge uses it for MirageOS, Facebook to write software analysers and now web applications (the web version of Facebook Messenger), Citrix in XenServer. Bloomberg developed a compiler from OCaml to Javascript.

Re: Draft of OCaml Scientific Computing book

#30

Post by mseri »

dunefox wrote: post #19

Interesting idea to use an ML for scientific programming, but I don't see any practical reasons not to use Julia or Python. I'd rather take advantage of everything Julia already offers (+ Python with PyCall.jl) than wait for the same support in a language not widely used in the first place.

You can use PyML to call python from OCaml in the same way, and it works fine to pass an owl ndarray to numpy.

As a user of both, I think they have different treadoffs. I tend to use OCaml when I am playing around with the code because I find it infinitely easier to refactor (and to figure out what I was doing if I leave the code rotten for too long)

Post reply on HN