@mro Would you like to expand a bit?
sure, which aspect? Here or elsewhere?
Iâm curious about the concerns you have. What kind of negative effect do you expect if ocaml becomes more widely used?
I spent time in the belly of the Java beast 1996-2008ish at IBM, and I think I can speak to some of this.
Javaâs evolution was hijacked by corporations, and by the architects and technologists at those corps. It suffered as a result (I have lots of receipts). If that happens to OCaml, yeah, itâd be pitiable. But I take the counter-example of Perl (or, heck, Python): widespread adoption doesnât need to inexorably imply control by some corporate cabal.
Some receipts:
- the way that the JDK contains so much stuff that really ought to be separate libraries
- the continued unavoidable JIT
- the lack of any sort of compile-time modularity (as compared with the CLR)
- The high initial memory and CPU footprint of the JVM
Nobody can imagine writing tar(1) as Java and having it be credible. But one can imagine writing it in OCaml. I wrote zip/unzip in OCaml and it was quite credibly fast and light, where a Java implementation of Jar is a ⌠pig.
I could go on and on ⌠but really, these are all ramifications of the decisions made by the Java consortium: by corps.
A simple one is the signal-to-noise ratio online. The more popular a language is, the more difficult it is to find good answers to your questions and separate the wheat from the chaff.
A simple one is the signal-to-noise ratio online. The more popular a language is, the more difficult it is to find good answers to your questions and separate the wheat from the chaff.
I partially agree with you, but if a language is less popular, youâre the first person who faces your problem, and you should answer your question by yourselfâŚ
I think that youâre the exceptional developer in this case. Most of the time from what Iâve seen, a project gains traction and users, and then it seems worthwhile for someone (sometimes the original author) to write heavy documentation. Of course, if the author is willing to put in the effort, thereâs a much better chance that the users will arrive. Itâs all ultimately feedback loops, as a good-looking, well maintained project will attract more users all other things being equal. Itâs also possible that standards are changing for the better, and that given CI and github-pages availability, itâs become easier to get projects into a position where theyâre more attractive to users.
I donât think Iâd be generalizing too much if I said that most developers dislike doing documentation and prefer to just focus on development. You often need a sufficient developer base often just to get those one or two people who are willing to put effort into the documentation (and who are sufficiently good at it).
If thereâs a lot of signal-to-noise and there are many users, youâll also get enough smart users who wish to cut through the noise and their answers will be upvoted. Itâs always better to have a popular language: a bigger ecosystem means more libraries are readily available; more experts are available; the language has been used to do more things; itâs easier to get jobs; itâs easier to find solutions online; etc. A small language with a small ecosystem is always in danger of dying out once enough people abandon it.
Most importantly, language ecosystems are driven by a feedback process. That library someone made today that you donât happen to care about will bring more people into the ecosystem, and it may have components that could be used to create something you do care about tomorrow. Every little improvement helps. Itâs like gaining interest on a savings account.
To add to this: Perl never suffered from this S/N ratio problem, even though it was immensely popular in the early days of the Internet. Neither did Python. There were always more-trusted sources to rely upon. For example, people are always going to pay more attention when @dbuenzli speaks, b/c his code is advance publicity for his words.
Thatâs right and correct.
Indeed and thatâs what I consider very much the most appealing â having exceptional community members! OCaml has a lot of them. Thatâs much more than a streamlined onboarding experience or test and code formatting baked-in (as awesome as Go or Elm may have it). Or even a modern standard library with Quic etc.
And the exceptional community (you, we, me, everybody!) has not happened by chance, but by decades of being serious about elegance and reliability.
So I find the initial question about âexpandingâ misleading as it has a side-taste of some lacking â which doesnât resonate with me.
Itâs interesting that you would say this. I was actually specifically thinking of Python as an example here, which I worked with for probably somewhere around 15 years. As Python became increasingly popular, I found it increasingly difficult to find answers to questions because web searches would turn up so much that was only tangentially related, if at all. Same for quality material (both on- and off-line) because so much was being published and most was mediocre, even when written by prominent members of the community.
Itâs curious that we would have such different views here. Mine is from the perspective of someone who programs only occasionally. I definitely found that over the years, it became harder and harder to find quality material/references/resources for Python. Not that it didnât exist but that there was so much more muck to trudge through first.
I feel the same way about R today. Itâs popularity means that whenever I forget how to do something or need to find out if some procedure exists and where, thereâs just a ton of half-baked, incomplete solutions that I need to filter out first.
Iâm not saying that it wouldnât be beneficial to grow the OCaml community. But I donât believe that to be unambiguously positive. And I donât believe that communities are necessarily self-correcting and meritocratic. Not that we need to worry about OCaml becoming as popular as Python. (But what do I know? I was also surprised when interest in R exploded. And when Ubuntu became so popular, so quickly. And countless other things.)
Thatâs the thing exactly. Some in this thread are so worried that the OCaml community will degrade into something they wonât like if it becomes more popular. IMHO, letâs worry about more realistic things than overcorrecting for OCamlâs impending (!) popularity and the incoming hordes of unwashed developers.
Thereâs this popular quote that does the rounds on LinkedIn:
âWhat if we train our people, and they leave?â
âWhat if we donât train them, and they stay?â
What if the OCaml community becomes filled with people who like the fact that itâs niche and inaccessible to outsiders?
Yawar, this is exactly right. 100%, exactly right.
And I say this, as someone who honestly doesnât give two hoots personally about whether The Great Unwashed use OCaml. I donât care about IDEs, merlin, LSP, Javascript, all that stuff. I use Emacs, xterms, and make. So none of it will affect me. And I am utterly unafraid of the hordes somehow crashing in and producing noise and turmoil: there will always be a core of stuff, a core of developers, that I pay attention to. For instance, I doubt that I will ever use any of the Javascript-related functionality in the OCaml ecosystem. Ever.
But two things:
-
I want OCaml to be successful, and I want the developers of OCaml to have a vibrant audience for their work. I may never use âWindersâ (no âmayâ about it!) but I want for OCaml to be successful on Windows.
-
We shouldnât be afraid of The Unwashed, the kids, crowding into OCaml. Itâs a great thing, and can only enhance OCamlâs value and ecosystem. From those kids, will come people who want to contribute to OCaml, who want to write new tools, packages, and documentation.
Especially when it comes to documentation, I think that the arrival of hordes of newbies could help a lot. I think that we old skool folks grew up in a world of âRTFS(ource)C(ode), Lukeâ, and we have a constitutional allergy to writing good documentation and tutorials. Fine. The newbies wonât be like that, b/c blogging, writing tutorials, and documentation, are all part of The Way Things Work Today.
It can only help.
âAnd I donât believe that communities are necessarily self-correcting and meritocratic.â
It would be interesting to see examples of this in communities that arenât led by companies. I know that Perl, for instance, has displayed precisely this sort of self-correcting behaviour. [Others may disagree with me, but] I thought the way Perl6 was evolving was âwow, thatâs gonna be the kitchen sinkâ. And then it detoured thru Haskell, and I was even more appalled. But Perl5 kept right on truckinâ, and I think this is an example of self-correction. I doubt that many people think of Perl6, unless theyâre weirdo PL-turned-industrial types like me.
Yawar, something else that I thought was worth saying:
I started on BSD UNIX in 1983, and with caml in 1991. From my grey-haired point-of-view, aside from the people who got PhDs in this stuff in the late 80s/early 90s, everybody is a ânewbieâ. Kids that I had as interns 20 years ago, are now trusted and reliable experts in areas I know nothing about, and some of them in areas where I thought I was an expert.
The lesson I draw from 25 years of watching newbies enter and create great things, is that we shouldnât dissuade them: that encouraging newbies who will enter and eventually (soon) become old greybeards, is important and valuable for every community.
niche in the sense of not being mainstream: yes, I see benefits here and dangers in the mainstream as I pointed out and others elaborated.
Being inaccessible: who ever said such? Please donât twist the words in my mouth. Iâm a outsider myself and canât see what you mean with inaccessible.
OCaml is just rarely known, itâs not that people say â uh it lacks X or Y. They say O-what? I for example got notice of OCaml via an article of @hannes about the mirage project in the periodical of an association Iâm member of. Or talks at the Chaos Communication Congresses or Jane street.
So I second the wish for visibility, talks and articles with quality well above the mediocre. Or just silly ads like the beforementioned stickers.
Donât just focus on infrastructure, itâs already sane, thatâs not what OCaml is about IMO. But rather spread the word, spread your enthusiasm to those, who never have heard of OCaml before. Talk more about the ends to achieve (e.g. small TCB, safe implementtions), not just the means like tooling.
And yes, I like things having character at the price of not being attractive for everybody. Iâm a huge fan of variety. No need being the best in all details if thriving.
I think that having a big community usually leads to more people getting into the community because the community traction. Is kind of a self feeding loop.
More people using the language means more docs and more libraries.
To give you an example of the importance of libraries, about 6 months ago my girlfriend needed a tool to process a bunch of files quickly for her work. I needed to process and filter a bunch of KMZ files and spit out them again filtered. I would have love to do it in ocaml, but I did it in node. Why? Because all I had to do was to pick a couple of libraries, glue them and give my girlfriend something she could use in a matter of days, not weeks.
KMZ is not a popular file format, and the fact that node had libraries for it was amazing and save me a lot of time.
I donât think I could have done it using ocaml. Sure, I can read the KMZ spec and write a parser, but then the taks would not be help my girlfriend anymore but build a KMZ parser and encoder
I want to build services and software running unmodified for decades. OCaml seems promising here where other options become sparse.
Choose the right tool for the job and not every tool has to be alike. They may differ. Even better if they do.
Since this is a loose thread Iâll just tell a little semi-OT anecdote.
I think we all get the importance of libraries :â)
But what people never seem to mention is the quality of the libraries in these âbatteries includedâ languages. Each time I reach for them I end up being disappointed by the very low power they provide â this is anecdotic of course, Iâm sure thereâs good software written there as well, I likely just got unlucky.
So hereâs the story. Last year I needed to devise under time pressure a pipeline to produce static IIIF images (a format to serve high resolution image on the web).
So I reach for an off-the-shelf solution, lose a couple of hours (3 according to my timesheet) searching the web for something decent until I find some python code based on the PIL python library that does that. I run the software and it takes something like 9 (!) hours to produce the image with tiles of a very dubious photographic quality. The knobs to improve or tweak the results are far from being obvious and anyways the time of production was a no go. Especially since we had to experiment with the results.
So in the end I dive into the spec and produce after seven hours and a half a 150 loc OCaml program that shells out ( I know I know) to imagemagick
and produces the desired file hierarchy in about 1min with all the control over quality we need (compression, color profiles etc.).
Sometimes the batteries are closer than we think :â)
So because you have those goals does it mean that I can not use for my purpose? As far as I know OCaml is a general purpose language, not a DSL for whatever niche usage.
The only reason I was not able to use ocaml was the lack of libraries, not because it was not possible or it would not allow me to do equally quick.
I guess you love reinventing the wheel on every project of yours and have one or two at most on a lifetime.