←back to thread

Evolving the OCaml Programming Language (2025) [pdf]

(kcsrk.info)
157 points matt_d | 3 comments | 05 Sep 25 00:05 UTC | HN request time: 0.001s | 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 #
alabhyajindal ◴[05 Sep 25 10:03 UTC] No.45136851[source]▶
This is not a direct comment on compiler development but on industrial projects in general: how do you begin contributing to something that is so large?

What should a beginner in compiler development, someone who has written a few compilers of their own, do to get involved in a project such as OCaml? I understand this issue is not specific to compilers, but is faced by any sufficiently large project. Still, I think it's an important issue. I believe there are many resources for people to get up and running in a field but not enough for them to make the next jump into industrial projects.

replies(1): >>45137725 #
1. rwmj ◴[05 Sep 25 12:28 UTC] No.45137725[source]▶
(I think this advice applies to most large open source projects)

Make sure you have installed and are using the software. Ideally you'd have an ongoing interest in it because it's something you use regularly (whether personally or for work).

Read first, especially the documentation, guidelines to contributing, mailing lists / Github issues / however else the upstream maintainers engage with each other.

Start small. Actually a great place is just to go and fix spelling mistakes and typos in documentation, code, comments, etc. Follow the guidelines for contributing to the letter, even if they appear over-complicated at first.

After you've engaged with small patches, build up. Look through their issues and (since you're using the software every day) find something that is an "itch" that you want to "scratch", and attempt to fix that.

I don't really need to go further because either at some point in this process you'll have become discouraged (for good or bad reasons), or you'll have found your community and will want to contribute more and more.

replies(2): >>45137759 #>>45143197 #
2. alabhyajindal ◴[05 Sep 25 12:31 UTC] No.45137759[source]▶
Thank you - I appreciate it!
3. nitnelave ◴[05 Sep 25 20:23 UTC] No.45143197[source]▶
Also, of course, talk to people. Pitch your PR idea before writing it, so you can avoid hearing "oh, there's a much simpler way" or "we can never merge this approach because of X"