4 ms·

Personally I prefer being on the other end of the expression problem - where extending underlying data (mainly sum types) is the costly operation. Like in Rust,

Personally I prefer being on the other end of the expression problem - where extending underlying data (mainly sum types) is the costly operation. Like in Rust, because it actually makes you think about the data model instead of the implementation. Adding new functions is "free" in the sense that it's not going to break your model. But I'm curious if you don't find object algebras in Java cumbersome and kind of fighting the type system? Because while I like this kind of thing in Scala, in Java it feels very much against the design of the language.

Twisol 6y ago
> Personally I prefer being on the other end of the expression problem I agree, I prefer sum types in general. And you can still get dynamic dispatch from trait objects (in Rust), so you have both approaches at your disposal. (In Java, all you have is a hammer...) > But I'm curious if you don't find object algebras in Java cumbersome and kind of fighting the type system? Yes and no. I try to use them where they make more sense than OO-style interfaces, so somewhat by definition I don't find them any more cumbersome than OO-style interfaces would be. Java feels like it has a dearth of modeling techniques, so even a seemingly-niche one like object algebras gives me a lot more to work with. Serializers/deserializers are a good fit for an object-algebra approach, since you don't want to define those methods directly on the data type you're serializing (if you even have control over that type). Traditionally algebraic types, where you can combine two instances to get a third, are also a good fit. (From a Haskell perspective, you can think of the `x.add(a, b)` as explicitly naming the dictionary of typeclass methods you'd get from writing `a + b` -- kind of like `a +_x b`, if you will.) And there's almost no choice if you want to define a signature over multiple types -- you need a mediator object anyway. It's pretty ergonomic if you stay nearby these and similar patterns.
- trumpeta 6y ago
  Thank you, this was very illuminating!

Twisol 6y ago

> Personally I prefer being on the other end of the expression problem I agree, I prefer sum types in general. And you can still get dynamic dispatch from trait objects (in Rust), so you have both approaches at your disposal. (In Java, all you have is a hammer...) > But I'm curious if you don't find object algebras in Java cumbersome and kind of fighting the type system? Yes and no. I try to use them where they make more sense than OO-style interfaces, so somewhat by definition I don't find them any more cumbersome than OO-style interfaces would be. Java feels like it has a dearth of modeling techniques, so even a seemingly-niche one like object algebras gives me a lot more to work with. Serializers/deserializers are a good fit for an object-algebra approach, since you don't want to define those methods directly on the data type you're serializing (if you even have control over that type). Traditionally algebraic types, where you can combine two instances to get a third, are also a good fit. (From a Haskell perspective, you can think of the `x.add(a, b)` as explicitly naming the dictionary of typeclass methods you'd get from writing `a + b` -- kind of like `a +_x b`, if you will.) And there's almost no choice if you want to define a signature over multiple types -- you need a mediator object anyway. It's pretty ergonomic if you stay nearby these and similar patterns.

trumpeta 6y ago
Thank you, this was very illuminating!