Neither paradigm solves the expression problem. This forces people to break the paradigm as the code grows. Look at the code in some Julia packages, and you will see good use of abstractions around a language design where the expression problem does not exist. This is practical stuff, being used in applied scientific research on a large scale.
I'll make a stronger statement than "can": I have and do productively use object algebras in my day-to-day in Java. It's a really fantastic tool when you need an "interface" that governs multiple types or across more than one receiver. Even when you're not trying to solve the expression problem.
When you're defining an interface on a type that doesn't need to appear in its own method parameters or return types, and where the actual type doesn't matter (as in classic OOP), Java interfaces are fine. But not all problems are best framed this way.
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.
> 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.
> The expression problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).
Why should I care about recompiling? That's an implementation detail.
Taking the compilation stuff out, it looks very similar to classy lenses.
