Introduction to Functional Programming in OCaml

https://www.fun-mooc.fr/courses/parisdiderot/56002S02/session02/about

by bogomipz • 10 years ago

168 86 10 years ago

vegabook4• 10 years ago

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).

sigjuice• 10 years ago

I did this last year and don't remember much. What were the sizable discreet jumps?

vegabook4• 10 years ago

I think some of the "question 3s" in the exercises were quite a challenge about 3 weeks into the course, and for people like me who insist on getting 100%, I remember spending 4-5x the allotted time on them (or maybe I'm just slow). But as per @ocamlmoocs comment here it looks like some of this has been looked at.

ocamlmooc2• 10 years ago

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• 10 years ago

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

hkjgkjy• 10 years ago

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...

cm34• 10 years ago

Read Real World OCaml and you'll find plenty use of S-Expressions for serialization and configuration due to Core libs by Jane Street :).

KirinDave6• 10 years ago

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.

ihodes3• 10 years ago

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).

spion4• 10 years ago

What about core.typed?

sheepmullet• 10 years ago

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.

What sort of size is the breaking point in your opinion?

I've recently made the move from f# to Clojure and I'm significantly more productive but I'm worried that when I get to larger projects (10-100kloc) I will come unstuck.

jamesthesnake• 10 years ago

hey Jane Street!

dorfsmay2• 10 years ago

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?

joshmarlow• 10 years ago

There's work on multicore doing on right now; IIRC, there was a possibility that it could've shipped in the 2015 December release, but didn't make it. So I think/hope it should be available in the near future.

cm34• 10 years ago

Rust took affine substructural types and integrated them into a language that looks as similar to C and C++ as possible, to make it not seem foreign to your average programmer. You can think of Rust as a focused version of ATS2 with less features for practical reasons.

Rust is for building lower-level code which you would have written in C or C++ before. The comfort features and type system plus compiler support make it more amenable to writing application code as well, which would have been written in Java, C++ or Python out of comfort, so it's used for that, too.

OCaml is still relevant and they complement each other. Rust is decidedly not a functional programming language, so its type system isn't going to magically support expressing the kind of constraints and abstractions (for more maintainable and less bug-prone code) you're able to in OCaml, Haskell, or even ATS2. It's not Rust vs OCaml but Rust and OCaml.

The selling point of Rust over ATS2 or OCaml is the popularity and resulting ecosystem around it, just like the JVM.

OCaml's existing multicore story is practical with async and friends, but they're about to land the low-level framework that allows one to build various concurrency abstractions on top. That one's based on KC's research and is pretty cool, actually.

catnaroek16• 10 years ago

async is for concurrent I/O, not parallel processing.

dorfsmay2• 10 years ago

Is ATS used at all outside academia?

bad_user5• 10 years ago

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.

catnaroek16• 10 years ago

You can do functional programming without garbage collection. The problem is social: few people in the functional programming community are interested in substructural types.

KirinDave6• 10 years ago

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.

spion4• 10 years ago

AFAIK OCaml probably has the best realtime GC.

joseraul• 10 years ago

OCaml is GCed and can infer more type annotations than Rust, so its code feels closer to Python.

Rust is best for complex systems where tight control of resources is required.

desireco42• 10 years ago

Look at Erlang / Elixir for that specific feature.

ihodes3• 10 years ago

Can't say I've tried it, but this approach looks very promising and has a nice, very composable API https://github.com/ocamllabs/reagents

Regarding Rust v OCaml, Rust is a nice language but solving a very different problem. The type system is far weaker than that of OCaml's, it's less expressive (more verbose) by virtue of its sometimes-GCless GC. Rust is meant for system programming, and OCaml is rather more general purpose and pleasant to write in, while remaining incredibly performant.

atopuzov• 10 years ago

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

bad_user5• 10 years ago

Is knowledge of French required for following this course?

cm34• 10 years ago

It's in English.

bad_user5• 10 years ago

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

agumonkey2• 10 years ago

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• 10 years ago

Which Haskell mooc?

agumonkey2• 10 years ago

edX hosted one with Erik Meijer as teacher/presenter.

cies• 10 years ago

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• 10 years ago

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_user5• 10 years ago

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.

aldanor• 10 years ago

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

Looks like a good course, will join.

Introduction to Functional Programming in OCaml

Related Stories