I should point out that this article is only my opinion, and I'm not even a "real" programmer. I don't really write production code, and I'm certainly not an expert on the general field of programming or on programming languages. I know these sort of conversations spark quite a lot of partisan emotions, so beware ;-)
My first impressions of Ocaml were that "it's a bit weird, but you can make it do what you want". For newbies, you have to get used to using a lot of recursion (something Ocaml does really efficiently), and that it's strongly typed, so an "int" can't magically become a "string" - ever, and in fact, most "variables" in Ocaml are actually immutable, so not variable at all. I figured I'd get used to it, like I had with a raft of other languages, and that pretty soon I'd be knocking out little tools and gadgets to make daily life a little easier. Certainly, I did write a few things in Ocaml, both from scratch and by adding to other people's code. However, I wasn't nearly as prolific as I wanted to be.
The first thing anyone ever says when you say you can't program in a language is "you don't know the language well enough". This is definitely true of me with Ocaml. In fact, I don't think I'll ever know Ocaml "well enough", even if I had stayed in an environment that uses it. My problem is that I'm just not a brilliant programmer - at best, I'm "mid range". Even in my most used, and most familiar language (Perl), I'm at best a mid-range programmer. Sure, I can make Perl do just about anything, but there are people who can do the same thing faster, smaller, neater or whatever than I can.
So why is Ocaml any different, if it's just a different language? Well, firstly I'd have to say that it's pretty esoteric. I'll challenge anyone to write some Ocaml that a reasonably proficient programmer could understand if they'd never seen any of it before. In terms of readability, I'm going to put it right up there with Assembly Language. However, unlike Assembly Language, a few characters (yes - characters, not lines) of Ocaml can do amazing things. That's part of it's appeal to those that love it, but when it comes to learning it, that makes it hard. Really hard.
Ultimately my problem with Ocaml is that because I'm only "mid range", and never spend all day, every day working with code, I have to re-learn any language (at least to some degree) every time I use it. Thus, if I work at it a lot, I become "proficient", maybe "expert" even for a time, but a month later I'm back down to "mid-range" and have to learn it all over again. That learning time in Ocaml is long, so unless I really get time to concentrate on it, I'm never really proficient.
This all matters because I look at a given problem and think things like "that looks like a couple of days work to knock up a program to solve that problem" (I'm not talking about production code - just enough of a prototype to have something working). I come up with those time estimates because of years of experience of programming and working with other programmers. Thus, I've "costed" a given problem at "a couple of days".
When I actually tried to write these "couple of days" jobs, it took me such an inordinate amount of time that quite honestly, I got bored. The idea was great when it was a couple of days work. Even spinning that up to a week, or a fortnight for learning time, it was still a reasonably good idea. However, after a month, or two months, it really wasn't a great idea at all. That meant most of my ideas weren't really that good, which made me feel like I wasn't able to do as much good stuff as I would have liked.
Looking at the "real" programmers around me, I could see they were able to knock out little tools and toys in a few hours or a day. That means it's definitely possible with Ocaml, and it really is just a difference in skills between them and myself.
Ultimately, I've come to the conclusion that Ocaml is a great language for making you think about what you're doing, how you're doing it and what's the best way to do what you're doing. For "production code" that's actually a very good thing. After all, you need to know the domain very well, so being forced to think about all the details of implementation is a really good thing. It makes the development cycle longer perhaps, but I'll bet that Jane Street's production code has less bugs in it per unit volume that the average Java (or Perl) program - even before any code review or testing cycles. That's got to be a good thing, right?
My gripe with Ocaml is I found it really hard to do less than perfect stuff. As a mid-range programmer, I don't really care about the intricate details of polymorphic variants or overloading versus overriding or whatever. I just want some code that "sorta works". For that, you actually want a "crappy" language like Perl (although feel free to 'upgrade' to Java or something). You don't want to spend time thinking about the intricacies of the language or the best algorithm to manipulate some data - you just want to get a job done, and actually, bugs aren't that important.
So my journey into Ocaml is (pretty much) over. It's been fun, and I've learned a lot, but it's not for me.