Bear with me if I speak for myself and my goals which may be different from yours. That’s variety best served by different tools. Sure you can use OCaml, why shouldn’t you. But no community is responsible providing a library in the language of your choice and your purpose for you.
But why don’t you want to use node in the first place if it solves your problem at hand? What’s your problem with node? Use OCaml where it shines and for the properties it has. IMO it need not excel at throwaway sprints. If it does what others cannot, it may fall behind with what others can. Do you know what I mean mentioning mirage and TCB?
It’s not your exact wording but it’s the end result that matters. This was my exact point–you are very fixated that it should not be too ‘attractive’ for ‘everybody’. Everybody? OCaml has been struggling to attract a community for a long time now, and meanwhile language communities have zipped past us and shown us how to do it right. I’m not even talking about Rust–look at Elixir for a great example of how to build up a community and ecosystem, by caring about developer joy. Or even look at F#–it’s what people compare OCaml to, after all!
And by the way, these are super-smart people, but their goal is not to learn the intricacies of package managers, build systems, and their interactions. Their goal is to get their work done. Even they can only do so much!
that’s insulting, right? Fixation is a mental disorder you label me with.
The second is a tautology, being too X is always a bad thing, isn’t it? Even being too nice. The quotes ridicule them. Please sport friendlyness and precision in discussion.
A last thing: if super-smart people demand empathy without having contributed a thing I’m not impressed. No matter how large their companies and numerous their followers may be. However, I am impressed by 25 years of OCaml or Is rescript damaging Ocaml ecosystem? - #27 by mars0i.
If we come to think of OCaml as a product and users as customers, then we will be locked in a struggle for market dominance and we will try to compete with other languages. I think this would lead us to fall into the same trap that is driving all the structures in our civilization towards the deadly embrace of addiction to exponential growth.
Instead, I hope we will think of OCaml as an ecosystem. Then we’ll aim to maintain its current health and sustainability, and protect the diversity and life that is already at home here. But we will also strive to provide more fertile grounds for diversity (which entails diversity of uses and users and, principle among many other things, concern with accessibility, in the sense of empowering those with relative disability). We should also look to build mutualistic systems of exchange with other ecosystems. But above all, I think this calls for maintaining healthy (and kind) relationships between the various people and organizations within the ecosystem. I think this is what allows new entrants to the ecosystem to find a safe place to take root.
I believe that the best thing we can do to expand the appeal of OCaml in a way that is healthy and sustainable is to continue to nurture, cultivate, and protect the ecosystem. This should definitely entail being compassionate and responsive to the difficulties people face! People who are in this ecosystem, or who want to be, obviously encounter issues with documentation, familiarity of tooling, etc. But we can justify and motivate the repair and improvement on this front without orienting everything to the aim of scaling up or improving our marketing.
This is enough: People need help. Let’s see what we can do to help them!
I am not labelling you with a mental disorder. The word also has the meaning ‘focused on a specific topic’.
The quotes indicate that they are quoted verbatim.
Anyway, I see we have reached the stage where every single word is being examined and nitpicked for ‘precision’ (use of the word ‘too’), while ignoring the actual relevant issues. I agree with Shon, it is time to end this discussion.
There are libraries and then there are libraries. For problems requiring enough domain expertise the effort to create and maintain a high quality library can be comparable to a programming language and it is no coincidence that they often and/or only exist as C/C++. If I were to write one I would like the greatest number of people to benefit from the effort as well. Well OCaml is as good as any other language to leverage C/C++ libraries. Then there are problems like “read the whole text file into a string” that do not make into the Stdlib but are easily solvable (with the first attempt being correct thanks to the type system). It is the in-between that could benefit from more users. Even an abandoned/unmaintained effort at solving something can be educational for a new entrant. And more users lead to more such attempts. But I think it is unrealistic to expect quality documentation in these cases. Instead what if we have tools that make reading source code easier? Source code analysis/transformation is what OCaml excels at, after all. Can we make it even more accessible? Like provide a Merlin like experience directly off the opam repository: you can browse the code off the web with tooltips showing you type annotation everywhere and let you jump to definition/declaration (even across projects!). All the information are already there in the builds. We just need a good interface. This is something that everyone could benefit from, not just new developers.
As an example of what I am getting at I did something for the OCaml compiler here. It is basic and incomplete but it is already helpful to my effort of trying to understand the compiler better. I think it is more profitable to work with human nature. Even the compiler has many un(der)documented features. At the same time it is the most hackable/accessible compiler anywhere. Let’s use the strength to benefit ourselves.
This is a very good explanation about the libraries problem and some good examples of interesting things to do.
Answering @shonfeder, I think the libraries (from my JS dev point of view) is something that easily grows exponentially. The more low level libraries you have the easier is to build greater abstractions on top of that and then on top of that. If I had a good Gzip library and a good XML parsing library, then creating a KMZ library will not be a lifelong task compared with having to write code to read compresses files
If I had a good Gzip library and a good XML parsing library, then creating a KMZ library will not be a lifelong task compared with having to write code to read compresses files
