From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id AEF387FD8B for ; Sun, 20 Dec 2015 14:55:58 +0100 (CET) IronPort-PHdr: 9a23:fvBYSxWqwwWwYSV7S8ylJdxvS03V8LGtZVwlr6E/grcLSJyIuqrYZh2Ot8tkgFKBZ4jH8fUM07OQ6PC+HzRYqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh770o8WbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t/vQqALbQACTynwZW2QQ2loUUkmWpC39C7f8tCfgt+k18i6dOIWiTb0yVS6j7I93TwfviWEfMDkgtmrQj5ojorhcpUeOrhZlwoPQKLqeNPdkc7mVKdwTT3BAU8IXTCdBD5mxdaMACuMAOaBTqIyr9AhGlge3GQT5XLCn8TRPnHKjmPBj3g== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-ig0-f173.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.213.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.213.173 as permitted sender) identity=mailfrom; client-ip=209.85.213.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ig0-f173.google.com) identity=helo; client-ip=209.85.213.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3AADBsnZWm63VVdFehAxtBoxMoQiReCGCLBCDMAKBEgc8EAEBAQEBAQEBEAEBAQEBBgsLCSEugi2CBwEBAQMBEggBCB0BGw8DBAcBAwELBgULDQ0TCgICIQEBEQEFAQoEAQ0GEwgKAgcHh3cBAwoIDp1WgTE+MYtIgWqCeYFxAQEJAQyGHQoZJwMKVoNBAQEIAQEBAQEBFwEFDoZIg3iBBoJTgVFkgm+BSQWGGwyQWYU7hhiBeIFcSYN8jiiBB4NogicSJIEXESiCLyOBXj00hHwBAQE X-IPAS-Result: A0B3AADBsnZWm63VVdFehAxtBoxMoQiReCGCLBCDMAKBEgc8EAEBAQEBAQEBEAEBAQEBBgsLCSEugi2CBwEBAQMBEggBCB0BGw8DBAcBAwELBgULDQ0TCgICIQEBEQEFAQoEAQ0GEwgKAgcHh3cBAwoIDp1WgTE+MYtIgWqCeYFxAQEJAQyGHQoZJwMKVoNBAQEIAQEBAQEBFwEFDoZIg3iBBoJTgVFkgm+BSQWGGwyQWYU7hhiBeIFcSYN8jiiBB4NogicSJIEXESiCLyOBXj00hHwBAQE X-IronPort-AV: E=Sophos;i="5.20,454,1444687200"; d="scan'208";a="193191162" Received: from mail-ig0-f173.google.com ([209.85.213.173]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Dec 2015 14:55:55 +0100 Received: by mail-ig0-f173.google.com with SMTP id to18so20766999igc.0 for ; Sun, 20 Dec 2015 05:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rnXdi6+/xbfN2ucqhvj4H2y3L2ZEqVpvgy+taEWXz74=; b=JVwm72hzr227tLL3EtRJQjFnUKBWjHhzttg4vzR+iWj6vhiBkOrhwuISQAs8MxdtC+ zumAW5FmvEJZCnihgiTiLQ5WIDGdmMoJFS10GdRxqGNtG/ozwGa8TKYRHbqUfUUp2pN5 zEJeS6cb3d7vco724IkfhWOJz/4tVkhCu2VtuRTGyOo7bf48gUJdDy0+9bg9TvfWSL1y 7iymOzjrLbcyElTKrCiM2KlwLiWqZ8xKolMqZanZ3ruAqeClSA4h1ClxEwfRh/aYXQSh W0NYvTOYd/IgPBvIsKDGD3FXPPykSsZOLKlAan77YyJ3apAkUyve4/90xOWAzgzD0L2q ZAUQ== X-Received: by 10.50.150.5 with SMTP id ue5mr3266316igb.50.1450619754349; Sun, 20 Dec 2015 05:55:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.27.205 with HTTP; Sun, 20 Dec 2015 05:55:14 -0800 (PST) In-Reply-To: References: <20151218010834.GA7442@topoi.pooq.com> <20151218011315.GB7442@topoi.pooq.com> From: Gabriel Scherer Date: Sun, 20 Dec 2015 14:55:14 +0100 Message-ID: To: Hendrik Boom Cc: OCaml Mailing List Content-Type: multipart/alternative; boundary=001a1133cd00298c58052754bb56 Subject: Re: [Caml-list] Is OCaml for experienced beginners? --001a1133cd00298c58052754bb56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that the usability of the OCaml ecosystem is very important. I feel it is one of the highest-priority tasks for the OCaml community to thrive, possibly the most important today. We should discuss openly what can be done to improve the current state, and encourage people to contribute to this improvement by highlighting moderate-cost tasks that really do help. There are two partly-orthogonal ways to improve the usability of the OCaml ecosystem for beginners. One is to document it better: give more information about each tool, give some opinionated guidance on tool selection to reduce decision fatigue, update various parts of the online information to make a more coherent whole where each part is informed of the rest. The other is to improve it by improving existing projects (evolution) or starting new ones (revolution). It is unclear to me what are the respective usefulness, on the long term, of those various options, and what we should encourage would-be contributors to do. It is clear than there is not only one Right Thing to recommend, we need a bit of all of that at the same time, and different approaches may suit better different parts of the problem. When I started being active in the OCaml community a few years ago (let's say around 2008), the "pain map" was fairly different from what it is today. We have improved considerably on many fronts, but I am afraid that we may have largely prioritized improvements that would benefit the existing userbase of OCaml semi-experts, at the detriment of those designed to lower the barrier of entry. Below is a rather rambly and subjective list of the various aspects I can think of, and how they evolved over this time period. + At the time, the development of the compiler distribution felt was perceived as a closed, opaque process. There is always room for improvement, but I think it is fair to say that today it is evidently not the case anymore. The compiler distribution, as a software project, welcomes external contributions, and has a fairly active network of external contributors. We are lucky to have such a enthusiastic crowd hacking the compiler, and I am sometimes surprised that other important and useful tools in the OCaml ecosystem are not similarly gifted with external contributions. + Another major hurdle for OCaml users was the lack of a consensus solution for packaging. Debian and RedHat/Fedora were (and still are, thanks to excellent maintenance work from their OCaml package maintainers) two safe islands were development environment were easy to setup, and GODI had a loyal and satisfied user base, but a large part of the community still considered external dependencies as grave sins that impeded their use of OCaml software. ocamlfind and OPAM have brought an end to this middle-age of OCaml library usage, and we now consider it a given that other people than ourselves will be able to use the libraries we distribute (without having to import their sources in the source tree). (History always moves a little bit slower for our brave Windows OCamlers, but some unsung heroes are doing their best there as well). - One thing (the only thing? for non-Windows users at least) that is currently rather bad about OPAM is its documentation. This is partly due to the fact that it is a very flexible tool, and partly to the fact that writing good documentation is Really Hard. This is one area where I think everyone could contribute small improvements that would have a large collective impact. ~ The third major blocker that I remember being clearly identified at the time was the lack of a "extended standard library" that would cover the everyday needs of OCaml programmers. Batteries and Core (the latter internally inside Jane Street at first) were started around the same time as attempts to fulfill this need, and Containers would be a notable more recent entrant. This is a mixed success at best: we now have good "extended libraries" which make many user's lives better, but no real "standard". It is unclear we should keep trying to feel this role, however, given the current use of distributing smaller, one-purpose libraries; I don't think that the OCaml community at large currently identifies this as a blocker high on the TODO list. On the other hand, the situation is arguably unclear and it may be the case that beginners find this confusing. + Interfacing with C APIs should be easier than it previously was thanks to the ocaml-ctypes project. ~ The library ecosystem is still poorer than we would like, with some functional areas that are not well-covered. This can be explained by the modest size of the community, and is improving at a steady pace. - There is no effective standard for running the internal tests of OCaml packages, which would be useful for quality analysis (and in particular be of help when assessing the impact of changes to the OCaml compiler or other parts of the base ecosystem). -- There is no effective standard for releasing and finding the documentation of OCaml packages. The convention of documentation comments in .mli files (protected both by the existence of the ocamldoc tool and the insistence on have separate interface descriptions) means that there often *is* decent documentation for OCaml libraries, but it can still be hard for users to find. As Hendrik Boom reports above, this disproportionately affects beginners. + The Merlin project now provides solid IDE-like support for a large portion of the OCaml community; in many ways it goes above and beyond the state-of-the-art in terms of language-specific support for partial program buffers. On the tooling front, ocp-indent also seems to be a success in terms of satisfyingly solving its problem area and getting widely adopted, but other tools (otags, ocp-index, ocamloscpe, {ocp-,ocaml}browser) seem to have more insular usage patterns. Finally, we cannot deny that the best OCaml programming experience is currently offered by editors from the 80s (Emacs and Vim; notable exceptions are half-decent support for Sublime text, and the laudable OcaIDE effort for OCaml on Eclipse that enables teaching OCaml in some universities); this is another aspect in which newcomers and beginners may be under-served by the current efforts targeted at the more vocal parts of the user community. ~ Another piece of the OCaml ecosystem that expert users like to complain about is build systems. There are many of them are none are entirely satisfying -- exactly the right environment to get rants from expert users. In practice, I feel they are all rather satisfying, and I wouldn't be ashamed to see a beginner pick any of them for their project. Decision fatigue may be part of the complaints from beginners on the ecosystem, however. ~ Relatedly, OASIS has only a mixed standing among expert users. In practice it has a large userbase and seem to work rather well for them. It is currently unique in the space of "project description" systems, but it currently does not go far enough in this direction -- in particular the Merlin files have to be written independently, which feels like a duplication of effort imposed on the users. I'm always a bit surprised that Sylvain Le Gall does not receive more external contributions on this project. This might be due to some of the technical aspects (auto-generated files) being perceived as unwieldy. + We have a nice website ( http://ocaml.org/ ) that was built from the start as a collaborative, community-driven process. (the ocaml.org organization is not just the website and manages some very useful infrastructure). Some parts are in need of improvement (a personal cringe of mine is the way the spotty "tutorials" section overlaps with the language manual and standard library documentation), but there is a clear and easy process to improve. Do interview OCaml beginners around you about which information they had a hard time finding, and submit pull requests to improve it! (On a maybe sourer note, back in 2008 we had the COCAN wiki as a very useful community-maintained OCaml resource (not the same as the "brion wiki" that never made it easy for external users to contribute), and it has since fallen out of favor. Distributed good will is not quite enough to produce high-quality online documents, and community-edited places are harder to keep relevant than we may think.) + As Fran=C3=A7ois Berenger notes above, we do have a fairly efficient beginner-support network in place through the caml-list and ocaml_beginners mailing lists, the #ocaml IRC channel and the StackOverflow community. It is a bit hard to keep track of all the cool new places (most being proprietary walled garden because startup money trumps benevolent sunday-afternoon contributions) people expect to get help from, but those that I know about are well served. + It should also be noted that the OCaml community has remained friendly and welcoming for as long as I know it; given the fact that no one actually makes any effort to maintain behaviour standards, it can only be explained by the fact that it remains small enough for people to just be nice to each other by default. On Fri, Dec 18, 2015 at 3:44 PM, Gabriel Scherer wrote: > > Are beginners even welcome? > > Yes, beginners are warmly welcome. Feel free to keep pointing out > changes that would help answer this question, this is helpful. Of > course small-scope changes (fixing library X to support format Y) are > always much easier to actuate than general recommendations > (more libraries). > > > Is anyone in charge of the OCaml ecosystem? > > No, there is no one in charge of the OCaml ecosystem, or of a general > "OCaml experience". This may explain some of the very real usability > issues, but it is also rather unclear to me how this should be > fixed. Would anyone volunteer for such a role (funded how?), and to do > what? > > I agree with your conclusion that the OCaml ecosystem today is > unforgiving, and that it is particularly harsh on non-accompanied > beginners. How could this state of affairs be improved? > > I think that while a unified vision for the ecosystem may be necessary > to fix some of the usability issues (one problem with unification is > that you need people to agree on it), a large part of the problem is > rather of the "death by thousand cuts" kind: small things that add up > to create an overall unpleasant experience. This portion of the > general problem is both too large for a single person to fix (no one > person can guess all use-cases), it is easily amenable to > crowd-fixing: reporting and/or fixing issues one at a time as you > discover them. So please keep doing that! > > > On Fri, Dec 18, 2015 at 2:13 AM, Hendrik Boom > wrote: > >> On Thu, Dec 17, 2015 at 08:08:35PM -0500, Hendrik Boom wrote: >> >> And in case anyone wonders, I haven't given up. I will continue trying >> to use OCaml becuse it seems to be the right kind of tool. Not everyone >> will be so stubborn, >> >> -- hendrik. >> >> > # Is anyone in charge of the OCaml ecosystem? >> > >> > I am a beginner to OCaml. I'm not a beginner to the functional style >> of programmins, nor to sophisticated type systems, nor to computing in >> general. I started programming in 1963, was involved with Algol 68, Lis= p, >> and constructive type theory. I've managed to get code running in the d= ays >> when you had to enter it as numbers; the machine I used then wouldn't e= ven >> type letters other than u, v, w, x, y, z (its version of hexadecimal). = In >> those days what you needed to know was the instruction set and its >> encoding. Everything followed from that. >> > >> > Believe be, I appreciate every advantage high-level languages have to >> offer. >> > >> > With this background, you'd expect I'd take to OCaml like a duck to >> water. >> > >> > Wrong. >> > >> > The language itself is actually usable. Once you figure out how the >> syntax works and where to put the brackets. >> > >> > But the world has changed since source code was in hexadecimal. >> > >> > ## Libraries >> > >> > Nowdays, software rests on a huge inventory of libaries and tools. A >> language, however elegant, isn't very usable for anything very practical >> without its libraries and their documentation. It's not enough to know = the >> machine inside out. >> > >> > That's the hurdle I face whenever I program in OCaml -- figuring out >> which libraries are usable, and which are actually documented. Not >> documented in the sense that someone has written an API guide and a >> tutorial, but documented in the sense that it is actually possible to fi= nd >> them. >> > >> > There are often multiple packages to accomplish a single task. >> > >> > You don't know which one to use. You try the obvious one, have >> trouble, ask about it, and then be told, No, that one is troubled, you >> should use this other one instead. The one you can download from *this* >> site. So you do, You download it. You figure out how to edit the >> Makefile so that it generates the right package files. The options you >> need are actually documented in the Makefile. >> > >> > I had to compile my own from the original Makefile, using the options >> that are indeed documented inside it.XXX >> > >> > I've actually manged to write a trivial 3D videogame once I was pointed >> to the usable OpenGL library. The one where the function names were >> closely related to the ones in the OpenGL manual, of which I have a prin= ted >> copy. I didn't have to guess what functions to use. >> > >> > But then you discover that the one you were recommended to use is in >> the opam library (the one you access by saying opam install ... with a >> default configuration), and you decide to simplify things by using the O= pam >> package instead of including all the library's source code within your o= wn >> project. But when you do that, it doesn't work, because the Opam package >> was was configured with optons that preclude essential functionality. (= in >> my case, the ability to load PNG files, not just JPEG). >> > >> > So what? another might say. Just tell opam to install with different >> options. But that is another *huge* problem for a beginner. >> > >> > So I stick with embedding the library source code in my application. I >> already understand how to edit a Makefile. >> > >> > ## Documentation >> > >> > And try to find documentation. I'm dealing with this problemm with gtk >> at the moment. There's a lablgtk. There's a lablgtk2. Whats the >> relationship between the two? And where's the documentation. There's >> links to a tutorial all over the place, but they seem all to be to the s= ame >> web page, which isn't there. >> > >> > Opam has a way, I'm told, to install documentation along with the >> package, but haven't been able to figure out how it works. Or maybe, j= ust >> maybe, the packages I've been trying it on don't have documentation. Who >> knows? >> > >> > ## Are beginners even welcome? >> > >> > Is there anyone in charge of any of this? >> > >> > And what's the result? It's a lovely language, it deserves to be used, >> but to get something done, I find myself programming in C++ instead, even >> though the concpts of OCAML fit my style of programming ike a glove and = fit >> C++ like a rusty nail keeps my hand warm. Or spend days or months tryi= ng >> things, asking questions, deciphering the answers, and so forth. >> > >> > I imagine if I were working in a shop where lots of people used OCaml, >> all the ways of doing stuff would be local folklore. But for the isolat= ed >> beginner, there's a huge barrier to entry. >> > >> > It's a lovely language, but the pragmatics of its ecosystem are all >> wrong. For a beginner. For someone with experience in the particular s= et >> of tools and libraries he needs, it's great. >> > >> > And most of the problem is lack of organised, findable documentation. >> > >> > -- hendrik >> > >> > >> > -- >> > Caml-list mailing list. Subscription management and archives: >> > https://sympa.inria.fr/sympa/arc/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.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > --001a1133cd00298c58052754bb56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that the usability of the OCaml ecosystem is = very important.
I feel it is one of the highest-priority tasks for the O= Caml community to thrive, possibly the most important today. We should disc= uss openly what can be done to improve the current state, and encourage peo= ple to contribute to this improvement by highlighting moderate-cost tasks t= hat really do help.

There are two partly-orthogonal ways to improve = the usability of the=20 OCaml ecosystem for beginners. One is to document it better: give more=20 information about each tool, give some opinionated guidance on tool=20 selection to reduce decision fatigue, update various parts of the online information to make a more coherent whole where each part is informed=20 of the rest. The other is to improve it by improving existing projects=20 (evolution) or starting new ones (revolution). It is unclear to me what=20 are the respective usefulness, on the long term, of those various=20 options, and what we should encourage would-be contributors to do. It is clear than there is not only one Right Thing to recommend, we need a=20 bit of all of that at the same time, and different approaches may suit=20 better different parts of the problem.

When I started being active i= n the OCaml community a few years ago (let's say around 2008), the &quo= t;pain map" was fairly different from what it is today. We have improv= ed considerably on many fronts, but I am afraid that we may have largely pr= ioritized improvements that would benefit the existing userbase of OCaml se= mi-experts, at the detriment of those designed to lower the barrier of entr= y. Below is a rather rambly and subjective list of the various aspects I ca= n think of, and how they evolved over this time period.

+ At the tim= e, the development of the compiler distribution felt was perceived as a clo= sed, opaque process. There is always room for improvement, but I think it i= s fair to say that today it is evidently not the case anymore. The compiler= distribution, as a software project, welcomes external contributions, and = has a fairly active network of external contributors. We are lucky to have = such a enthusiastic crowd hacking the compiler, and I am sometimes surprise= d that other important and useful tools in the OCaml ecosystem are not simi= larly gifted with external contributions.

+ Another major hurdle for= OCaml users was the lack of a consensus solution for packaging. Debian and= RedHat/Fedora were (and still are, thanks to excellent maintenance work fr= om their OCaml package maintainers) two safe islands were development envir= onment were easy to setup, and GODI had a loyal and satisfied user base, bu= t a large part of the community still considered external dependencies as g= rave sins that impeded their use of OCaml software. ocamlfind and OPAM have= brought an end to this middle-age of OCaml library usage, and we now consi= der it a given that other people than ourselves will be able to use the lib= raries we distribute (without having to import their sources in the source = tree). (History always moves a little bit slower for our brave Windows OCam= lers, but some unsung heroes are doing their best there as well).

- = One thing (the only thing? for non-Windows users at least) that is currentl= y rather bad about OPAM is its documentation. This is partly due to the fac= t that it is a very flexible tool, and partly to the fact that writing good= documentation is Really Hard. This is one area where I think everyone coul= d contribute small improvements that would have a large collective impact.<= br>
~ The third major blocker that I remember being clearly identified a= t the time was the lack of a "extended standard library" that wou= ld cover the everyday needs of OCaml programmers. Batteries and Core (the l= atter internally inside Jane Street at first) were started around the same = time as attempts to fulfill this need, and Containers would be a notable mo= re recent entrant. This is a mixed success at best: we now have good "= extended libraries" which make many user's lives better, but no re= al "standard". It is unclear we should keep trying to feel this r= ole, however, given the current use of distributing smaller, one-purpose li= braries; I don't think that the OCaml community at large currently iden= tifies this as a blocker high on the TODO list. On the other hand, the situ= ation is arguably unclear and it may be the case that beginners find this c= onfusing.

+ Interfacing with C APIs should be easier than it previou= sly was thanks to the ocaml-ctypes project.

~ The library ecosystem = is still poorer than we would like, with some functional areas that are not= well-covered. This can be explained by the modest size of the community, a= nd is improving at a steady pace.

- There is no effective standard f= or running the internal tests of OCaml packages, which would be useful for = quality analysis (and in particular be of help when assessing the impact of= changes to the OCaml compiler or other parts of the base ecosystem).
-- There is no effective standard for releasing and finding the documenta= tion of OCaml packages. The convention of documentation comments in .mli fi= les (protected both by the existence of the ocamldoc tool and the insistenc= e on have separate interface descriptions) means that there often *is* dece= nt documentation for OCaml libraries, but it can still be hard for users to= find. As Hendrik Boom reports above, this disproportionately affects begin= ners.

+ The Merlin project now provides solid IDE-like support for a= large portion of the OCaml community; in many ways it goes above and beyon= d the state-of-the-art in terms of language-specific support for partial pr= ogram buffers. On the tooling front, ocp-indent also seems to be a success = in terms of satisfyingly solving its problem area and getting widely adopte= d, but other tools (otags, ocp-index, ocamloscpe, {ocp-,ocaml}browser) seem= to have more insular usage patterns. Finally, we cannot deny that the best= OCaml programming experience is currently offered by editors from the 80s = (Emacs and Vim; notable exceptions are half-decent support for Sublime text= , and the laudable OcaIDE effort for OCaml on Eclipse that enables teaching= OCaml in some universities); this is another aspect in which newcomers and= beginners may be under-served by the current efforts targeted at the more = vocal parts of the user community.

~ Another piece of the OCaml ecos= ystem that expert users like to complain about is build systems. There are = many of them are none are entirely satisfying -- exactly the right environm= ent to get rants from expert users. In practice, I feel they are all rather= satisfying, and I wouldn't be ashamed to see a beginner pick any of th= em for their project. Decision fatigue may be part of the complaints from b= eginners on the ecosystem, however.

~ Relatedly, OASIS has only a mi= xed standing among expert users. In practice it has a large userbase and se= em to work rather well for them. It is currently unique in the space of &qu= ot;project description" systems, but it currently does not go far enou= gh in this direction -- in particular the Merlin files have to be written i= ndependently, which feels like a duplication of effort imposed on the users= . I'm always a bit surprised that Sylvain Le Gall does not receive more= external contributions on this project. This might be due to some of the t= echnical aspects (auto-generated files) being perceived as unwieldy.
+ We have a nice website ( http://ocaml.org/ ) that was built from the start as a collaborative, = community-driven process. (the ocaml.org organization is not just the website and manages some very= useful infrastructure). Some parts are in need of improvement (a personal = cringe of mine is the way the spotty "tutorials" section overlaps= with the language manual and standard library documentation), but there is= a clear and easy process to improve. Do interview OCaml beginners around y= ou about which information they had a hard time finding, and submit pull re= quests to improve it!
(On a maybe sourer note, back in 2008 we had the C= OCAN wiki as a very useful community-maintained OCaml resource (not the sam= e as the "brion wiki" that never made it easy for external users = to contribute), and it has since fallen out of favor. Distributed good will= is not quite enough to produce high-quality online documents, and communit= y-edited places are harder to keep relevant than we may think.)

+ As Fran=C3=A7ois Berenger notes above, we do have a fairly efficient be= ginner-support network in place through the caml-list and ocaml_beginners m= ailing lists, the #ocaml IRC channel and the StackOverflow community. It is= a bit hard to keep track of all the cool new places (most being proprietar= y walled garden because startup money trumps benevolent sunday-afternoon co= ntributions) people expect to get help from, but those that I know about ar= e well served.

+ It should also be noted that the OCaml community ha= s remained friendly and welcoming for as long as I know it; given the fact = that no one actually makes any effort to maintain behaviour standards, it c= an only be explained by the fact that it remains small enough for people to= just be nice to each other by default.

On Fri, Dec 18, 2015 at 3:44 PM, Gabriel Sch= erer <gabriel.scherer@gmail.com> wrote:
> Are beginner= s even welcome?

Yes, beginners are warmly welcome. Feel free to keep= pointing out
changes that would help answer this question, this is help= ful. Of
course small-scope changes (fixing library X to support format Y= ) are
always much easier to actuate than general recommendations
(mor= e libraries).

> Is anyone in charge of the OCaml ecosystem?=

No, there is no one in charge of the OCaml ecosystem, or of = a general
"OCaml experience". This may explain some of the ver= y real usability
issues, but it is also rather unclear to me how this sh= ould be
fixed. Would anyone volunteer for such a role (funded how?), and= to do
what?

I agree with your conclusion that the OCaml ecosyste= m today is
unforgiving, and that it is particularly harsh on non-accompa= nied
beginners. How could this state of affairs be improved?

I th= ink that while a unified vision for the ecosystem may be necessary
to fi= x some of the usability issues (one problem with unification is
that you= need people to agree on it), a large part of the problem is
rather of t= he "death by thousand cuts" kind: small things that add up
to = create an overall unpleasant experience. This portion of the
general pro= blem is both too large for a single person to fix (no one
person can gue= ss all use-cases), it is easily amenable to
crowd-fixing: reporting and/= or fixing issues one at a time as you
discover them. So please keep doin= g that!


On Fri, Dec 18, 2015 at 2:13 AM, Hendrik Boom <hendrik@= topoi.pooq.com> wrote:
On Thu, Dec 17, 2015 at 08:08:35PM -0500, Hendrik Boom wrote= :

And in case anyone wonders, I haven't given up.=C2=A0 I will continue t= rying
to use OCaml becuse it seems to be the right kind of tool.=C2=A0 Not everyo= ne
will be so stubborn,

-- hendrik.

> # Is anyone in charge of the OCaml ecosystem?
>
> I am a beginner to OCaml.=C2=A0 I'm not a beginner to the function= al style of programmins, nor to sophisticated type systems, nor to=C2=A0 co= mputing in general.=C2=A0 I started programming in 1963, was involved with = Algol 68, Lisp, and constructive type theory.=C2=A0 I've managed to get= code running in the days when you had to enter it as numbers; the machine = I=C2=A0 used then wouldn't even type letters other than u, v, w, x, y, = z (its version of hexadecimal).=C2=A0 In those days what you needed to know= was the instruction set and its encoding.=C2=A0 Everything followed from t= hat.
>
> Believe be, I appreciate every advantage high-level languages have to = offer.
>
> With this background, you'd expect I'd take to OCaml like a du= ck to water.
>
> Wrong.
>
> The language itself is actually usable.=C2=A0 Once you figure out how = the syntax works and where to put the brackets.
>
> But the world has changed since source code was in hexadecimal.
>
> ## Libraries
>
> Nowdays, software rests on a huge inventory of libaries and tools.=C2= =A0 A language, however elegant, isn't very usable for anything very pr= actical without its libraries and their documentation.=C2=A0 It's not e= nough to know the machine inside out.
>
> That's the hurdle I face whenever I program in OCaml -- figuring o= ut which libraries are usable, and which are actually documented.=C2=A0 Not= documented in the sense that someone has written an API guide and a tutori= al, but documented in the sense that it is actually possible to find them.<= br> >
> There are often multiple packages to accomplish a single task.
>
> You don't know which one to use.=C2=A0 You try the obvious one, ha= ve trouble, ask about it, and then be told, No, that one is troubled, you s= hould use this other one instead.=C2=A0 The one you can download from *this= * site.=C2=A0 So you do,=C2=A0 You download it.=C2=A0 You figure out how to= edit the Makefile so that it generates the right package files.=C2=A0 The = options you need are actually documented in the Makefile.
>
> I had to compile my own from the original Makefile, using the options = that are indeed documented inside it.XXX
>
> I've actually manged to write a trivial 3D videogame once I was po= inted to the usable OpenGL library.=C2=A0 The one where the function names = were closely related to the ones in the OpenGL manual, of which I have a pr= inted copy.=C2=A0 I didn't have to guess what functions to use.
>
> But then you discover that the one you were recommended to use is in t= he opam library (the one you access by saying opam install ... with a defau= lt configuration), and you decide to simplify things by using the Opam pack= age instead of including all the library's source code within your own = project.=C2=A0 But when you do that, it doesn't work, because the Opam = package was was configured with optons that preclude essential functionalit= y.=C2=A0 (in my case, the ability to load PNG files, not just JPEG).
>
> So what? another might say.=C2=A0 Just tell opam to install with diffe= rent options.=C2=A0 But that is another *huge* problem for a beginner.
>
> So I stick with embedding the library source code in my application.= =C2=A0 I already understand how to edit a Makefile.
>
> ## Documentation
>
> And try to find documentation.=C2=A0 I'm dealing with this problem= m with gtk at the moment.=C2=A0 There's a lablgtk.=C2=A0 There's a = lablgtk2.=C2=A0 Whats the relationship between the two?=C2=A0 And where'= ;s the documentation.=C2=A0 There's links to a tutorial all over the pl= ace, but they seem all to be to the same web page, which isn't there. >
> Opam has a way, I'm told, to install documentation along with the = package, but=C2=A0 haven't been able to figure out how it works.=C2=A0 = Or maybe, just maybe, the packages I've been trying it on don't hav= e documentation.=C2=A0 Who knows?
>
> ## Are beginners even=C2=A0 welcome?
>
> Is there anyone in charge of any of this?
>
> And what's the result?=C2=A0 It's a lovely language, it deserv= es to be used, but to get something done, I find myself programming in C++ = instead, even though the concpts of OCAML fit my style of programming ike a= glove and fit C++ like a rusty nail keeps my hand warm.=C2=A0 =C2=A0Or spe= nd days or months trying things, asking questions, deciphering the answers,= and so forth.
>
> I imagine if I were working in a shop where lots of people used OCaml,= all the ways of doing stuff would be local folklore.=C2=A0 But for the iso= lated beginner, there's a huge barrier to entry.
>
> It's a lovely language, but the pragmatics of its ecosystem are al= l wrong.=C2=A0 For a beginner.=C2=A0 For someone with experience in the par= ticular set of tools and libraries he needs, it's great.
>
> And most of the problem is lack of organised, findable documentation.<= br> >
> -- hendrik
>
>
> --
> Caml-list mailing list.=C2=A0 Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/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.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--001a1133cd00298c58052754bb56--