12 ms·

Why OCaml, why now? (2014)

185 points by lelf 12y ago

tejinderss 12y ago
Now that .net is going cross platform, I see a great future of f# (another variant of ML family). Its got multi processors support too.
- melling 12y ago
  Is there somewhere one can follow the Mac and Linux ports? I'm stoked about F#/OCaml too.
  - rdtsc 12y ago
    Have you tried Mono and Monodevelop? I have used C# with Mono and for back-end work (non-GUI) and it works pretty well so far. I think they have F# support as well.
    - jfeser 12y ago
      I can confirm that MonoDevelop works reasonably well for F#, but the documentation for F# on Mono isn't great. Coming from OCaml, I love F# as a language, but the tooling isn't as good as it is for OCaml. Might be better on Windows with VS, but I haven't looked closely at that.
  - deleted 12y ago
    [deleted]
- integraton 12y ago
  F# seems like a very nice language, but it won't really be compelling outside of the Microsoft bubble until it's divorced from the thick layer of Microsoft .CORP Brand Identity 2010, Visual Studio Visual Studio Visual Studio, and posts from Microsoft Outreach Engineers. Compare these two Stack Overflow "getting started with" answers for Haskell http://stackoverflow.com/a/1016986 http://stackoverflow.com/a/1016986 and F# http://stackoverflow.com/a/11974625 http://stackoverflow.com/a/11974625 With the Haskell answers I don't know or care what platforms, operating systems, editors, or IDEs they are using. With the Microsoft answer it's like a dystopian scene filled with Branding, Branding, and more Branding. Personally, I spend a lot of time experimenting with languages and ecosystems and the ".NET" platform is the only one where I feel the need to put on a plaid shirt and dockers with a Windows Phone on my belt and schedule a conference call with a committee at Microsoft to tell them to give it a rest already.
  - BSousa 12y ago
    mac: brew install mono run f# console/repl: fsharpi compile files: fsharpc file.fs Not sure about linux, but should be simple as well. And as with Haskell and cabal, you have FAKE ( http://fsharp.github.io/FAKE/ http://fsharp.github.io/FAKE/ ) which isn't exactly the same but similar The main difference between those two answers is that for Haskell, the author pointed to generic Haskell resources while F# pointed to windows ones. I've been developing with F# for a while on the Mac and found no issues whatsoever. There is also MonoDevelop/Xamarin if you want a more complete IDE which is better than anything I found for Haskell (but there maybe new stuff I'm missing, having messed with Haskell in a while) but SublimeText and Vim work fine.
- lmm 12y ago
  I think most people who wanted a cross-platform, VM-based, corporate-ecosystem-integrated ML derivative with good concurrency support have already found Scala :P.
  - aphexairlines 12y ago
    The problem with Scala is that you don't just get ML -- you have to accept everything else that comes along -- so F# can be a more comfortable choice.
    - frowaway001 12y ago
      It might be easier to accept the additional parts of Scala, because the creators didn't design them to be an tacked-on, intentionally horrible feature. (OO in F#/OCaml anyone?) Plus, sane typeclasses and higher-kinded types. :-)
      - sixbrx 12y ago
        I agree and I think F# would look a lot more attractive to functional programmers if it had some type of polymorphism other than the C#-like generics and traditional OO subtyping. I can understand not choosing to go the ML route "down the Functor rat hole" as one of its developers said. But then it also chooses not to do the simpler type classes either. Apparently a proper impl would need CLR changes which is a downside to the reified generics, they are baked in as C#/VB imagined them. That leaves a language that conceptually is very close to C#/VB, with a somewhat different syntax. I find either of typeclasses or an ML-like module system far preferable for expressing abstractions than traditional ("left-biased") OO, even if OO can (clumsily) get the same results in other ways. Or I may have missed some developments in F# since I last looked. I really hope so, F# does have a lot going for it.
  - MichaelGG 12y ago
    I've looked but not touched Scala. My impressions are A: Rather verbose. B: Carries a lot more OO/Java baggage. C: I've heard that the performance can be underwhelming.
didyoucheckthe 12y ago
> The first question I usually get ... is “Why not Haskell?”. > The answer is JavaScript. My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2]. Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why: It uses a completely declarative state machine to model a fully interactive and complete GUI! This is the dream React.js and Om didn't even know they were heading towards! And yes, it is as good as it sounds. [1]: http://elm-lang.org/ http://elm-lang.org/ [2]: http://elm-lang.org/learn/FAQ.elm http://elm-lang.org/learn/FAQ.elm EDIT: Also, Elm fixed Haskell's awful syntax record name collision problem, and awesomely too!
- jarcane 12y ago
  Purescript[1] is also gaining some traction and even has a pretty nice looking book out. [2] It has some changes however; most notably it's strictly evaluated rather than lazy, and there are differences in how it handles type variables. [3] Personally though, I've grown more fond of F# than Haskell; I only wish the documentation for Websharper and Funscript was more solid. [1] http://www.purescript.org/ http://www.purescript.org/ [2] https://leanpub.com/purescript/read https://leanpub.com/purescript/read [3] https://github.com/purescript/purescript/wiki/Differences-from-Haskell https://github.com/purescript/purescript/wiki/Differences-fr...
  - didyoucheckthe 12y ago
    Elm is actually 3 things rolled into one: 1. an language very similar to Haskell 2. a set of runtime libraries 3. a technique for modeling a GUI as a declarative state machine PureScript only competes with #1 and #2 here. Where Elm really shines is #3, which #2 helps with a lot. Technically #3 could be done in any language. But it really helps to model it in such an expressive language with immutable data and no side-effects (except via Signals).
    - purescript 12y ago
      I won't argue that Elm does anything other than an exemplary job at #3, but it is worth noting that there are some interesting efforts to build similar functionality in PureScript libraries: https://github.com/paf31/purescript-thermite https://github.com/paf31/purescript-thermite https://github.com/kRITZCREEK/reactive-psc https://github.com/kRITZCREEK/reactive-psc https://github.com/bodil/purescript-signal https://github.com/bodil/purescript-signal https://github.com/michaelficarra/purescript-demo-mario https://github.com/michaelficarra/purescript-demo-mario https://github.com/mechairoi/purescript-frp-rabbit https://github.com/mechairoi/purescript-frp-rabbit To me, this is the benefit of PureScript - yes, you have to do a little more work, because you don't get these things for free from the compiler and tools, but you gain complete control over your application structure. You're not forced to work in some ambient Signal category.
dbpatterson 12y ago
I think the author doesn't give enough credit to things that OCaml has that Haskell doesn't have: a powerful module system (ie, functors), polymorphic variants/subtyping, etc.
- vitriol83 12y ago
  IMO key advantage OCaml is easier to learn and much more pragmatic.
- amirmc 12y ago
  Toolchains also matter and OPAM (the package manager) has gone from strength to strength since this post. It's the basis for the OCaml Platform which combines a number of useful tools and libs into a coherent workflow (making development much more productive).
  - more_original 12y ago
    Also merlin is worth mentioning explicitly. It finds and highlights errors during editing (in emacs, vim and co), does autocompletion, shows types and since recently can also write pattern matches automatically. http://the-lambda-church.github.io/merlin/destruct.ogv http://the-lambda-church.github.io/merlin/destruct.ogv
  - ufo 12y ago
    OPAM still doesn't run natively on Windows though :(
- jordwalke 12y ago
  There's a bunch of other nice features of OCaml such as named arguments, fast compile times, strictness, c-types, and reasonable records. To achieve (some of the feature in) Elm style "structural subtyping" records in OCaml you use the more verbose "object" keyword which is just a record with row polymorphism. Most choose to stick with standard records because they compile to more efficient code. I think the ML module system (in OCaml and other languages) is very powerful because it allows you to abstract and operate not only on types but also on values simultaneously. F#, Haskell, and most others lack this but it would be great if they were to officially adopt it. OCaml is also very easy to learn and I seriously recommend Real World OCaml - it's free online and excellent.
lmm 12y ago
If it's about what's well-supported for compiling to Javascript, does scala.js becoming non-experimental change the landscape?
- spyder81 12y ago
  I knew about scala.js when writing the post (although it was still experimental at the time) but I didn't mention it because I don't like Scala. It looked promising when I first saw it, but then I had to write some production code in it. My opinion now is that if you're forced to use the JVM then Scala is one of the best options. But that's a low bar, given the choice I would pick something else.
saosebastiao 12y ago
Is there anywhere that I can track the status of the multicore runtime and modular implicits?
- lpw25 12y ago
  Multicore: https://github.com/stedolan/ocaml https://github.com/stedolan/ocaml Modular implicits: https://github.com/ocamllabs/ocaml-modular-implicits https://github.com/ocamllabs/ocaml-modular-implicits
wyager 12y ago
I honestly don't get how people can claim that Haskell is unusually hard to learn. I started learning Haskell with zero functional programming experience, and after getting over that initial pure+functional learning curve (which took two or three weeks of casual learning), it was smooth sailing. Haskell is actually a very simple language compared to popular languages like python or C++; you just have to do a bit of thinking to get out of the procedural/imperative/impure mindset. I especially don't understand how people get tripped up by laziness. 99.9% of strict code will work with no changes in a lazy environment. The rest usually just needs a slight tweak to avoid memory leaks. To anyone considering undertaking the modest effort required to learn Haskell, I completely recommend it. My code in every language has tangibly improved.
- alayne 12y ago
  From your website, you appear to be a college student. Perhaps your expectations and uses are different than commercial developers.
  - lomnakkus 12y ago
    That's a pretty sad indictment of commercial developers. Or perhaps just the pressures put on said developers :/.
  - paulrpotts 12y ago
    College students often feel at the time that they are completely overloaded with work and barely getting through (in some cases that is true, especially students who are working or non-traditional). But looking back, it is pretty clear that although I worked hard in school, I could have worked so much harder, and also that never in my life again will I be in an environment that was so _supportive_ of just learning. Not just in classes; in fact, my college experience was _especially_ supportive things learned outside of classes. And also, at 20, 21, 22 -- there are very good reasons those are the traditional college years. Our brains are just able to _soak_ up ideas so quickly at that age. They aren't wise, they can't necessarily integrate everything, but we are _sharp_ then! (Usually...)
  - wyager 12y ago
andrewstuart 12y ago
I wanted to like OCaml, mainly for working with Unikernels. When I looked at the syntax it just looked very arcane, which was discouraging.
- ignoramous 12y ago
  Might come handy in case you want help yourself get over the seemingly cryptic syntax: http://rigaux.org/language-study/syntax-across-languages/ http://rigaux.org/language-study/syntax-across-languages/
- ufo 12y ago
  The syntax is certainly very wonky but you get used to it. Installing merlin (vim / emacs plugin) helps a lot too.
ignoramous 12y ago
Unless start-ups or top companies [0] start adopting OCaml, I doubt its rise would be meteoric. Take go-lang, for example. It performs no better than Java on JVM, but is gaining tremendous traction because Google is putting all its weight behind it. I believe C# gets far less credit than it deserves... and MSFT knows exactly what its doing by open sourcing it. I digress. I feel, one is better off investing time in Clojure or Haskell (if functional programming is what one is after), both of which are gaining a lot more traction in the industry and the academia compared to OCaml. I can speak from what I observed here at Amazon... which did try and make use of Erlang (due to its excellent concurrency model) at one point, but gave up (Simple DB is powered by Erlang, but its successor DynamoDB is JVM based). At least Erlang had its chance... OCaml community within Amazon is non-existent. Whereas Clojure (plenty of traction within due to STM on JVM, I guess) has plenty going for it, as does Nodejs and go-lang. All of these plaforms are popular due to the strong community presence both within the company and at other tech power houses. I'd also like to point out that the current crop of volunteers behind ocaml.org [1] are doing a really great job of evangelising OCaml. [0] https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html and http://clojure.org/Companies http://clojure.org/Companies and https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry [1] https://ocaml.org/about.html https://ocaml.org/about.html
- amirmc 12y ago
  You mean top companies like, say, Facebook? Or startups like, Esper? I'm not really sure what your comment is trying to say because it comes across as circular ('they're popular because lots of people use them'). Edit: seems you've added the links I was about to point to.
- aphexairlines 12y ago
  It doesn't take much to boot up a community in a large company like Amazon or Facebook as long as it brings value. See the FXL, Haxl, and React work at Facebook. (I removed my comments on Amazon as it's hard to gauge what's ok to mention in public)
- danieldk 12y ago
  Take go-lang, for example. It performs no better than Java on JVM, but is gaining tremendous traction because Google is putting all its weight behind it. That's definitely a large factor. But let's not forget that Go already took off when it was barely beyond being a 20% project. Go also fills some niches, three particular ones I can think of are: - People who like Java, but favor the UNIX approach of small programs over the JVM. - People who like Python or Ruby, but need more performance. - People who like C, but want garbage collection and some extra safety in some of their projects. Add to that that Go is trivial to learn for anyone with a Java, C, or C++ background. Of course, it takes some time to learn all the idioms, but someone who knows languages with C-like syntax can start writing Go programs productively within a day.
yodsanklai 12y ago
One thing I don't like about OCaml is that I always find myself writing the same things, like "to_string" functions for my variant types (although there must be some ways to alleviate this burden). Also, when your programs use abstract data types you lose the benefits of pattern matching. In that case, I'm happier with languages like Go or Ada with a friendlier syntax.
- mercurial 12y ago
  PPX lets you generate show functions automatically. As for abstract types you can use "private" if you need to pattern match outside the module but wont to ensure that the structure can only be created by your module.
- tel 12y ago
  If you have an ADT but want pattern matching, try Scott Encoding. For instance, here we have Option module Option = struct let scott (some : 'a -> 'r) (none : 'r) (opt : 'a option) = match opt with | Some a -> some a | None -> none end For Option, since it's non-recursive, the Scott Encoding and the recursor/inductor/Church Encoding are identical. Here's a linked list, though module LL : sig type 'a t val fold : ('a -> 'r -> 'r) -> 'r -> ('a t -> 'r) val scott : ('a -> 'a t -> 'r) -> 'r -> ('a t -> 'r) end = struct type 'a t = Cons of 'a * 'a t | Nil let rec fold cons nil = function | Cons (h, t) -> cons h (fold cons nil t) | Nil -> nil let scott cons nil = function | Cons (h, t) -> cons h t | Nil -> nil end Anyway, the pattern should be more clear now. These provide effectively "functionalized" pattern matching which you can apply whenever you need. In particular, you can think of these as expressing a (potentially partial) "view" of the abstract type. For instance, my linked list might have not been a linked list exactly but instead some kind of tree, but `scott` and `fold` let me expose a "view" of that tree as though it were a linked list.
  - ufo 12y ago
    If you look at this from an "expression problem" point of view, this version with the records-of-functions is very similar to OO programming. But without inheritance, classes and so on.
jonsterling 12y ago
Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possibility of, e.g., using effects to implement a semantically pure interface. On the other hand, OCaml has actual effects, which can be used in an open-ended way to implement all sorts of functional interfaces. 3. strictness: arguments abound about whether laziness or strictness is better; for me, it comes down to the fact that with some pain, you can embed laziness in a strict language with effects, but you cannot embed full-on ML-style strictness into a language like Haskell; moreover, strictness-by-default permits safe uses of benign effects. I'd call Haskell an expression-oriented programming language, since the types end up classifying expressions and algorithms (i.e. the particular "effects" you used get put into the type). Whereas I'd say (OCa)ML is a value-oriented language, since values (canonical forms) are considered separately from general expressions (canonical and non-canonical forms); moreover, implementation details don't end up in the types, so you can really consider them to be classifying values and functions (i.e. equivalence classes of algorithms, not algorithms themselves). This is largely orthogonal from strictness vs laziness, but as soon as you add partiality in, strictness becomes the only tractable way to have canonical-form-based meaning explanations for the judgements of the theory. P.S. My day job is writing Haskell. (In case the Pedagogical Brethren wish to come and "correct" me.)
- jordwalke 12y ago
  I generally prefer programming with immutability, but I certainly appreciate the ability to use "benign effects" in my programs. Besides the case for performance, I have applied a strange combination of benign effects, GADTs, and functors to generate a sort of "proof of type equality" between two values passed into a framework, each of which are not known to the framework because they're passed into the framework by two separate clients of the framework. At that point, I had the ability to reason about two values with arbitrary and potentially distinct types, as either being not the same (None), or the same Some(x, y) with x and y having the same type. I have no clue if there's a more elegant way to do this (edit: there probably is), but even I (as a n00b) was able to figure out how to do this by using benign effects. There's only a single mutation in this library - but it was such a critical one that made everything else possible. I'm curious about the reason for preferring generative functors over applicative functors. It seems like both could have valid use cases. Could you point me to a writeup that explains why you believe generative functors are superior?

185 points by lelf 12y ago

Now that .net is going cross platform, I see a great future of f# (another variant of ML family). Its got multi processors support too.

melling 12y ago
Is there somewhere one can follow the Mac and Linux ports? I'm stoked about F#/OCaml too.
- rdtsc 12y ago
  Have you tried Mono and Monodevelop? I have used C# with Mono and for back-end work (non-GUI) and it works pretty well so far. I think they have F# support as well.
  - jfeser 12y ago
    I can confirm that MonoDevelop works reasonably well for F#, but the documentation for F# on Mono isn't great. Coming from OCaml, I love F# as a language, but the tooling isn't as good as it is for OCaml. Might be better on Windows with VS, but I haven't looked closely at that.
- deleted 12y ago
  [deleted]
integraton 12y ago
F# seems like a very nice language, but it won't really be compelling outside of the Microsoft bubble until it's divorced from the thick layer of Microsoft .CORP Brand Identity 2010, Visual Studio Visual Studio Visual Studio, and posts from Microsoft Outreach Engineers. Compare these two Stack Overflow "getting started with" answers for Haskell http://stackoverflow.com/a/1016986 http://stackoverflow.com/a/1016986 and F# http://stackoverflow.com/a/11974625 http://stackoverflow.com/a/11974625 With the Haskell answers I don't know or care what platforms, operating systems, editors, or IDEs they are using. With the Microsoft answer it's like a dystopian scene filled with Branding, Branding, and more Branding. Personally, I spend a lot of time experimenting with languages and ecosystems and the ".NET" platform is the only one where I feel the need to put on a plaid shirt and dockers with a Windows Phone on my belt and schedule a conference call with a committee at Microsoft to tell them to give it a rest already.
- BSousa 12y ago
  mac: brew install mono run f# console/repl: fsharpi compile files: fsharpc file.fs Not sure about linux, but should be simple as well. And as with Haskell and cabal, you have FAKE ( http://fsharp.github.io/FAKE/ http://fsharp.github.io/FAKE/ ) which isn't exactly the same but similar The main difference between those two answers is that for Haskell, the author pointed to generic Haskell resources while F# pointed to windows ones. I've been developing with F# for a while on the Mac and found no issues whatsoever. There is also MonoDevelop/Xamarin if you want a more complete IDE which is better than anything I found for Haskell (but there maybe new stuff I'm missing, having messed with Haskell in a while) but SublimeText and Vim work fine.
lmm 12y ago
I think most people who wanted a cross-platform, VM-based, corporate-ecosystem-integrated ML derivative with good concurrency support have already found Scala :P.
- aphexairlines 12y ago
  The problem with Scala is that you don't just get ML -- you have to accept everything else that comes along -- so F# can be a more comfortable choice.
  - frowaway001 12y ago
    It might be easier to accept the additional parts of Scala, because the creators didn't design them to be an tacked-on, intentionally horrible feature. (OO in F#/OCaml anyone?) Plus, sane typeclasses and higher-kinded types. :-)
    - sixbrx 12y ago
      I agree and I think F# would look a lot more attractive to functional programmers if it had some type of polymorphism other than the C#-like generics and traditional OO subtyping. I can understand not choosing to go the ML route "down the Functor rat hole" as one of its developers said. But then it also chooses not to do the simpler type classes either. Apparently a proper impl would need CLR changes which is a downside to the reified generics, they are baked in as C#/VB imagined them. That leaves a language that conceptually is very close to C#/VB, with a somewhat different syntax. I find either of typeclasses or an ML-like module system far preferable for expressing abstractions than traditional ("left-biased") OO, even if OO can (clumsily) get the same results in other ways. Or I may have missed some developments in F# since I last looked. I really hope so, F# does have a lot going for it.
- MichaelGG 12y ago
  I've looked but not touched Scala. My impressions are A: Rather verbose. B: Carries a lot more OO/Java baggage. C: I've heard that the performance can be underwhelming.

didyoucheckthe 12y ago

> The first question I usually get ... is “Why not Haskell?”. > The answer is JavaScript. My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2]. Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why: It uses a completely declarative state machine to model a fully interactive and complete GUI! This is the dream React.js and Om didn't even know they were heading towards! And yes, it is as good as it sounds. [1]: http://elm-lang.org/ http://elm-lang.org/ [2]: http://elm-lang.org/learn/FAQ.elm http://elm-lang.org/learn/FAQ.elm EDIT: Also, Elm fixed Haskell's awful syntax record name collision problem, and awesomely too!

jarcane 12y ago
Purescript[1] is also gaining some traction and even has a pretty nice looking book out. [2] It has some changes however; most notably it's strictly evaluated rather than lazy, and there are differences in how it handles type variables. [3] Personally though, I've grown more fond of F# than Haskell; I only wish the documentation for Websharper and Funscript was more solid. [1] http://www.purescript.org/ http://www.purescript.org/ [2] https://leanpub.com/purescript/read https://leanpub.com/purescript/read [3] https://github.com/purescript/purescript/wiki/Differences-from-Haskell https://github.com/purescript/purescript/wiki/Differences-fr...
- didyoucheckthe 12y ago
  Elm is actually 3 things rolled into one: 1. an language very similar to Haskell 2. a set of runtime libraries 3. a technique for modeling a GUI as a declarative state machine PureScript only competes with #1 and #2 here. Where Elm really shines is #3, which #2 helps with a lot. Technically #3 could be done in any language. But it really helps to model it in such an expressive language with immutable data and no side-effects (except via Signals).
  - purescript 12y ago
    I won't argue that Elm does anything other than an exemplary job at #3, but it is worth noting that there are some interesting efforts to build similar functionality in PureScript libraries: https://github.com/paf31/purescript-thermite https://github.com/paf31/purescript-thermite https://github.com/kRITZCREEK/reactive-psc https://github.com/kRITZCREEK/reactive-psc https://github.com/bodil/purescript-signal https://github.com/bodil/purescript-signal https://github.com/michaelficarra/purescript-demo-mario https://github.com/michaelficarra/purescript-demo-mario https://github.com/mechairoi/purescript-frp-rabbit https://github.com/mechairoi/purescript-frp-rabbit To me, this is the benefit of PureScript - yes, you have to do a little more work, because you don't get these things for free from the compiler and tools, but you gain complete control over your application structure. You're not forced to work in some ambient Signal category.

dbpatterson 12y ago

I think the author doesn't give enough credit to things that OCaml has that Haskell doesn't have: a powerful module system (ie, functors), polymorphic variants/subtyping, etc.

vitriol83 12y ago
IMO key advantage OCaml is easier to learn and much more pragmatic.
amirmc 12y ago
Toolchains also matter and OPAM (the package manager) has gone from strength to strength since this post. It's the basis for the OCaml Platform which combines a number of useful tools and libs into a coherent workflow (making development much more productive).
- more_original 12y ago
  Also merlin is worth mentioning explicitly. It finds and highlights errors during editing (in emacs, vim and co), does autocompletion, shows types and since recently can also write pattern matches automatically. http://the-lambda-church.github.io/merlin/destruct.ogv http://the-lambda-church.github.io/merlin/destruct.ogv
- ufo 12y ago
  OPAM still doesn't run natively on Windows though :(
jordwalke 12y ago
There's a bunch of other nice features of OCaml such as named arguments, fast compile times, strictness, c-types, and reasonable records. To achieve (some of the feature in) Elm style "structural subtyping" records in OCaml you use the more verbose "object" keyword which is just a record with row polymorphism. Most choose to stick with standard records because they compile to more efficient code. I think the ML module system (in OCaml and other languages) is very powerful because it allows you to abstract and operate not only on types but also on values simultaneously. F#, Haskell, and most others lack this but it would be great if they were to officially adopt it. OCaml is also very easy to learn and I seriously recommend Real World OCaml - it's free online and excellent.

lmm 12y ago

If it's about what's well-supported for compiling to Javascript, does scala.js becoming non-experimental change the landscape?

spyder81 12y ago
I knew about scala.js when writing the post (although it was still experimental at the time) but I didn't mention it because I don't like Scala. It looked promising when I first saw it, but then I had to write some production code in it. My opinion now is that if you're forced to use the JVM then Scala is one of the best options. But that's a low bar, given the choice I would pick something else.

saosebastiao 12y ago

Is there anywhere that I can track the status of the multicore runtime and modular implicits?

lpw25 12y ago
Multicore: https://github.com/stedolan/ocaml https://github.com/stedolan/ocaml Modular implicits: https://github.com/ocamllabs/ocaml-modular-implicits https://github.com/ocamllabs/ocaml-modular-implicits

wyager 12y ago

I honestly don't get how people can claim that Haskell is unusually hard to learn. I started learning Haskell with zero functional programming experience, and after getting over that initial pure+functional learning curve (which took two or three weeks of casual learning), it was smooth sailing. Haskell is actually a very simple language compared to popular languages like python or C++; you just have to do a bit of thinking to get out of the procedural/imperative/impure mindset. I especially don't understand how people get tripped up by laziness. 99.9% of strict code will work with no changes in a lazy environment. The rest usually just needs a slight tweak to avoid memory leaks. To anyone considering undertaking the modest effort required to learn Haskell, I completely recommend it. My code in every language has tangibly improved.

alayne 12y ago
From your website, you appear to be a college student. Perhaps your expectations and uses are different than commercial developers.
- lomnakkus 12y ago
  That's a pretty sad indictment of commercial developers. Or perhaps just the pressures put on said developers :/.
- paulrpotts 12y ago
  College students often feel at the time that they are completely overloaded with work and barely getting through (in some cases that is true, especially students who are working or non-traditional). But looking back, it is pretty clear that although I worked hard in school, I could have worked so much harder, and also that never in my life again will I be in an environment that was so _supportive_ of just learning. Not just in classes; in fact, my college experience was _especially_ supportive things learned outside of classes. And also, at 20, 21, 22 -- there are very good reasons those are the traditional college years. Our brains are just able to _soak_ up ideas so quickly at that age. They aren't wise, they can't necessarily integrate everything, but we are _sharp_ then! (Usually...)
- wyager 12y ago

andrewstuart 12y ago

I wanted to like OCaml, mainly for working with Unikernels. When I looked at the syntax it just looked very arcane, which was discouraging.

ignoramous 12y ago
Might come handy in case you want help yourself get over the seemingly cryptic syntax: http://rigaux.org/language-study/syntax-across-languages/ http://rigaux.org/language-study/syntax-across-languages/
ufo 12y ago
The syntax is certainly very wonky but you get used to it. Installing merlin (vim / emacs plugin) helps a lot too.

ignoramous 12y ago

Unless start-ups or top companies [0] start adopting OCaml, I doubt its rise would be meteoric. Take go-lang, for example. It performs no better than Java on JVM, but is gaining tremendous traction because Google is putting all its weight behind it. I believe C# gets far less credit than it deserves... and MSFT knows exactly what its doing by open sourcing it. I digress. I feel, one is better off investing time in Clojure or Haskell (if functional programming is what one is after), both of which are gaining a lot more traction in the industry and the academia compared to OCaml. I can speak from what I observed here at Amazon... which did try and make use of Erlang (due to its excellent concurrency model) at one point, but gave up (Simple DB is powered by Erlang, but its successor DynamoDB is JVM based). At least Erlang had its chance... OCaml community within Amazon is non-existent. Whereas Clojure (plenty of traction within due to STM on JVM, I guess) has plenty going for it, as does Nodejs and go-lang. All of these plaforms are popular due to the strong community presence both within the company and at other tech power houses. I'd also like to point out that the current crop of volunteers behind ocaml.org [1] are doing a really great job of evangelising OCaml. [0] https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html and http://clojure.org/Companies http://clojure.org/Companies and https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry [1] https://ocaml.org/about.html https://ocaml.org/about.html

amirmc 12y ago
You mean top companies like, say, Facebook? Or startups like, Esper? I'm not really sure what your comment is trying to say because it comes across as circular ('they're popular because lots of people use them'). Edit: seems you've added the links I was about to point to.
aphexairlines 12y ago
It doesn't take much to boot up a community in a large company like Amazon or Facebook as long as it brings value. See the FXL, Haxl, and React work at Facebook. (I removed my comments on Amazon as it's hard to gauge what's ok to mention in public)
danieldk 12y ago
Take go-lang, for example. It performs no better than Java on JVM, but is gaining tremendous traction because Google is putting all its weight behind it. That's definitely a large factor. But let's not forget that Go already took off when it was barely beyond being a 20% project. Go also fills some niches, three particular ones I can think of are: - People who like Java, but favor the UNIX approach of small programs over the JVM. - People who like Python or Ruby, but need more performance. - People who like C, but want garbage collection and some extra safety in some of their projects. Add to that that Go is trivial to learn for anyone with a Java, C, or C++ background. Of course, it takes some time to learn all the idioms, but someone who knows languages with C-like syntax can start writing Go programs productively within a day.

yodsanklai 12y ago

One thing I don't like about OCaml is that I always find myself writing the same things, like "to_string" functions for my variant types (although there must be some ways to alleviate this burden). Also, when your programs use abstract data types you lose the benefits of pattern matching. In that case, I'm happier with languages like Go or Ada with a friendlier syntax.

mercurial 12y ago
PPX lets you generate show functions automatically. As for abstract types you can use "private" if you need to pattern match outside the module but wont to ensure that the structure can only be created by your module.
tel 12y ago
If you have an ADT but want pattern matching, try Scott Encoding. For instance, here we have Option module Option = struct let scott (some : 'a -> 'r) (none : 'r) (opt : 'a option) = match opt with | Some a -> some a | None -> none end For Option, since it's non-recursive, the Scott Encoding and the recursor/inductor/Church Encoding are identical. Here's a linked list, though module LL : sig type 'a t val fold : ('a -> 'r -> 'r) -> 'r -> ('a t -> 'r) val scott : ('a -> 'a t -> 'r) -> 'r -> ('a t -> 'r) end = struct type 'a t = Cons of 'a * 'a t | Nil let rec fold cons nil = function | Cons (h, t) -> cons h (fold cons nil t) | Nil -> nil let scott cons nil = function | Cons (h, t) -> cons h t | Nil -> nil end Anyway, the pattern should be more clear now. These provide effectively "functionalized" pattern matching which you can apply whenever you need. In particular, you can think of these as expressing a (potentially partial) "view" of the abstract type. For instance, my linked list might have not been a linked list exactly but instead some kind of tree, but `scott` and `fold` let me expose a "view" of that tree as though it were a linked list.
- ufo 12y ago
  If you look at this from an "expression problem" point of view, this version with the records-of-functions is very similar to OO programming. But without inheritance, classes and so on.

jonsterling 12y ago

Nice post! There are a lot of good reasons to use OCaml over Haskell which are more compelling than “JavaScript”, though. A few of them are: 1. modularity (and now that they have added generative functors à la SML, you can have true abstraction) 2. benign effects: in Haskell "proper", you do not have effects; rather you have "codes" for effects, which get interpreted into effects by the RTS; this rules out the possibility of, e.g., using effects to implement a semantically pure interface. On the other hand, OCaml has actual effects, which can be used in an open-ended way to implement all sorts of functional interfaces. 3. strictness: arguments abound about whether laziness or strictness is better; for me, it comes down to the fact that with some pain, you can embed laziness in a strict language with effects, but you cannot embed full-on ML-style strictness into a language like Haskell; moreover, strictness-by-default permits safe uses of benign effects. I'd call Haskell an expression-oriented programming language, since the types end up classifying expressions and algorithms (i.e. the particular "effects" you used get put into the type). Whereas I'd say (OCa)ML is a value-oriented language, since values (canonical forms) are considered separately from general expressions (canonical and non-canonical forms); moreover, implementation details don't end up in the types, so you can really consider them to be classifying values and functions (i.e. equivalence classes of algorithms, not algorithms themselves). This is largely orthogonal from strictness vs laziness, but as soon as you add partiality in, strictness becomes the only tractable way to have canonical-form-based meaning explanations for the judgements of the theory. P.S. My day job is writing Haskell. (In case the Pedagogical Brethren wish to come and "correct" me.)

jordwalke 12y ago
I generally prefer programming with immutability, but I certainly appreciate the ability to use "benign effects" in my programs. Besides the case for performance, I have applied a strange combination of benign effects, GADTs, and functors to generate a sort of "proof of type equality" between two values passed into a framework, each of which are not known to the framework because they're passed into the framework by two separate clients of the framework. At that point, I had the ability to reason about two values with arbitrary and potentially distinct types, as either being not the same (None), or the same Some(x, y) with x and y having the same type. I have no clue if there's a more elegant way to do this (edit: there probably is), but even I (as a n00b) was able to figure out how to do this by using benign effects. There's only a single mutation in this library - but it was such a critical one that made everything else possible. I'm curious about the reason for preferring generative functors over applicative functors. It seems like both could have valid use cases. Could you point me to a writeup that explains why you believe generative functors are superior?