Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The road to OCaml 5.0

discuss.ocaml.org

Post reply on HN
Print view View original

91–100 of 118 posts

Re: The road to OCaml 5.0

#91

Post by infogulch »

octachron wrote: post #42
grumpyprole wrote: post #40

Earlier quoted context omitted.

If they can also ship algebraic effects (and even better, typed algebraic effects), then I think it will push the language back firmly into "state of the art". This will mean it continues to get the attention it deserves. I'm excited about algebraic effects, I think they are much more intuitive than monads (and don't require code to be rewritten).

The current plan is to have runtime support for effects in 5.0, but without a syntax nor an effect type system. Those two will come later in the 5.x branch. The aim is to decouple the switch to the multicore runtime from the design of the typed effect system. In the interim period, effect handlers would be exposed through an experimental module (exposed through an experimental module (see https://discuss.ocaml.org/t/…

OCaml Workshop 2021 - Experiences with Effects - https://www.youtube.com/watch?v=k3oQwpyXmpo

Re: The road to OCaml 5.0

#92

Post by mirekrusin »

Zababa wrote: post #68
mirekrusin wrote: post #47

Earlier quoted context omitted.

> (...) with the departure of Rescript (Bucklescript) from the OCaml community (...) I wasn't aware anything like that is happening, is it? Rescript departed from Reason, that's all, right? They want to focus solely on js target, because... that's what rescript is. New stuff they're doing looks really good.

The best source of information is probably this thread: https://discuss.ocaml.org/t/a-short-history-of-rescript-buck...

Yes, thank you, I don't see any OCalm depart there, just depart from ReasonML is mentioned.

Re: The road to OCaml 5.0

#93

Post by short_sells_poo »

philzook wrote: post #37
short_sells_poo wrote: post #2

I 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…

There is an actively developed python to ocaml interop library for purposes quite similar to yours. I have seen demos where ocaml and python are used within the same jupyter notebook https://signalsandthreads.com/python-ocaml-and-machine-learn... https://github.com/thierry-martinez/pyml

Thank you, I'll pass this on. An important feature is zero copy arrays, which seem to be supported.

Re: The road to OCaml 5.0

#94

Post by short_sells_poo »

rkangel wrote: post #33
short_sells_poo wrote: post #2

I 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 think Elixir would be interesting for your usecase. It's a dynamic, garbage collected language. It's easy to pick up and get going with. As a functional programming language there isn't a lot to learn in the way of language constructs, and you don't even have to do the 'wrestling with the type system' thing that you have to do in compiled functional languages like OCaml or Haskell (like you do in Rust). Its process…

Thank you! So this looks interesting but it seems like there's no easy way to share numpy arrays?

The main use case for a language other than python is a more robust codebase but also performance. We need to be able to efficiently ship lots of large arrays between the languages and the Rust-Python interop supports zero copy arrays for example.

Re: The road to OCaml 5.0

#95

Post by Zababa »

mirekrusin wrote: post #92
Zababa wrote: post #68

Earlier quoted context omitted.

The best source of information is probably this thread: https://discuss.ocaml.org/t/a-short-history-of-rescript-buck...

Yes, thank you, I don't see any OCalm depart there, just depart from ReasonML is mentioned.

I think the "depart" is not supporting newer OCaml feature. While Rescript/ReasonML at first was just an alternative syntax, it has now become a standalone programming language.

Re: The road to OCaml 5.0

#96

Post by short_sells_poo »

hajile wrote: post #82
short_sells_poo wrote: post #71

Earlier quoted context omitted.

When you are trying to solve a complex optimal payoff problem, you really don't want to get bogged down with lifetimes. That's a completely orthogonal concern to what you are trying to establish. You are not writing production code, you are doing research. It's the core reason why languages with easy REPL and immediate feedback (like matlab, R, python, julia, etc...) are used for research, because you get immediate a…

Most of my day-to-day coding is in Typescript and I often find myself wondering if more than a few jobs wouldn't be easier and faster with plain JS and no need to feed the type checker. Many of the same thoughts about you vs the language tracking things applies here too. In my case, I'd say that yes, I have to track the types myself, but the tradeoff is at least sometimes worth the extra mental overhead in my opinion…

You are correct, lifetimes are being tracked in some form at all times. So let me rephrase: lifetimes are irrelevant to the primary work of a quant during research. The objective is to establish whether an idea works. In 99% of the cases, it doesn't and the code and the project are a dead end. Under these circumstances you need to reduce the amount of cognitive overhead that goes into program structure to a minimum.

Research is fundamentally different from the usual programming exercise. Research is like prospecting. You want to try as many different locations as possible. You don't want to build nuclear shelter grade construction at every potential site because 99 out of a 100 is a dud. You'd never find anything.

You want a tool that allows you to get quick results to confirm if a site has potential and then you want to be able to scale your tools for proper mining.

Re: The road to OCaml 5.0

#97

Post by short_sells_poo »

mtoner23 wrote: post #30
nv-vn wrote: post #28

Earlier quoted context omitted.

This is a terribly misinformed take. If you throw enough resources at Python then sure, you can probably get adequate throughput . The problem is that in finance a lot of problems require you to think about latency , which is a total non-starter for Python

If it were a total non starter than why would their entire company be using it?

I have no doubts that we are able to handle our requirements with python, but if there's a better way, does it not make sense to investigate?

A skilled carpenter can undoubtedly use a hammer instead of a screwdriver. This doesn't mean that I should insist they use a hammer when a screwdriver would do a better job.

Re: The road to OCaml 5.0

#98

Post by pharmakom »

Zababa wrote: post #63
dunefox wrote: post #34

Earlier quoted context omitted.

> Java has good to great FP Java does absolutely not have "good to great FP" support. It's an imperative and OO programming language that recently got lambdas, no more, no less.

There's sealed classes, records, pattern matching, optionals. It's getting there.

All good improvements, but Java is missing some really key pieces:

- pipe operator (or custom operators in general)

- do-notation

- tail call optimisation

- currying / partial application

- (better) type inference

- expression orientated

- less syntactic noise around function calls (fewer commas and parenthesis)

- type-classes or even runtime generic information to work around that

Some of the thing I’ve listed can never be added without dramatically changing what Java is. At that point it would be a new language.

Re: The road to OCaml 5.0

#99

Post by Zababa »

pharmakom wrote: post #98
Zababa wrote: post #63

Earlier quoted context omitted.

There's sealed classes, records, pattern matching, optionals. It's getting there.

All good improvements, but Java is missing some really key pieces: - pipe operator (or custom operators in general) - do-notation - tail call optimisation - currying / partial application - (better) type inference - expression orientated - less syntactic noise around function calls (fewer commas and parenthesis) - type-classes or even runtime generic information to work around that Some of the thing I’ve listed can n…

I think you're moving the goalposts from "good to great FP support" to "is Haskell". I think that's the only one that fullfills both do-notation and tail call optimisation at the same time. Well, there's also Purescript and Scala.js running on JavaScriptCore since it has tail call optimisation, but that's a bit of a stretch. I see a lot of people like you that seem to have a very precise idea of what FP is supposed to be, and that idea always boils down to "basically Haskell". I think that's a fallacy, and that Haskell is not the only way to do FP. We have now languages like Koka, and soon (ish) OCaml that have effects, and are going to provide an alternative to Haskell's monads. There's also stuff like Scala with the DOT calculus. Lots of exciting stuff is happening in that space, and being a purist of one specific implementation isn't helping.

To get back to the subject of "good to great FP support", maybe we disagree fundamentally. Here are a few examples:

I would say that Rust is a good example of "great FP support". It's not a functional programming language, but it supports a lot of the patterns that make statically-typed functional programming languages effective. However, its DNA is still mostly "imperative programming language".

For "good FP support", I'd say TypeScript and C# are nice examples. C# has LINQ, pattern matching, records, optionals in a way. TypeScript has the usual JS stuff, plus the type system is nice. Both are lacking in some places. For example, in TypeScript/JavaScript, the usual map/reduce/filter are only functions on Array, and don't work with iterators.

To take the opposite view: what would be a functional programming language with good or great support for another paradigm? OCaml could be an example of good/great support for imperative programming. Scala has great functional programming and great object-oriented programming.

Re: The road to OCaml 5.0

#100

Post by yawaramin »

Zababa wrote: post #81
yawaramin wrote: post #66

Earlier quoted context omitted.

A couple of years ago, opam was the recommended package manager and dune was the recommended build system–just as today. The opam package index was also searchable for libraries. The OCaml website may have been slightly less clear about these things than it is now, but I think a reasonable user would have been able to find them, especially if they went to the forum and asked. People would have gladly answered questio…

I don't think that's totally fair. The Up and Running page of the OCaml website ( https://ocaml.org/learn/tutorials/up_and_running.html ) was added during 2020. Before that it lacked a straighforward introduction on what you need and how to install it. Node, Go and Rust all come with the package manager, and Rust even comes with a way of managing the different Rust versions. The essential part are here, and everythin…

Let's take a look at the page around this time two years ago.

Landing page: https://web.archive.org/web/20191002202720/https://ocaml.org...

From which you can click through to the Install page: https://web.archive.org/web/20190819032815/https://ocaml.org...

Over there the second and third lines are:

> The OCaml compiler and libraries can be installed in several ways:

> - With OPAM, the OCaml package manager (recommended).

That points you to the opam install instructions, which looks pretty similar to what it does now.

Look, I agree with you that OCaml installation and tooling are not the easiest to get into. But it wasn't like what the GP was making it out to be.

Post reply on HN