7 ms·

OCaml for the Masses

120 points by fogus 15y ago

Stasyan 15y ago
He talks about C# 4.0, but F# is not mentioned at all. Once you switch from OCaml to F# you never go back.
- sausagefeet 15y ago
  F# is mentioned at the end.
- j2labs 15y ago
  What makes F# so much more compelling?
  - nicolasp 15y ago
    .NET compatibility and Visual Studio tools are two huge practical advantages for F# adoption over OCaml IMO.
  - Stasyan 15y ago
    I programmed OCaml for couple of years, and now I've been programming F# for past 3 years. OCaml is more verbose than F#. F# is on par with Python. F# besides having all features of OCaml. (You could (and maybe still can) compile OCaml using F# compiler.) also has some nice extras. Workflows (think monads in Haskel). Workflows in turn used to implement Asynchronous Workflows, and mailbox thread processing. So you get Erlang style multithreading. Another point for F#: since it's on .Net and .Net actually runs on multicore machines the way one would think it should run. OCaml on the other hand has garbage collection that does not play with multicore very well. Last but not least: F# can call any .Net function or create any .Net object -> you have access to a lots of things out of the box. F# - batteries included; OCaml - batteries are not included. [Edit - spelling and formatting]
    - Dn_Ab 15y ago
      My memory of OCaml is faded. Can you explain how Ocaml can be more verbose? Especially since the inference story in F# is not as full due to having to deal with objects with ad-hoc polymorphism. I don't see how Ocaml can be more verbose. The core language of both is virtually identical. Also F# is not all of Ocaml. To mind, it lacks functors, ocaml strength modules and polymorphic variants. Ocaml also has the potential to be faster. At least in the single core case.
      - Stasyan 15y ago
        I meant that the syntax of OCaml is more verbose. In F# (now that the #light directive is a default) you need less comparing to OCaml. Do not need to add ;; to terminate an expression (except for in REPL). Do not need to have "done" to close every loop declaration. Do not need to have "in" for "let" declarations.
        pdhborges 15y ago
        You don't need ;; to terminate an expression (except when using the REPL).
      - Stasyan 15y ago
        > Ocaml also has the potential to be faster. At least in the single core case. F# can only go as fast as .NET. Compiled OCaml though is very fast - I completely agree with you.
    - more_original 15y ago
      > F# besides having all features of OCaml. Some important features, such as modules, are missing in F#. I suppose the intention is to replace them by interfaces and classes, but modules in particular are an important omission that makes me prefer OCaml (though I like both ;)).
      - zachsnow 15y ago
        A few other missing features: polymorphic variants, structural types for objects, functors, camlp4 (though it's not really O'Caml core, it's pretty nice). Of course, F# adds lots of things; here's a nice summary: http://stackoverflow.com/questions/179492/f-and-ocaml/2485277#2485277 http://stackoverflow.com/questions/179492/f-and-ocaml/248527...
  - stonemetal 15y ago
    Take a look at the limitations section of the article at the end. F# doesn't have any of those. It has great tools, massive library support, and really good parallelism support. Unfortunately it comes with its own drawbacks. It is a more complicated language. The type system is weaker. Performance isn't as good.
  - Dn_Ab 15y ago
    I don't think F# is necessarily more compelling. It is subjective to what you weight higher. If you go to the article at the bottom it lists some limitations. Libraries, tooling and proper parallelism including in GC. Also IMO F# ties OOP with functional better, on par with Scala. If you weight these against F#'s weaknesses: lack of full modules and functors, tied to .net and mono / non native code generation and they come up being more of an issue then you would prefer F#. Which is the choice I ended up making.
  - gtani 15y ago
    (One not inconsequential issue: I spend 20 minutes the other day googling the F# "as" keyword. In the end, all you can do is read the language spec and source) http://cs.ioc.ee/~keiko/FSharp.html http://cs.ioc.ee/~keiko/FSharp.html http://news.ycombinator.com/item?id=1826564 http://news.ycombinator.com/item?id=1826564 http://stackoverflow.com/questions/4507600/extension-techniques-in-functional-programming-such-as-f http://stackoverflow.com/questions/4507600/extension-techniq... http://stackoverflow.com/questions/4239121/code-compatibility-between-ocaml-and-f http://stackoverflow.com/questions/4239121/code-compatibilit... http://stackoverflow.com/questions/6390665/hesitating-between-c-c-ocaml-and-f-for-my-compiler http://stackoverflow.com/questions/6390665/hesitating-betwee...
  - swah 15y ago
    Does not compile to native code! (???)
    - Stasyan 15y ago
      Do you really need to ?
      - technomancy 15y ago
        I may be an outlier, but the ability to compile to native code is the main reason I'm interested in OCaml. I already know enough VM-based languages, so having something that works close to the metal fills an important gap in my skill set.
  - tincholio 15y ago
    I haven't used it, but I'd wager it's about having Visual Studio, and F# basically using CAML light syntax, so it's less verbose than OCAML.
- mhd 15y ago
  Look at this video[1], 1:09:40. Apparently their code is too functional (heh…) for F# (or, well, the CLR). Not sure whether that has changed with recent versions of both F# and the .NET platform, although I think some problems are really, really hard to solve if you want to stay compatible with .NET libraries. [1]: http://video.google.com/videoplay?docid=-2336889538700185341 http://video.google.com/videoplay?docid=-2336889538700185341
chrisaycock 15y ago
Hmm, this link was posted just a few minutes earlier: http://news.ycombinator.com/item?id=3047682 http://news.ycombinator.com/item?id=3047682
chrisaycock 15y ago
Yaron Minsky has a few videos about Jane Street's use of OCaml in the finance industry: http://www.janestreet.com/technology/ocaml.php http://www.janestreet.com/technology/ocaml.php
scott_s 15y ago
The code examples were formatted wrong in my browser. If that happened to you, try the pdf: http://delivery.acm.org/10.1145/2040000/2038036/p40-minsky.pdf?ip=129.34.20.19&CFID=48219331&CFTOKEN=92125742&__acm__=1317218739_8d77a1cfe3577a2347dbe1d0dd567eb7 http://delivery.acm.org/10.1145/2040000/2038036/p40-minsky.p...
- kkwok 15y ago
  Thank you for this. When I was reading his article I was not seeing how OCaml was readable. Good to know it was just formatted oddly on the webpage.
silentbicycle 15y ago
Duplicate. http://news.ycombinator.com/item?id=3047682 http://news.ycombinator.com/item?id=3047682
- fogus 15y ago
  Sorry about that, I suppose I should'nt lay true faith on the HN dup detector. I typically delete a dup, but for some reason the conversation on this thread has been hot.
chollida1 15y ago
Seeing as how the discussion seems to be here, I'll post my comment from the other post here... Yaron really does know his stuff when it comes to OCaml. http://ocaml.janestreet.com/?q=node/61 http://ocaml.janestreet.com/?q=node/61 people interested in some great OCaml libraries should check out what Jane street has released to the public: http://ocaml.janestreet.com/?q=node/13 http://ocaml.janestreet.com/?q=node/13
- Stasyan 15y ago
  It's an awesome video. Thank you for posting it. I wish I could upvote you more than once
deleted 15y ago
[deleted]
agentgt 15y ago
I love Ocaml. My only gripe is that the language has a ton of ways to do something.. ie there is a syntactical shortcut for almost everything. So I can see how Python guys might scoff at the language. It would be pretty cool if someone made a node.js (event lib) like web server for Ocaml.
- silentbicycle 15y ago
  Ocsigen (http://ocsigen.org/ http://ocsigen.org/) is based on cooperative threads, AKA coroutines. There's also an OCaml-to-Javascript compiler.
wickedchicken 15y ago
Weirdly enough, last night I posted a project skeleton up on GH: https://github.com/wickedchicken/ocaml_skeleton https://github.com/wickedchicken/ocaml_skeleton While the core OCaml language is fun to play around in, a lot of the build tools are scattered across the web and hard to decipher (4 year old blog posts with only half-working code don't help). This aims to remedy that, and I'd appreciate any feedback :).
- aplusbi 15y ago
  I highly recommend you check out oasis (http://oasis.forge.ocamlcore.org/ http://oasis.forge.ocamlcore.org/). It's a meta build system which is quickly gaining traction in the OCaml community. It's still in early development but works extremely well for most projects.
  - wickedchicken 15y ago
    Wow! Very cool. Excited to take a look at this
- fogus 15y ago
  Over the past half year I've been exploring Haskell and so naturally my interest has recently piqued at OCaml. Thank you for this, it couldn't have come at a better time. I wonder if you think it would be worth including camlp4/p5 in the skeleton?
  - wickedchicken 15y ago
    Unfortunately as I'm still coming up in the language myself I don't have knowledge of what would be useful there. If someone who does can point to somewhere, I can try and fit it in.
- deleted 15y ago
  [deleted]
- iskander 15y ago
  Cool, this would have helped me a lot when I was getting started. An idea: You might want to start the README with 'Skeleton is X'. I had to scan around for a while to figure out what your project actually does.
michaelochurch 15y ago
This is one of the most important articles of the past year. It's not just about functional programming being powerful and concise and awesome, even though it is those things. (Mostly, that is. Functional programming, taken too far, can be incomprehensible.) Ocaml's a very simple language: a bare-bones skeleton for what a 2020 language will look like, a functional C. I don't intend to claim that everyone should drop their favorite languages and switch to ML, but it's important to grok the idea of ML to get a taste for: (1) higher-order functions (instead of objects) as the default abstraction when mutability's not needed, and (2) the power of strong, static typing. The actual "language of 2020" won't be this Ocaml (no multicore support) implementation and probably not Ocaml at all, but it will look a lot like Ocaml, Haskell, and Scala. Let me bring out one snippet: Reading code was part of the firm's approach to risk from before we had written our first line of OCaml. Early on, a couple of the most senior traders (including one of the founders) committed to reading every line of code that went into the core trading systems, before those systems went into production. That's not bullshit. A smart person with a general sense of algorithms, but who's not necessarily a full-time programmer, can read and understand most OCaml code. In C++ this would be impossible; you'd need a C++ expert just to make sure you're not going to get impaled by undefined behavior. What makes OCaml awesome is that it's the only language I've encountered (Haskell and Scala may have this property; insufficient exposure) where reading average-case code is fun. Haskell is a great language as well, but it seems to be optimized for writers of code; Ocaml's optimized for readers. Yes, there's horrid Ocaml code out there and there's beautiful code in lesser languages, but Ocaml is the only language I've ever encountered where 50th-percentile code looks attractive. The consequence is that people do read code. Sometimes, just for fun. (Yes, imagine that.) I learned a hell of a lot about programming when I was working in Ocaml simply because I enjoyed reading the code. Average-case C++ code is never fun to read, and what matters in a professional environment is not what the language makes possible, but what average code actually ends up looking like. If you're not familiar in detail with the benefits of functional programming and strong static typing, read this article. Read it 3 times, even.
colanderman 15y ago
This is missing one key feature of OCaml: module functors. Briefly stated, module functors allow you to wrap up a set of functions and types as a module, and state not only which functions and types this module provides but also which functions and types the modules requires. You can plug together module functors with complementary provides and requires, like building with toy bricks. Many languages support the provides half of this feature (e.g. Java's interfaces) but few support the requires half (Scheme's units are one of the few that come to mind). The advantage of supporting both provides and requires include ability to swap out equivalent implementations of some module, perform massive code abstraction, and to better isolate unit tests without resorting to conditional compilation. (You can quite literally plug a high-level module into a fake lower-level module in order to test the high-level one using one line of code.) The "language of 2020" will have this, or an equivalent, means of massive abstraction. Or better still, such a mechanism will exist as a separate language unto itself which can work with multiple languages. (Think C-style symbolic linking combined with a .NET ABI.)
- cwzwarich 15y ago
  OCaml does have functors.
  - colanderman 15y ago
    Yes, I said "This is missing one key feature of OCaml", not "OCaml is missing one key feature" :)
- raphscallion 15y ago
  Functors simply provide dependency injection for modules. It's no different from any other kind of dependency injection, except that modules themselves are a very flexible unit of organisation.

120 points by fogus 15y ago

Stasyan 15y ago

He talks about C# 4.0, but F# is not mentioned at all. Once you switch from OCaml to F# you never go back.

sausagefeet 15y ago
F# is mentioned at the end.
j2labs 15y ago
What makes F# so much more compelling?
- nicolasp 15y ago
  .NET compatibility and Visual Studio tools are two huge practical advantages for F# adoption over OCaml IMO.
- Stasyan 15y ago
  I programmed OCaml for couple of years, and now I've been programming F# for past 3 years. OCaml is more verbose than F#. F# is on par with Python. F# besides having all features of OCaml. (You could (and maybe still can) compile OCaml using F# compiler.) also has some nice extras. Workflows (think monads in Haskel). Workflows in turn used to implement Asynchronous Workflows, and mailbox thread processing. So you get Erlang style multithreading. Another point for F#: since it's on .Net and .Net actually runs on multicore machines the way one would think it should run. OCaml on the other hand has garbage collection that does not play with multicore very well. Last but not least: F# can call any .Net function or create any .Net object -> you have access to a lots of things out of the box. F# - batteries included; OCaml - batteries are not included. [Edit - spelling and formatting]
  - Dn_Ab 15y ago
    My memory of OCaml is faded. Can you explain how Ocaml can be more verbose? Especially since the inference story in F# is not as full due to having to deal with objects with ad-hoc polymorphism. I don't see how Ocaml can be more verbose. The core language of both is virtually identical. Also F# is not all of Ocaml. To mind, it lacks functors, ocaml strength modules and polymorphic variants. Ocaml also has the potential to be faster. At least in the single core case.
    - Stasyan 15y ago
      I meant that the syntax of OCaml is more verbose. In F# (now that the #light directive is a default) you need less comparing to OCaml. Do not need to add ;; to terminate an expression (except for in REPL). Do not need to have "done" to close every loop declaration. Do not need to have "in" for "let" declarations.
      - pdhborges 15y ago
        You don't need ;; to terminate an expression (except when using the REPL).
    - Stasyan 15y ago
      > Ocaml also has the potential to be faster. At least in the single core case. F# can only go as fast as .NET. Compiled OCaml though is very fast - I completely agree with you.
  - more_original 15y ago
    > F# besides having all features of OCaml. Some important features, such as modules, are missing in F#. I suppose the intention is to replace them by interfaces and classes, but modules in particular are an important omission that makes me prefer OCaml (though I like both ;)).
    - zachsnow 15y ago
      A few other missing features: polymorphic variants, structural types for objects, functors, camlp4 (though it's not really O'Caml core, it's pretty nice). Of course, F# adds lots of things; here's a nice summary: http://stackoverflow.com/questions/179492/f-and-ocaml/2485277#2485277 http://stackoverflow.com/questions/179492/f-and-ocaml/248527...
- stonemetal 15y ago
  Take a look at the limitations section of the article at the end. F# doesn't have any of those. It has great tools, massive library support, and really good parallelism support. Unfortunately it comes with its own drawbacks. It is a more complicated language. The type system is weaker. Performance isn't as good.
- Dn_Ab 15y ago
  I don't think F# is necessarily more compelling. It is subjective to what you weight higher. If you go to the article at the bottom it lists some limitations. Libraries, tooling and proper parallelism including in GC. Also IMO F# ties OOP with functional better, on par with Scala. If you weight these against F#'s weaknesses: lack of full modules and functors, tied to .net and mono / non native code generation and they come up being more of an issue then you would prefer F#. Which is the choice I ended up making.
- gtani 15y ago
  (One not inconsequential issue: I spend 20 minutes the other day googling the F# "as" keyword. In the end, all you can do is read the language spec and source) http://cs.ioc.ee/~keiko/FSharp.html http://cs.ioc.ee/~keiko/FSharp.html http://news.ycombinator.com/item?id=1826564 http://news.ycombinator.com/item?id=1826564 http://stackoverflow.com/questions/4507600/extension-techniques-in-functional-programming-such-as-f http://stackoverflow.com/questions/4507600/extension-techniq... http://stackoverflow.com/questions/4239121/code-compatibility-between-ocaml-and-f http://stackoverflow.com/questions/4239121/code-compatibilit... http://stackoverflow.com/questions/6390665/hesitating-between-c-c-ocaml-and-f-for-my-compiler http://stackoverflow.com/questions/6390665/hesitating-betwee...
- swah 15y ago
  Does not compile to native code! (???)
  - Stasyan 15y ago
    Do you really need to ?
    - technomancy 15y ago
      I may be an outlier, but the ability to compile to native code is the main reason I'm interested in OCaml. I already know enough VM-based languages, so having something that works close to the metal fills an important gap in my skill set.
- tincholio 15y ago
  I haven't used it, but I'd wager it's about having Visual Studio, and F# basically using CAML light syntax, so it's less verbose than OCAML.
mhd 15y ago
Look at this video[1], 1:09:40. Apparently their code is too functional (heh…) for F# (or, well, the CLR). Not sure whether that has changed with recent versions of both F# and the .NET platform, although I think some problems are really, really hard to solve if you want to stay compatible with .NET libraries. [1]: http://video.google.com/videoplay?docid=-2336889538700185341 http://video.google.com/videoplay?docid=-2336889538700185341

chrisaycock 15y ago

Hmm, this link was posted just a few minutes earlier: http://news.ycombinator.com/item?id=3047682 http://news.ycombinator.com/item?id=3047682

chrisaycock 15y ago

Yaron Minsky has a few videos about Jane Street's use of OCaml in the finance industry: http://www.janestreet.com/technology/ocaml.php http://www.janestreet.com/technology/ocaml.php

scott_s 15y ago

The code examples were formatted wrong in my browser. If that happened to you, try the pdf: http://delivery.acm.org/10.1145/2040000/2038036/p40-minsky.pdf?ip=129.34.20.19&CFID=48219331&CFTOKEN=92125742&__acm__=1317218739_8d77a1cfe3577a2347dbe1d0dd567eb7 http://delivery.acm.org/10.1145/2040000/2038036/p40-minsky.p...

kkwok 15y ago
Thank you for this. When I was reading his article I was not seeing how OCaml was readable. Good to know it was just formatted oddly on the webpage.

silentbicycle 15y ago

Duplicate. http://news.ycombinator.com/item?id=3047682 http://news.ycombinator.com/item?id=3047682

fogus 15y ago
Sorry about that, I suppose I should'nt lay true faith on the HN dup detector. I typically delete a dup, but for some reason the conversation on this thread has been hot.

chollida1 15y ago

Seeing as how the discussion seems to be here, I'll post my comment from the other post here... Yaron really does know his stuff when it comes to OCaml. http://ocaml.janestreet.com/?q=node/61 http://ocaml.janestreet.com/?q=node/61 people interested in some great OCaml libraries should check out what Jane street has released to the public: http://ocaml.janestreet.com/?q=node/13 http://ocaml.janestreet.com/?q=node/13

Stasyan 15y ago
It's an awesome video. Thank you for posting it. I wish I could upvote you more than once

deleted 15y ago

[deleted]

agentgt 15y ago

I love Ocaml. My only gripe is that the language has a ton of ways to do something.. ie there is a syntactical shortcut for almost everything. So I can see how Python guys might scoff at the language. It would be pretty cool if someone made a node.js (event lib) like web server for Ocaml.

silentbicycle 15y ago
Ocsigen (http://ocsigen.org/ http://ocsigen.org/) is based on cooperative threads, AKA coroutines. There's also an OCaml-to-Javascript compiler.

wickedchicken 15y ago

Weirdly enough, last night I posted a project skeleton up on GH: https://github.com/wickedchicken/ocaml_skeleton https://github.com/wickedchicken/ocaml_skeleton While the core OCaml language is fun to play around in, a lot of the build tools are scattered across the web and hard to decipher (4 year old blog posts with only half-working code don't help). This aims to remedy that, and I'd appreciate any feedback :).

aplusbi 15y ago
I highly recommend you check out oasis (http://oasis.forge.ocamlcore.org/ http://oasis.forge.ocamlcore.org/). It's a meta build system which is quickly gaining traction in the OCaml community. It's still in early development but works extremely well for most projects.
- wickedchicken 15y ago
  Wow! Very cool. Excited to take a look at this
fogus 15y ago
Over the past half year I've been exploring Haskell and so naturally my interest has recently piqued at OCaml. Thank you for this, it couldn't have come at a better time. I wonder if you think it would be worth including camlp4/p5 in the skeleton?
- wickedchicken 15y ago
  Unfortunately as I'm still coming up in the language myself I don't have knowledge of what would be useful there. If someone who does can point to somewhere, I can try and fit it in.
deleted 15y ago
[deleted]
iskander 15y ago
Cool, this would have helped me a lot when I was getting started. An idea: You might want to start the README with 'Skeleton is X'. I had to scan around for a while to figure out what your project actually does.

michaelochurch 15y ago

This is one of the most important articles of the past year. It's not just about functional programming being powerful and concise and awesome, even though it is those things. (Mostly, that is. Functional programming, taken too far, can be incomprehensible.) Ocaml's a very simple language: a bare-bones skeleton for what a 2020 language will look like, a functional C. I don't intend to claim that everyone should drop their favorite languages and switch to ML, but it's important to grok the idea of ML to get a taste for: (1) higher-order functions (instead of objects) as the default abstraction when mutability's not needed, and (2) the power of strong, static typing. The actual "language of 2020" won't be this Ocaml (no multicore support) implementation and probably not Ocaml at all, but it will look a lot like Ocaml, Haskell, and Scala. Let me bring out one snippet: Reading code was part of the firm's approach to risk from before we had written our first line of OCaml. Early on, a couple of the most senior traders (including one of the founders) committed to reading every line of code that went into the core trading systems, before those systems went into production. That's not bullshit. A smart person with a general sense of algorithms, but who's not necessarily a full-time programmer, can read and understand most OCaml code. In C++ this would be impossible; you'd need a C++ expert just to make sure you're not going to get impaled by undefined behavior. What makes OCaml awesome is that it's the only language I've encountered (Haskell and Scala may have this property; insufficient exposure) where reading average-case code is fun. Haskell is a great language as well, but it seems to be optimized for writers of code; Ocaml's optimized for readers. Yes, there's horrid Ocaml code out there and there's beautiful code in lesser languages, but Ocaml is the only language I've ever encountered where 50th-percentile code looks attractive. The consequence is that people do read code. Sometimes, just for fun. (Yes, imagine that.) I learned a hell of a lot about programming when I was working in Ocaml simply because I enjoyed reading the code. Average-case C++ code is never fun to read, and what matters in a professional environment is not what the language makes possible, but what average code actually ends up looking like. If you're not familiar in detail with the benefits of functional programming and strong static typing, read this article. Read it 3 times, even.

colanderman 15y ago

This is missing one key feature of OCaml: module functors. Briefly stated, module functors allow you to wrap up a set of functions and types as a module, and state not only which functions and types this module provides but also which functions and types the modules requires. You can plug together module functors with complementary provides and requires, like building with toy bricks. Many languages support the provides half of this feature (e.g. Java's interfaces) but few support the requires half (Scheme's units are one of the few that come to mind). The advantage of supporting both provides and requires include ability to swap out equivalent implementations of some module, perform massive code abstraction, and to better isolate unit tests without resorting to conditional compilation. (You can quite literally plug a high-level module into a fake lower-level module in order to test the high-level one using one line of code.) The "language of 2020" will have this, or an equivalent, means of massive abstraction. Or better still, such a mechanism will exist as a separate language unto itself which can work with multiple languages. (Think C-style symbolic linking combined with a .NET ABI.)

cwzwarich 15y ago
OCaml does have functors.
- colanderman 15y ago
  Yes, I said "This is missing one key feature of OCaml", not "OCaml is missing one key feature" :)
raphscallion 15y ago
Functors simply provide dependency injection for modules. It's no different from any other kind of dependency injection, except that modules themselves are a very flexible unit of organisation.