This deserves an hour of reading. My first pass is a criticism too sadly. Addition is too trivial, and every example is pure - this needs a rubber meets the road example to really spell out the benefits.

Philip Wadler story for you though: he taught me first year at uni and his first lecture he rips open his shirt and proclaims himself “Lambda Man!” - Haskell was a fun first semester

In green fields projects, this makes a fair bit of sense at initial reading, tentatively.

But new code becomes old code, and then builds on the quality / discipline / cowboy status of the last person to touch the code, in a complex and interlocking way.

I can’t say I’d be excited to find a partially converted existing codebase of this. But in fairness, I’m on my couch on a Sunday and haven’t actually worked through your examples (or read the original paper). I see the benefit to having both types of extensibility, obviously. Just not sure it outweighs the real world risk once actual humans start getting involved.

I don’t know a single person who can’t say they’ve never taken a single “good enough” shortcut at work, ever, and it seems this only works (efficiently) if it’s properly and fully implemented.

This is a very common toy example we use in Haskell, though honestly this OOP version leaves a lot to be desired, comparatively

The issue is that it tries to shoehorn separation of data and functions on data into a paradigm that’s fundamentally about fusing those two things together.

Here’s the Haskell version. Note how much simpler it is because data and functions are separate:

data Expr
  = Lit Int
  | Add Expr Expr

eval :: Expr -> Int
eval expr = case expr of
  Lit n -> n
  Add a b -> eval a + eval b

print :: Expr -> String
print expr = case expr of
  Lit n -> show n
  Add a b -> "(" ++ print a ++ " + " ++ print b ++ ")"

Typescript can do something similar:

type Expr = {
  kind: 'Lit',
  value: number
} | {
  kind: 'Add',
  left: Expr,
  right: Expr
}

function eval(expr: Expr): number {
  switch(expr.kind){
    case 'Lit': return expr.value;
    case 'Add': return eval(expr.left) + eval(expr.right);
    default:
      const _impossible: never = expr;
      return _impossible;
}

function print(expr: Expr): string {
  switch(expr.kind){
    case 'Lit': return `${expr.value}`;
    case 'Add': return `(${print(expr.left)} + ${print(expr.right)})`;
    default:
      const _impossible: never = expr;
      return _impossible;
}

Both the OOP approach and Typescript itself struggle with additions to the algebra composed of different types, however. For example, imagine extending it to handle booleans as well, supporting equality operations. It’s difficult to make that well-typed using the techniques discussed thus far. In Haskell, we can handle that by making Expr a GADT, or Generalized Algebraic Data Type. That article actually already provides the code for this, so you can look there if you’re curious how it works.