Re: [Caml-list] OCaml maintenance status / community fork

[tools <toolslive@yahoo.com>]

Hi,

I'm responsible for the introduction of OCaml in two companies( www.incubaid.com , www.amplidata.com ).
This cost me a lot of energy and a few years of my life, I'm sure. 

As we now are few years further, so I can look back and reflect a bit.

The whole experience of working with a strongly typed, polymorphic, functional, programming language feels really gratifying.
I think everybody who has been exposed to this for a longer period of time feels the same.
It's a winning strategy.

As far as compiler/toolchain/runtime/programming environment/libraries/community go, I have a few remarks which I address below
 (random order):

- "language" I'm not eagerly awaiting new features. OCaml might not be too sexy, but it gets the job done.

- "multi core" (talked about in great detail here on the mailing list) I won't say anything more than
    it would be nice if there was support to harvest the current generation of cpus as we currently resort 
   to ad hoc solutions (and keep on reinventing the wheel). We're not really in pain, but worried.

- "ocamlbuild/oasis/ " I have a hard time bashing 'autofoo' and 'make' when every little thing I need to explain to ocamlbuild
  eats away a half day of my time. Yes, in the end, the delta is always small, but it's the time not the number of lines that matter.
  It's probably a documentation issue (the wiki is outdated)

- "IDE". actually, only emacs is more or less ok; tuareg needs tweaking, and debugging is painful (and yes, sometimes you would like too).
   ...but not everybody likes emacs. Personally I'm rather impartial, but I have access to an emacs zealot, which helps.

- "tools": what tools? 
-- a heap profiler would be nice. OCamlviz is broken/abandoned/not enough.
    You just hope you never have an ocaml lwt-based server that fuzzily grows to 10GB without any clue about what's eating the memory.
-- a performance profiler that understands the language would help too: we currently resort to valgrind (Valgrind is not the problem)
-- a debugger that doesn't make you want to kill your spouse would be nice too.
-- we use bisect for coverage and that's ok.

- "Windows". has been covered before. It seems to be difficult to set up. Actually, I wouldn't know as we currently (and nothing in the pipeline) only do linux.
   (And it's a reassuring feeling that our brief escapades on BSD and Solaris turned out ok). 

   But I'm convinced  people who have windows as their only platform, will prefer F# or Haskell (I would too).

- "libraries": A lot is out there. Some are good, some are bad,  some don't like each other (lwt and async fe), some are lean, some are kitchen sinks.
  This will always be the case (whatever paradigm, programming language, or community). We actually don't need a lot since we mostly do system programming. 
  What we do need and often use is the foreign function interface, and I don't have complaints there (having experienced JNI in the past, I know this can be painful).

- "Community" I think we might split them in 2. the "Cathedral" (responsible for the download bundle) and Others (sometimes the same people in a different context)
-- Cathedral: If you want to have something in there (patch, bugfix, feature) and you're not part of the inner circle, you have zero insight in what will happen, 
   and a small chance of success. (This has also been covered here a lot, no need to digress)
-- Others 
--- LWT:   We have experience with the ocsigen people, and a track record of several lwt bugs discovered, testcases that assert the problem, and patches to the mailing list or the developers personally.
   If it concerns code, 95% (not measured, but this is how it feels) of the time, things are fixed the same or next day in their repo. 
   [We also sent documentation patches cleaning up the "Franglais", but these were totally ignored. I guess they just don't notice how bad it really is.]

--- Other libraries: again, most of the time, if we contact the developer(s) we quickly get a response. If it is a bug, it's fixed (almost) immediately.
    most (OCaml library) developers seem to have enough pride in what they do to make this happen. Really, no complaints there.

The bottom line is this: In our companies, there are 3 sets of people with OCaml exposure.
- those attracted to the greener pastures of Haskell
- those that think the OCaml ecosystem sucks, but less than other things, and not enough to move.
- those that think OCaml tool support sucks too much, and consider moving back to "the evil they know" (C++)


Btw, I checked, and none of them have any problem with type inference, or functional programming.


Anyway, I think that the next time we have the opportunity to choose the programming language for a component, we will have some interesting discussions.

have fun,

Romain.