The problem is that you are going to miss some documentation with that. People already complain there are not enough docs, if the doc website actually eats the little that exist, it’s pretty bad…
Until at least this is fixed I wouldn’t recommend people to peruse the docs there – also the website in dire need of a good ux round, it’s barely usable.
Why isn’t a “blessed” webpage enough for listing recommended packages? Versus a meta package (which would effectively be a second-level stdlib), a web page has the advantage that it can list the “default” recommendation, plus also have commentary/discussion of alternatives. Like what happens here on Discuss but less transitory and ephemeral.
I don’t need a meta-package. I am perfectly happy to go find these packages – search a bit, read doc, look at examples, and decide for myself. But I’ve read enough complaints by enough people who do want a meta-package they could just install, that had a whole shopping-cart full of packages of all sorts, so they wouldn’t need to decide anything.
And who am I to say they are wrong? If we want OCaml to thrive, it needs to be useful to people who don’t give a damn about the things many of us care about. It needs to be useful to people who want to write business software at insurance companies (I’m sorry to say, but it’s true, it’s true). For those people, they need standardization, not diversity.
I mean, I hate dune. I’m never gonna use it: I want Makefiles and autoconf. Period. But I’m not dogmatic, and I recognize that dune is the way that most people-not-like-us will consume OCaml. It is what it is, as a famous not-philosopher once said.
Why not both? Python has a ‘meta package’ (its large standard library) and a webpage (the comprehensive standard library reference docs, replete with examples).
sorry, not saying that web pages and documentation are bad; just noting that they’re not enough for the kind of people that OCaml wants to attract. As much as I hate the idea (and I really do hate it: I railed against the inclusion of XML/XSL and JDBC in the JDK, not that it did any good at all), it’s necessary to have a “single quasi-officially blessed collection” for wider adoption.
One thing I feel pretty strongly about, though, is that that collection should be independently-maintained, apart from the core system. I saw the nightmare of yoking the JVM to … fricken’ XSL, FFS. I mean … madness. Just madness.
One of the things I’m hoping to do with OCamlverse (now that it’s more accepted in the community) is to have a set of recommended libraries. I think that’s a step in the right direction – we don’t want people wasting time on outdated or problematic libraries.
I would like to counter with an argument that has not yet been made by other, more erudite commenters: it is actually not that hard for a relative beginner (of the language, not programming in general) to (sort of) understand the compiler and even hack it for some fun and learning. I don’t think this is necessarily the case with most other languages. So if one is willing to spend some time and effort, many of the complaints could go away. For example this compiler source code browser was made with fairly simple usage of some built-in compiler functionality hooks and addresses the fact that it is not easy to browse compiler code itself with ide features like code navigation and type hints: https://htzh.github.io/browse-ocaml/ While “read the code” is not a beginner friendly advice, with OCaml it is at least practicable.
Regarding the lack of cargo-like tool, I’m surprised no one mentioned drom or spin. What’s wrong with these tools?
My vote is against this. Haskell does that and something I’ve noticed is that many other languages can solve simple example problems in less code that Haskell takes just to list all the imports required to do anything of interest. That significantly eats into the attractiveness of the language to beginners, IMO.
Or I suppose you could just relegate only really specific functionality to requiring imports and provide a chunky prelude so most examples wouldn’t need to include anything. But a chunky prelude isn’t the OCaml way.
Flow from Facebook is a type-checker written in OCaml with amazing errors. Something to check?
opam install drom
⊘ remove ocaml-lsp-server 1.13.1
[conflicts with dune]
⊘ remove fiber 3.4.1
[conflicts with dune]
⊘ remove dune-rpc 3.4.1
[conflicts with dune]
⊘ remove chrome-trace 3.4.1
[conflicts with dune]
⊘ remove xdg 3.4.1
[conflicts with dune]
⊘ remove stdune 3.4.1
[conflicts with dune]
⊘ remove dyn 3.4.1
[conflicts with dune]
⊘ remove ordering 3.4.1
[conflicts with dune]
↘ downgrade dune 3.4.1 to 2.9.3
[required by drom]
This was one I felt too… I had the impression that ocamlformat was probably what the community was mostly using, but I found the resulting style fairly unpleasant to read
Like the previous commenter I have been using ocp-indent instead and am quite happy with it
Yes, some of drom dependencies used to have a useless constraint dune < 3, that was removed a few days ago in the opam-repository, so you should not notice this behavior anymore after performing an opam update.
Ah thanks, today it does the job.
From my experience it comes down to one’s taste. From time to time I come across ocaml projects that are formatted (by hand) in a really weird way and I already know that trying to get the maintainer to adopt ocamlformat is not going to go well, they would probably defend their style as being the mainstream one an that ocamlformat should cater to their style.
In the meantime if you witness something that should be improved in ocamlformat don’t hesitate to open an issue.
These are also the projects where when you contribute your PR is gonna get a ton of comments about formatting.
While I don’t think the style ocamlformat outputs is the way I would format myself, being able to write code whatever way and calling dune fmt to make it consistent (and being able to put it in CI) has been an absolute game-changer. Formatting code manually feels like such a chore, and ocamlformat gets me one step closer to my dream of “structured editing” where I work on the AST and ocamlformat just prettyprints that AST.
Well, I’m maintaining a project that does not use ocamlformat or any other automatic formatting tool, and I wouldn’t defend my style as the “mainstream” one. Because I don’t think there is such a style. Nor do I find the lack of a mainstream style as particularly bothersome.
What I do think is that automatic formatting tools that insist their opinions about good style should be made universal by fiat are a bad idea to be resisted.
And that’s why I’m not rushing to adopt one.
And it’s bad because formatting is information. Automatic formatting based entirely on AST means losing that information, or having to replace it with harder to process constructs such as comments, which makes code harder to understand.
That’s not to say it might not be a trade-off worth making in many situations, or that you can’t mitigate some of the information loss by preserving blank lines, for example, like many formatters do. But talking about formatting solely in terms of styles and whether or not one automatically enforced style is better than another is missing the point by a mile.
Preface: I maintain camlp5. Which means I program in an alternative syntax for OCaml all the time (the “revised syntax”). So I’m speaking-up for a rule that I regularly break, and can see the cost of that breakage.
Automatically-enforced style, like other syntactic rules, is of great utility in making all code readable to a uniform standard. The Google C++ Style Guide is a great example of this: it has all sorts of rules for what some might call niggling syntax issues: stuff like sorting the #include declarations, all in service of establishing a uniform standard for code so that when you come to a new piece of code, you can understand it with the least amount of cruft getting in the way.
This is valuable in C++ (and the other approved languages at Google), and I think valuable in OCaml too.