From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pB7E0577030273 for ; Wed, 7 Dec 2011 15:00:05 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkHAFVw305ii1vwaWdsb2JhbAA2DZoxjxqBKg0JCwcZGweBbQEEAQEFCyAVAQIGDxYMAQ4GBUYvAQ4BBhIGJwUChS2CNwqlLAqCYYRciS4BBgsBiygEiC6FBYc/hUMqSIgqg14 X-IronPort-AV: E=Sophos;i="4.71,313,1320620400"; d="scan'208";a="134359599" Received: from nm11-vm0.bullet.mail.sp2.yahoo.com ([98.139.91.240]) by mail1-smtp-roc.national.inria.fr with SMTP; 07 Dec 2011 14:59:59 +0100 Received: from [98.139.91.63] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 07 Dec 2011 13:59:57 -0000 Received: from [98.139.91.60] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 07 Dec 2011 13:59:57 -0000 Received: from [127.0.0.1] by omp1060.mail.sp2.yahoo.com with NNFMP; 07 Dec 2011 13:59:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 849909.67876.bm@omp1060.mail.sp2.yahoo.com Received: (qmail 64470 invoked by uid 60001); 7 Dec 2011 13:59:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1323266397; bh=Y0zmCn4ZriFD6LyG+wv7p/SHkKF8goFVuH8TY1v6z/U=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4u0be9PMG26xmcW7GUwPXr3nIrPMpNxyZVgx3Qv4xlp1XDOjJnT1Nzd5xfeawvYfsAc9SaCaUR1UbVDIAIL/920Ot2P9gKYM0VvmwnGtsYodwla+xHRihKNVMuyiurSObogI8LncYsuPFH5gxmKM/ldfzGdw9O6QK7h17Atskiw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nfh8Lms0oJp98zOTWHf4gvZOk4f6FBunyGhw0mVQRWp6nOs6BiuOhiiy+bCWRaGat4Wwza0UQHyoADtoOs7Q36/zb1I6RUkolcYPU/x+R30vMtsimgP+XLgaX2DBqgjFuaPwMruDUTdcqyvHNqkYxO5xH/2X00ZjUL3LYGCsiIA=; X-YMail-OSG: nGFbNw8VM1l.uT11war0LlifEBGtCw9Pmhq2k6rp7R8dXLr IaY6YEmsdpDh2V7qjTGilhnYwPbwBWD.vJRB0qHk4Eji0YnYlmmN3cLMxuzK JA0i700jA5G_AvakAk.yVpxTlF.p4ff8sUCP2hd.RL6mpdHPZtwxpdBldLmR 1KiWFcvXvr.weD5dBR6o1XspNM1lKAZL_siRN63gSnM3fJQ91Nd6qGvAZGfc fBwF.mPW26l.yspeNyhUukit5Bt_ZepnHDNyq7XNs.DhTDSNAl4k.ghWz4lW thTDhHq5Vrzhf6VQV8GYkuJYdXc.i_bzqccN5IrT0c1I0BGqlwJk77donpo4 J2oxHrAiCRLfsGymKY9GVZ87bApOw_ytKwKzzNjYYUPUNb5hf5xjluPS0KMx AjUtvYVYBX_a4yNfmqf_t8Tu3dHRA5l01qRuf0XtlXZBo8R1OOtvbVE0IwRJ s1PaetIq67TzBxs3aPvPfkWpx.14O1VhqMS56d_Xgbi4gwjMRfGXS4c10xaE QQJBydNMjFTtoirusuzxXIJNACTXZ2GfwaHt_Nvpr92ZqVesKHmUADxCu69v GDA-- Received: from [85.255.197.126] by web120603.mail.ne1.yahoo.com via HTTP; Wed, 07 Dec 2011 05:59:56 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <201112071100.pB7B0N8J020839@walapai.inria.fr> Message-ID: <1323266396.63331.YahooMailNeo@web120603.mail.ne1.yahoo.com> Date: Wed, 7 Dec 2011 05:59:56 -0800 (PST) From: tools Reply-To: tools To: "caml-list@inria.fr" In-Reply-To: <201112071100.pB7B0N8J020839@walapai.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pB7E0577030273 Subject: Re: [Caml-list] OCaml maintenance status / community fork 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.