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

81–90 of 132 posts

Re: Draft of OCaml Scientific Computing book

#81

Post by centimeter »

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 more advanced topics you can go into with Haskell, especially around the type system. There is nothing I can think of that you can learn in ocaml that you can’t learn in Haskell

* More fun - if you want to, there are lots of entertaining/aesthetically pleasing things you can do with writing concise/elegant programs or proving properties using the type system

Also, a lot of the putative advantages of OCaml over Haskell (e.g. “Monads seem complicated”) disappear when you use OCaml in practice.

This isn’t to shit on OCaml - it’s better than 95% of languages out there. But if you’re starting from scratch with no prior investment, I would not prefer it in any scenario I can think of.

Re: Draft of OCaml Scientific Computing book

#82

Post by mseri »

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…

There is another widely used standard library: containers. Which is much less opinionated and aims to extend the standard library instead of replacing it. In many use it in production, so it quite well tested and polished.

It is also true that the standard library is growing faster recently, so maybe this will become less of a problem I. The future.

Re: Draft of OCaml Scientific Computing book

#83

Post by smabie »

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 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 before and I'll say it again, modular implicits would be a game changer for OCaml.

Re: Draft of OCaml Scientific Computing book

#84

Post by smabie »

ziotom78 wrote: post #48
chalst wrote: post #24

Earlier quoted context omitted.

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

> I think Julia has shown us that strong typing is not really needed for scientific computing. I think you meant static typing, in opposition to dynamic. Julia is strongly typed like OCaml.

Julia has dynamic typing, not static. You can specify types, but they don't really do anything except help with performance.

A far cry from OCaml's great type inference and compile time static checking.

Re: Draft of OCaml Scientific Computing book

#85

Post by octachron »

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 would encourage people to learn both Haskell and OCaml. Between functors, GADTs, recursive types one can already have a lot of fun with the advanced corners of OCaml type system. One point where OCaml and Haskell differs a lot is on the question of abstraction and modularity: Haskell requires a transparent world where type definitions are always visible, and abstract interfaces have always one implementation by type whereas OCaml promotes a world where implementation details might be abstracted away and behavior are not bound to types.

Re: Draft of OCaml Scientific Computing book

#86

Post by octachron »

yawaramin wrote: post #72
cultus wrote: post #36

In my opinion, static languages don't bring a whole lot to the table with numerical math. There's not many types for one. You basically just use matrices and vectors of floats most of the time. What would really be a bigger deal is some limited dependent typing to avoid errors from mismatched array sizes. Until then though, Julia is a bit more practical choice for me.

OCaml can provide that: https://github.com/Octachron/tensority

Slap (https://github.com/akabe/slap) is a more serious attempt. Tensority is still a prototype library that ventures very far into statistical safety, probably at a quite steep cost in usability.

Re: Draft of OCaml Scientific Computing book

#87

Post by smabie »

As someone that likes and uses OCaml a lot but uses Julia for scientific computing, it's not worth it, just use Julia.

The Julia code is going to be shorter, faster, and more elegant. The libraries will be sooo much better. The static typing of OCaml doesn't really help in this area and sometimes actually hurts (statically typed DataFrames don't work so well).

Re: Draft of OCaml Scientific Computing book

#88

Post by devmunchies »

rich_sasha wrote: post #56
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)

Interesting, thank you! From just preliminary research, F# seems both loved by its devs, but also found to be a bit of an unloved child on a sidetrack - that was probably another reason I hesitated in getting started. Do you think that is justified?

I wouldn't say its unloved or on a side track, it's baked into .net as a first class citizen and has dedicated engineers at Microsoft working on it.

When I started I was pleasantly surprised how easy it was to download .net core on a mac and not do anything else to use F#.

Its less popular than C# so its there's not as much documentation from 3rd party sources, youtube videos, etc, but you can use any C# modules in F# so you'll get used to reading C# docs.

I would highly recommend this overview of the .Net ecosystem: https://www.youtube.com/watch?v=bEfBfBQq7EE

I really like how it showed a preview of "modern C#" at 12:20 which is being influenced by F#.

After that, this talk opened my eyes to the power of f# philosophy and type system: https://www.youtube.com/watch?v=2JB1_e5wZmU

Re: Draft of OCaml Scientific Computing book

#89

Post by ddragon »

smabie wrote: post #84
ziotom78 wrote: post #48

Earlier quoted context omitted.

> I think Julia has shown us that strong typing is not really needed for scientific computing. I think you meant static typing, in opposition to dynamic. Julia is strongly typed like OCaml.

Julia has dynamic typing, not static. You can specify types, but they don't really do anything except help with performance. A far cry from OCaml's great type inference and compile time static checking.

The grandparent meant that OCaml is static while Julia is dynamic, and both are strongly typed.

>You can specify types, but they don't really do anything except help with performance.

For Julia it's the exact opposite though, types don't help with performance since the compiler infers them anyway regardless of declaring them or not (you only really should to specify in very particular cases where inference is not possible to avoid the compiler being too conservative, and if you overspecify types you might even end up with a slower program). You declare them for their main purpose of controlling dispatch.

Julia's type system is a core aspect of it's paradigm (multiple dispatch [1]), which is the key element in both it's performance and polymorphism. It's different from a gradual typed language in which the language can exist without the types at compilation time, but those can be optionally added to enhance safety or performance, Julia cannot be compiled without knowing the types, which will happen regardless of declaration.

[1] https://www.youtube.com/watch?v=kc9HwsxE1OY

That said, types in Julia are not used for compile time static checking, which is a compromise that for many tasks it's not worth it. Ocaml ML and Julia ML can coexist well exactly because they have vastly different compromises, with Julia focused on interactivity/fast prototyping and Ocaml in safety (like Lisp x Haskell, but with somewhat more pragmatic languages).

Re: Draft of OCaml Scientific Computing book

#90

Post by zucker42 »

srean wrote: post #74
zucker42 wrote: post #62

Earlier quoted context omitted.

I don't know. I think Scala and F# have stolen OCaml's thunder more than Rust. While Rust has been inspired by ML, OCaml and Rust have much different usecases.

Other than interop with .NET does F# bring anything more ? Perhaps a little cleaner syntax. One thing F# does not bring is Ocaml's powerful module system

I'd agree that interop with .NET is the main advantage of F# over OCaml.

My point was more that I think OCaml competes mostly with other functional and more generally GCed languages, not a language like Rust.

Post reply on HN