What are the biggest reasons newcomers give up on OCaml?

Community
61

Just curious, are you referring to installing GTK from these instructions? The GTK Project - A free and open-source cross-platform widget toolkit

62

opam 2.2 will extend depexts to both Cygwin and MSYS2 (pacman). It sounds like lablgtk will need a little .opam tweak to use the provided pkg-config after it is released. For Diskuv OCaml, pacman will be using CLANG64 which (today) is the closest we can get to proper Microsoft compatibility.

Of course. But you don’t need to be a hard-core Windows user (the committed, really commiited Windows users you mention) to tweak your .opam or CI to support Windows. The benefit that accrues to you is a potential doubling of your users. That is no small thing.

3 Likes
63

Yes, and with gtk2 instead of gtk3, since lablgtk is a Gtk2 binding. But Gtk3 is also installed.

64

So I tried that with the Mac. There are two different Mac distros that opam is starting to support, and here’s what I found:

  1. if I do nothing, users whine because the packages I release don’t support the Mac

  2. if I ask them for help in getting things to work, they’re too inexperienced or lazy to do the work. I am reminded of the early days of open-source, when the admonition RTFSC was relevant. Or “Use the source, Luke”. People who don’t know how to read and run Makefiles. The Lazy.

    There’s nothing wrong with being lazy. But if you’re lazy, then don’t expect other people to do your work for you, unpaid. Offer them a fair wage for their hours of work. Or, y’know, get a Linux box.

  3. When I figured out how to make one of the two distros work, people continued to complain that the other distro didn’t work. Jesus, just use the Mac distro that does work, what’s so hard about that?

  4. And thru it all, when stuff broke, I had no way of debugging, b/c I don’t have a Mac, don’t have access to a Mac, and so cannot actually debug a build-failure.

All of that will get worse for WIndows, b/c at least MacOS is UNIX; Windows is some completely other thing.

P.S. the packages in question were literally “conf-perl-*” packages – that is, packages whose content was “install this pretty well-known Perl module”. So it ain’t like what I needed help with was rocket science, and yet, Mac users who used distro X didn’t know how to do that for distro X. I mean, they chose the bloody platform, you’d think they’d know how to actually use the thing.

1 Like
65

Yes, in that course we do cover the unix command shell. Students who know the command shell are not helpless when things go wrong.

66

That’s fair. If you or any other package maintainer needs help getting your package to work with Windows (after the upcoming opam 2.2 is released), perhaps start a thread on discuss.ocaml.org asking for help.

5 Likes
67

Thank you for this! I will keep your offer in mind. This was all I wanted: somebody who wanted something to work on the Mac, and was willing to do the Mac-platform-specific bits (which, as I described, were completely unrelated to the code of my packages).

68

Well, yes. Ultimately most things have a limited number of root causes. Usually lack of resources. But it helps to identify what exactly are the things that are missing before we try to identify where exactly to spend the resources. In our case we know the root cause is ‘no one has put up enough money to get anyone to seriously work on DX especially Windows’. And Jonah made a really good suggestion that people can contribute and pool funds with the OCSF. But we are trying to figure out ‘what exactly would make the DX good especially on Windows’. It seems no one is quite sure yet.

69

I could be wrong about this, but: If there were sufficiently experienced and skilled Windows developers who used OCaml, then they could tell you what was wrong, what was needed. That nobody really knows, means that nobody with that level of experience is actually using it on Windows.

2 Likes
70

This is becoming a discussion about Windows (and Mac) support. Nevertheless, the reality is that the majority of people in the world have Windows boxes. There are countless macs out there. Linux is just a teeny tiny fraction of the desktop and laptop market. If our community wants to grow, and especially if it wants to not disappear, it has to have good support for these operating systems. Fortunately, these things are progressing.

Yes – we’re stuck in a chicken-and-egg problem, because our support on Windows is so poor, that we have very few Windows developers. As our support for Windows improves, we’ll get more of them, and they’ll be able to help other people with similar issues. These are all feedback loops.

How far along are we on that path? @dra27 ?

6 Likes
71

While we wait for an official answer, there was this talk recently: Copying opam switches – it should Just Work™ - Watch OCaml

2 Likes
72

I just want to say thank you for this message @jbeckford, I’m fully behind this. Good windows support means that more people can use OCaml, which will ultimately benefit every platform. It’s important to get out of the mindset that windows support is only the job of windows people.

4 Likes
73

Getting there! Partly, as noted in the Q&A in the talk (assuming that’s on the video), getting OCaml 5.0 of the door was a bigger priority the last couple of months (and the COVID I caught at ICFP really hasn’t helped!).

I’m feeling on track to have the OCaml PRs ready in plenty of time for 5.1’s release cycle - before that, I intend to publish an opam-repository fork which can be used for testing it on the 4.08-5.0 versions demonstrated in the video (I only haven’t done that because the caching mechanism used in September is slightly too liberal with its checks).

4 Likes
74

We do have infrastructure for generating documentation from the source. As an example, from caqti itself, some documentation for one if its modules which is derived from the source. This is all generated automatically for any package in opam, via an ocurrent pipeline.

This is, of course, not at all adequate as you’ve pointed out – there’s no way to automate the writing of beginners guides, tutorials, examples and so on. What it does mean is that when this is done, it will automatically be built and hosted in a central site, which will be improving as our infrastructure improves.

We’re currently working on a feature where you’ll be able to jump to the source (implementation, not interface) from the docs, and also we’re working on improved search, where we’ll be ranking search results based on the uses in other code, so highly used types and values should appear first in search results.

I’m hopeful that these sorts of improvements will encourage library authors to write more documentation for their libraries! There is a lot of information on the odoc website to help people.

13 Likes
75

This looks fantastic @jonludlam!

Have you considered integrating a doctest-like feature (aka “testable examples”) into odoc?

If documenting could be merged into one’s (basic) testing workflow, I’m sure it would encourage even more adoption and usage.

Here are a few implementations of what I’m talking about:

This feature/concept is integrated into the default Go, Rust and Elixir tool chains (not sure about Python which is were the idea came from years ago).

The doctest feature for Haskell is supported by the default vscode tooling and easily integrated into a cabal workflow. It’s very nice to use, and looks like this:

This comment turns into executable code:
image

From the caller’s perspective:
image

This is what happens if I change my function input and click “Refresh” (the feedback is instantaneous).
image

Or clear the line and let the tooling auto-fill the output by clicking on “Evaluate”, similar to a dune promote workflow.
image

2 Likes
76

Yes! I fully agree that testable example stuff is essential. I made a PR to add mld support to mdx to do exactly this a while back, but I’m afraid I got a bit distracted from it and didn’t get around to making the required changes: https://github.com/realworldocaml/mdx/pull/377 - the PR includes an example here if you’re interested in seeing what it looks like. It supports the dune ‘promote’ workflow, so you should be able to edit then dune runtest; dune promote to get the results corrected. I should get back to it!

1 Like
77

does it?

I would rather see it sustain and thrive.

Excessive growth could be counterproductive.

1 Like
78

I’ve been using MDX for tests recently. Most of Eio’s tests are like this, for example:

Some benefits:

  1. You don’t have to write printers for values, because you have a top-level environment with the types from the compiler.

  2. This makes it easy to dump the whole output, rather than just probing a few properties.

  3. The format encourages you to comment the test cases, group them under headings, etc.

  4. If you change something in the code, it automatically generates a diff showing how the test output changes, and you can just choose to accept it (dune runtest --autopromote).

It has some problems too, though:

  1. There’s no support for skipping tests on certain platforms (e.g. for Windows-only tests, or skipping IPv6 tests on platforms without that).

  2. No merlin or ocp-indent support when editing the files.

  3. Hard to see output-so-far if a test hangs (have to hunt around in /tmp for the output file).

  4. Everything runs as byte-code, so it won’t find bugs specific to native code.

2 Likes
79

Yes, it does. First, that is part of the OCSF mission statement: https://ocaml-sf.org/

We collect donations from our sponsors, companies, entities or people interested in growing the OCaml programming language, and redistribute these resources to grow, support and strengthen the OCaml community.

Second, based on the last available survey results: OCAML USER SURVEY

The most voted-for responses for what the community wants the OCSF to work on, are all activities that would grow the community. A couple of examples:

  • Encourage & support OCaml courses for students
  • Promote the language in the industrial world
6 Likes
80

Looking promising :slight_smile:

Do you think this could work with .ml files too?