←back to thread

Evolving the OCaml Programming Language (2025) [pdf]

(kcsrk.info)
157 points matt_d | 1 comments | 05 Sep 25 00:05 UTC | HN request time: 0s | source
Show context
kcsrk ◴[05 Sep 25 04:03 UTC] No.45134878[source]▶
I am the author of the talk here o/.

This talk is a _subjective_ take on how the OCaml programming language evolves, based on my observations over the last 10 years I've been involved with it. My aim/hope is to demystify the compiler development process and the tradeoffs involved and encourage more developers to take a shot at contributing to the OCaml compiler.

Happy to answer questions, but also, more importantly, hear your comments and criticisms around the compiler development process, ideas to make it more approachable, etc.

replies(4): >>45135115 #>>45135373 #>>45136851 #>>45145616 #
ofrzeta ◴[05 Sep 25 04:58 UTC] No.45135115[source]▶
To be honest the story about the two closed PRs for dynamic arrays doesn't really inspire contributions :)
replies(3): >>45135152 #>>45135208 #>>45135483 #
aseipp ◴[05 Sep 25 06:16 UTC] No.45135483[source]▶
I think it's just the nature of the beast, in this case. Serious "industrial" implementations of a programming language might stick around for a long time, and breaking things a lot can mar the appeal; getting it right the first time pays off in that case.

I think the acceptance threshold can be much lower in other kinds of tooling. "It is what it is", so to speak.

replies(1): >>45137195 #
1. Quekid5 ◴[05 Sep 25 10:57 UTC] No.45137195[source]▶
Add a sane deprecation process and this is much less of an issue -- see e.g. the Java language. Sure, it's not ideal to have multiple implementations of the 'same' data structure (if a better way is found, say)... but at least you aren't stalling everything and causing API interop issues for years and years.