Re: [Caml-list] how to encourage adoption of OCaml?

[Dean Thompson <deansherthompson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]

Great comments from lots of people.

I am in the mobile app business, so I find myself thinking about this as a conversion funnel:

(1) Some number of people will hear enticing things about OCaml. So Gabriel Scherer’s point is important:

> The best thing I can think of is to communicate more and better, talk about the cool world that is being done in the OCaml communities, and importantly talking about it outside it. Supporting software projects that have a potential for impact outside the OCaml community is also key -- Coq, MLdonkey, Coccinelle, Flow, the SLAM static verifier toolkit, just to name a few.


(2) Once someone realizes OCaml is enticing, they will poke around the web to see what the community looks like. We want to maximize the percentage who decide the community looks solid enough for them to invest effort in learning OCaml. So Duane Johnson’s point, for example, is important:

> In summary, all of the signals that I usually depend on to evaluate the community around a technology are either weak or give me the impression of “old and barely stable". 


(3) Once someone decides the community is solid enough for their purposes, they begin learning. We want to maximize the percentage who have sufficient positive experiences that they decide to persevere. So, for example, Gabriel Scherer makes additional important points:

> Regarding usability, I think the tooling ecosystem is too complex today. If I wanted to bootstrap a beginner to do stuff I would have to tell them about the OCaml compiler tools (ocamlc, ocamlopt), ocamlfind, a build system (make or ocamlbuild for example), oasis, Merlin, opam, and get them to learn either Vim or Emacs.


(4) Further along in the learning process, Hendrik Boom’s points on an earlier thread (for example) are important:

> 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 find them.
> 
> There are often multiple packages to accomplish a single task. You don't know which one to use.

On the more encouraging side, we also have this from Gabriel Scherer on the earlier thread:

> 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.

Is it possible we should be organizing ourselves to map the main flows of the beginner experience, identify the most severe cuts along those flows, and systematically address them? We could start with cheap solutions, like FAQs, and work our way to engineering fixes.

Dean

[-- Attachment #2: Type: text/html, Size: 4574 bytes --]