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

91–100 of 132 posts

Re: Draft of OCaml Scientific Computing book

#91

Post by choeger »

weeniehutjr420 wrote: post #61
vmchale wrote: post #46

Earlier quoted context omitted.

> Facebook does some OCaml too Using an ML or a Lisp for language tooling is the way to go. Nothing else in that league.

How about Haskell?

Haskell is like the nerdy cousin of the ML family. Everyone knows he's smart, but no one would think to ask him to fix the kitchen sink or install the new dishwasher.

Seriously, Haskell is massively impressive, both as a research language and as an implementation. But it does not shed that certain research attitude. Every known problem seems to be boring. "Oh you want a proxying http server? No problem, this is just the inversion of the endofoo over the category of abstract Monobars!". Sometimes I get the feeling that no one focuses on shipping actual software with Haskell.

Re: Draft of OCaml Scientific Computing book

#92

Post by Twisol »

sadiq wrote: post #33
mseri wrote: post #20

Earlier quoted context omitted.

Multicore development has sped up pace, there are many changes in the latest two compiler internals that were made in order to accommodate the new GC, and you can read updates on those works in this year's' POPL and ICFP talks. Multicore benchmarks are on github and are used to drive the changes. When used properly you can see large speedups without affecting much the speed of single core OCaml (which is quite fast).…

Just to add to this good summary, OCaml already has some support for parallelism that would be useful for scientific computation. Essentially you can already have multi-threaded OCaml programs as long as only one thread is using the OCaml runtime at any point in time. For numerical code where you might be spending the vast majority of your time in external libraries this ends up not being a major problem. It's not a…

> the recent ICFP2020 paper

I'll just note here that this paper is hot off the presses! ICFP is taking place as we speak, this week, Monday to Friday.

Re: Draft of OCaml Scientific Computing book

#93

Post by heavyset_go »

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.

> Each year I think wether should I learn OCaml or not

Ask yourself if you want to learn OCaml for practical reasons, or because you want to satisfy an internal itch. Both are perfectly good reasons to learn a language.

When I went to evaluate OCaml, I realized I wouldn't get much practical use out of it despite my curiosity, and focused on learning skills that I would get practical use out of. I'm happy with my choice, and plan to revisit the language to satisfy my curiosity at some other point.

Re: Draft of OCaml Scientific Computing book

#94

Post by ducaale »

yodsanklai wrote: post #75
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.

As others said, I think the language is great. Things get uglier when you want to go from OCaml to real world OCaml. The standard library is lacking, which means you have to use Jane Street libraries or other third-party library which may not be very robust, stable, documented. Jane Street libraries are fine but they significantly increase the complexity of the langage. They also encourage you into doing things a cer…

>Also, I find monad-based asynchronous programming to be quite tedious.

Have you tried using OCaml's monadic let expressions? It was introduced on verion 4.08 and they share similarity with F# computation expressions.

* https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-...

* https://caml.inria.fr/pub/docs/manual-ocaml/bindingops.html

Re: Draft of OCaml Scientific Computing book

#95

Post by cole-k »

steev wrote: post #42
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. Probably for the exact same reason each year you think about learning OCaml you decide not to (I mean this sincerely, not trying to be snide). I think the main reasons it doesn't see mass adoption in industry: * There are only two major companies that do a substantial amount of OCaml that I can think of off the top of my head, Jane Street and Ahrefs. Facebook…

> * The tooling is lacking.

Care to elaborate on this point? Maybe it's just because I'm coming from Haskell (lol), but my experience with OCaml's tooling has been pretty darn good.

While I don't think there's a heavyweight IDE for OCaml à la IntelliJ, in Emacs I get my error messages inline, on-the-fly checking (including type inference and checking, which is huge), and pretty good completion. All of this seems to "just work".

The build system also seems to "just work" and utop is pretty nice.

Re: Draft of OCaml Scientific Computing book

#96

Post by gnufx »

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.

The most serious scientific computation gets done on distributed memory systems, not shared. That likely just means bindings to MPI and other appropriate libraries. That will often do pretty well on shared memory too.

Re: Draft of OCaml Scientific Computing book

#97

Post by brmgb »

centimeter wrote: post #81
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.

As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostly to do with some aspects of the module system and polymorphic variants. I strongly believe Haskell is: * More production ready (including insanely good multithreading - probably the best of any language except perhaps Erlang) * Better for learning - there are…

I see the Haskell community offensive on OCaml is still going strong.

Having worked with both, I really like using OCaml but avoid Haskell like the plague. Being lazy by default makes it very difficult to reason about Haskell performance really fast.

Admittedly another benefit of using OCaml is that you don't have to deal with the Haskell community and its obsession with looking smart. From experience, OCaml users tend to be a lot more oriented towards practical matters like, you know, building softwares rather than lenses library.

Re: Draft of OCaml Scientific Computing book

#98

Post by gnufx »

fluffything wrote: post #22

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, on…

It is a continuing source of wonder how many scientists seem unable to apply scientific method/research to computing. However, yes, things like debugging, measurement, and hardware features should be taught and rarely are apart from courses on performance engineering which seem to pass most by.

Re: Draft of OCaml Scientific Computing book

#99

Post by brmgb »

smabie wrote: post #83
centimeter wrote: post #81

Earlier quoted context omitted.

As someone who uses 90% OCaml for work, I would strongly recommend learning Haskell instead. There are only a few very narrow fronts where I prefer OCaml, mostly to do with some aspects of the module system and polymorphic variants. I strongly believe Haskell is: * More production ready (including insanely good multithreading - probably the best of any language except perhaps Erlang) * Better for learning - there are…

I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala. I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong. I've said this befor…

> I've said this before and I'll say it again, modular implicits would be a game changer for OCaml.

That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml.

The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the time.

Re: Draft of OCaml Scientific Computing book

#100

Post by gnufx »

jimbokun wrote: post #63
Bukhmanizer wrote: post #39

Earlier quoted context omitted.

Let’s face it, is this researcher ever going to read a book on scientific computing in OCaml? Most researchers won’t even read a book on scientific computing.

Why do you think that? That's like saying "most programmers would never read a book about science, or finance...", or whatever field they are writing software for.

> Why do you think that?

Observation in research support, I'd guess. It typically no longer seems to be the case that you do whatever you need to for your data.

Post reply on HN