Surface Tension of Software

Yup, it's quite rare that ADTs (or Rust enums) are so clear cut and obvious.

The idea that the data model looks like

   enum XYZ {
      case A(B, C, D, E);
      case F(G, H, I, J, K);
      case L();
      case M(N, O);
   }

I think messaging is one case where it can happen, but even there it's often good to combine fields and share them (and common code) over multiple types of messages. If Messages A and B both have a field "creationTime" or whatever (with identical semantics), it's probably a bad idea to model them as separate fields, because that leads to code duplication, which is unmaintainable.

Maybe I can be more precise by proclaiming that ADTs can be good to be clear what's "there", so they can be used to "send" information. But to write any useful usage code, typically a different representation that folds common things into common places is needed. And it might just happen that field F is valid in cases A and B but not C. That's life! Reality is not a tree but a graph.

That's why it's a bad idea to try and model the exact set of possible states and rule out everything else completely in the type system. Even the most complicated type systems can only deal with the simple cases, and will fail and make a horrible mess at the more complicated ones.

So I'm saying, there is value to preventing some misuse and preventing invalid states, but it comes at a cost that one has to understand. As so often, it's all about moderation. One should avoid fancy type system things in general because those create dependency chains throughout the codebase. Data, and consequently data types (including function signatures) is visible at the intersection of modules, so that's why it's so easy to create unmaintainable messes by relying on type systems too much. When it's possible to make a usable API with simple types (almost always), that's what you should do.

> that specific example is wrong

This will be discovered at compile time if you use immutability & types like the article suggests.

> So the assumption that you either are loading XOR have data XOR have an error does not hold.

If you design render() to take actual Userdata, not LoadingUserdata, then you simply cannot call render if it's not loaded.

The way to produce unspecified behaviour is to enable nulls and mutability. Userdata{..} changing from unloaded to loaded means your render() is now dynamically typed and does indeed hit way more states than anticipated.

Please elaborate. I thought the article was interesting and would love a contrasting take.

Edit: thank you for the answers, I don't know how I missed that em dash clue.

Indeed. But ... do not confuse your model with reality.

There's a folk story - I don't remember where I read it - about a genealogy database that made it impossible to e.g. have someone be both the father and the grandfather of the same person. Which worked well until they had to put in details about a person who had fathered a child with his own daughter - and was thus both the father and the grandfather of that child. (Sad as it might be, it is something that can, in fact, happen in reality, and unfortunately does).

While that was probably just database constraints of some sort which could easily be relaxed, and not strictly "unrepresentable" like in the example in the article - it is easy to paint yourself into a corner by making a possible state of the world, which your mental model dims impossible, unrepresentable.

Wonder how old is this advice. Must be at least 20 years?

> How about you never write the wrong state in the first place ?

Indeed, and tagged unions (enums in Rust) explicitly allow you to avoid creating invalid state.

Then you have to take care of nobody ever writing the wrong state, which is increasingly annoying the more people work on the thing.

what is it with this take that oop is dead… even the linux kernel heavily uses OOP.

inheritance is what has been changing in scope, where it’s discouraged to base your inheritance structure on your design domain.

I'm all for FP, but there's no way the mainstream is taking side-effects seriously.

Neither Kotlin nor Rust cares about effects.

Switching to Kotlin/Rust for FP reasons (and then relying on programmer discipline to track effects) is like switching to C++ for RAII reasons.

I wouldn't say OOP failed in any general sense. There seem to these strawman exceptions and Convay's law is often what actually is the problem.

Having tried Kotlin in IDEA, I must admit their refactoring tools for Java are miles ahead of Kotlin.

I don't know how strong lock in is.