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 pB6BV82L028602 for ; Tue, 6 Dec 2011 12:31:10 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYCAAH83U7U436rkWdsb2JhbABEmiyNNIJ7IgEBAQEJCwsHFAMigXIBAQQBbgsFCwUGGA0hRRIGEwkIAQIGh20CBrUtg3KHQASMchMVAZls X-IronPort-AV: E=Sophos;i="4.71,304,1320620400"; d="scan'208";a="134142877" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Dec 2011 12:31:09 +0100 Received: from office1.lan.sumadev.de (dslb-188-097-001-048.pools.arcor-ip.net [188.97.1.48]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MfZE3-1R9sIh01xD-00P9Dv; Tue, 06 Dec 2011 12:31:08 +0100 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id 5A62EC00C7; Tue, 6 Dec 2011 12:31:07 +0100 (CET) Received: from 84.233.128.147 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Tue, 6 Dec 2011 12:31:07 +0100 Message-ID: <4adc9f6482cdbe0208c0baf4992392de.squirrel@gps.dynxs.de> In-Reply-To: References: <1B0D83BD-1902-4F7C-B3FB-B759122D6AB9@googlemail.com> Date: Tue, 6 Dec 2011 12:31:07 +0100 From: "Gerd Stolpmann" To: "Gabriel Scherer" Cc: "Benedikt Meurer" , "caml users" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V02:K0:xets/1rP30Ik3ctXElBFDkTDiE6haud8UU7i6N5832s fCD9SwPXaM2TQ/2Kv2gS1QTqzU6B1ol8gO8ZGCz+PPHwxcdr3m mFNwuqxA5UjiNAKAz5EuFwZpt6pIrYaDHYuJkv1CW2zfmIblJi 8yQL+m6a/lWJvIiPjh3sKPrwOlUZ+Z9pzNVSbU+5cY+5gZCxpm dVjAC7hsz1LsVmd4I21R2qLebR1yvr9pwhJFOF/dzaL/YzXm5H i1owUeSUowUi4L0cWb5Ja5Y/z7OIxP5rjPGtx/5RJTiCGC42w8 eydGzND+X95jDJ94bm0EzYUooiEIa8CZTuTZQNA5X4mL2xaO5L IboC+fAcm7F9oL4ZK6d2K+w/wtnq5gN6Y2JmjYvnv7/A1JvO6P 8rZiWAVNOH4FwewqDqOMGvuX0g/Pz349Zg= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pB6BV82L028602 Subject: Re: [Caml-list] OCaml maintenance status / community fork > I would like to comment on a tangential aspect of the rationale you gave: > >> Given that OCaml is such a nice language with a lot of useful frameworks >> available, >> it is too sad to see it loosing ground just because of it's closed >> development process >> and lack of time of the official team. I'm quite reluctant to discuss topics about the said decline of something. However, there is certainly a point here. I have my own theory - basically the users with FP knowledge have now more options (e.g. F# or the JVM-based FP languages like Scala), and so the "share" for Ocaml is decreasing. This has nothing to do with the language. However, the question is whether we can do more to attract programmers with FP knowledge (or even better educate programmers without). Ocaml is not doing enough here - there is no (really good) beginner's site, and there are not enough "success stories", i.e. users reporting that they solved something with Ocaml, and why it was a good choice. Gerd > I don't think OCaml "losing ground" can be just-because-explained by a > closed development process. It's a fact that the OCaml community is > generally less active than other communities of comparable programming > languages, the first example coming to mind being Haskell. It is > interesting to discuss what we could/should do to get a comparably > healthy community. > > I agree with the analysis that the OCaml language implementation is > not as open as it could be, and I understand the idea that this > probably had a detrimental effect on the "OCaml community" as a whole. > But this is by no mean obvious (and difficult to objectively verify), > and it is certainly not the only factor -- or even, I claim, the main > factor -- to explain OCaml feeble community growth. > > There have been numerous "OCaml community meeting" discussing > precisely these issues. I attended the 2008 meeting, and several > aspects were discussed, including among others > (1) the lack of openness of the compiler development (what you discuss > here) > (2) the apparent stagnation of the OCaml language itself > (3) the lack of a comprehensive general-purpose set of software > libraries that newcomers could just use as a standard starting point > (4) the lack of visibility of user-contributed OCaml code, tools and > libraries, or perceived difficulties to install and deploy such code > (5) (related) the lack of communication of OCaml users about what they do > > You are singling out problem (1) as *the* problem with OCaml. I think > this is more a reflect of your personal preferences (indeed, you are > now a distinguished OCaml backend hacker) than a global analysis of > the needs of the "OCaml community". I agree that (1) hasn't changed > much since 2008; as you noted (at least from an external point of > view), there are important human factors that make the situation > difficult : not everyone can contribute to the compiler as there are > both technical and social barriers to contribution. > > (2) has clearly turned to be wrong. I distinctly remember being > surprised at that time by the announcement of 3.12's first-class > module, and thinking when Xavier Leroy mentioned GADTs -- at the 2008 > meeting -- that it would just never happen. > > (3) is currently being worked on by different people. The OCaml > Batteries Included project as an ambitious goal to provide a > community-built "distribution" of OCaml software in a coherent whole > (the idea was later taken, and impressively performed, by the "Haskell > Platform" effort). It has since restrained it ambitions to providing a > superset of the libraries distributed with the compiler, as a wider > "standard library". Jane Street Core's library similarly aims to > provide a "bigger standard library", with in particular an impressive > offering regarding the pervasive cross-module aspects such as > marshalling / unmarshalling data and similar datatype-generic > concerns. > http://batteries.forge.ocamlcore.org/ > http://ocaml.janestreet.com/?q=node/13 > > Using, contributing to or talking about those projects would also help > OCaml not to "loose ground". I won't make any judgement on whether a > more complete library is more or less useful that a change to the > compiler toolchain, and it certainly is a different kind of work prone > to interest different peoples. But it is also an important aspect of > the OCaml ecosystem. > I have irregularly contributed to the Batteries project, and I know > for sure that the project is willing to accept any help on things to > improve (in particular unit testing and documentation). Even, or > especially, small one-shot contributions can help : three unit tests > for a given function, a new tiny auxiliary function in such module, a > bunch of typo fixes for the documentation... > > The problem (4), which is really a multi-faceted set of related > problem, has also been tackled by different people with different > projects. In particular, GODI and Oasis are both impressive efforts in the > right > direction, and I suspect both projects would benefit from > contributions, eg. packaging existing libraries, reporting issues with > either tool, communicating about them and disseminating exemple > packages that other can look upon to reproduce for their own software. > > If think specific progress on (5) resulted from those meeting. There > is now an OCaml Planet, which has interesting posts about OCaml from, > for example, Matías Giovannini ( > http://alaska-kamtchatka.blogspot.com/ ). Activity on the planet come > and goes, but everyone can help by posting interesting stories that > would be of interest to an OCaml audience, or targeted at non-ocaml > people that may be interested in the language. As a starter, you could > just suscribe to the planet, read the posts, and submit stimulating > feedback to the writers. > http://planet.ocamlcore.org/ > > Having a personal blog is not the only way to help disseminate > information about OCaml. If you participate to news-aggregation sites > such as Slashdot, Reddit or whatever, you should consider submitting > OCaml-related content that could be of interest to the target > audience, or participating in relevant discussions when appropriate. > "Appropriate" is the key word here : quality should be favored over > quantity, and I personally try not to get involved in negative > discussions (in particular language flamewars: informed users of other > programming languages are not enemies, even if they are frustratingly > better at propaganda, have a nicer surface syntax, and indulge > themselves into letting people think that "pure" necessarily means > "better", hint hint :-). The OCaml community should have a public face > to be proud of; it is currently gradually moving out of total silence. > > > I'm not trying to say that your fork is a bad idea, not useful or > anything. I have really no opinion; we'll see how things turn out. But > I wouldn't want people to start thinking that "indeed, compiler > development is the biggest problem with OCaml today, we need the great > Xavier, Benedikt, Jun, Jacques, Alain, Fabrice... to sort things out", > hiding or neglecting other issues that are not so delicate (on the > human side) to handle, could easily benefit from efforts from > everyone, and may have an equal or higher impact in the long term. > > Dear reader, if you wish to help OCaml strive as a language, there are > a lot of different ways you can help. Improving the compiler toolchain > may be one of them, but there are others that are also useful, > important, lack manpower and have a lower barrier to entry. Consider > how you could be involved according to your interests; I'm not talking > about a huge, demanding personal investment from some key people, but > lots of small contributions by anyone interested. A community is a > collective effort. > > On Tue, Dec 6, 2011 at 9:25 AM, Benedikt Meurer > wrote: >> Dear caml-list, >> >> During the last year or two it seems that time and interest in OCaml >> maintenance from the official OCaml development team is diminishing. It >> takes several months to get a patch reviewed (if at all), which is quite >> frustrating for OCaml contributors and even worse for OCaml users. I >> suspect that this is one of the top reasons why there are only a few >> active contributors to OCaml (and the number of active users, at least >> on the mailing list, is declining). >> >> I understand that INRIA does not necessarily pay people for full time >> maintenance jobs on OCaml (and Coq), and the official dev team is >> probably already doing as much as possible to maintain OCaml. Given that >> OCaml is such a nice language with a lot of useful frameworks available, >> it is too sad to see it loosing ground just because of it's closed >> development process and lack of time of the official team. >> >> I'd therefore propose to open up OCaml development to a wider range of >> developers / contributors, to ensure that OCaml will be ready for the >> (functional programming) future. There are already various "OCaml forks" >> in the wild, with different goals and patch sets, so simply starting >> another fork would be rather useless. Instead I'd suggest to bundle >> efforts in a new "OCaml community fork", which is always based on the >> most recent upstream OCaml release (starting point would be 3.12.1 for >> now), and takes care to review and integrate pending patches as well as >> developing and testing new features. Let's say we'd name the fork >> "OCaml-ng", then we'd try to release a new patch set every month or two, >> based on the official OCaml release, i.e. "ocaml-3.12.1+ng201112" and so >> on, to get early testing and feedback (should work together closely with >> the Debian/Ubuntu/etc. OCaml maintainers). >> >> With this process, OCaml upstream could merge (tested) patches from >> OCaml-ng once they proved working in the wild, and thereby >> >> 1. maintenance overhead for INRIA people is reduced, >> 2. maintenance status of OCaml would be way better, >> 3. there would be a lot less frustration for possible contributors, and >> 4. users benefit from a better and more up to date OCaml. >> >> Now that does of course raise a few questions: >> >> 1. What is the opinion of the official development team / INRIA on this? >> 2. Who would help with the community fork? >> 3. What about infrastructure? >> >> Feedback and suggestions are welcome. >> >> Benedikt >> >> -- >> Caml-list mailing list.  Subscription management and archives: >> https://sympa-roc.inria.fr/wws/info/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > > -- Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you.