What's the OCaml way to do multiple interfaces?

[kantian]

Indeed, it was the article I had in mind.

[kantian]

I won’t argue against you, and it’s great to see that you change your mind an opinion since you wrote https://linuxfr.org/users/bluestorm/journaux/pourquoi-la-recherche-en-langages-de-programmation#comment-1717176:

Je pense que c’est assez clair que Go 1 ignore complètement les 40 dernières années de recherche en langages de programmation (à l’exception des primitives de concurrence qui ont inspirés ses goroutines). Pour tout le reste, l’absence de generics, de sum types, la présence de nil et de interface{} sont clairement aux antipodes de la plupart des systèmes à la pointe de la recherche (par exemple mezzo, ou même rust) qui sont plutôt du coté fonctionnel avec un typage expressif

With a translation for non french reader:

I think it’s pretty clear that Go 1 completely ignores the last 40 years of research in programming languages (with the exception of the concurrency primitives that inspired its goroutines). For everything else, the absence of generics, sum types, the presence of nil and interface{} are clearly at odds with most of the systems at the forefront of research (for example mezzo, or even rust) which are rather on the functional side with express typing

Don’t forget that at this time I take the defense of Golang programmer.

[c-cube]

Are you confusing me with @gasche?

I agree about go ignoring decades of PL research anyway, but not because of interfaces; just because of the rest. You could have a great ML with interfaces and sum types and proper support for FP.

[kantian]

@c-cube

Are you confusing me with @gasche?

I don’t think so. For a very a good reason that at @gasche has a quality that we (you and me) don’t have is diplomacy. For sure, he expressed that Golang is not so much interesting for the kind of research he does, but he was not so rude as you were.

[kantian]

@c-cube

I agree about go ignoring decades of PL research anyway, but not because of interfaces; just because of the rest. You could have a great ML with interfaces and sum types and proper support for FP.

I should add that, from a typing point of view, what you’re promoting is Golang without genericity and without convenience for ergonomy (from the caller side).

[klcantrell]

@kantian

I should add that, from a typing point of view, what you’re promoting is Golang without genericity and without convenience for ergonomy (from the caller side).

I’m genuinely curious, is what’s being discouraged here the use of objects in OCaml in particular or do you also discourage the use of first class modules and other techniques for abstracting over multiple different concrete types?

I’m new to OCaml from languages like Swift or Rust, so not sure if I’m forcing something that isn’t natural to OCaml and regular users of it. I really like something like Rust traits for how it helps write generic code and promote standards and documentation in a codebase, but I’m open to learning a different way of doing things.

[jhw]

@klcantrell

I’m genuinely curious, is what’s being discouraged here the use of objects in OCaml in particular or do you also discourage the use of first class modules and other techniques for abstracting over multiple different concrete types?

I dunno about what others mean to encourage or discourage, but I feel moved to give this perhaps not entirely unsolicited advice.

1. You can do quite a lot with just ordinary functions and algebraic data types. Don’t reach for any the advanced language features until you’re sure you need them. A lot of the time, you ain’t gonna need them.

2. The module and functors language can usually get you the other 90% of the way to where you need to go when ordinary functions and algebraic data falls short. You’ll know you need it when you find yourself needing to write functions at the type level rather than value level.

3. The class and object language should be your last resort. Not only is method dispatch slower than you think (because objects are structurally typed, not nominally typed). You’ll know you need it when you find yourself really needing to use the constraint keyword and the ( :> ) operator a lot. (This is an unnatural concept to most Rust programmers, because it has no subtyping relation between types of the regular kind.)

Hope that helps.

[klcantrell]

@jhw

You can do quite a lot with just ordinary functions and algebraic data types. Don’t reach for any the advanced language features until you’re sure you need them. A lot of the time, you ain’t gonna need them.

I appreciate the advice! There is much power in YAGNI.

[kantian]

I’m sorry to have diverge from your original question. For sure, you can use object and it will feed your needs:

I want a list of values that have this behavior, I don’t care what their concrete type is

If it’s your need, object is one of a possible solution.

[c-cube]

Oh dear.

Maybe you were pointing to my comment in this thread (my browser didn’t scroll to it but that would explain the confusion). I forgot about that comment so I basically made the same again right here and now