
Introduction to Functional Programming in OCaml - bogomipz
https://www.fun-mooc.fr/courses/parisdiderot/56002S02/session02/about
======
agumonkey
Some note: compared to the Haskell mooc, the FUN ocaml mooc is quite
pragmatic, they don't go into faux monadic concurrency through Continuations
or Tree Functors. There are some mind bending exercices though. (speaking from
the previous run of course)

~~~
ximeng
Which Haskell mooc?

~~~
agumonkey
edX hosted one with Erik Meijer as teacher/presenter.

------
cies
I'm really interested in OCaml, especially now that Reason has reduced the
entry barrier for our team, and the BuckleScript OCaml-to-JS compiler has
matured.

A very pragmatic yet functional stack could show from this, call it the ORBS-
stack (OCaml/Reason/BuckleScript).

Now I wonder what cool front-end frameworks, possibly binding to JS
frameworks, exist. In PureScript I really like Thermite and Halogen.

~~~
learningman
I'm with you but the F#-Websharper stack already exists for isomorphic ML
coding in both the front and backends. Reason/bucklescript is only on the
frontend and is an entirely different "dialect" compared to OCaml.

~~~
bad_user
Having both Ocaml and F# descending from ML doesn't say much really, other
than both implementing Hindley–Milner type inference and sharing some syntax.
They are very different languages.

For example Ocaml has functors, polymorphic variants and row polymorphism,
versus F# which has .NET"s OOP and subtyping. F# as a language feels to me
more limiting.

I won't comment on the runtimes / environments, as they have pros and cons,
but there's something odd about F# to Javascript compilers. There's WebSharper
and FunScript and now Fable. I don't understand why the community can't get
behind a single one, because neither of them is popular enough to have reached
critical mass. Take a look at WebSharper's commit activity for the past year
and compare with Scala.js or with ClojureScript. And note I'm not saying
anything about its technical merits.

Whereas for FunScript and Fable, well FunScript is probably going to die and
neither of them seem to cope with "isomorphic" libraries.

~~~
junkyarddog
There's more to F# then HM type inference plus ".NET's OOP and subtyping". OOP
and subtyping are rarely used. While it lacks some of OCaml's powerful
features it shares many core features such as algebraic data types, exhaustive
pattern matching, immutability by default, Option types and so on. It's also
arguably easier to read with it's white space significance and not needing the
rather distracting "in" keyword.

Having the vast .NET library is a big plus for the language, of which OCaml
has no equivalent. Other great features of F# are type providers,
straightforward multi-core programming and units of measure, which I don't
believe have OCaml equivalents.

------
dorfsmay
I got exited about OCaml when I tried to solve my performance issues in
Python, but then realised OCaml didn't have a good multi core story either...

Any progress in that area?

Given that rust has picked up a lot in terms of typing and even syntax from
OCaml, is OCaml still worth investigating?

~~~
bad_user
If you're looking for exhausting your CPU cores, you can do it with Python as
well, by using multiple processes, like when using "multiprocessing". What
Python and (currently) Ocaml won't do is being able to run in parallel
multiple OS-managed threads that share the same address space. The approach in
Ocaml is thus to use multiple processes instead of threads and do message
passing between them and if you need to share some memory, you can do that
too, although it gets tricky.

In terms of performance, inability to do in-process threads-based parallelism
isn't Python's biggest problem though. Good throughput is generally achieved
by avoiding indirection and by being able to control the memory layout.
Because Ocaml is static, because Ocaml code isn't heavy on OOP and because
Ocaml also gives you low level tools allowing you to control the memory
layout, you can have code that's " _as fast as C_ ".

> _Given that rust has picked up a lot in terms of typing and even syntax from
> OCaml, is OCaml still worth investigating?_

Rust and Ocaml are very different programming languages. Rust does not have a
GC and that changes its nature completely. For example Rust could be used for
real-time systems where garbage collected languages would struggle. Another
consequence for example is that Rust isn't a functional programming language.

~~~
KirinDave
> If you're looking for exhausting your CPU cores, you can do it with Python
> as well, by using multiple processes, like when using "multiprocessing".

Successful multiprocessing frameworks are, in a modern sense,
indistinguishable from networked peer-to-peer systems. While this space is
well explored, it's very difficult to call the resulting discipline "easy."
Just like threaded programming, it's easy to make something subtly wrong.

> Rust and Ocaml are very different programming languages. Rust does not have
> a GC and that changes its nature completely. For example Rust could be used
> for real-time systems where garbage collected languages would struggle.

Surveying the field, real time garbage collection is not a pipe dream. It's a
delivered and purchasable reality. Propagating the myth that only direct
memory management can possibly deliver good results is ignoring the last 15
years of hard work on the subject, as well as products in the field.

You're propagating a sort of urban legend. Please reconsider it.

~~~
catnaroek
> Surveying the field, real time garbage collection is not a pipe dream. It's
> a delivered and purchasable reality. Propagating the myth that only direct
> memory management can possibly deliver good results is ignoring the last 15
> years of hard work on the subject, as well as products in the field.

Hardcoding the optimal resource reclamation strategy into your program will
always be more efficient at runtime than not doing so. What “real-time”
garbage collection gives you is only freedom from arbitrarily long pauses, not
closeness to the optimal strategy. Furthermore, it doesn't come for free: it
imposes some memory usage overhead. Finally, garbage collection simply can't
handle resources that need to be reclaimed in a deterministic fashion, like
file handles, GUI objects and network connections.

~~~
wtetzner
> Hardcoding the optimal resource reclamation strategy into your program will
> always be more efficient at runtime than not doing so.

That depends on what you mean by efficient. Since this thread is about real-
time stuff, you may be right (though I wouldn't be on it). However, often a GC
will give better throughput.

It depends on the style of memory management on both sides, of course. But for
example, in a situation where you call `free` (or, `delete`, etc.) to free
each allocation, you might end up doing more work than a copying GC, where you
only have to track live references.

~~~
catnaroek
Of course, “the optimal resource reclamation strategy” depends on what you
want to optimize in the first place. I didn't intend to suggest it's always
“free every resource as soon as you don't need it anymore”.

------
aldanor
The background soundtrack for the intro video sounds hilarious for some reason
:)

Looks like a good course, will join.

------
hkjgkjy
Sounds like a lot of fun! I'm a Clojure user feeling queasy about leaving
s-expressions, but am very interested in the type safety. Signing up now...

~~~
KirinDave
I founded and help maintain a very large Clojure codebase and to be honest, I
am sick to death of not having a real type system to help me.

Sure, we can test the crap out of our code watching for npe's. We can lint
like crazy. We can write large integration tests to better understand the
larger picture better. But ultimately nothing is as pervasive as the compiler
relentlessly asking you to be clear.

What's more, the benefits of a language like OCaml (where Tagged unions,
GADTs, direct modeling of errors via an Either composition, etc. rule the day)
on your code leads you to a really good place when the codebase is
sufficiently large.

Giving up s-expressions and monads is indeed a sad thing. I'd miss it.

~~~
ihodes
You don't need to leave monads in OCaml (in fact, I'd be very sad to not be
using them regularly). Typically the Lwt, Option, and Error monad. (Also
speaking as a former Clojurer).

~~~
Scarbutt
Could you expand on "former Clojurer"? :)

~~~
ihodes
I used to write a fair bit of Clojure, in 2009-2011, but have moved to mostly
OCaml these days.

~~~
KirinDave
Is there a reason you didn't consider F#?

I'm contemplating similar chnages to my tool chain.

------
bad_user
Is knowledge of French required for following this course?

~~~
cm3
It's in English.

~~~
bad_user
OK, cool. I just registered on fun-mooc.fr and saw they've got courses in
French.

~~~
Davidbrcz
Disclosure : I'm French and know some people who dubbed the course.

The course may be taught in English but speakers are mostly French people. So
expect crappy English accent.

The site itself is an attempt by the French government to build a French mooc
platform.

------
vegabook
Has this course changed or evolved in any way from the one that was given last
year at this time (which was very good but had a few sizeable discreet jumps
in the learning curve at certain points, which could have done with being
smoothed out a little).

~~~
ocamlmooc
The overall structure stays the same, but we have made some changes: notably,
we reduced the workload by suppressing some exercises which turned out to be
too difficult, and quite a few glitches have been fixed.

If you have precise suggestions for improvement, please do not hesitate to
send them to the course authors, there maight still be time to take them into
account.

~~~
1_listerine_pls
Why OCaml instead of other functional languages such as Scala, Haskell,
Erlang, etc...? Is there anything unique about OCaml.

~~~
vegabook
It is purer than Erlang, has less cruft than Scala, is more practical than
Haskell, and in my opinion has a very nice syntax. It is also very fast.

~~~
reddit_clone
>It is purer than Erlang

Not sure what value of 'pure' you are using here. Erlang has (practically) no
mutation to speak of. Thus I would consider that purer.

Ocaml on the other hand is as mutating as you want it to be.

~~~
vegabook
Yes I guess I was throwing static typing, somewhat incorrectly, into the
"pure" catch-all.

------
jamesthesnake
hey Jane Street!

------
atopuzov
I'm so excited and I just can't hide it! ;-)

