I took this course ten years ago with Didier Remy, I was very disappointed.
First of, the course was called "Operating Systems", and I was expecting subsetting like the Tannenbaum, explaining the theory and practice behind kernels. The course actually was about Unix system programming, and solely about that. At least the page is properly named.
Second, I think OCaml is an amazing language, but frankly it's a terrible choice for this course. One needs the right tool for the right job. No particular " insight " is gained as the page alleges, beyond the insight that, gee, C would probably be a better lanhuage to interface with the system it was designed for!
Our project consisted in implementing the "ls" command in OCaml, which meant mostly covering all the corner cases brought by different flags. It wasn't interesting, it didn't teach valuable skills.
Functional programming languages shine when they deal with complex, recursive data structures, not for simple tasks which are primarily IO and need to handle many cases.
> Functional programming languages shine when they deal with complex, recursive data structures
While I obviously can't comment on the details of the course you took a decade ago, I do have to disagree vehemently with this. OCaml is close to as ideal a systems programming language as I've ever used since:
- it has a simple, stable and predictable runtime with strict evaluation semantics, so you can identify what statements allocate memory by inspecting code.
- the compilation to native code is fast and Unix-like, with standard object files generated that can be linked to and from C programs easily.
- the memory representation of values is uniform and native code debugging with gdb/lldb works great, thanks to the DWARF symbols emitted.
- OCaml's basic language features such as algebraic data types and exhaustive pattern matching are fantastic for both building low-level programs, and refactoring them in the future as they inevitably get more complex.
> not for simple tasks which are primarily IO and need to handle many cases.
And this is exactly where libraries like Async or Lwt are so useful, since you can juggle millions of concurrent threads and still do high-level programming without getting lost in the noise. Error monads, failure monitors, function wrappers to ensure resources get freed, can all be built directly within the language itself using the usual ML abstractions, and the compiled code is still lightweight and natively compiled.
For those interested in reading more about the runtime system in OCaml, the entire third part of Real World OCaml is dedicated to this topic: https://realworldocaml.org/v1/en/html/pt03.html
C is not a great language for the sort of stuff in this course. Apart from good documentation. Mostly it is not performance critical, and often deals with strings. The C interfaces are very verbose and easy to make mistakes in. Hence the popularity of Go etc. IPC,sockets and so on is a core framework of programming so wide language support is good.
This is primarily what I use functional languages for so far, so naturally I disagree. As long as their aren't stringent performance requirements (though functional languages like Ocaml and Haskell are pretty fast) I find functional languages to be a generally better fit.
Also parsing and string handling in C is worlds more difficult than something like Parsec using parser combinators.
> Functional programming languages shine when they deal with complex, recursive data structures, not for simple tasks which are primarily IO and need to handle many cases.
I think most of the advantages of FP languages (as they exist today) become disadvantages as your data structures get more and more complex. Efficient mutability becomes necessary. Pattern matching breaks down as (G)ADTs can no longer encode useful invariants. Referential transparency becomes useless once you realize you want explicit sharing. Laziness and space leaks become a huge PITA. The RTS and the mandatory GC start getting in your way as it gets harder and harder to eek out performance from your code. etc etc..
This sounds really cool. I currently TA a CS course that deals primarily with OCaml so it is great to have real world applications/uses I can show to students in the class.
[+] [-] murbard2|11 years ago|reply
First of, the course was called "Operating Systems", and I was expecting subsetting like the Tannenbaum, explaining the theory and practice behind kernels. The course actually was about Unix system programming, and solely about that. At least the page is properly named.
Second, I think OCaml is an amazing language, but frankly it's a terrible choice for this course. One needs the right tool for the right job. No particular " insight " is gained as the page alleges, beyond the insight that, gee, C would probably be a better lanhuage to interface with the system it was designed for!
Our project consisted in implementing the "ls" command in OCaml, which meant mostly covering all the corner cases brought by different flags. It wasn't interesting, it didn't teach valuable skills.
Functional programming languages shine when they deal with complex, recursive data structures, not for simple tasks which are primarily IO and need to handle many cases.
[+] [-] avsm|11 years ago|reply
While I obviously can't comment on the details of the course you took a decade ago, I do have to disagree vehemently with this. OCaml is close to as ideal a systems programming language as I've ever used since:
- it has a simple, stable and predictable runtime with strict evaluation semantics, so you can identify what statements allocate memory by inspecting code.
- the compilation to native code is fast and Unix-like, with standard object files generated that can be linked to and from C programs easily.
- the memory representation of values is uniform and native code debugging with gdb/lldb works great, thanks to the DWARF symbols emitted.
- OCaml's basic language features such as algebraic data types and exhaustive pattern matching are fantastic for both building low-level programs, and refactoring them in the future as they inevitably get more complex.
> not for simple tasks which are primarily IO and need to handle many cases.
And this is exactly where libraries like Async or Lwt are so useful, since you can juggle millions of concurrent threads and still do high-level programming without getting lost in the noise. Error monads, failure monitors, function wrappers to ensure resources get freed, can all be built directly within the language itself using the usual ML abstractions, and the compiled code is still lightweight and natively compiled.
For those interested in reading more about the runtime system in OCaml, the entire third part of Real World OCaml is dedicated to this topic: https://realworldocaml.org/v1/en/html/pt03.html
[+] [-] justincormack|11 years ago|reply
[+] [-] codygman|11 years ago|reply
This is primarily what I use functional languages for so far, so naturally I disagree. As long as their aren't stringent performance requirements (though functional languages like Ocaml and Haskell are pretty fast) I find functional languages to be a generally better fit.
Also parsing and string handling in C is worlds more difficult than something like Parsec using parser combinators.
[+] [-] denim_chicken|11 years ago|reply
I think most of the advantages of FP languages (as they exist today) become disadvantages as your data structures get more and more complex. Efficient mutability becomes necessary. Pattern matching breaks down as (G)ADTs can no longer encode useful invariants. Referential transparency becomes useless once you realize you want explicit sharing. Laziness and space leaks become a huge PITA. The RTS and the mandatory GC start getting in your way as it gets harder and harder to eek out performance from your code. etc etc..
[+] [-] pekk|11 years ago|reply
[+] [-] jlukecarlson|11 years ago|reply