At what point is the language going to get serious adoption? It's mature, unbloated, elegant, and fun to write. The only thing I really think needs improvement is its multicore stuff.
The problem is that pretty much the entire standard library isn't thread safe. It would take some serious work to get OCaml ready, unless you stick to message passing between distinct processes.
Slight off-topic: Judging from H1B stats [0], Jane Street pays quite below the market rate (for NYC finance sector). Also, they haven't sponsored any H1B's for the last 3-4 years. I wander if these stats are reliable... Or maybe, JS puts more emphasis into bonuses (on top of the base salary), in order to not to disclose salaries?
I've been a Haskell user for about a year now, and am pretty comfortable with the language. Ocaml has a lot of things that I like (the module system seems great; strict evaluation is a win; mutability/loops/etc without having to jump through hoops). But every time I look at the actual code, I'm really turned off by a few things:
* lets everywhere, even at top-level. Haskell doesn't do this, which is a lot nicer.
* let rec. Wut?
* Apparently to produce code to run at top-level main loop you just assign it to a let _ = ..., which looks really hacky.
* Double semicolons.
* Type variables annotated with 'a. In Haskell, lowercase type names are variables, uppercase are constants (or type classes, but those aren't mixed).
* Mix of semicolons and end.
Haskell seems syntactically more elegant, has type classes which are (at least on the surface) more straightforward than modules, though I don't know which is more useful at the end of the day. Haskell's do syntax is very nice.
That said, in many ways OCaml seems much more like "my kind of language". But there are a number of turnoffs.
Hint: double semicolons are not necessary in files (just in the REPL). Also, personally I dislike Haskell's lower/uppercase conventions, and find OCaml's syntax marginally better in this respect (although I think best would be pre-declared parameters, like in C/Java/Scala/Julia).
I'd like to like ocaml but its not clear to me why I would choose it above anything else to write an application. I have the sense vaguely it might be a good thing. A little reading and examination of some example source hasn't thrown much light.
What's it good for? Why should I use it? Why is it a better choice than language X or Y?
"Among this worthy set of languages, OCaml stands apart because it manages to provide a great deal of power while remaining highly pragmatic. The compiler has a straightforward compilation strategy that produces performant code without requiring heavy optimization and without the complexities of dynamic just-in-time (JIT) compilation. This, along with OCaml's strict evaluation model, makes runtime behavior easy to predict. The garbage collector is incremental, letting you avoid large garbage collection (GC)-related pauses, and precise, meaning it will collect all unreferenced data (unlike many reference-counting collectors), and the runtime is simple and highly portable."
It's really fast, has minimal boiler plate and supports functional programming without any of the "orthodoxy" of Haskell. That is, you can write a recursive function but also write a for loop.
Imagine something that can compete with C and C++, but doesn't require all of the low-level reinvention and memory management. It's like a high-level language for smart people that doesn't feel entirely impractical. It has some things that people bitch about (like having to use +. to add two floats and + to add two ints), which don't really bother me that much.
If it were more popular and had better libraries/platform support (unless that's changed drastically in the past year or so), it would be a serious contender for general development. Being completely honest, I think Jane Street is probably the biggest organization pulling OCaml, and from a navel-gazing standpoint you can either view that as good or bad.
Use it because you learned it and thought it didn't suck, I guess?
We use it in our backend to tie everything together. It serves an http/json api to our client apps (Web/JavaScript, Android/Java; iOS/Objective-C coming soon). We're handling the same data types in JavaScript, Java and OCaml.
What is clear is that we spend a lot of time fixing type errors in JavaScript due to the lack of basic type checking. Java does not have this problem and for Android programming it is a breeze since really the mobile app is just a GUI which doesn't have to do anything clever with the data.
Now the backend is in charge of serving correct data to the client apps. I could explain that OCaml is fast and lets us implement any CPU-intensive algorithm without having to switch to C, but the truth is most of our code is not much about algorithms but very much about data modeling and data management. Anything we store needs to be stored correctly if we don't want to accumulate broken data resulting in bugs that are costly to fix. Untyped languages such as JavaScript let you store anything without checking their conformance to a type definition, this is awful. Java for example would be perfectly acceptable if it wasn't so verbose. We want to write JSON-like records and arrays like in JSON or JavaScript. OCaml provides this, Java doesn't.
Now, we don't want half of our code to consist in annotating each variable with a type. The compiler should infer that 123 is an int. How hard is that? You tell me. JavaScript doesn't check anything. Java or C++ force you to declare that 123 is an int. How clever is that? I don't know. OCaml, Haskell just figure out that 123 is an int. That's called type inference. That makes code readable like JavaScript or Python, with the safety of Java and the performance of C++.
apart from the more objective criteria, it's simply a very pleasant language to use. i usually evaluate new application programming languages by what they offer me that ocaml does not.
Algebraic data types and pattern matching are bliss. It's almost a cliche, but you don't know what you're missing without them and once you know them you'll wish every other language had them.
A couple of people have asked why you might choose OCaml over other languages. I've not done as much OCaml work as others on this thread (I work primarily on ReactJS (Facebook/Instagram's) functional UI framework), but I can offer a different perspective as someone who is outside of the OCaml community, but asking the same questions. Here are some of my personal findings.
I'll narrow any comparison down to the ML family of languages. Java/C++/ and many other languages are just now beginning their slow, but inevitable evolution into becoming a dialect of ML (which IMHO is a sort of admission of the ML/functional family superiority).
Once you embrace the power of pattern matching, it's hard to use anything but an ML family language (StandardML/Haskell/F#/OCaml). I would program in any one of those languages over Java/C++/Objective-C/JS.
Practical reasons why you might choose OCaml:
- OCaml's records aren't as elegant as SML's but OCaml has labeled arguments with optional default values which can satisfy many of the reasons why you'd use records as arguments in the first place (and may be even more powerful in some cases).
- Two modes of compilation (fast native executable XOR fast compilation). Who doesn't like options.
- All the benchmarks I can find show that OCaml is very fast (around as fast as C++).
- Excellent JS target and and apparent commitment to maintaining it (as someone building a JS library, this is very important to me) (and as someone who wants to build apps and be able to instantly share them with everyone in the world.)
- Someone has built an autocomplete plugin for Vim/Emacs (merlin). ("VimBox" (https://github.com/jordwalke/VimBox/) has configured it to complete as you type - like in Visual Studio etc.)
- On very rare occasion, you'll run into a problem that is inherently better suited to OO (dynamic dispatch). I can usually find a way to solve it with functors/modules, but it's nice to know that you have OO in your back pocket in case you ever need it. It's also nice to know you probably won't have to.
- Finally, a common package manager (OPAM) is becoming standard. I look forward to seeing how OPAM helps make the new dev experience and the code-sharing/development experience seamless.
- The module system is very powerful (SML's). Haskell does not have this, and strangely F# dropped it. (I hear, Haskell's type classes fulfill similar roles (but with more sugar)).
- There's usually ocamlyacc grammars for most languages. Most examples of languages, type systems, parsers are already in OCaml (or ML). It's a nice (but small) perk.
- Predictability. OCaml is not lazy by default. Lazy computations could become problematic for low-latency applications (such as UIs) if a lot of computation becomes is deferred until the moment a final dependency has been satisfied, but by that time you may be close to your screen refresh deadline and it may lead to a dropped frame. It would have been better to have been computing while waiting for a final dependency. I'm not sure if Haskell (a lazy language) has had this problem. You can opt into laziness in OCaml if you would like to.
- Mutability. I feel strange saying this, as such a huge proponent of immutability, but sometimes you just need to hack something in place, mutate some state and come back to clean it up later. (You can still use monads in OCaml).
- Tagged Variants (no need to predeclare variants, just pattern match on them and OCaml ensures that only properly matched values ever make their way into that expression).
- Industry use is growing. OCaml is used here at Facebook and many other places as mentioned.
- There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...).
OCaml Cons:
- There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...).
Quite a good summary. I use OCaml at Red Hat for a lot of virtualization tools. I had reason to use Python for some code quite recently, and it reminded me of how much better ML-derived languages are.
The things I found awful about Python compared to OCaml:
- Lots of bugs which are never noticed, even at run time, eg. along error paths. 'pylint' helps here, but it doesn't catch all the bugs, and IMHO if you need a lint tool to fix your language you're doing it wrong in the first place.
- Really hard to refactor code. In OCaml the compiler helps refactoring -- you just break something and hit 'make -k' until you've fixed all the places that need fixing. In Python you have to visually grep all the code, which doesn't scale and is bug-prone.
- I miss nested variable declarations.
- Poor support for data types. Python in theory has lots, but in practice everyone's using dictionaries and objects, which are unsafe and introduce bugs by design.
- Slow. Really slow.
There were a few good aspects of Python, but I ended up with a lot of buggy code, and I know there are many more bugs in there which I haven't yet found, which just wouldn't be the case with a statically typed, type-inferenced ML-derived language.
> Java/C++/ and many other languages are just now beginning their slow, but inevitable evolution into becoming a dialect of ML (which IMHO is a sort of admission of the ML/functional family superiority).
You can't be serious. The fact that they are borrowing some features from functional languages is in no way an indication that they're going to turn into an ML dialect. They will remain imperative languages, with all that entails (mutability, inheritance, etc) for the foreseeable future. Hell, even Scala isn't an "ML dialect".
I'll just add in the Cons: no ad-hoc polymorphism. This is what causes ocaml to use different operators for each type (+, +., +|, etc), which is what most beginners don't like about the language.
Delimited overloading[1] is a nice progress on this front that I wished I knew when I started using ocaml. Though I admit you can later appreciate the benefit of not having ad-hoc polymorphism in several situations.
[+] [-] amirmc|11 years ago|reply
http://www.reddit.com/r/programming/comments/25vr5t/ocaml_40...
[+] [-] cheepin|11 years ago|reply
[+] [-] Totient|11 years ago|reply
[+] [-] zerr|11 years ago|reply
[0]: http://www.myvisajobs.com/Visa-Sponsor/Jane-Street-Capital/2...
[+] [-] hackerboos|11 years ago|reply
[+] [-] thinkpad20|11 years ago|reply
* lets everywhere, even at top-level. Haskell doesn't do this, which is a lot nicer.
* let rec. Wut?
* Apparently to produce code to run at top-level main loop you just assign it to a let _ = ..., which looks really hacky.
* Double semicolons.
* Type variables annotated with 'a. In Haskell, lowercase type names are variables, uppercase are constants (or type classes, but those aren't mixed).
* Mix of semicolons and end.
Haskell seems syntactically more elegant, has type classes which are (at least on the surface) more straightforward than modules, though I don't know which is more useful at the end of the day. Haskell's do syntax is very nice.
That said, in many ways OCaml seems much more like "my kind of language". But there are a number of turnoffs.
[+] [-] tomp|11 years ago|reply
[+] [-] andrewstuart|11 years ago|reply
What's it good for? Why should I use it? Why is it a better choice than language X or Y?
[+] [-] avsm|11 years ago|reply
https://realworldocaml.org/v1/en/html/prologue.html#why-ocam...
"Among this worthy set of languages, OCaml stands apart because it manages to provide a great deal of power while remaining highly pragmatic. The compiler has a straightforward compilation strategy that produces performant code without requiring heavy optimization and without the complexities of dynamic just-in-time (JIT) compilation. This, along with OCaml's strict evaluation model, makes runtime behavior easy to predict. The garbage collector is incremental, letting you avoid large garbage collection (GC)-related pauses, and precise, meaning it will collect all unreferenced data (unlike many reference-counting collectors), and the runtime is simple and highly portable."
[+] [-] jgg|11 years ago|reply
Imagine something that can compete with C and C++, but doesn't require all of the low-level reinvention and memory management. It's like a high-level language for smart people that doesn't feel entirely impractical. It has some things that people bitch about (like having to use +. to add two floats and + to add two ints), which don't really bother me that much.
If it were more popular and had better libraries/platform support (unless that's changed drastically in the past year or so), it would be a serious contender for general development. Being completely honest, I think Jane Street is probably the biggest organization pulling OCaml, and from a navel-gazing standpoint you can either view that as good or bad.
Use it because you learned it and thought it didn't suck, I guess?
EDIT: changed some phrasing
[+] [-] mjambon|11 years ago|reply
What is clear is that we spend a lot of time fixing type errors in JavaScript due to the lack of basic type checking. Java does not have this problem and for Android programming it is a breeze since really the mobile app is just a GUI which doesn't have to do anything clever with the data.
Now the backend is in charge of serving correct data to the client apps. I could explain that OCaml is fast and lets us implement any CPU-intensive algorithm without having to switch to C, but the truth is most of our code is not much about algorithms but very much about data modeling and data management. Anything we store needs to be stored correctly if we don't want to accumulate broken data resulting in bugs that are costly to fix. Untyped languages such as JavaScript let you store anything without checking their conformance to a type definition, this is awful. Java for example would be perfectly acceptable if it wasn't so verbose. We want to write JSON-like records and arrays like in JSON or JavaScript. OCaml provides this, Java doesn't.
Now, we don't want half of our code to consist in annotating each variable with a type. The compiler should infer that 123 is an int. How hard is that? You tell me. JavaScript doesn't check anything. Java or C++ force you to declare that 123 is an int. How clever is that? I don't know. OCaml, Haskell just figure out that 123 is an int. That's called type inference. That makes code readable like JavaScript or Python, with the safety of Java and the performance of C++.
[+] [-] emmelaich|11 years ago|reply
http://roscidus.com/blog/blog/archives/
It has been previously discussed on HN and Reddit.
[+] [-] pjmlp|11 years ago|reply
From what I can understand in the SkillsThatMatter sessions, the finance and insurance sector in some European countries are big users.
The applications aren't full ML stacks, just the algorithms are done with them, with the UIs using a more traditional one.
Might not seem much, but it already a foot in the door.
[+] [-] zem|11 years ago|reply
[+] [-] andrewflnr|11 years ago|reply
[+] [-] zerr|11 years ago|reply
[+] [-] jordwalke|11 years ago|reply
I'll narrow any comparison down to the ML family of languages. Java/C++/ and many other languages are just now beginning their slow, but inevitable evolution into becoming a dialect of ML (which IMHO is a sort of admission of the ML/functional family superiority).
Once you embrace the power of pattern matching, it's hard to use anything but an ML family language (StandardML/Haskell/F#/OCaml). I would program in any one of those languages over Java/C++/Objective-C/JS.
Practical reasons why you might choose OCaml:
- OCaml's records aren't as elegant as SML's but OCaml has labeled arguments with optional default values which can satisfy many of the reasons why you'd use records as arguments in the first place (and may be even more powerful in some cases).
- Two modes of compilation (fast native executable XOR fast compilation). Who doesn't like options.
- All the benchmarks I can find show that OCaml is very fast (around as fast as C++).
- Excellent JS target and and apparent commitment to maintaining it (as someone building a JS library, this is very important to me) (and as someone who wants to build apps and be able to instantly share them with everyone in the world.)
- Someone has built an autocomplete plugin for Vim/Emacs (merlin). ("VimBox" (https://github.com/jordwalke/VimBox/) has configured it to complete as you type - like in Visual Studio etc.)
- On very rare occasion, you'll run into a problem that is inherently better suited to OO (dynamic dispatch). I can usually find a way to solve it with functors/modules, but it's nice to know that you have OO in your back pocket in case you ever need it. It's also nice to know you probably won't have to.
- Finally, a common package manager (OPAM) is becoming standard. I look forward to seeing how OPAM helps make the new dev experience and the code-sharing/development experience seamless.
- The module system is very powerful (SML's). Haskell does not have this, and strangely F# dropped it. (I hear, Haskell's type classes fulfill similar roles (but with more sugar)).
- There's usually ocamlyacc grammars for most languages. Most examples of languages, type systems, parsers are already in OCaml (or ML). It's a nice (but small) perk.
- Predictability. OCaml is not lazy by default. Lazy computations could become problematic for low-latency applications (such as UIs) if a lot of computation becomes is deferred until the moment a final dependency has been satisfied, but by that time you may be close to your screen refresh deadline and it may lead to a dropped frame. It would have been better to have been computing while waiting for a final dependency. I'm not sure if Haskell (a lazy language) has had this problem. You can opt into laziness in OCaml if you would like to.
- Mutability. I feel strange saying this, as such a huge proponent of immutability, but sometimes you just need to hack something in place, mutate some state and come back to clean it up later. (You can still use monads in OCaml).
- Tagged Variants (no need to predeclare variants, just pattern match on them and OCaml ensures that only properly matched values ever make their way into that expression).
- Industry use is growing. OCaml is used here at Facebook and many other places as mentioned.
- There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...).
OCaml Cons: - There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...).
(Edited for formatting)
[+] [-] rwmj|11 years ago|reply
The things I found awful about Python compared to OCaml:
- Lots of bugs which are never noticed, even at run time, eg. along error paths. 'pylint' helps here, but it doesn't catch all the bugs, and IMHO if you need a lint tool to fix your language you're doing it wrong in the first place.
- Really hard to refactor code. In OCaml the compiler helps refactoring -- you just break something and hit 'make -k' until you've fixed all the places that need fixing. In Python you have to visually grep all the code, which doesn't scale and is bug-prone.
- I miss nested variable declarations.
- Poor support for data types. Python in theory has lots, but in practice everyone's using dictionaries and objects, which are unsafe and introduce bugs by design.
- Slow. Really slow.
There were a few good aspects of Python, but I ended up with a lot of buggy code, and I know there are many more bugs in there which I haven't yet found, which just wouldn't be the case with a statically typed, type-inferenced ML-derived language.
[+] [-] mercurial|11 years ago|reply
You can't be serious. The fact that they are borrowing some features from functional languages is in no way an indication that they're going to turn into an ML dialect. They will remain imperative languages, with all that entails (mutability, inheritance, etc) for the foreseeable future. Hell, even Scala isn't an "ML dialect".
[+] [-] tenfingers|11 years ago|reply
Delimited overloading[1] is a nice progress on this front that I wished I knew when I started using ocaml. Though I admit you can later appreciate the benefit of not having ad-hoc polymorphism in several situations.
[1] http://pa-do.forge.ocamlcore.org/