The road to OCaml 5.0
discuss.ocaml.org
The road to OCaml 5.0
1–10 of 118 posts
Re: The road to OCaml 5.0
#2I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifetimes etc.
How is the python-ocaml interop story? To be clear, any language that does not have first-class interop with python is basically dead in the water (at least for our case).
Re: The road to OCaml 5.0
#3Dang, it's finally happening. I've been waiting for 10+ years.
Re: The road to OCaml 5.0
#4I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…
> last thing one wants is a language that requires a lot of thought about lifetimes etc.
I challenge you: A lack of understanding about the data lifetimes in a program means lack of understanding about the data.
Not saying you can't have a lot of short-lived data items that you don't want to manage one-by-one. I'm saying that for the vast majority of data items, one should be able to give a reasonably well defined lifetime upper bound. So a good solution is to make a few boxes that group items by lifetime. And from time to time, throw the outdated boxes away.
And of the few items that don't have such an upper bound at creation time, many can be created in a special box that allows migrating boxes later when required.
Re: The road to OCaml 5.0
#5I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…
> last thing one wants is a language that requires a lot of thought about lifetimes etc. I challenge you: A lack of understanding about the data lifetimes in a program means lack of understanding about the data. Not saying you can't have a lot of short-lived data items that you don't want to manage one-by-one. I'm saying that for the vast majority of data items, one should be able to give a reasonably well defined li…
> A lack of understanding about the data lifetimes in a program means lack of understanding about the data.
But this argument can extend forever.
Is your program precisely dependently typed? If not is that a lack of understanding about the nature of the data as well and should you challenge yourself to fix that?
You have to trade-off how much you specify things with how valuable it is to get the result more quickly.
Re: The road to OCaml 5.0
#6>Hopefully, OCaml 5.0 will then be released between March and April 2022.
Just to call out expectation-setting here in the comments: yes, the MVP of multicore will ship in OCaml 5.0, but OCaml 5.0 will ship no sooner than March 2022 (and very likely some point later, based on how challenging it appears to be to integrate the large-scale changes for multicore).
Re: The road to OCaml 5.0
#7I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…
> last thing one wants is a language that requires a lot of thought about lifetimes etc. I challenge you: A lack of understanding about the data lifetimes in a program means lack of understanding about the data. Not saying you can't have a lot of short-lived data items that you don't want to manage one-by-one. I'm saying that for the vast majority of data items, one should be able to give a reasonably well defined li…
You don't have to challenge the person you're responding to. You have to challenge their quants. And they're not going to want to add that into the million other things they're thinking about while doing research in a Jupyter notebook or something.
You're just not going to get this buy-in from people who want to use a tool to get their work done.
Re: The road to OCaml 5.0
#8I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…
Python type checking (type annotation, mypy) should at least partially solve the problem of maintaining complex Python systems. Though it doesn't help with performance.
Re: The road to OCaml 5.0
#9I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…
[deleted]
Re: The road to OCaml 5.0
#10Earlier quoted context omitted.
> last thing one wants is a language that requires a lot of thought about lifetimes etc. I challenge you: A lack of understanding about the data lifetimes in a program means lack of understanding about the data. Not saying you can't have a lot of short-lived data items that you don't want to manage one-by-one. I'm saying that for the vast majority of data items, one should be able to give a reasonably well defined li…
> A lack of understanding about the data lifetimes in a program means lack of understanding about the data. But this argument can extend forever. Is your program precisely dependently typed? If not is that a lack of understanding about the nature of the data as well and should you challenge yourself to fix that? You have to trade-off how much you specify things with how valuable it is to get the result more quickly.
What you say is true. I only brought up "boxes" because the concept is still not widely known.