I can't find the time to learn a language for fun. I need to find a way to incorporate it into my daily routine. There just aren't enough hours in the day to play.
Anyway, I've got a couple side projects, one of which is website in Go. How's OCaml for web development?
> I also saw oCaml for iOS but it didn't seem to be up to date
There is work underway to improve cross-compilation support [1][2]. Once that lands in a release, there shouldn't be any reason to maintain forks of the compiler for iOS, Android, etc.
I recently looked at OCaml and quite liked it, but I was wondering if there is any SLIME/Geiser (these are the lisp and scheme IDEs for emacs) equivalent for it?
I know there is tuareg-mode, but as far as I can tell it is not nearly as convenient as SLIME.
Any ideas?
I struggled to get an interactive environment for OCaml that was similar to SLIME/Cider. I recorded a video showing what I had pieced together to get a kind of repl-like env [0] and posted it to twitter, hoping people would tell me how silly that was and there was already an existing system. Turns out it's not a very high priority, the OCaml community seems to work in a different way, but I've never been able to work in person with someone to see how they do it.
That say, the type helps from Tuareg/merlin and a few other things really started to become very handy, and I miss them in ClojureScript now.
I haven't got to the point of doing any benchmarks, but according to the author, it is slower than plain OCaml. I've only written a couple of toy programs (a Swing GUI in OCaml!)
I am, however, very impressed by the implementation. The author wrote an OCaml library that emits Java bytecode, and then modified the OCaml compiler to emit bytecode. He then ran the compiler on itself, and got an OCaml implementation on the JVM written completely in OCaml (plus some runtime classes in Java).
The author, who used to work at INRIA told me he's now working on a startup using OCaml-Java.
I also think it is interesting, once I put 2+2 together, you pointed out the OCaml Java runtime from Xavier is not open source ... yet. It will be, but it is binary only at this point.[1]
I want to make a joke about the F/L/OSS spirit of this guy, but the whole QPL thing has been repeated a la Shen in circles where I read and seems to have left a sour taste in the mouth of some, like this guy.[2]
Still, I am in place to judge OCaml devs or the community around them, as they seem increasingly awesome. I am a novice, but a CS undergrad in my hood specifically said check out OCaml when we discussed functional langs because of the Jane Street videos. And before that, my only expsoure to what OCaml was, let alone is or even coding it, was the eMule software package.
OCaml has no corporate support and a limited standard library. It does not benefit from the larger MS ecosystem. It does not have multicore support (not until the end of the year if all goes well). On the other hand, it is really fast, it has some great features (functors, mostly) not found in F#, a really good package management story, and some great libraries (eg, lwt). It can also boast of having one of the most developed unikernels out there (mirage) and can generate sane Javascript via js_of_ocaml.
That said, it's definitely an even harder sell than F# in the corporate space.
I was as recently as today quite curious to find that there was an implementation of Ocaml 2.00 for RISC OS, but alas, it seems to have been lost to the internet.
My only skeptikism with OCaml is that OPAM (latest packages) does not work on windows and does not cooperate with msys2 (lates libraries) or another port solution like winbuilds.
I have to install msys2 and keep compiling by hand.
Even if a source solution that kept updating even if I had to compile regularly, would be preferable.
The wg-windows@lists.ocaml.org working group has just started this week to sort this out properly. Now that OPAM itself is fairly mature on Linux/BSD/MacOSX, we can tackle this properly.
I'm studying this language right now at a french school, with INRIA researcher.
And, well... I'm not really satisfied with it. OCaml produces a small amount of code, but is really slow and hard to understand. Sometimes, it looks like obfuscated code!
Documentation and libraries are not polished, and I would recommend Haskell instead of OCaml. Good for research and some algorithms, bad for applications.
And... God... "This page was last updated on 17 June 2006."
Same feeling, and why are they ignoring EVERY programming convention ? One more thing I really hate is there are many way to the same basic thing, ie. declaring a new function or doing a pattern matching.
Finally, standard libraries are not well named (List.split will not do what you think) nor easy to use (List.last ? Nope !).
1. "unfamiliar" syntax. Well... It is unfamiliar if your first exposure to programming stopped at Java. Guess what .. pattern matching is quite an old convention in programming languages old (Prolog, Erlang, ML, Haskell)... and new (Rust, Swift)..
2. Standard libraries are a crap shoot... cruft accumulates in standard libraries just like any piece of software but harder to clean up owing to demands of backward compatibility. Just go and look at Python standard library. Even on a superficial level, the stdlib is a mix of CamelCase and under_score .. which can be irritating.
This is very consistently my biggest problem with OCaml: it just doesn't follow conventions set in other ecosystems. I predict this is the sole reason it could never be "the next Java."
It's worth noting, however, that I've had very, very few problems with the semantic properties of the language. I think the slog is worth it for that reason.
> This is very consistently my biggest problem with OCaml: it just doesn't follow conventions set in other ecosystems.
Well, the reason is that Caml predates those ecosystems; the original Caml was released nearly a decade before Java [1], and ML itself dates back to the 1970s.
There is zero need for a general purpose List.last. It encourages programming using List.last, when in most cases that leads to crap performance (as it would run in O(n) time).
It's a one line function to write, but it certainly has no business being in the standard library.
Looks like OCaml was not your first language. I suspect you are coming from a imperative language background.
OCaml is slow? and your recommendation is to use Haskell instead... That doesn't compute well if we were to assume that you are writing some compute-intensive tasks for which (unoptimized non-C language can be "slower".
It more likely the case that students hate whatever languages the university teaches in place of language-de-jour. (Just read the reviews of SICP on Amazon).
And yes there are pages on the internet that are older than 2006, so what? No one goes "Pffft.. this is 300 years old.." when they come across Newton's Principa.
> And yes there are pages on the internet that are older than 2006, so what? No one goes "Pffft.. this is 300 years old.." when they come across Newton's Principa.
The difference is that programming languages evolve all the time. Having such an old page still up and promoted to the front page of Hacker News tells everyone that OCaml hasn't evolved since 2006.
Well, I pretty love javascript, is it an imperative language? ;)
Please don't be so sharp, I really don't understand why this link is in HN, and I'm just exposing my point of view, after practising OCaml a lot. So what, I'm a student so my opinion is worthless?
Ah yes, the "functional" and "object oriented" Javascript, how I love thee.
When you are starting out, convenience and familiarity (which are visceral) can trump abstract notions like "pure", "correct", "reason-able".
I'm not saying your opinion is worthless, just that your judgement could be coloured by inexperience.
My sincere recommendation is to use "Real World OCaml" - https://realworldocaml.org/ as a reference to learn OCaml instead of old and busted tutorials littering the internet. Trust me, I have been trying to learn OCaml "on the side" for a few years and RWO is the first book that I have absolute love (even accounting for a wide variety of PL books I read) for being
practical, current and explaining stuff.
> OCaml produces a small amount of code, but is really slow and hard to understand.
Do you mean that OCaml produces small binaries, or that the language itself is compact? As for being slow, that's the first time I hear this charge being leveled. Single-thread performance is usually really good.
OCaml is a hard sell for me. I want to really like it but everytime I start to play with it, I drift back to F#, .net core, service stack, and all the other open source projects are really hard to compete with. The Syntax is similar to OCaml (really really close IMO) and other then it's ties to Microsoft it's seems to be all upside with F#. Is there a compelling lib or advantage of OCaml over f#?
OCaml has cool stuff like MirageOS, as one compelling lib (still a research project). It's a library that constructs unikernels. You write your application, build it, and out comes a VM that you can run.
I feel that many of the advantages of switching to OCaml are minimised when you are already using an ML!
Soon, there should be a compelling performance case for using OCaml. There are rumours that in the next release, there'll be an MLton type whole program optimisation setup, which should reduce the cost of abstraction to zero.
MirageOS is more than just a research project. It's deployed in the wild by folks who weren't active researchers. I'd certainly call it an open-source project in its own right.
Functors tend to be the big thing that's missing, right? F# just had to drop the feature because of compatibility with .Net packages, as I understand, but it severely cripples the module system.
MLs are such that the value-level stuff and the module-level stuff are more or less independent. So you can go a long way just liking the value-level stuff without really caring about the status of the module-level stuff. But it's also a pretty big motivator for the design of ML. F# is at least weirdly missing out here.
Sure. I'm not super familiar with F#, but I can state things which depend upon functors.
A good example is the Set.Make functor in the OCaml stdlib. Elements in a Set must be orderable for efficiency's sake, so to construct a Set you parameterize it over a module specifying not only the type but also its ordering.
module type Set = sig
module type OrderedType =
sig
type t
val compare : t -> t -> int
end
module type S =
sig
type elt
type t
val empty : t
(* ... *)
end
module Make :
functor (Ord : OrderedType) -> S
with type elt = Ord.t
end
Here the OrderedType module signature represents any type that also has an ordering. The S signature represents the result signature of calling the Make functor which is passed any OrderedType-substantiating module and uses it to construct the (Set.S with type elt = Ord.t) module.
"a redesign of ML in which modules are truly first-class values, and core and module layer are unified into one language. In this "1ML", functions, functors, and even type constructors are one and the same construct; likewise, no distinction is made between structures, records, or tuples."
> Is there a compelling lib or advantage of OCaml over F#?
Maybe not for folks whose primary platform in Windows? The .NET stack is the primary advantage there, no?
For those of us on Linux, IMO OCaml is the similar language with complete platform support. I know .NET core is now available, but some time will have to pass to know if Microsoft's support for .NET on Linux is a long term plan.
Very good point, most of the time when a post with a "sensationalistic" title makes it to the front page I immediately go to the comments section first.
OCaml/js_of_ocaml is presently my favourite AltJS stack.
OCaml syntax is super idiosyncratic and doesn't resemble anything, but, once you retrain your eyes, the underlying semantics are terrific.
js_of_ocaml imposes very minimal code overhead (6k-ish). Sourcemaps work great, and OCaml values are mapped into JS in a very straightforward way. You can read them in a JS debugger.
Ocsigen's lwt library is also the best "callback hell" solution I've found.
Could you recommend a project to look at? I'm familiar with OCaml but found Ocsigen as a whole impenetrable and would be interested in something more library than framework.
I don't, unfortunately, nor do I have any source code I can share. :(
The only advice I can offer is that the documentation actually is correct and pretty complete, but there's nevertheless something about its organization that makes it difficult to find what you're after.
Just reposting from below, but if you want lightweight, take a look at OWebl[0]. It is by far the smallest with no Core dependencies. The API is familiar if you write Python or Ruby. Documentation is continually published and it remains one of the most up to date alternatives to Ocsigen.
I started writing OCaml in college after hearing a talk by Jane Street [0], one of the most outspoken corporate supporters of OCaml.
After getting past the steep learning curve (about a weekend of pedal-to-the-metal debugging), I really got a feel for how beautiful OCaml semantics really are.
If you're looking for a solid and familiar OCaml stack, check out OWebl [0]. Always looking for helping hands or other support.
I've been developing in Haskell for a while and I recently had to learn OCaml to help TA for a course in my university.
I couldn't shake the feel that I was learning "Haskell Light". No pure/impure code (I/O, mutable references, exceptions), no monad syntax sugar, less syntax sugar for pattern matching, much smaller base library, plus surely other differences that my current level of expertise of Haskell is hiding.
Perhaps the simpler semantics make it easier to translate to js (I know haskell->js transpilers are very complex and I'm sure lazy evaluation has a lot to do with it), but in terms of language features, what am I missing in Haskell that makes you more productive/helps you write clearer code in OCaml?
I have never used either language in teaching. But maybe you have more experience as a TA: do you think OCaml is easier for students because of strict evaluation?
I haven't used Haskell in teaching either. It probably is. My professor does not like lazy evaluation at all (note how i did not insert it in my "haskell light" list of features), he said he played with it at the time this stuff was being researched but he never saw the benefit to offset the complication in semantics.
Our students were mostly having trouble with OCaml being a functional language than anything else. Some of them independently discovered mutable references and for loops and probably wondered why we hid from them such useful constructs! Pattern matching was also something that only the best students took serious advantage of.
OCaml's module system (and conventions associated with it) give a few advantages over Haskell.
- There are good conventions for naming and argument order (and named arguments!) so I don't have to memorize a bunch of different APIs. This is made possible by the module system. It could probably be solved in Haskell with better tooling.
- Modules allow you to, for lack of a better word, make your code more modular. Modules are essentially the same thing as what people use objects for in Java. They let you abstract implementation and program against a particular interface (i.e., a collection of types and values) easily in a way you can't really in Haskell.
OCaml modules have many similar characteristics to Haskell type class[0]. One of the primary differences being that the Haskell type classes handle dictionary passing automatically and support ad-hoc polymorphism. This can be achieved with ML modules but requires bit more labor.
Haskell type classes can make it a bit easier to encode (and infer) interfaces but assume a single implementation per data type. ML modules do not make this assumption and support a higher degree of modularity as a result.
Type classes are far less direct to encode. One also requires existential types to get the modularity properties of ML modules and they are a burden to deal with in Haskell.
A good example of something easy to do with ML modules and hard to do in Haskell is the Cohttp library which is a HTTP stack that works using the Lwt async backend, the Async async backend, and a Javascript Lwt backend. It is merely modularized over that interface and you can plug in whatever backend you like.
There are examples of doing similar things (Reflex is modeled this way, e.g.) but it's hairier in Haskell.
I don't know much about Ocaml's modules, however Haskell's type-classes require global uniqueness, which makes them anti-modular. Another problem with Haskell's type-classes is that they are magical, in the sense that they aren't either types or values, hence combining type-classes is always an exercise in frustration. If you want to think of type-classes as being much like OOP interfaces, you're making a mistake. Ironically in Scala, which is the lesser FP language, type-classes are modeled by OOP interfaces and instances are values, so you won't get the same problems.
Offtopic, but I hate the usage of the word "transpiler" and I hate how popular it got.
First of all the word "compiler" is perfectly adequate to convey the meaning of a "transpiler", meaning a computer program whose purpose is to translate code from one programming language into another. The usage of the word "transpiler" only happened because of languages like CoffeeScript, as a word was needed to express that CoffeeScript is just as broken as Javascript, but with syntax changed for no good reason.
But more importantly, many compilers that target Javascript, such as Scala.js, ClojureScript, GHCJS, Dart, are very much not like CoffeeScript, meaning that we are talking about languages with different type and module systems, with big standard libraries, that treat Javascript as bytecode and that need to be compressed with Google Closure to be viable. If you're missing the source-maps, the end result will be much harder to understand than Java or .NET bytecode. Therefore the usage of the word "transpiler" in this context is not only annoying, but incorrect as well.
Simple translation to the native code of your target environment is a feature in itself, especially when you have to debug. I suppose if you can write everything in Haskell and never have to interact directly with your runtime environment (be it native or a browser), you could treat Haskell itself as a bedrock abstraction (http://www.loper-os.org/?p=55). But in many real projects, you do have to work directly with the underlying environment. In that case, the bedrock abstraction is the machine itself (or, for a browser-based app, the JavaScript runtime). So closeness to the machine is a desirable feature in a language and its compiler, to be balanced with other things like developer productivity (so C with manual memory management is the wrong choice for a lot of applications). That's why, if OCaml is simpler to translate to native code or JS than Haskell, I think I'd prefer OCaml.
I did a couple small projects in OCaml and I loved the syntax and style of programming, but I think there would pretty much always be a better language choice for a serious project, regardless of what type of program you are writing. Also, the standard library leaves a lot to be desired and parts of the ecosystem (e.g. docs, and OPAM) are pretty rough. The standard library has a lot of gaps so you end up implementing a lot of low-level functions that will seem tedious and inefficient if you are coming from a more mainstream language with a rich ecosystem. Using the Jane Street's Core library helps a little bit but still leaves a lot of gaps. It's still a fun language though, but I don't think there would be a compelling reason to choose it nowadays for a new project.
> there would pretty much always be a better language choice for a serious project
The Mirage library OS is a pretty serious project. Facebook also uses OCaml for Flow and the Hack type checker. And of course, Jane Street Capital uses OCaml.
But I'm guessing what you mean is that OCaml is a very non-mainstream language, so it will be rejected for most corporate projects just because it's so foreign.
> But I'm guessing what you mean is that OCaml is a very non-mainstream language, so it will be rejected for most corporate projects just because it's so foreign.
Rather than snidely guessing what I meant, why not just read the rest of my comment or ask for clarification like an adult? Also, I'm not denying there are a few odd projects here and there that use it successfully -- as well as Jane Street, of course, who are almost synonymous with OCaml. But like I said, although it is a very nice (and educational) language, I just don't feel like it is "best of breed" in any particular area. Not sure what that has to do "corporate projects", etc.
73 comments
[ 3.1 ms ] story [ 123 ms ] threadAnyway, I've got a couple side projects, one of which is website in Go. How's OCaml for web development?
I also saw oCaml for iOS but it didn't seem to be up to date: http://psellos.com/ocaml/compile-to-iphone.html
Have a look at: https://github.com/mirage/ocaml-cohttp
You can of course also use cohttp directly but it's a little raw.
There is work underway to improve cross-compilation support [1][2]. Once that lands in a release, there shouldn't be any reason to maintain forks of the compiler for iOS, Android, etc.
[1] http://caml.inria.fr/mantis/view.php?id=6266
[2] https://github.com/ocaml/ocaml/pull/182
https://github.com/realworldocaml/book/wiki/Installation-Ins...
* OPAM for package management * Utop for a REPL * merlin for autocomplete and type queries * ocp-indent for aotomatic indentation
That say, the type helps from Tuareg/merlin and a few other things really started to become very handy, and I miss them in ClojureScript now.
[0] "Early OCaml workflow pains" - https://www.youtube.com/watch?v=rDFocxR6Mpw
And because of my guess, what do you think of the performance?
I haven't got to the point of doing any benchmarks, but according to the author, it is slower than plain OCaml. I've only written a couple of toy programs (a Swing GUI in OCaml!)
I am, however, very impressed by the implementation. The author wrote an OCaml library that emits Java bytecode, and then modified the OCaml compiler to emit bytecode. He then ran the compiler on itself, and got an OCaml implementation on the JVM written completely in OCaml (plus some runtime classes in Java).
The author, who used to work at INRIA told me he's now working on a startup using OCaml-Java.
I want to make a joke about the F/L/OSS spirit of this guy, but the whole QPL thing has been repeated a la Shen in circles where I read and seems to have left a sour taste in the mouth of some, like this guy.[2]
Still, I am in place to judge OCaml devs or the community around them, as they seem increasingly awesome. I am a novice, but a CS undergrad in my hood specifically said check out OCaml when we discussed functional langs because of the Jane Street videos. And before that, my only expsoure to what OCaml was, let alone is or even coding it, was the eMule software package.
Anyway, good to see you on the field. If you are paying attention to this, I certainly will! [1] https://github.com/xclerc/ocamljava/issues/22
[2] http://programmers.stackexchange.com/a/62704
That said, it's definitely an even harder sell than F# in the corporate space.
I have to install msys2 and keep compiling by hand.
Even if a source solution that kept updating even if I had to compile regularly, would be preferable.
This is my only hesitation.
Please do feel free to join the group and give your 2 cents about the direction that this should take: http://lists.ocaml.org/listinfo/wg-windows
And, well... I'm not really satisfied with it. OCaml produces a small amount of code, but is really slow and hard to understand. Sometimes, it looks like obfuscated code!
Documentation and libraries are not polished, and I would recommend Haskell instead of OCaml. Good for research and some algorithms, bad for applications.
And... God... "This page was last updated on 17 June 2006."
1. "unfamiliar" syntax. Well... It is unfamiliar if your first exposure to programming stopped at Java. Guess what .. pattern matching is quite an old convention in programming languages old (Prolog, Erlang, ML, Haskell)... and new (Rust, Swift)..
2. Standard libraries are a crap shoot... cruft accumulates in standard libraries just like any piece of software but harder to clean up owing to demands of backward compatibility. Just go and look at Python standard library. Even on a superficial level, the stdlib is a mix of CamelCase and under_score .. which can be irritating.
OCaml is not unique in this regard.
It's worth noting, however, that I've had very, very few problems with the semantic properties of the language. I think the slog is worth it for that reason.
Well, the reason is that Caml predates those ecosystems; the original Caml was released nearly a decade before Java [1], and ML itself dates back to the 1970s.
[1] http://caml.inria.fr/about/history.en.html
Talk of syntax is almost always history and religion, not science.
It's a one line function to write, but it certainly has no business being in the standard library.
OCaml is slow? and your recommendation is to use Haskell instead... That doesn't compute well if we were to assume that you are writing some compute-intensive tasks for which (unoptimized non-C language can be "slower".
It more likely the case that students hate whatever languages the university teaches in place of language-de-jour. (Just read the reviews of SICP on Amazon).
And yes there are pages on the internet that are older than 2006, so what? No one goes "Pffft.. this is 300 years old.." when they come across Newton's Principa.
The difference is that programming languages evolve all the time. Having such an old page still up and promoted to the front page of Hacker News tells everyone that OCaml hasn't evolved since 2006.
Please don't be so sharp, I really don't understand why this link is in HN, and I'm just exposing my point of view, after practising OCaml a lot. So what, I'm a student so my opinion is worthless?
When you are starting out, convenience and familiarity (which are visceral) can trump abstract notions like "pure", "correct", "reason-able".
I'm not saying your opinion is worthless, just that your judgement could be coloured by inexperience.
My sincere recommendation is to use "Real World OCaml" - https://realworldocaml.org/ as a reference to learn OCaml instead of old and busted tutorials littering the internet. Trust me, I have been trying to learn OCaml "on the side" for a few years and RWO is the first book that I have absolute love (even accounting for a wide variety of PL books I read) for being practical, current and explaining stuff.
Do you have some examples of well-known applications built with OCaml? I'll have to check that too.
Do you mean that OCaml produces small binaries, or that the language itself is compact? As for being slow, that's the first time I hear this charge being leveled. Single-thread performance is usually really good.
I guess the official homepage http://ocaml.org would be better for up-to-date information.
I feel that many of the advantages of switching to OCaml are minimised when you are already using an ML!
Soon, there should be a compelling performance case for using OCaml. There are rumours that in the next release, there'll be an MLton type whole program optimisation setup, which should reduce the cost of abstraction to zero.
e.g. http://amirchaudhry.com/unikernels-for-everyone/
MLs are such that the value-level stuff and the module-level stuff are more or less independent. So you can go a long way just liking the value-level stuff without really caring about the status of the module-level stuff. But it's also a pretty big motivator for the design of ML. F# is at least weirdly missing out here.
A good example is the Set.Make functor in the OCaml stdlib. Elements in a Set must be orderable for efficiency's sake, so to construct a Set you parameterize it over a module specifying not only the type but also its ordering.
Here the OrderedType module signature represents any type that also has an ordering. The S signature represents the result signature of calling the Make functor which is passed any OrderedType-substantiating module and uses it to construct the (Set.S with type elt = Ord.t) module.http://www.mpi-sws.org/~rossberg/1ml/
"a redesign of ML in which modules are truly first-class values, and core and module layer are unified into one language. In this "1ML", functions, functors, and even type constructors are one and the same construct; likewise, no distinction is made between structures, records, or tuples."
Maybe not for folks whose primary platform in Windows? The .NET stack is the primary advantage there, no?
For those of us on Linux, IMO OCaml is the similar language with complete platform support. I know .NET core is now available, but some time will have to pass to know if Microsoft's support for .NET on Linux is a long term plan.
Also, this page is almost ten years old.
Not sure how this kind of post ever makes it to the front page.
OCaml syntax is super idiosyncratic and doesn't resemble anything, but, once you retrain your eyes, the underlying semantics are terrific.
js_of_ocaml imposes very minimal code overhead (6k-ish). Sourcemaps work great, and OCaml values are mapped into JS in a very straightforward way. You can read them in a JS debugger.
Ocsigen's lwt library is also the best "callback hell" solution I've found.
The only advice I can offer is that the documentation actually is correct and pretty complete, but there's nevertheless something about its organization that makes it difficult to find what you're after.
In particular, start by reading this page carefully: http://ocsigen.org/js_of_ocaml/2.5/manual/library
It explains everything at a high level.
1: https://github.com/rgrinberg/opium
[0] http://meetowebl.com
After getting past the steep learning curve (about a weekend of pedal-to-the-metal debugging), I really got a feel for how beautiful OCaml semantics really are.
If you're looking for a solid and familiar OCaml stack, check out OWebl [0]. Always looking for helping hands or other support.
[0] - https://www.janestreet.com/
[1] - http://meetowebl.com
I couldn't shake the feel that I was learning "Haskell Light". No pure/impure code (I/O, mutable references, exceptions), no monad syntax sugar, less syntax sugar for pattern matching, much smaller base library, plus surely other differences that my current level of expertise of Haskell is hiding.
Perhaps the simpler semantics make it easier to translate to js (I know haskell->js transpilers are very complex and I'm sure lazy evaluation has a lot to do with it), but in terms of language features, what am I missing in Haskell that makes you more productive/helps you write clearer code in OCaml?
Our students were mostly having trouble with OCaml being a functional language than anything else. Some of them independently discovered mutable references and for loops and probably wondered why we hid from them such useful constructs! Pattern matching was also something that only the best students took serious advantage of.
- There are good conventions for naming and argument order (and named arguments!) so I don't have to memorize a bunch of different APIs. This is made possible by the module system. It could probably be solved in Haskell with better tooling.
- Modules allow you to, for lack of a better word, make your code more modular. Modules are essentially the same thing as what people use objects for in Java. They let you abstract implementation and program against a particular interface (i.e., a collection of types and values) easily in a way you can't really in Haskell.
Haskell type classes can make it a bit easier to encode (and infer) interfaces but assume a single implementation per data type. ML modules do not make this assumption and support a higher degree of modularity as a result.
Robert Harper has some extremely good writing out there on this topic (and many more): https://existentialtype.wordpress.com/2011/04/16/modules-mat...
[0] - http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf
A good example of something easy to do with ML modules and hard to do in Haskell is the Cohttp library which is a HTTP stack that works using the Lwt async backend, the Async async backend, and a Javascript Lwt backend. It is merely modularized over that interface and you can plug in whatever backend you like.
There are examples of doing similar things (Reflex is modeled this way, e.g.) but it's hairier in Haskell.
First of all the word "compiler" is perfectly adequate to convey the meaning of a "transpiler", meaning a computer program whose purpose is to translate code from one programming language into another. The usage of the word "transpiler" only happened because of languages like CoffeeScript, as a word was needed to express that CoffeeScript is just as broken as Javascript, but with syntax changed for no good reason.
But more importantly, many compilers that target Javascript, such as Scala.js, ClojureScript, GHCJS, Dart, are very much not like CoffeeScript, meaning that we are talking about languages with different type and module systems, with big standard libraries, that treat Javascript as bytecode and that need to be compressed with Google Closure to be viable. If you're missing the source-maps, the end result will be much harder to understand than Java or .NET bytecode. Therefore the usage of the word "transpiler" in this context is not only annoying, but incorrect as well.
The Mirage library OS is a pretty serious project. Facebook also uses OCaml for Flow and the Hack type checker. And of course, Jane Street Capital uses OCaml.
But I'm guessing what you mean is that OCaml is a very non-mainstream language, so it will be rejected for most corporate projects just because it's so foreign.
Rather than snidely guessing what I meant, why not just read the rest of my comment or ask for clarification like an adult? Also, I'm not denying there are a few odd projects here and there that use it successfully -- as well as Jane Street, of course, who are almost synonymous with OCaml. But like I said, although it is a very nice (and educational) language, I just don't feel like it is "best of breed" in any particular area. Not sure what that has to do "corporate projects", etc.
You're right; I'm sorry.