11–20 of 52 posts
Because exceptions aren’t checked, this effectively means that a language designed for type safety has as much type safety as python, because it’s very easy to forget handling something, and get runtime errors.
How do you deal with this day to day? I assume it’s impossible to just believe that all the code you pull in doesn’t use exceptions?
Earlier quoted context omitted.
You are right that the dynamic arrays story does not read like a straightforward “how to inspire contributions.” But part of what I wanted to do in the talk was to show things as they actually unfolded. In OCaml compiler development, there is a very strong emphasis on correctness and long-term stability. That can make contributions, especially to core language features, feel harder than they might in faster-moving ec…
I think this is the tension in most software. If you want to have excellent and correct software it will take time. And if you want more features with a "fix as you go approach" you will often have huge technical debt and get saddled with poor interfaces, often forever. But, I think OCaml errs too much on the side of getting it right the first time. The result is that state of the art keeps moving far ahead. By the t…
So here we have gotten the worst of both worlds -- a language that is evolving slowly and a language that has large features that are almost soft discouraged. My primary language is Rust and not OCaml (mostly dabble in OCaml) so I may not fully know what I'm talking about when it comes to OCaml.
Earlier quoted context omitted.
You are right that the dynamic arrays story does not read like a straightforward “how to inspire contributions.” But part of what I wanted to do in the talk was to show things as they actually unfolded. In OCaml compiler development, there is a very strong emphasis on correctness and long-term stability. That can make contributions, especially to core language features, feel harder than they might in faster-moving ec…
I think this is the tension in most software. If you want to have excellent and correct software it will take time. And if you want more features with a "fix as you go approach" you will often have huge technical debt and get saddled with poor interfaces, often forever. But, I think OCaml errs too much on the side of getting it right the first time. The result is that state of the art keeps moving far ahead. By the t…
I remember the go to alternative "standard" library was being developed by some bank from Wall Street. Is it still the case? i.e. do most people still use that 3rd party lib or did the real standard library evolve since then?
But yes, the standard library has added many helper functions that were sorely needed during the last few years, and the upcoming 5.4 keeps adding more. Still not as many goodies as Jane Street's libraries, but nowadays I don't miss them as long as I can use just a few small libraries, mostly by dbunzli and c-cube.
For people using OCaml, there’s one thing that kinda discourages me in it, that is exceptions as part of the API in the standard library. Because exceptions aren’t checked, this effectively means that a language designed for type safety has as much type safety as python, because it’s very easy to forget handling something, and get runtime errors. How do you deal with this day to day? I assume it’s impossible to just…
That's an exaggeration.
You can use error types / monads like you would do in Rust/Haskell. When you use the Core standard library, you can use function who don't throw exceptions. Those who do use specific name conventions (foobar_exn).
I remember the go to alternative "standard" library was being developed by some bank from Wall Street. Is it still the case? i.e. do most people still use that 3rd party lib or did the real standard library evolve since then?
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,…
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.
Earlier quoted context omitted.
I think this is the tension in most software. If you want to have excellent and correct software it will take time. And if you want more features with a "fix as you go approach" you will often have huge technical debt and get saddled with poor interfaces, often forever. But, I think OCaml errs too much on the side of getting it right the first time. The result is that state of the art keeps moving far ahead. By the t…
Now OCaml values adding features carefully to the language so that there is no future regret. But being slow and conservative has _not_ minimized regret. The "O" in OCaml i.e. Objects (and Classes) is almost ignored nowadays. Janestreet, a large industrial user seems to be actively against using the "O" part of OCaml. So here we have gotten the worst of both worlds -- a language that is evolving slowly and a language…
It's literally just objects, one large (and early!) feature. Arguably too large compared to the rest of the language: first-class modules or polymorphic variants can handle most of their use cases while being much simpler, and faster than the existing class system. (Objects and object types without the actual classes are maybe ok.)
The only other controversial feature I can think of is Seq and that's just because it can be allocation-heavy. Then again ordinary OCaml lists are not much cheaper (thankfully immutable arrays are already in for 5.4).
Earlier quoted context omitted.
I think this is the tension in most software. If you want to have excellent and correct software it will take time. And if you want more features with a "fix as you go approach" you will often have huge technical debt and get saddled with poor interfaces, often forever. But, I think OCaml errs too much on the side of getting it right the first time. The result is that state of the art keeps moving far ahead. By the t…
Now OCaml values adding features carefully to the language so that there is no future regret. But being slow and conservative has _not_ minimized regret. The "O" in OCaml i.e. Objects (and Classes) is almost ignored nowadays. Janestreet, a large industrial user seems to be actively against using the "O" part of OCaml. So here we have gotten the worst of both worlds -- a language that is evolving slowly and a language…