OCaml's domains

I’m not exactly sure what you mean by that. But before you spread misconceptions, let’s be a bit more precise.

OCaml’s float type are IEEE-754 64 bit double precision binary floating point number. There is no support for 32 bit single precision numbers.

While individual float values will in general be boxed when you pass them across functions they are not locally when you perform computations (and this long before flambda existed). floats are also special cased and stored unboxed in the float array type (though that may change in the future as it seems the feature is controversial among compiler hackers).

I believe this old document about numerical computations in OCaml is still conservatively accurate (things may have however have improved e.g. when using flambda).

3 Likes

I appreciate the details and the link, but I think my general summary was correct. OCaml would not be my choice for programs with heavy float usage. You can’t even write efficient recursive functions (one of the main paradigms of functional programming) with floats – even with flambda. If I wanted to use for/while loops everywhere, I would have stuck with another language.

Clearly, floating point usage was not the main consideration when designing OCaml – otherwise, we could have used something like nan tagging (which of course has its own trade-offs).

I am going to both agree with you and disagree. I fully agree that community building and a focus on strategic projects will help the community a lot. I’m going to disagree that this is something that is likely to happen because people who are very interested in engineering on the language decide to spend most of their time learning how to build a community. This is doubly true because such people usually prefer working on technical problems. :slight_smile: Mostly a community gets built because of a virtuous circle, where strategic improvements drive new adopters which drive new strategic improvements.

1 Like

A side note: (hand) performance optimization of FP heavy code often requires selecting which floating point format to use for which case. Precision vs. cycles tradeoffs are quite real on some architectures.

Rust is a new system programming language (usually unpopular) that’s attracting developers from various communities. It has libraries for everything that I need. Those libraries usually have great documentation and many contributors. OCaml needs a coordinated and deliberate effort to match that. A lot of developers are probably dropping out because they discover that many packages are missing or have serious quality issues. The current status does not encourage contribution. The excitement about the OCaml language is dampened by the lack of packages, fragmentation, and slow pace of progress.

1 Like

The first thing I want to note is that things have really improved in the OCaml space. By a lot. People new to the language aren’t really aware of this, but it’s true. Most of this I attribute to OCaml labs and the great people that have come out of there, a few companies’ investment in the community, and additionally now we’re experiencing a bonus Renaissance due to ReasonML.

At the same time, I think the main thing holding OCaml back (aside from lack of people) is a certain culture that’s pervasive, and is very common among older programmers: “Who needs this new thing? My thing works just fine for me and there’s no need to change it.” This is followed up by “You want to do this? Go implement it on your own and prove to me it’s worthwhile before I even consider it.”

The first problem is that this mentality ultimately saps the energy of people who want to improve things until they give up and move on, and all you’re left with is a self-selection for the same old attitude and culture. The other problem is that without change - without advancing with the time - you lose out on the most important thing, which is new users in the ecosystem. Users are everything to a language.

It took a long while until the community was convinced to try Discourse. Even now, there are old-time OCamlers who don’t show up here – who are still clinging to the old OCaml mailing list. Was the old list ‘good enough’? Well, it was functional, but there are many advantages to Discourse, the chief one of which being that you now can attract new users who see a live, rather than a dying, community.

I would argue that the same thing needs to happen to the IRC channel. Is IRC decent? Sure. But you’re isolating yourself from the world, and you need the world a lot more than it needs you. OCaml can’t afford to look like the old man shouting at young people to get off his lawn. It’s not a good look, and it doesn’t attract anybody. How many people have not been exposed to OCaml because they didn’t stumble on a live discussion with knowledgeable users? I’d wager it’s a lot.

As an example of the opposite culture, if you step into the Rust chat, you can’t help but be attracted to it. They’re discussing RFCs for language features in the forum, for goodness’ sake! Conversations that happen in hallways or on private email messages in the OCaml world are taking place out in the open, and interested people can get involved in whatever interests them. You can’t beat that. That infuses the community with energy.

And lest you think this is too hard to replicate, just look at ReasonML. Sure, they’re just designing a front-end, but the energy is there because the process is open, and they have an attitude of change and growth that’s infectious.

I also want to mention that I think backwards compatibility can be overrated. I appreciate solid backwards-compatibility as much as the next person, but backwards-compatibility is most important when you have a large audience. When you have a small audience, your existing projects break down into a mix of a majority of dead and unmaintained projects left behind by people who mostly abandoned the language, and modern projects that are really interested in the changes you want to make, and would update their code to support it because they care about the future of the language. The point is, if making changes will grow your ecosystem significantly, potentially all the backwards-compatible projects that now exist will be a drop in the ocean of projects that will eventually exist.

6 Likes

Well, I agree that it’s nice when people are enthusiastic, and when they can contribute design decisions and RFCs and whatnot. Rust seems amazing indeed, but as pointed out earlier it’s a brand new language that has the huge advantage of hindsight.

“Who needs this new thing? My thing works just fine for me and there’s no need to change it.”

What are you talking about? Have you seen the statistics about packages migrating to dune, for example? People are ready to move to new alternatives when they clearly seem better. If you have concrete examples of that behavior I’d like to hear them.

I would argue that the same thing needs to happen to the IRC channel.

What, should I leave IRC (and the friends I have there) just because there are newer, shinier things? What alternative would you even suggest (please don’t say “slack”)? Discourse is cool and seems to be welcoming to newcomers, that doesn’t mean we need to kill everything else.

I also want to mention that I think backwards compatibility can be overrated.

Will you please rewrite my projects on every compatibility breakage, then? The community is not very big but there’s a lot of existing OCaml code; in particular, but not only, in academia, where manpower is scarce. If you break compatibility you destroy all this work. And by the way, note that rust also makes big promises on retrocompatibility.

2 Likes

Yes, but Dune had to be built out of whole cloth and given to the community. Were it not for Jane Street’s graciousness, we would still be in the build system mess, with each person clinging to their own system. A build system had to go viral to save us from ourselves, and the energy for that viral transition came from the younger people in the community.

I’m surprised that you would say this, given your difficulty in getting changes into the stdlib or Batteries to the point that you had to do exactly what I mentioned – you went and built a thing entirely from scratch (Containers) to prove it could be done differently. This isn’t a scalable way to do this – not everyone can build an stdlib from scratch.

We should be open to trying out a new tool. If it doesn’t work out, ok that’s fine. But the overwhelming response is ‘get off my lawn’ (though as I mentioned, it’s changing recently). Your friends should all migrate with you, because there is a whole world of people waiting you meet you guys.

This is more of a side point. Like I said, I appreciate backwards compatibility. But fear of breaking things can be paralyzing, and all I’m saying is the community almost entirely errs on the side of being conservative in this matter. We can often come up with tools to translate old code to new (as we do now with ppx, or Reason does with refmt), and yet backwards compatibility always dominates. Not saying it shouldn’t win out most of the time, just that we could temper it with a forward-facing understanding of the potential for exponential growth.

As a part of the Reason community I have to say that an open process is by no means an integral part of the Reason or Reason React project (except for few instances when the public opinion was consulted).

Reason has grown because of its Discord channel and Reason’s creators who burned half of their productive time to respond to simple and repetitive questions. In another words it’s a maniacal focus on new people and people who can convert from javascript (look syntax).

Currently the Reason community is a self propelling machine powered by mostly novice people who mutually help each other. There’s definitely something to the Reason community but it’s not openness. I’d say it’s more patience of the people who started it and their incredible responsiveness who set the tone.

That said, in general hard tasks (like Bucklescript) lack contributors (a similar situation).

I believe this is right. I am not sure if people who maintain this forum have such experience. Matter of fact one of the hardest things is separating such mostly unproductive and noisy discussions from ones that can have substance. I’d say that what should be a common practice is forcefully moving discussions which get too off topic into new threads. This sub-thread for instance could be called “I want more and better libraries”. “What you tolerate is what you become.”

5 Likes

While I think new and shiny methods of discussion (such as the discourse forum) are great, I have some reserves about realtime chat options. More particularly, IRC has the great advantage that there are many interfaces/frontend you can use, such as weechat, irssi, etc… many of them open source, it doesn’t require subscription, and it’s well adapted for multiple channels and server, i.e. you can very easily access multiple communities with the same tool.

Now if every community turns to some proprietary chat service, you need to get used to a different interface for each community, you may be required to create accounts on proprietary services, you may have to install the corresponding apps on you smartphone (with all the permission and privacy problems it can entail), etc… Personally, I find this to be more of a problem than the technical aspect of figuring out how to connect to IRC.

Although I generally agree that it is good to try new things, in the case of the IRC channel it has proven useful to me a couple of times, and I’m suffering from severe chat client overload. I have far too many and don’t want more new ones. :frowning:

(This is more a factor of the fact that the instant messaging world hasn’t adopted a single reasonable standard than anything to do with OCaml. I shudder to think what it would be like if email was like this and we didn’t have SMTP and IMAP.)

I do use OCaml for scientific computations (mostly solving ODE/PDE and nonlinear optimization) and this has never been an issue. In my case (research), being able to quickly change de code to try new ideas is very important and OCaml shines at that. The small set of available scientific libraries is more a problem than raw speed. That being said, more float efficiency is good (and I hope flambda keeps improving that) but that should not deter you from writing scientific code in OCaml.

8 Likes

I’ll second this. I wrote a lot of float-heavy code in my academic life and industry life using OCaml and enjoyed the experience a lot.

1 Like

Ok, well - I’m glad I was wrong about this.

Younger people in the community, you mean Janestreet paying people full time to work on Dune and migration of a huge number of packages by Mirage people (who are all 20 years old dev, it’s a well known fact)?
Or you mean big investments to develop opam (ocp and mirage, only newcomers and teenagers)?

You know why no one fixed the build system mess before? Because it’s a hard problem, it takes a very long time and no one is ready to work for free one whole year just to please you.

You want shiny libraries, big documentation, what about writing all this? Many people in the ocaml community are professional ocaml developers. Which means they write ocaml code for a company, not for the community. Lucky for us, many companies are nice enough to open code when possible. But it doesn’t mean all those developers have to give their free time to wrote new libraries to solve problems of other people.

It’s easy to complain that members or the community are not working hard enough and are not welcoming. But it seems to be hard to get actual empathy.

I highly appreciate that some people here are not just complaining but presenting facts and volunteering to improve the situation.

3 Likes

We can’t magically find new leaders and founding to make those people work on improving the community. Sure it would be nice, but there is a limited number of OCaml developers, even more limited number of OCaml developers willing to give their free time. And it’s hard to compete with big communities.

Also, ocaml doesn’t have curly braces so it cannot win this battle.

1 Like

I’m going to heed this excellent advice and ask people to consider staying somewhat in-topic – OCaml’s domains. I think it would help in general if people paid a bit more attention to staying in-topic. (Also, when we discuss big-picture questions such as “OCaml (non)-adoption”, it’s better to focus on actionable things to do rather than generic/vague issues.)

Edit: @bluddy was faster and already created a new thread: Community building. Let’s move the relevant conversation there.

2 Likes

From my rather detached point of view the main problem of OCaml is the lack of a benevolent dictator, someone who could define current goals, priorities and a vector of development. It seems that OCaml is being developed by scattered groups of (very smart, but scarce) people, it’s rather unclear, what should be done or what would be ready to the next release, releases seems to be a bunches of pull requests which were reviewed up to the moment of a release. So the development pace is relatively slow and the goal is ambiguous, nobody seems to have a clear picture in mind what OCaml would look like 3 years from now (would it support multicore? implicits?). Haskell development process looks much more vigorous.

1 Like

The one area where Ocaml outshines everybody is program analysis + writing compiler tools, it even beats Haskell there.

1 Like

The real problem with the “State Of Ocaml” is the fact that the groups of people who use it the most are,

People who like writing compiler tools.

European Scientists.

Comp Sci professors and grad students who love it as a teaching language, and like making toys in it on the weekends.

Hipster Douche Systems Programmers (I fall under this category).

These are all groups of people who tend to reinvent the wheel … a lot, refuse to agree upon standard big frameworks or libraries, and who start a lot of projects they never finish, and are terrible at promoting themselves.

The other thing is the common obsession with modularity, in the ocaml community, most of the time when we are making libraries apart from like facades for blatantly obvious use cases, we never make things that just magically work out of the box, then you have the fact that unless a big company osed it, chances are the library is unmaintained.

The Erlang community is similar, in that regard to the point where we get called toxic very often, the sort of reality is though the community’s culture creates a self perpetuating cycle.

I do think though that if we were a more smug community, we could get a lot of users, I mean look at Haskell, yes it’s a good language and all, and has lot’s of actually good devs, but most of the neophytes come in so that they think they can feel better than other people, but that’s sort of a cop out to me.