
Haskell for OCaml programmers - networked
http://science.raphael.poss.name/haskell-for-ocaml-programmers.html
======
TazeTSchnitzel
Avoiding using the "M-word" and pretending they're just "recipes" is going to
cause confusion when these new Haskell programmers see someone using the list
monad.

I don't understand this almost religious need to rename things. It's a monad,
call it a monad. People don't know what it is? Well, explain what it is to
them. If you hide the real name from them they're going to be confused later.

It's also very strange and unhelpful to tell people that ; in Haskell ("inside
a do block") and OCaml are equivalent. The closest equivalent thing in Haskell
is (>>), which sequences two monad operations together, discarding the result
of the first. Alongside that, there's (>>=), which sequences two monad
operations and passes the result of the first operation to your function. From
there, you can _then_ introduce do-notation, which is just syntactic-sugar.
This way, you avoid newcomers being confused about what `do` does:
[https://wiki.haskell.org/Do_notation_considered_harmful#Dida...](https://wiki.haskell.org/Do_notation_considered_harmful#Didactics)

So `p1 (); p2 ()` would be better translated into Haskell as `main = p1 >>
p2`. And in `main = do putStrLn "world"`, the `do` is redundant.

------
toolslive
One of the reasons I've seen a lot of people move from OCaml to Haskell is the
"holy grail of multi core domination". In OCaml, if you want control over
multiple cores, you need to scale via the process model or wait for OCaml
4.03.

Some people have just moved on.

~~~
istvan__
Well, I am using it mostly for CLI applications where multi core is not a
problem, but the type system is a bliss. An we can just compile to native or
bytecode and deploy a single file (just like Go). Does Haskell support CSP
(channels, cooperative threads)?

~~~
thoughtpolice
The runtime is SMP-capable and lightweight threads are preemptable,
multiplexed on top of epoll (or kqueue) based event loops. So it's a
preemptive N:M model. Haskell threads basically try to behave like OS threads
as much as possible (with semantics that look like they're blocking) but they
have a lot better cost model overall, so you don't need to do manual callback-
based programming. It's pretty nice.

There are really dozens of concurrency abstractions you can choose from, and
yes, CSP-style programming is an option, available as a library:
[http://hackage.haskell.org/package/chp](http://hackage.haskell.org/package/chp)
\- and common abstractions like MVars (which are essentially simple,
concurrent 1-place queues) can get you a long way even without that.

There are other libraries for more specific needs; like graph/dataflow based
parallelism, array parallelism, GPU-based programming, DSLs for image
processing, etc etc.

All that said I'm very happy and hopeful to see OCaml 4.03 adopt multicore
support. OCaml has an excellent, robust and lightweight toolchain and
implementation, and is very straight-forward and powerful out of the box. It's
not my personal cup of tea, but we'd be worse off if they weren't here.

~~~
istvan__
Thank you for the detailed response.

OCaml is not my cup of tea either, but it is really interesting to learn it.
If you have any ML like experience than I guess it is less interesting though.
The toolchain is great this was one reason I decided to try it out.

------
zerr
A question: Why ML family languages need `rec` for recursive functions while
other languages do not?

~~~
eatonphil
[http://stackoverflow.com/questions/9325888/why-does-ocaml-
ne...](http://stackoverflow.com/questions/9325888/why-does-ocaml-need-both-
let-and-let-rec)

and

[http://stackoverflow.com/questions/900585/why-are-
functions-...](http://stackoverflow.com/questions/900585/why-are-functions-in-
ocaml-f-not-recursive-by-default)

