TLDR; I can’t say that my initial experience with OCaml was mind-blowing, but it was definitely pleasant and with time the language grows on me. I miss the simplicity and uniformity of Clojure (still my favorite programming language by far) and Lisps in general or some of Haskell’s goodies (e.g. typeclasses, Hackage and ghci), but I feel OCaml strikes a very good balance between functional programming, pragmatism and performance. It’s a fun language to work with!
I’d be really curious to hear your own thoughts on the subject and to receive feedback about any mistakes I might have made due to not being familiar enough with OCaml and its ecosystem.
Exactly the kind of thing newcomers or casual users would absolutely never know unless they did a lot of research.
Indeed! Clearly finding the right libraries is not trivial in this case. Hopefully the situation will be improved with time.
Yes, seconded - even as someone who’s spent more time with the OCaml ecosystem, when I’m exploring a new domain, the process of finding an appropriate library to handle a new task is quite arduous.
I’d say the development tooling for OCaml is pretty decent, although I wouldn’t go as far as saying it’s great.
Finally, a shameless plug, if you’re more familiar with lisp development tooling, have you tried gopcaml-mode? It provides paredit style structural editing support for OCaml:
Well isn’t that the case in any language ? I would even say that, in OCaml, options being quite limited, it’s rather the opposite :–) Try to go find a library appropriate to handle a new task in the JavaScript eco-system…
I love to see this; aside from ocamlearlybird integration, this kind of structural editing support is (IMO, obviously) easily the most impactful thing that could be added to the vscode support.
To clarify, the challenge is just the lack of much discussion on what exactly should be used.
In the case of Javascript, I’m not that familiar with the ecosystem, but I assume that if I searched for “how to handle <…X…> in JS”, I’d be hit with a plethora of blog posts and opinionated articles on why some particular library or another is the one that I should use.
Granted, this in itself can be confusing, but after reading an article or two, I can usually come to a conclusion about which library would be best suited for my particular case.
For OCaml, given it’s a smaller ecosystem, naturally it’s unreasonable to expect the same level of resources being available, but it would be nice to have some kind of consolidated place to find which libraries are recommended to be used (I guess I haven’t checked it in a while, but I guess the OCamlverse does kind of fit this need already). I usually just search through the OCaml discuss to find previous discussions to help choose libraries, but this isn’t really scalable.
Not sure how that’s really different from asking or searching on discuss for advice and how this particularly “scales” – especially in a world where software tooling is now largely marketed rather than objectively assessed.
To take the particular unicode example. If you do opam search unicode and filter out the obviously irrelevant results you will end up with 4-5 items to review or ask for on a venue with OCaml programmers.
I don’t want to drag this discussion further but in these newcomer posts I always try to sort out the objective problems intrisic to the eco-system from the problems and feelings everyone has when you dab into a new territory. Regarding this particular one – that is “which library should I use for X” – it’s not as if I don’t have exactly the same one whenever I dab out of OCaml land.
I would like to extend this point of view with my own. A fragmentation of the ecosystem over several libraries remains for me a very good approach in the long term where the choice of the users is built not on “trending” which would force us to make only “default” choices but on a pro-active approach which implies a small learning curve and which, above all, results in the empowerment of the user on his choice - which for me, remains essential in the design of a software.
There are always several approaches to solving the same problem and the multiplicity of solutions basically pushes us to refine the problem to learn, understand and finally be aware (with all that this implies) of our choice. This may take more time, it certainly requires more effort, but this approach makes us less prone to software entropy and a multiplicity of levels that ultimately leads to a disempowerment of bugs and security holes (because we no longer know who or why we made a particular choice).
More broadly, a monopoly situation of one library on a given problem (and therefore the default choice) is never a good thing for a given ecosystem .
obvious once you know the spell – and extremely hard if you don’t. That’s why I love such posts and articles that just tell how one did it. Blog your examples. Spread them here.
I don’t want to drag this discussion further but in these newcomer posts I always try to sort out the objective problems intrisic to the eco-system from the problems and feelings everyone has when you dab into a new territory. Regarding this particular one – that is “which library should I use for X” – it’s not as if I don’t have exactly the same one whenever I dab out of OCaml land.
I respectfully disagree. My point here is that you have to turn to external libraries even for things that are normally built-in in most languages, which means more learning overhead. More learning overhead means that newcomers would be more likely to stop learning, if they are not very determined. E.g. I can’t recall when was the list time I needed to look for an external library for regular expressions or when I was suggested to replace the standard library of language completely with some 3rd party alternative. It’s no accident that newer languages focus so much on newcomer experience - that’s how you build a healthy community. That’s the message I’ve been trying to get across.
The above for me is way more important than potential discoverability improvements for 3rd party libraries (even I think there’s plenty of room for improvement there as well). I learn new languages often and I know how to search for stuff, but let’s be honest - in certain ecosystems that’s easier than in others. Let’s revisit your example of opam search unicode. Here’s a small part of the output:
uucd -- Unicode character database decoder for OCaml
uucp -- Unicode character properties for OCaml
uunf -- Unicode text normalization for OCaml
uuseg -- Unicode text segmentation for OCaml
uutf 1.0.3 Non-blocking streaming Unicode codec for OCaml
uuuu -- Mapper of ISO-8859-* to Unicode
Do you seriously believe that most people would figure out they need something that does “Unicode text normalization/segmentation”? Or that they will start checking every library on the list that seems like a potential solution for their problem. 90%+ of all people will google for their problem and if the first results they get are not what they need they’ll likely drop the topic and move on. That’s the world we live in these days. I myself googled for “working with unicode strings in ocaml”.
Yeah, many newcomers fret too much on “imaginary” problems that are present everywhere, but I do think the problems I highlighted are kind of specific to OCaml.
More broadly, a monopoly situation of one library on a given problem (and therefore the default choice) is never a good thing for a given ecosystem .
No argument from me. However, my point was more in the spirit of we need something good out of the box (robust and feature rich standard library), and/or at least one high-quality 3rd party alternative/complement. Some guidance in the learning resources on such topics is not a bad thing IMO. E.g. If I find 20 testing libraries I’d appreciate some recommendations to pick 2-3 to try, instead of investing a lot more time to go over all of them and examine them myself. It’s a matter of respecting the (limited) time of the people who are exploring your platform/tools.
In the particular case of Unicode that is not really true.
If you take go as an example, it provides the same string model as OCaml does (sequences of bytes) aswell as UTF-{8,16} codecs, which the Stdlib now also fully provides.
Beyond that it seems the only thing it provides over what OCaml does is this outdated (Unicode v13.0.0) random selection of Unicode character properties – for that you will need to use uucp (which is not outdated).
I seriously think that if you know what you are doing that provides you with an excellent answer.
That’s maybe the problem, what is your definition of “working with unicode strings in OCaml” ? As far as Unicode processing is concerned this is a very vague request.
IMO, there are two, distinct, conversations happening.
Given that not everything can be built into the stdlib, if one is looking for a library to solve a problem, how hard is that?
How much should be in the stdlib?
I believe that @dbuenzli is saying that (1) is the same in most languages, and arguably harder in JS because the churn on libraries is much larger than Ocaml, finding the library you should use may be no easier in a more popular language than in Ocaml.
Discussion (2) has happened a lot and the conclusion seems very heavily to rely on third party stdlibs. No amount of appeal seems to be able to change that. If one wants to change that, they should find a new tactic.
Indeed. Nothing is stopping the community from coalescing around a set of specific libraries and defining a single “meta-library”, say kitchen-sink, that would have them all as dependencies.
This library would represent the community consensus of what should go into the standard library and one could answer to the perennial beginner question of which libraries to use to just “install the kitchen-sink”.
Of course, such a project would have to make some tricky choices (lwt or async or …, base/core or containers or …, etc), come up with a versioning story, deal with style differences between the different libraries, etc. All in all, a lot of work, and probably not everyone will be satisfied in the end
The reality is that aside from stronger introductions to the language itself, we need a lot of material helping people solve domain-specific problems that they will encounter in the real world. OCaml’s 3rd-party libraries are inconsistent (as are all 3rd-party libraries), and the more material we have guiding people with up-to-date solutions, the better off we’ll be. The hard part is that unlike the language itself, one needs to have domain-specific experience in order to document these things better. I welcome contributions to ocamlverse in these aspects.
Agree, it really is just more guides and documentation. The tools exist to cover 80% of web development.
My running list of deps for the run of the mill api application so far: caqti, jose (jwt), dream, the aws ocaml sdk, alcotest (or the new one from the tezos team), cohttp.
Aside from specific domain, having a set of web dev tools that mirrors elixir’s offerings feels like it’d serve 80% of the usual web application work: auth, sql, cloud sdks, http clients, test lib. I’ve also successfully worked around the lack of certain libraries by leveraging aws lambdas for specific node libraries (from elixir, yet to use ocaml for any company work).
Hopefully the ecosystem also converges on eio, or enables easy interop over time.
IMO, before we can say what “we need”, it might be useful to define who the “we” is and why it’s “needed” (what is the goal?). Rust has come up here a few times here and it has a pretty strong culture of trying to do the best it can for developer experience (error messages, being one example, as well as maintainers taking feedback from developers). There is an organization around Rust that deals with everything from docs to stdlib to compiler to outreach. It’s fairly organized. C, on the other hand, is very much “every developer for themself”.
The most official Ocaml “organization” I’m aware of is the compiler team, and, again, AFAIK, they just deal with the compiler. They control the stdlib as well because that comes with the compiler. But a lot of decisions are rationalized by if it suits the objectives of the compiler team, and their objectives are not necessarily language growth.
My point is: there is often a discussion here where those that want to do things to promote the language assume that is the goal shared by others. I believe this is why discussions are always about what we “need” to do and not status updates on if it’s being executed. Perhaps those people who find it valuable are enough to sustain it, but perhaps it’s also worth taking a different approach.
One approach could be to just accept that this isn’t a shared goal, take it on one’s self to do what they can to achieve their individual goal. I think people are grateful for any improvement in docs and outreach even if they don’t prioritize it. Another approach would be to get organized. Try to make official ocaml organizations with explicit goals that they act on built around a shared objective. For example, maybe the Ocaml stdlib would grow if there was a structure in place to ensure there are developers for it outside of the compiler team, and at the same time the compiler team would have to be OK with giving that responsibility away.
I would love to create an OCaml Ecosystem team that emphasized open processes and OCaml’s growth. I just don’t know if there are enough people who are interested.
.