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

111–120 of 132 posts

Re: Draft of OCaml Scientific Computing book

#111

Post by brmgb »

centimeter wrote: post #107
brmgb wrote: post #97

Earlier quoted context omitted.

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 te…

I'm not part of "the Haskell community", just a random hobbyist. You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist. > Being lazy by default makes it very difficult to reason about Haskell performance really fast. I think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all. > practical matters like, you know, building soft…

> You seem to have invented some sort of persecution scenario that I'm pretty sure doesn't exist.

It's not persecution. It's just that recently you can't have a discussion about OCaml without having an Haskell devotee dropping by and implying you should use Haskell instead generally for somewhat spurious reasons (same with Rust but the languages are so different, it's easier to ignore). It gets a bit tiring.

> think this is a ~complete non-issue mostly brought up by people who haven't actually used Haskell much at all.

We might have to agree to disagree on this one.

> Not having a well-functioning asynchronous programming system (Async sucks).

It's a chance everyone uses Lwt then. Pretty much no one uses Async apart from Jane Street.

> Also, OCaml does have a clone of Lens, but it was only written in the last year. Another example of how OCaml is very far behind Haskell in terms of development/production readiness.

OCaml has multiple lenses libraries including one written by Jane Street which are not used a lot because mutations are fine. This is not being far behind. It is being practical.

Re: Draft of OCaml Scientific Computing book

#112

Post by bmitc »

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…

I just cannot understand how people find Python easy to learn but languages like F# or OCaml hard to learn. I personally find Python to be a much more confusing language than F#.

Re: Draft of OCaml Scientific Computing book

#113

Post by smabie »

centimeter wrote: post #108
smabie wrote: post #83

Earlier quoted context omitted.

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…

> Of course I guess I could use unsafePerformIO everywhere I don't understand comments like this. This is obviously not something that Haskellers actually do, so the simplest conclusion (or, it seemed simplest to me starting Haskell) is that thinking this is necessary is simply indicative of not understanding how to program functionally/monadically. Indeed, once you figure out Haskell idioms this isn't ever an issue.…

Of course it's not necessary. I have a lot of experience with Haskell, but I still believe the Haskell way of tracking effects puts an undue burden on the developer. I'm simply not interested in keeping track of effects and mutation.

In my experience, there's little value in the monadization of all effects and also a non-trivial cost. I much prefer the traditional FP style of avoiding mutation and side-effects but not lifting them into the type system when they are necessary.

This does mean you can screw up and accidentally mutate things, but I've personally never had the problem.

Re: Draft of OCaml Scientific Computing book

#114

Post by devmunchies »

heavyset_go wrote: post #102
devmunchies wrote: post #54

Earlier quoted context omitted.

Data science and interactive programming are actually the main focus of the next release of f#. Not saying it’s bad now, but Microsoft wants it to be a strong option in data workflows. https://devblogs.microsoft.com/dotnet/announcing-f-5-preview... I had originally been learning ocaml but switched to f# because it has much better tooling and more uses (e.g. better web server support since I use .net libs)

How much of F#, .net and its data science stack can be divorced from Windows?

.net is cross platform now. it has the same "run anywhere" philosophy as the JVM. I haven't used windows in over 10 years.

Re: Draft of OCaml Scientific Computing book

#115

Post by brmgb »

smabie wrote: post #110
brmgb wrote: post #109

Earlier quoted context omitted.

> For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explic…

But what if you're doing a bunch of category theory stuff? Passing in the right monoid or whatever to every function is such a drag. Alternatively using local open is also a drag. Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. Not sure how it came to be that everyone totally ignores it.

But why would you be doing a bunch of category theory stuff while writing softwares ?

Local open with let+ and let* make writing monadic and applicative code very easy when needed. Anything more abstract than that is over complex abstraction.

OCaml is not Haskell. Trying to write Haskell code in OCaml is always going to result in something highly unidiomatic.

> Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful.

I have written a fair bit of OCaml and never actually encountered these problems. In practice, module prefixing and local open are just fine. You rarely use more than one module per function anyway.

I agree that the object system is nice but structural typing is rarely what you want and it leads to convoluted error messages.

Re: Draft of OCaml Scientific Computing book

#116

Post by mseri »

smabie wrote: post #105
gnufx wrote: post #103

Earlier quoted context omitted.

What makes Julia code shorter and more elegant generally? I strongly disagree with static typing not being useful in scientific computing. Most of that I see isn't dealing with data frames, though I've seen confusion with types in those with R users.

I would say the biggest difference is broadcasting. So let's say I have an array of returns, r: r = [0.0001; -0.00002...] I might be interested to find the cumulative returns: cumprod(1 .+ r) .- 1 Or just apply a function f to it: f.(r) In Ocaml I can't vectorize any notation: List.map ~f:(fun x -> x - 1)) @@ List.cumprod(List.map r ~f:((+) 1)) List.map r ~f:f Julia allows you to write code in a very vectorized, arra…

owl ndarrays come with operations that support broadcasting though

Re: Draft of OCaml Scientific Computing book

#117

Post by heavyset_go »

devmunchies wrote: post #114
heavyset_go wrote: post #102

Earlier quoted context omitted.

How much of F#, .net and its data science stack can be divorced from Windows?

.net is cross platform now. it has the same "run anywhere" philosophy as the JVM. I haven't used windows in over 10 years.

I'm aware that .net is cross platform, however there is the issue that C# apps that use WinForms or WPF aren't cross platform, or at least that was the case the last time I checked.

I am curious as to whether the F# ecosystem is similarly fragmented by Windows-only libraries.

Re: Draft of OCaml Scientific Computing book

#118

Post by matrixanger »

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…

This has a chapter on low level optimisation in Owl: https://ocaml.xyz/book/core-opt.html, which includes how core functions are implemented in C, and how OpenMP is utilised etc. Besides, Owl relies on certain libraries such as OpenBLAS and FFTPack for the performance of key operations in e.g. linear algebra.

Re: Draft of OCaml Scientific Computing book

#119

Post by fluffything »

matrixanger wrote: post #118
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…

This has a chapter on low level optimisation in Owl: https://ocaml.xyz/book/core-opt.html , which includes how core functions are implemented in C, and how OpenMP is utilised etc. Besides, Owl relies on certain libraries such as OpenBLAS and FFTPack for the performance of key operations in e.g. linear algebra.

This chapter showcases the problem perfectly.

It gives scientists a lot of information about how to perform low level optimization on code, e.g., if your code is "slow", use SIMD, OpenMP, BLAS, or do this or that trick.

But it does not provide the scientist with even the most basic tools to answer the question: "Is my code fast or slow?" (i.e. should I optimize it at all?), much less "_Why_ is it slow, and what's the best way to address that?" (e.g. if it is slow because its using 100% of the peak FLOPs of the CPU, but your hardware has a GPU, so you end up with 1% total FLOP utilization, then none of the "tricks" there will help).

It also completely avoids the issue that, in practice, a O(N) algorithm beats a OpenMP+SIMD-optimized O(N^2/p) algorithm pretty much all the time.

The chapter kind of assumes that scientists OCaml code will be slow, and gives them a "bag of tricks" that they can try to make it faster.

So we end up with the irony of a book on scientific computing that completely ignores the scientific method.

Re: Draft of OCaml Scientific Computing book

#120

Post by fluffything »

Bukhmanizer wrote: post #39
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…

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.

I suppose this book exists because somebody developed a scientific computing course at university that uses it.

So I'd expect that every year, there will at least be a class of 30 scientists taking this course.

Post reply on HN