12 ms·

Why We Use OCaml

169 points by ALee 12y ago

vvijay03 12y ago
Good read. I really liked how the author concretely defined the things they use in OCaml, instead of just saying "functional programming" and waving their hands.
- andrewflnr 12y ago
  "Algebraic data types!" [waves hands vigorously]. Seriously though, I agree. It's a very solid run-down of all the main ways OCaml is cool. I'll probably link people here if they ask my about why they should bother with OCaml.
toby 12y ago
What are some advantages of OCaml over Haskell?
- edwintorok 12y ago
  Haskell uses lazy evaluation by default, which makes it hard to reason about the space usage (or termination) of a particular program. OCaml on the other hand is not lazy by default (but supports it if you need it). At least that is one of the reasons why I chose to learn more OCaml than Haskell.
  - quchen 12y ago
    Why do you think termination is easier to reason about in eager languages? I think it's quite the opposite: in lazy languages functions compose, in strict ones they don't necessarily. For example, you cannot compose a "take ten values" and "square all elements" function in a strict language if the argument you apply their composition to has infinite length (e.g. is cyclic).
    - edwintorok 12y ago
      With a lazy language its not always obvious if a certain expression needs to be evaluated now or not. In particular I was writing some list comprehensions in Haskell, trying to solve some of the project Euler problems, and when I introduced a bug I got an infinite loop. When I fixed the bug I got the correct answer thanks to lazy evaluation, but the buggy code and the correct code looked awfully similar. Maybe it is just my inexperience with lazy languages that caused trouble (I came from C), and learning two radically new concepts: functional programming and lazy evaluation was too steep of a learning curve. Or perhaps list comprehensions aren't really supposed to be (ab)used like that. Unfortunately I don't have that code anymore, it would've made it more clear what I'm refering to...
      - kluge 12y ago
        Maybe it is because you didn't show an example, but that doesn't seem like something caused by lazy evaluation. It is pretty easy to get into infinite loops due to logic errors in Project Euler type problems even when using imperative loops.
    - seliopou 12y ago
      The eager vs. lazy distinction is not relevant here. There are some programs that under eager application semantics will not terminate, but under lazy application semantics they will, and vice versa. What complicates reasoning about termination is the presence of mutation. In a lazy language, you'll never have mutation so you don't have to worry about those complications. You could have an eager language with no mutation (e.g., Elm[0]), but for the most part eager languages include some form of mutation and so you may have a harder time proving termination. [0]: http://elm-lang.org http://elm-lang.org
      - quchen 12y ago
        I don't think that's right. There is a basic theorem in (untyped) lambda calculus that says that if a term has a normal form, then any evaluation strategy, including strict and non-strict, will reduce that term to that normal form. Since non-strict evaluation can "skip" arguments that may have no normal form, there are expressions in non-strict languages that terminate while their strict counterparts don't. The opposite scenario does not exist: if a term has to be evaluated, it has to be done in both the strict and non-strict versions. (And in simply typed lambda calculus, all reduction sequences terminate.)
- Dewie 12y ago
  The MLs seem to have better module systems. Or, they have a module system.
- orbifold 12y ago
  It has polymorphic / open variants and a very powerful module system. It is also an impure functional programming language, so you can write straightforward and reasonably fast imperative code in it, if you need to.
- seliopou 12y ago
  I've used Haskell to build JavaScript tools and analyses[0], among other things[1], and have been using OCaml for the past nine months to develop a software-defined networking controller called frenetic[2]. Off the top of my head, here are a few areas where OCaml has an edge on Haskell: 1. The module system. OCaml's module system is a language in and of itself. It not only allows you to define modules that export certain identifiers and types, it also allows you to write functors, which are essentially functions in the module language that can take a module as an argument and produce a new module as a result. This is a great way of reusing code in a project as well as defining external APIs in a general but natural way. OCaml's module system the closest I've seen to realizing the dream of building software by taking some modules from here or there and composing them together. 2. Mutation. Unlike Haskell, OCaml allows mutation. Specifically, OCaml allows value mutation in certain contexts, while both Haskell and OCaml do not allow variable mutation. What this means is that in both languages, if you have an identifier, you cannot change the value that the identifier points to; you can only shadow the identifier with a new binding. But in OCaml, you can declare certain fields of your types to be mutable. You can also wrap values in a "box" which allows you get the same feel that you would out of variable mutation. While in general it's a good idea to limit your use of mutation, sometimes you know it's ok and you just want to do it. OCaml lets you do that, but it requires you to be explicit about it rather than just letting you do it willy-nilly. 3. gdb-able. If you know how to use gdb (and even valgrind I believe), you can use it to debug your OCaml programs. If you try and use these tools with Haskell, you will get nothing but nonsense until you learn how to read the matrix. This fact by itself for some people will make OCaml a candidate for systems programming over Haskell. 4. Subtyping. Certain features of OCaml's type system allow you to do subtyping, complete with type variable annotations to indicate covariance or contravariance. This is a feature that Haskell's type system does not have, so in a sense this is a strength of OCaml. However in my experience, this feature of the type system is hard to use and reason about, and I've seen little (maybe no?) code in the wild that takes advantage of it, with the exception of some simple inference the type system can do in this respect related to polymorphic variants[3]. All that being said, Haskell's still my hobby language of choice. But for building real systems, I'm warming to idea of OCaml as a viable candidate language. [0]: http://www.cs.brown.edu/research/plt/dl/adsafety/v1/ http://www.cs.brown.edu/research/plt/dl/adsafety/v1/ [1]: https://github.com/seliopou/typo https://github.com/seliopou/typo [2]: https://github.com/frenetic-lang/frenetic https://github.com/frenetic-lang/frenetic [3]: https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants https://realworldocaml.org/v1/en/html/variants.html#polymorp...
- tel 12y ago
  A few mentioned in this article are true modules and polymorphic variants. Both can be partially modeled in Haskell, but it's tougher. I feel that almost nobody would disagree that these are advantages of OCaml. Most people also suggest that strict evaluation and impurity are good traits of OCaml. This is more a contested point, however, as lazy evaluation and strict evaluation are more like duals than one being definitely better than the other. Furthermore, unrestricted side effects are a major tradeoff between convenience and safety—it's up to your use case to decide what's best. Finally, OCaml obviously has an "O"bject system in it. My understanding is that serious OCamlers shy away from it for reasons of complexity and low value. The major stuff is provided by the module system and doesn't have anything particularly "object" about it.
- TylerE 12y ago
  Haskell tries to be exceedingly (some might argue excessivly) clever. OCaml strives to be pragmatic and predictable.
  - codygman 12y ago
    Do you have any specific examples? I ask as someone that has landed on the Haskell boat but still keeps an eye/ear on the Ocaml one ;)
    - TylerE 12y ago
      Very small and seemingly innocent changes in a Haskell program can vastly change the runtime characteristics, especially if they introduce a space leak or alter the compiler's strictness analysis. That isn't a factor at all in OCaml - in fact the compiler is fairly "dumb".
- tomsthumb 12y ago
  I would say Ocaml code is much easier to understand as a beginner than Haskell. Even with context I've never been able to just look at some production haskell and get the gist quickly. Ocaml takes work, but I at the very least have an idea of what's going on after giving a chunk of code a once-over. Here's an example: http://llvm.org/docs/tutorial/OCamlLangImpl1.html http://llvm.org/docs/tutorial/OCamlLangImpl1.html
IvarTJ 12y ago
Could someone comment on what instances you would typically apply lambdas and closures in real-world code? I figure that they are at least more convenient than callbacks with a *userData parameter like in C.
- edwintorok 12y ago
  As argument to a 'map' function for example.
- agumonkey 12y ago
  Each time you want to write such callback, you'll need a special userData struct right ? otherwise you'll have a generic bag and lose typechecking. Let's say Closures are free typed anonymously defined structs.
- zem 12y ago
  the "with-" pattern (originally from lisp, i believe, but ruby did a lot to bring it to the masses), where something like a filehandle manages its own lifecycle, and calls your closure in between. so rather than the C-like let f = open-file-for-writing(filename); for line in array { write-line-to-file(f, line); } close-file(f); you can do with-open-file-for-writing(filename) {|f| for line in array { write-line-to-file(f, line); } } where the definition of with-open-file-for-writing() would look like def with-open-file-for-writing(filename, closure) { let f = open-file-for-writing(filename); call-closure(closure, f); close-file(f); } the benefit of having this be a closure rather than just a function pointer can be seen in the write array to file example above, where the "array" variable is in the scope of the calling function, but when with-open-file-for-writing calls your closure it can make full use of its own local variables.
  - dllthomas 12y ago
    Of course, you can build your own closure: void do_stuff_with_file(struct relevant_data *, FILE *); ... { struct relevant_data data = { ... } with_open_file_for_writing(do_stuff_with_file, data, filename); } IMO, the biggest downside there being how far it typically pushes the definition of that function from the call site. Small functions - a good practice anyway - ameliorates that a bit.
kenko 12y ago
From the "About" page: "We want to see a world where everyone gets the mental luxury of an assistant, including the assistant. We are making this future happen. [...] Oh, did we mention every team member gets an assistant?" So ... there's some kind of cycle of assistants, where X is my assistant, Y is X's assistant, and I'm Y's assistant? Esper currently employs infinity people? Assistants are employees but not, you know, team members?
- S4M 12y ago
  The assistants mentioned in the About page are electronic, not real persons, and I suppose that it's the product Esper is building. I'm not affiliated with them in any way but I like the concept.
- deleted 12y ago
  [deleted]
_random_ 12y ago
A bit surprised F# was not even mentioned. I guess they are hardcore meta-programming users?
- Dn_Ab 12y ago
  Why would they? They neither mention other close cousins like Standard ML, second cousins like Haskell or distant relatives like Scala. This is targeted squarely at the 1% of languages that control 60% of mindshare wealth.
- LeonidasXIV 12y ago
  Or maybe the support for OCaml on their platform of choice (Linux, Java via OCamlJava, don't know) is better than of F#. Or maybe they started off from an existing (older) codebase that was started before F# existed. Many possible reasons.
- jonsterling 12y ago
  F# is an ML without any of the things which make ML good (modularity). It's a breath of fresh air if you're on a Microsoft platform, but if you can use OCaml, it is superior.
  - JamesBarney 12y ago
    Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to know a little more about what specifically F# lacks that makes OCAML superior. I want to know what I'm missing out on.
    - yohanatan 12y ago
      Functors (also known as parameterized modules). See: http://ocaml.org/learn/tutorials/modules.html http://ocaml.org/learn/tutorials/modules.html
    - argentpyro 12y ago
      I've never used F#, but I found an SO question [0] which provided the following: - Functors (https://realworldocaml.org/v1/en/html/functors.html https://realworldocaml.org/v1/en/html/functors.html) - OCaml-style objects (https://realworldocaml.org/v1/en/html/objects.html https://realworldocaml.org/v1/en/html/objects.html) - Polymorphic variants (https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants https://realworldocaml.org/v1/en/html/variants.html#polymorp...) - The camlp4 preprocessor (https://realworldocaml.org/v1/en/html/the-compiler-frontend-parsing-and-type-checking.html#preprocessing-source-code https://realworldocaml.org/v1/en/html/the-compiler-frontend-...) - Stronger guarantees from type system. F# allows null values, it seems, while you would need to use an Option type in OCaml. [0] http://stackoverflow.com/questions/179492/f-changes-to-ocaml http://stackoverflow.com/questions/179492/f-changes-to-ocaml
claudiusd 12y ago
> OCaml includes many features that are not available in the more mainstream programming languages ... and we believe this gives us a competitive advantage. ... The purpose of this post is to explain the benefits of OCaml and compare it to other languages. We hope to convince readers, especially other developers, to consider adopting OCaml for their projects as well. The authors did a great job explaining the benefits of OCaml and why I as a developer should think about using the language. I actually want to play around with it now in a side project. As a start-up manager though, I think the business case is strongly against them and don't believe there is any "competitive advantage" from using OCaml... in fact, I think the opposite. Here's why: * There is not a strong community behind OCaml. You can't take advantage of the numerous libraries and references created by the community like you can with Ruby, Python, Javascript, Java, or any of the other mainstream languages. * OCaml is hard (and so are most functional programming languages). You will always need exceptionally talented developers to work on your code base and that will get expensive. * OCaml is not popular. You will have to pay an additional premium for OCaml developers due to the lack of experienced talent. * OCaml is a risk. If you're starting a consumer-oriented service, you need to prove there is a market for it. Will OCaml help you get to market faster? I don't know. Will Ruby-on-Rails? Yes. I'd pick RoR any day just to eliminate the risk of getting to market late.
- sgeisenh 12y ago
  But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes. While most OCaml implementations have poor standard libraries, Jane Street Capital has released several open source libraries that make it easy to implement high quality, performant applications.
  - ryen 12y ago
    > But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates? > While most OCaml implementations have poor standard libraries That right there should tell you something.
eridius 12y ago
Interesting list. I'm curious if the author has looked at Rust and how they think it stacks up. Rust is obviously still pre-1.0, and it doesn't have an identical feature list, but it seems to me to perhaps be a lot more practical for a lot of work than OCaml (largely because Rust can basically be used anywhere C++ can be, and it has good support for C FFI).
- dbpatterson 12y ago
  I think that, having used both of them, Rust is going to feel a lot lower level than OCaml. The single biggest thing is that it's pretty hard (slash near impossible) to write Rust code without thinking about memory allocation, which adds non-trivial mental overhead to the work. That isn't to put down Rust - I think they are the first language that actually has a static, type-checkable story about memory allocation, and that's phenomenal, _but_, the reason for this is to be able to write soft-realtime code (for example, browser engines, games, etc). Web code, at least in the early stages, probably usually has lower performance requirements, and most people would probably trade some performance (and I don't mean to say that OCaml is slow, anymore than Go is slow, etc) for not having to even think about that stuff.
  - deleted 12y ago
    [deleted]
  - eridius 12y ago
    Eh, I don't see that as a downside. And actually, I'm not sure that's even true. It's already apparent that a lot of people are using a lot of completely unnecessary allocation in Rust, precisely because they aren't thinking about what they're doing (and so are doing things like using heap-allocated String objects when they really just need &str slices, or using Box unnecessarily; this was one of the reason cited for moving away from the ~ sigil, as it was considered to "hide" allocation too much). And speaking personally, I almost never have to consciously think about allocation, unless I'm doing really performance-sensitive work. The straightforward approach is usually correct.
- Dewie 12y ago
candl 12y ago
They mention they use Ocaml for server-side tasks. Is there a popular solution in OCaml for writing web pages or rest apis?
- dllthomas 12y ago
  I don't know about the current popularity, and I'm sure other stuff has come along since I've been familiar with what's going on in OCamlland, but there's certainly http://en.wikipedia.org/wiki/Ocsigen http://en.wikipedia.org/wiki/Ocsigen
- hbbio 12y ago
  You can have a look at http://github.com/MLstate/opalang http://github.com/MLstate/opalang
- tizoc 12y ago
  It is quite new compared to what others posted: https://github.com/rgrinberg/opium https://github.com/rgrinberg/opium
ALee 12y ago
Hey HNers, I'm the CEO of Esper - there's been a lot of questions regarding the business case for OCaml and I think it'd be helpful to write here: 1) It's practical - for our team, we had developed in it before and had deployed a large system in it - we could get to where we wanted quickly. 2) we think it's a competitive advantage (see OP and PG's Beating the Averages essay) - additionally, since we deal with large amounts of data, OCaml was particularly helpful in that regard too 3) OCaml is a good filter - the thing that matters more to us is a person's elasticity of learning - their ability to learn new things. We use the right tool for the right job, so we also use javascript, java, objective-C, etc. OCaml is a pretty good filter and test for elasticity of learning. Lastly, not a primary reason, but an advantage - languages get popular because the companies that use them are popular (i.e. gain market traction and can pay developers). That doesn't mean it's the most efficient way to get things done. We'd like to be part of the group that helps make the industry more efficient.
- amirmc 12y ago
  There are many additional reasons that impact the maintenance of established code bases and code reuse. OCaml's Module system is good in this regard. In addition, there are many other companies that use functional languages and my (subjective) experience had been that such orgs are able to achieve far more with smaller teams (cf Whatsapp and Erlang). Facebook and Bloomberg are also users. I find it somewhat bizarre that people are making an issue of the business case for using OCaml in a startup. How many people did that before using Python/Ruby/etc back in the day? Edit: and here's a clicky link to PG's essay http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- tel 12y ago
  I'd love to hear about point (2), in particular how OCaml helped with dealing with large volumes of data.
- undershirt 12y ago
  > languages get popular because the companies that use them are popular ... We'd like to be part of the group that helps make the industry more efficient. It seems true that technology can only go mainstream if there are companies taking the risk to use it in production.
advocaat23 12y ago
Cool tech, but ... I went to the About-Page and I got the following message out of it: "We all want to spend our time dooing meaningful things so we ... bla bla ... have to make an app for that". Come on, I think this is just bullshit. Yes, the premise is correct, people are working too much on stuff they don't like (and we have to fix that), but solving this problem via some time-managment-assistant-whatever-app (oh, there are surely some contrived ML problems to solve here) is just hilarious.
- deleted 12y ago
  [deleted]
roryokane 12y ago
For a more in-depth list of reasons to use OCaml, I recommend “OCaml: What You Gain” at http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain.... It is part of the series of posts linked in “Python to OCaml: Retrospective” at http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... (HN story: https://news.ycombinator.com/item?id=7858276 https://news.ycombinator.com/item?id=7858276). I learned a lot about OCaml from that series of posts. For more comparisons between OCaml and other langages, see the first two posts in the series. In the first post, http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r..., the author compares OCaml to many languages, including Python, Go, and Haskell. The second post http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/ http://roscidus.com/blog/blog/2013/06/20/replacing-python-ro... summarizes his conclusions about the languages – he decided that either Haskell or OCaml would meet his needs best. (He chose OCaml after that, obviously.)
skrebbel 12y ago
I think the HTML example in the blog post is excellent. It's a real, recognizable problem, and the solution is simple and concise. Many FP blog posts get too fundamental/abstract at this stuff, but here it really shows how static typing and pattern matching makes something very simple that is much more involved in e.g. Python or C#.
bby 12y ago
in before JSC

169 points by ALee 12y ago

Good read. I really liked how the author concretely defined the things they use in OCaml, instead of just saying "functional programming" and waving their hands.

andrewflnr 12y ago
"Algebraic data types!" [waves hands vigorously]. Seriously though, I agree. It's a very solid run-down of all the main ways OCaml is cool. I'll probably link people here if they ask my about why they should bother with OCaml.

toby 12y ago

What are some advantages of OCaml over Haskell?

edwintorok 12y ago
Haskell uses lazy evaluation by default, which makes it hard to reason about the space usage (or termination) of a particular program. OCaml on the other hand is not lazy by default (but supports it if you need it). At least that is one of the reasons why I chose to learn more OCaml than Haskell.
- quchen 12y ago
  Why do you think termination is easier to reason about in eager languages? I think it's quite the opposite: in lazy languages functions compose, in strict ones they don't necessarily. For example, you cannot compose a "take ten values" and "square all elements" function in a strict language if the argument you apply their composition to has infinite length (e.g. is cyclic).
  - edwintorok 12y ago
    With a lazy language its not always obvious if a certain expression needs to be evaluated now or not. In particular I was writing some list comprehensions in Haskell, trying to solve some of the project Euler problems, and when I introduced a bug I got an infinite loop. When I fixed the bug I got the correct answer thanks to lazy evaluation, but the buggy code and the correct code looked awfully similar. Maybe it is just my inexperience with lazy languages that caused trouble (I came from C), and learning two radically new concepts: functional programming and lazy evaluation was too steep of a learning curve. Or perhaps list comprehensions aren't really supposed to be (ab)used like that. Unfortunately I don't have that code anymore, it would've made it more clear what I'm refering to...
    - kluge 12y ago
      Maybe it is because you didn't show an example, but that doesn't seem like something caused by lazy evaluation. It is pretty easy to get into infinite loops due to logic errors in Project Euler type problems even when using imperative loops.
  - seliopou 12y ago
    The eager vs. lazy distinction is not relevant here. There are some programs that under eager application semantics will not terminate, but under lazy application semantics they will, and vice versa. What complicates reasoning about termination is the presence of mutation. In a lazy language, you'll never have mutation so you don't have to worry about those complications. You could have an eager language with no mutation (e.g., Elm[0]), but for the most part eager languages include some form of mutation and so you may have a harder time proving termination. [0]: http://elm-lang.org http://elm-lang.org
    - quchen 12y ago
      I don't think that's right. There is a basic theorem in (untyped) lambda calculus that says that if a term has a normal form, then any evaluation strategy, including strict and non-strict, will reduce that term to that normal form. Since non-strict evaluation can "skip" arguments that may have no normal form, there are expressions in non-strict languages that terminate while their strict counterparts don't. The opposite scenario does not exist: if a term has to be evaluated, it has to be done in both the strict and non-strict versions. (And in simply typed lambda calculus, all reduction sequences terminate.)
Dewie 12y ago
The MLs seem to have better module systems. Or, they have a module system.
orbifold 12y ago
It has polymorphic / open variants and a very powerful module system. It is also an impure functional programming language, so you can write straightforward and reasonably fast imperative code in it, if you need to.
seliopou 12y ago
I've used Haskell to build JavaScript tools and analyses[0], among other things[1], and have been using OCaml for the past nine months to develop a software-defined networking controller called frenetic[2]. Off the top of my head, here are a few areas where OCaml has an edge on Haskell: 1. The module system. OCaml's module system is a language in and of itself. It not only allows you to define modules that export certain identifiers and types, it also allows you to write functors, which are essentially functions in the module language that can take a module as an argument and produce a new module as a result. This is a great way of reusing code in a project as well as defining external APIs in a general but natural way. OCaml's module system the closest I've seen to realizing the dream of building software by taking some modules from here or there and composing them together. 2. Mutation. Unlike Haskell, OCaml allows mutation. Specifically, OCaml allows value mutation in certain contexts, while both Haskell and OCaml do not allow variable mutation. What this means is that in both languages, if you have an identifier, you cannot change the value that the identifier points to; you can only shadow the identifier with a new binding. But in OCaml, you can declare certain fields of your types to be mutable. You can also wrap values in a "box" which allows you get the same feel that you would out of variable mutation. While in general it's a good idea to limit your use of mutation, sometimes you know it's ok and you just want to do it. OCaml lets you do that, but it requires you to be explicit about it rather than just letting you do it willy-nilly. 3. gdb-able. If you know how to use gdb (and even valgrind I believe), you can use it to debug your OCaml programs. If you try and use these tools with Haskell, you will get nothing but nonsense until you learn how to read the matrix. This fact by itself for some people will make OCaml a candidate for systems programming over Haskell. 4. Subtyping. Certain features of OCaml's type system allow you to do subtyping, complete with type variable annotations to indicate covariance or contravariance. This is a feature that Haskell's type system does not have, so in a sense this is a strength of OCaml. However in my experience, this feature of the type system is hard to use and reason about, and I've seen little (maybe no?) code in the wild that takes advantage of it, with the exception of some simple inference the type system can do in this respect related to polymorphic variants[3]. All that being said, Haskell's still my hobby language of choice. But for building real systems, I'm warming to idea of OCaml as a viable candidate language. [0]: http://www.cs.brown.edu/research/plt/dl/adsafety/v1/ http://www.cs.brown.edu/research/plt/dl/adsafety/v1/ [1]: https://github.com/seliopou/typo https://github.com/seliopou/typo [2]: https://github.com/frenetic-lang/frenetic https://github.com/frenetic-lang/frenetic [3]: https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants https://realworldocaml.org/v1/en/html/variants.html#polymorp...
tel 12y ago
A few mentioned in this article are true modules and polymorphic variants. Both can be partially modeled in Haskell, but it's tougher. I feel that almost nobody would disagree that these are advantages of OCaml. Most people also suggest that strict evaluation and impurity are good traits of OCaml. This is more a contested point, however, as lazy evaluation and strict evaluation are more like duals than one being definitely better than the other. Furthermore, unrestricted side effects are a major tradeoff between convenience and safety—it's up to your use case to decide what's best. Finally, OCaml obviously has an "O"bject system in it. My understanding is that serious OCamlers shy away from it for reasons of complexity and low value. The major stuff is provided by the module system and doesn't have anything particularly "object" about it.
TylerE 12y ago
Haskell tries to be exceedingly (some might argue excessivly) clever. OCaml strives to be pragmatic and predictable.
- codygman 12y ago
  Do you have any specific examples? I ask as someone that has landed on the Haskell boat but still keeps an eye/ear on the Ocaml one ;)
  - TylerE 12y ago
    Very small and seemingly innocent changes in a Haskell program can vastly change the runtime characteristics, especially if they introduce a space leak or alter the compiler's strictness analysis. That isn't a factor at all in OCaml - in fact the compiler is fairly "dumb".
tomsthumb 12y ago
I would say Ocaml code is much easier to understand as a beginner than Haskell. Even with context I've never been able to just look at some production haskell and get the gist quickly. Ocaml takes work, but I at the very least have an idea of what's going on after giving a chunk of code a once-over. Here's an example: http://llvm.org/docs/tutorial/OCamlLangImpl1.html http://llvm.org/docs/tutorial/OCamlLangImpl1.html

IvarTJ 12y ago

Could someone comment on what instances you would typically apply lambdas and closures in real-world code? I figure that they are at least more convenient than callbacks with a *userData parameter like in C.

edwintorok 12y ago
As argument to a 'map' function for example.
agumonkey 12y ago
Each time you want to write such callback, you'll need a special userData struct right ? otherwise you'll have a generic bag and lose typechecking. Let's say Closures are free typed anonymously defined structs.
zem 12y ago
the "with-" pattern (originally from lisp, i believe, but ruby did a lot to bring it to the masses), where something like a filehandle manages its own lifecycle, and calls your closure in between. so rather than the C-like let f = open-file-for-writing(filename); for line in array { write-line-to-file(f, line); } close-file(f); you can do with-open-file-for-writing(filename) {|f| for line in array { write-line-to-file(f, line); } } where the definition of with-open-file-for-writing() would look like def with-open-file-for-writing(filename, closure) { let f = open-file-for-writing(filename); call-closure(closure, f); close-file(f); } the benefit of having this be a closure rather than just a function pointer can be seen in the write array to file example above, where the "array" variable is in the scope of the calling function, but when with-open-file-for-writing calls your closure it can make full use of its own local variables.
- dllthomas 12y ago
  Of course, you can build your own closure: void do_stuff_with_file(struct relevant_data *, FILE *); ... { struct relevant_data data = { ... } with_open_file_for_writing(do_stuff_with_file, data, filename); } IMO, the biggest downside there being how far it typically pushes the definition of that function from the call site. Small functions - a good practice anyway - ameliorates that a bit.

kenko 12y ago

From the "About" page: "We want to see a world where everyone gets the mental luxury of an assistant, including the assistant. We are making this future happen. [...] Oh, did we mention every team member gets an assistant?" So ... there's some kind of cycle of assistants, where X is my assistant, Y is X's assistant, and I'm Y's assistant? Esper currently employs infinity people? Assistants are employees but not, you know, team members?

S4M 12y ago
The assistants mentioned in the About page are electronic, not real persons, and I suppose that it's the product Esper is building. I'm not affiliated with them in any way but I like the concept.
deleted 12y ago
[deleted]

_random_ 12y ago

A bit surprised F# was not even mentioned. I guess they are hardcore meta-programming users?

Dn_Ab 12y ago
Why would they? They neither mention other close cousins like Standard ML, second cousins like Haskell or distant relatives like Scala. This is targeted squarely at the 1% of languages that control 60% of mindshare wealth.
LeonidasXIV 12y ago
Or maybe the support for OCaml on their platform of choice (Linux, Java via OCamlJava, don't know) is better than of F#. Or maybe they started off from an existing (older) codebase that was started before F# existed. Many possible reasons.
jonsterling 12y ago
F# is an ML without any of the things which make ML good (modularity). It's a breath of fresh air if you're on a Microsoft platform, but if you can use OCaml, it is superior.
- JamesBarney 12y ago
  Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to know a little more about what specifically F# lacks that makes OCAML superior. I want to know what I'm missing out on.
  - yohanatan 12y ago
    Functors (also known as parameterized modules). See: http://ocaml.org/learn/tutorials/modules.html http://ocaml.org/learn/tutorials/modules.html
  - argentpyro 12y ago
    I've never used F#, but I found an SO question [0] which provided the following: - Functors (https://realworldocaml.org/v1/en/html/functors.html https://realworldocaml.org/v1/en/html/functors.html) - OCaml-style objects (https://realworldocaml.org/v1/en/html/objects.html https://realworldocaml.org/v1/en/html/objects.html) - Polymorphic variants (https://realworldocaml.org/v1/en/html/variants.html#polymorphic-variants https://realworldocaml.org/v1/en/html/variants.html#polymorp...) - The camlp4 preprocessor (https://realworldocaml.org/v1/en/html/the-compiler-frontend-parsing-and-type-checking.html#preprocessing-source-code https://realworldocaml.org/v1/en/html/the-compiler-frontend-...) - Stronger guarantees from type system. F# allows null values, it seems, while you would need to use an Option type in OCaml. [0] http://stackoverflow.com/questions/179492/f-changes-to-ocaml http://stackoverflow.com/questions/179492/f-changes-to-ocaml

claudiusd 12y ago

> OCaml includes many features that are not available in the more mainstream programming languages ... and we believe this gives us a competitive advantage. ... The purpose of this post is to explain the benefits of OCaml and compare it to other languages. We hope to convince readers, especially other developers, to consider adopting OCaml for their projects as well. The authors did a great job explaining the benefits of OCaml and why I as a developer should think about using the language. I actually want to play around with it now in a side project. As a start-up manager though, I think the business case is strongly against them and don't believe there is any "competitive advantage" from using OCaml... in fact, I think the opposite. Here's why: * There is not a strong community behind OCaml. You can't take advantage of the numerous libraries and references created by the community like you can with Ruby, Python, Javascript, Java, or any of the other mainstream languages. * OCaml is hard (and so are most functional programming languages). You will always need exceptionally talented developers to work on your code base and that will get expensive. * OCaml is not popular. You will have to pay an additional premium for OCaml developers due to the lack of experienced talent. * OCaml is a risk. If you're starting a consumer-oriented service, you need to prove there is a market for it. Will OCaml help you get to market faster? I don't know. Will Ruby-on-Rails? Yes. I'd pick RoR any day just to eliminate the risk of getting to market late.

sgeisenh 12y ago
But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes. While most OCaml implementations have poor standard libraries, Jane Street Capital has released several open source libraries that make it easy to implement high quality, performant applications.
- ryen 12y ago
  > But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates? > While most OCaml implementations have poor standard libraries That right there should tell you something.

eridius 12y ago

Interesting list. I'm curious if the author has looked at Rust and how they think it stacks up. Rust is obviously still pre-1.0, and it doesn't have an identical feature list, but it seems to me to perhaps be a lot more practical for a lot of work than OCaml (largely because Rust can basically be used anywhere C++ can be, and it has good support for C FFI).

dbpatterson 12y ago
I think that, having used both of them, Rust is going to feel a lot lower level than OCaml. The single biggest thing is that it's pretty hard (slash near impossible) to write Rust code without thinking about memory allocation, which adds non-trivial mental overhead to the work. That isn't to put down Rust - I think they are the first language that actually has a static, type-checkable story about memory allocation, and that's phenomenal, _but_, the reason for this is to be able to write soft-realtime code (for example, browser engines, games, etc). Web code, at least in the early stages, probably usually has lower performance requirements, and most people would probably trade some performance (and I don't mean to say that OCaml is slow, anymore than Go is slow, etc) for not having to even think about that stuff.
- deleted 12y ago
  [deleted]
- eridius 12y ago
  Eh, I don't see that as a downside. And actually, I'm not sure that's even true. It's already apparent that a lot of people are using a lot of completely unnecessary allocation in Rust, precisely because they aren't thinking about what they're doing (and so are doing things like using heap-allocated String objects when they really just need &str slices, or using Box unnecessarily; this was one of the reason cited for moving away from the ~ sigil, as it was considered to "hide" allocation too much). And speaking personally, I almost never have to consciously think about allocation, unless I'm doing really performance-sensitive work. The straightforward approach is usually correct.
Dewie 12y ago

candl 12y ago

They mention they use Ocaml for server-side tasks. Is there a popular solution in OCaml for writing web pages or rest apis?

dllthomas 12y ago
I don't know about the current popularity, and I'm sure other stuff has come along since I've been familiar with what's going on in OCamlland, but there's certainly http://en.wikipedia.org/wiki/Ocsigen http://en.wikipedia.org/wiki/Ocsigen
hbbio 12y ago
You can have a look at http://github.com/MLstate/opalang http://github.com/MLstate/opalang
tizoc 12y ago
It is quite new compared to what others posted: https://github.com/rgrinberg/opium https://github.com/rgrinberg/opium

ALee 12y ago

Hey HNers, I'm the CEO of Esper - there's been a lot of questions regarding the business case for OCaml and I think it'd be helpful to write here: 1) It's practical - for our team, we had developed in it before and had deployed a large system in it - we could get to where we wanted quickly. 2) we think it's a competitive advantage (see OP and PG's Beating the Averages essay) - additionally, since we deal with large amounts of data, OCaml was particularly helpful in that regard too 3) OCaml is a good filter - the thing that matters more to us is a person's elasticity of learning - their ability to learn new things. We use the right tool for the right job, so we also use javascript, java, objective-C, etc. OCaml is a pretty good filter and test for elasticity of learning. Lastly, not a primary reason, but an advantage - languages get popular because the companies that use them are popular (i.e. gain market traction and can pay developers). That doesn't mean it's the most efficient way to get things done. We'd like to be part of the group that helps make the industry more efficient.

amirmc 12y ago
There are many additional reasons that impact the maintenance of established code bases and code reuse. OCaml's Module system is good in this regard. In addition, there are many other companies that use functional languages and my (subjective) experience had been that such orgs are able to achieve far more with smaller teams (cf Whatsapp and Erlang). Facebook and Bloomberg are also users. I find it somewhat bizarre that people are making an issue of the business case for using OCaml in a startup. How many people did that before using Python/Ruby/etc back in the day? Edit: and here's a clicky link to PG's essay http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
tel 12y ago
I'd love to hear about point (2), in particular how OCaml helped with dealing with large volumes of data.
undershirt 12y ago
> languages get popular because the companies that use them are popular ... We'd like to be part of the group that helps make the industry more efficient. It seems true that technology can only go mainstream if there are companies taking the risk to use it in production.

advocaat23 12y ago

Cool tech, but ... I went to the About-Page and I got the following message out of it: "We all want to spend our time dooing meaningful things so we ... bla bla ... have to make an app for that". Come on, I think this is just bullshit. Yes, the premise is correct, people are working too much on stuff they don't like (and we have to fix that), but solving this problem via some time-managment-assistant-whatever-app (oh, there are surely some contrived ML problems to solve here) is just hilarious.

deleted 12y ago
[deleted]

roryokane 12y ago

For a more in-depth list of reasons to use OCaml, I recommend “OCaml: What You Gain” at http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain.... It is part of the series of posts linked in “Python to OCaml: Retrospective” at http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... (HN story: https://news.ycombinator.com/item?id=7858276 https://news.ycombinator.com/item?id=7858276). I learned a lot about OCaml from that series of posts. For more comparisons between OCaml and other langages, see the first two posts in the series. In the first post, http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r..., the author compares OCaml to many languages, including Python, Go, and Haskell. The second post http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/ http://roscidus.com/blog/blog/2013/06/20/replacing-python-ro... summarizes his conclusions about the languages – he decided that either Haskell or OCaml would meet his needs best. (He chose OCaml after that, obviously.)

skrebbel 12y ago

I think the HTML example in the blog post is excellent. It's a real, recognizable problem, and the solution is simple and concise. Many FP blog posts get too fundamental/abstract at this stuff, but here it really shows how static typing and pattern matching makes something very simple that is much more involved in e.g. Python or C#.

bby 12y ago

in before JSC