"OCaml... That's a name I haven't heard in a long time..."
The road to OCaml 5.0
11–20 of 118 posts
Re: The road to OCaml 5.0
#12I 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.
The larger problem in my view is that big Python systems tend to follow OOP design since functional programming patterns do not work well in Python. So you start with something minimal and simple inside a script or notebook, but quickly it evolves into something more like a Java code-base.
Typing does help, agreed.
Re: The road to OCaml 5.0
#13Earlier 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.
[deleted]
Re: The road to OCaml 5.0
#14A lighthearted but very true remark: OCaml is a wonderful language.
Re: The road to OCaml 5.0
#15I 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…
If your language doesn't worry about lifetimes, they don't go away. It just means you have to worry about them yourself instead.
Sometimes that is great. Other times, that will be very hard and error-prone.
Re: The road to OCaml 5.0
#16That's great. It's a terrific language.
Python let's me start programming quickly. ML let's me finish quickly.
Re: The road to OCaml 5.0
#17I 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…
Have you looked into Julia, Nim, Clojure, or even Common Lisp? I'm not sure bout Python interop with CL, but Nim and Clojure seems to have some kind of beta-grade interop, and there's a solid interop story in Julia. And all of those languages have some of their own "native" data analysis and scientific computing toolkits (Julia having more than "some", of course).
That said, complicated Python systems can be improved a lot by adding type annotations. That's more of a solution for web servers and other "easily type-able" applications. Typing support for scientific computing isn't quite there yet. So it depends on what kinds of systems are the complicated ones.
Re: The road to OCaml 5.0
#18Earlier quoted context omitted.
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.
The larger problem in my view is that big Python systems tend to follow OOP design since functional programming patterns do not work well in Python. So you start with something minimal and simple inside a script or notebook, but quickly it evolves into something more like a Java code-base. Typing does help, agreed.
I strongly suggest the Attrs library for cutting down the boilerplate of making small "data classes": https://attrs.org/
With type annotations, you can move away from "inheritance OO" to logicless "data classes" and functions that operate on them.
Re: The road to OCaml 5.0
#19I 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…
I personally haven't used it but Jane Street heavily uses OCaml and has written a blog post on this: https://blog.janestreet.com/using-python-and-ocaml-in-the-sa...
Re: The road to OCaml 5.0
#20I 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…
If your language doesn't worry about lifetimes, they don't go away. It just means you have to worry about them yourself instead. Sometimes that is great. Other times, that will be very hard and error-prone.
An extremely simple thing like having two objects stored in a struct where one object has a reference to the other is a Herculean task in Rust. This is not a language designed for prototyping...