One small example: if you go to https://ocaml.org/api/ you are redirected to https://v2.ocaml.org/api/ (why? the new site is v3…), and the modules are ordered in seemingly totally random order. Every time I go there, I spend a few seconds fooling myself thinking I can just scan the page to find the module I want, then give up and use the find-in-page command.
3 Likes
That is not a good starting point. You should be offered an option not to use ocaml if you don’t like it.
This kind of OCaml sucks rants is at least a decade old. I don’t think the future of ocaml depends on such rants. OCaml is still there and improving, ocaml future is as promising now than ever. Of course i forgive you : you shouldn’t be forced, you should be free. OCaml will improve but never to the point you will love it. OCaml sucks doesn’t empower you. You should claim your freedom, as a student please give me alternative courses, as a programmer job please give me a place where i feel better.
7 Likes
I think this is worthy of more than a side note. The criticisms provided are only half true throughout, and the choice of handle combined with repeated hyperbole (X sucks, Y sucks, Z is dumb, etc) makes the whole thing function as a bad faith hit-and-run IMO.
There are many very valid critiques to be made of OCaml, but ~this~ (gestures wildly) is not one of them. I think it’d be 100% okay if the admins killed or hid the topic entirely.
7 Likes
Thanks for all the answers 
Sorry if I offended anyone, I initially wrote this to myself as a bunch of notes, and then decided that it might be useful for the community and didn’t want to edit it too much. Obviously some people can’t see past the name of the account, or the writing style, but in the middle of my “it’s hard to get used to FP” I think there’s some real feedback that needs to be taken if we want to see OCaml succeed.
OCaml is not a new language, there’s a lot of people contributing, but IMO the contributions are not efficiently targeted. What is important, is to attract and retain new developers. New developers will contribute to the ecosystem by building tooling, and wrappers around dune/opam, and good libraries, etc. But to get new developers, you need to care about OCaml like it’s a “product”. You need to match what others offer today: an attractive website, attractive docs and resources to learn, good tooling, good error messages, good defaults, etc.
7 Likes
But to get new developers, you need to care about OCaml like it’s a “product”. You need to match what others offer today: an attractive website, attractive docs and resources to learn, good tooling, good error messages, good defaults, etc.
Making things attractive and easy has been a clear focus for a while. Recently the website’s even shifted to trying to sell the language to management rather than only taking hackers as their audience. You’re dissatisfied with dune but if someone spares you from reading the documentation and gives you steps for what you want to do, they’re very modern steps to follow, very comparable to cargo and the like. When I first tried to learn OCaml I was writing Makefiles and trying to remember when to include unix.cmxa in my arguments.
current website: https://ocaml.org/ (v3), " General-Purpose, Industrial-Strength, Expressive, and Safe", “Trusted by Industry Leaders”, big picture of attractive-looking code (that is trivial math and factorial for some reason), scroll down for huge salespitch
2015 website (v2): https://web.archive.org/web/20150901011336/http://ocaml.org/ , just the slogan for a salespitch, wall of links, picture of attractive-looking code (that is defining a binary tree and some operations on it)
2011 website: The Caml language: Home , very attractive picture of a camel, and I think there’s a hidden excerpt from the Koran that praises the good design of the camel.
The docs are also more attractive, and easier to search, and accompanied by more tutorials, exercises, etc.
2011’s “Comprehensive documentation” page: Documentation
current ‘Learn’ link: Learn OCaml
What’s interesting to me is what hasn’t improved in all this time: the actual documentation.
I even much prefer the looks and readability of 2011 Printf over current OCaml library : Printf . But no prose has been added, no examples have been added. In 11 years the documentation hasn’t changed at all, but is slightly more annoying to read, and in both respects it’s completely blown away by Rust’s std::fmt - Rust
Error messages have not changed much for an outright syntax error:
The Objective Caml toplevel, version 3.12.1
File "fact2.ml", line 10, characters 4-5:
Error: Syntax error
vs.
The OCaml toplevel, version 5.1.0+dev1-2022-06-09
File "./fact2.ml", line 10, characters 4-5:
10 | !result
^
Error: Syntax error
But dune turns on a bunch of warnings by default that make the compiler feel friendlier.
8 Likes
Maybe Printf’s documentation hasn’t been improved (which is a shame, although Format is arguably more useful and uses the same format strings).
However in this recent post there was mention of funding being used to add many examples to the documentation (using this PR as an example). Also, improving the manual is possibly the easiest way to contribute to OCaml itself; I’ve heard it, and it also matches my experience.
3 Likes
I wasn’t hunting for an example of forgotten documentation, I just picked Printf at random. There’s 2011 documentation for Format and it also looks very similar to the current version. Reading it again now, I’m able to spot very helpful passages like
You may consider this module as providing an extension to the
printffacility to provide automatic line splitting.
and (emphasis added)
The format string
fmtis a character string which contains three types of objects: plain characters and conversion specifications as specified in the Printf module, and pretty-printing indications specific to theFormatmodule.
and in the tutorial (emphasis added)
In addition to the usual conversion facility provided by printf, you can write pretty-printing indications directly inside the format string
But my actual experience with Format not to long ago was this: I saw someone say that Format should be used instead of Printf, and I went to these docs, and I was completely baffled as to how I could print anything at all with Format. There are no trivial examples like Format.printf "n: %d" 22; the only format specifier mentioned in prose is %a where it isn’t explained. The documentation is (naturally) completely focusing on Format’s innovations which are all about pretty-printing and automatic line-breaking, and since that wasn’t what I wanted to do (I just heard “Format’s better–use it instead”) I skimmed those parts, concluded that it was necessary to use @[..@] somehow to print normally, and got distracted so much by those characters that I missed this useful example:
printf "@[<1>%s@ =@ %d@ %s@]@." "Prix TTC" 100 "Euros";;
Prix TTC = 100 Euros
- : unit = ()
Imagine this experience: you ask, “how do I do formatted output or string interpolation in OCaml, like printf?” You’re told: “the Format module does that.” Great! You go to ocaml.org → Learn → Standard Library API, and right at the top is “Format_tutorial”, so you click that.
Then you read the format tutorial: “Principles. Line breaking is based on three concepts: boxes: …” … ---b---b … “Print spaces” … “Indentation of new lines” … oh it’s pretty-printing nested parentheses, that’s cool … keep scrolling while looking for code, finally find “A concrete example” … give up. Conclusion: OCaml doesn’t actually have a feature like printf().
8 Likes
What? That’s … not what I’ve ever understood. Printf implements printf, and sure, Format has a version of printf, but that’s not what it’s really for. Format is for Oppen-style pretty-printing, and unless you know what that means, you shouldn’t be using it.
Where did you read that Format was the thing that did printf ?
ETA: “Oppen” as in Derek Oppen.
1 Like
Another “what I dislike about OCaml” post from reddit (original post) by PurpleUpbeat2820:
- Compilation in VSCode and batch compilation produce different errors.
- Changes in one file aren’t reflected in other files until I batch recompile from the CLI and edit the file.
- The REPL in VSCode regularly crashes.
- Pasting any significant code/data into the utop REPL is grindingly slow.
- No more built-in Camlp4 which was great for writing parsers.
- No JIT so the REPL is grindingly slow.
Opam is also pretty buggy. This discussion prompted me to try upgrading to OCaml 4.14 but that broke it.
This one is less detailed and structured than @throwaway’s post above (thanks!) but I think it may also contain valuable feedback.
In general I try to use this sort of feedback to generate ideas of specific things to do to improve on the criticisms. Pick a point, wonder how it could be improved (“solving the issue completely” is rarely a realistic goal), and see if you can lend a hand in working on that.
For example, there is a discussion that the OCaml compiler error messages should be improved. Here is a low-hanging fruit. @EduardoRFS has a Pull Request to introduce more formatting in error messages. There was a disagreement about which color scheme to adopt, but there is consensus on having types displayed in bold, to stand out of the rest of error message text. It should be a relatively simple change to make, especially if you start from Eduardo’s existing code.
(Note: if I remember correctly, color in error messages was originally introduced by @c-cube. Thanks! Several people worked on compiler improving error messages, including @Armael, @octachron, @Drup, @lpw25, Antal Spector-Zabusky and myself. I’m hoping that we will eventually get a nice contribution on syntax error messages from @let-def as well.)
4 Likes
Reacting to @c-cube’s post with a tangential mention of the OCaml Software Foundation: indeed, this sort of feedback touches many of our core goals. (How to make OCaml more pleasant to use? How to attract more people into the community? Can we grow a healthy ecosystem where people contribute without risk or pain to solve these problems?)
We have funded several actions to improve user experience, documentation etc., and tried even more. It is surprisingly difficult to solve those problems with money: many people with the skills and interest to improve on this already have an employer and are not interested in extra funding, or don’t accept funding for other reasons.
If you know someone that would be qualified to work on a specific topic around this, and would accept our funding to do so, please feel free to send me a message / email.
Note that even when we do fund someone, their contribution is going to be handled, reviewed by many other people, so there is volunteer work involved all over the place. I think we can hardly avoid this for such “thousand paper cuts” problems that require small fixes all over the place. In my opinion the way forward is to encourage everyone interested to do a bit to improve things, in addition to funding key projects or targeted actions that are outside the reach of goodwill hobby hacking. We have had very nice improvements thanks to the involvement of a not-so-large set of people, and I think we can do even more by growing the base of interested caretakers and/or making it easier for them to contribute.
9 Likes
Are the plans to add a machine-readable format for compiler errors?
It will help with editor integration if nothing else.
1 Like
It’s already there if you use LSP. LSP gives you error messages and much more
2 Likes
There is an in-progress PR implementing the basics of JSON output for compiler messages. One reason it is not making progress is that there are in fact few interested users of the feature – most projects that are programmatically calling the compiler already have worked around their own way to do this, and do not seem so interested in rewriting their code to use a new approach or even in giving us clear feedback on what they need.
2 Likes
For the JSON-formatted error messages, I had some feedback that at least @rgrinberg and the lsp-server would be interested, at least partially to have an easier way to segment error messages in submessages.
That would be a start. As of today, editor tooling has the following requirements from error messages:
- The ability to extract sub messages and their locations
- Preserve formatting metadata. That means NOT rendering boxes, wrapping, colors.
- A way to identify the type of the error without parsing the error message to offer users context specific suggestions on how to fix the error.
- A way to compare two errors for equality to deduplicate errors coming from dune and merlin.
I hope this feedback is clear enough as to what our needs are.
I shared my take on the very problematic nature of this POV not too long ago:
There is so much we want to do: to improve our community, to further the development of our common language, to build out our tooling, to make our culture more inclusive and inviting, to strengthen its mutualistic connections with other communities… So much to do, and so little time in this fraught world.
Having granted that there is very much to do to nurture the OCaml ecosystem and confirming that it is well worth doing, I’d also like to remember that successful technology and communities ought not have size or popularity as their primary measure. There are many amazing technologies that provide high value in very particular niches (to name a few Prolog, Z3, Mirage) and there are many healthy and vibrant communities that do not end up becoming massive trends and contending domination in the world mono-culture (and I’m not sure how healthy the communities are that do end up contending thus).
I was inspired to add this delayed reply by the following photo of a slide from RustConf:
https://pbs.twimg.com/media/FZaa6ObUEAEEED_?format=jpg&name=large
11 Likes
IME when people say ‘think of it like a product’ what they really mean is ‘think of the UX/DX’. If we were actually thinking of it as a product we would be asking what’s the marketing budget. What we’re actually talking about here is how easy or difficult is it for people to use? Of course after spending enough effort and training on something, anything can become easy. But what’s the activation energy required to get started with the OCaml toolchain? That’s the critical question.
2 Likes
They mean something more: they really mean “think of the UX/DX for newbies”. And sure, that’s important. But (for instance) I’m not actually very impressed by Rust’s Cargo. I mean, it’s a single unified tool, sure that’s great. Which means that it incessantly (and I mean incessantly) recompiles dependencies. Every damn time I switch from cargo build to cargo bench or maturin develop (I develop a lot of code that gets wrappered by Python and maturin is the tool for that – gosh, more than one tool! Get me my fainting couch!) it recompiles everything in sight.
I much, much prefer the split between opam and whatever per-package build-tool you use (I prefer Makefiles to dune – don’t @ me unless you’re ready to bring your A game). And maybe there are some problems, in which case, sure, show 'em, maaaan.
To go back to a refrain from my Golang comment elsewhere: none of us actually knows what big companies that use these languages do for tooling. But we know that (for instance) at Google, they use bazel (called “blaze” internally), and that it’s very different from all these other build-tools. It’s great, just great really, to provide these little shiny toys for newbies to use. Sure, great, have at it, kids. But I’m a professional, and I don’t build toys. So I want professional tools, and professional tools scale to large projects and to complex multi-language projects. A package/build-system that doesn’t allow me to step in and do that, is going to get in my way.
I actually think OCaml’s opam/dune design is excellent in this regard.
6 Likes
And that’s exactly the problem. Simple things are difficult because the tools insist that they want to handle large-scale use cases from day 1. They force the newbies to have to care about the things that the experts care about. This is not a great UX.
Forget about Rust for a second. Look at Go’s UX. I do go mod init to create a project, just start importing and using modules in my source code files, then run go mod tidy to download, cache, and checksum them all in one shot. And it even works beautifully for reproducible builds and CI from day one, because it produces a go.sum lockfile with not just the versions but also the hashes of all the used dependencies. I don’t have to worry about opam files, dune-project files, dune files in each directory, and trying to figure out how I’m going to set up switches and lock the dependency versions.
I’ve said this before but I really think we can learn a lot from Go’s tooling and attention to supply chain security. I wouldn’t even mind a build system that forced me to declare my library dependencies at the top of each OCaml source code file.
EDIT: I’d even go further and say that, in retrospect, tools which try to cater to primarily expert use cases are taking the wrong approach. Experts will just use findlib and Makefiles, as you yourself have proven. The whole point of tools like this is to cater to non-expert use cases.
2 Likes
This is a fair cop. But I would add that opam does an excellent job of managing package interactions and evolution. I had a bad experience with Rust early-on, where some Rust package C depended on B, which depended on A, in ways that made B break when A got a new release. This was pretty unpleasant, and what was more unpleasant is that there was no way to force the version of A selected, to be a backlevel one.f
The opam maintainers and their discipline (which they enforce on all of us) makes the opam repository the closest thing I’ve ever experienced, to a massive mono-repo.
That’s valuable, and I wouldn’t want to give that up. Having experienced Rust’s “crates”, I’m even more adamant on clinging to the stability of opam-repository.
3 Likes