Applying “make invalid states unrepresentable”

Post by NegativeLatency » Mon, Oct 05, 2020, 3:47 PM UTC

peteradio wrote: post #71

dghf wrote: post #55

Earlier quoted context omitted.

It's not that much more complex: if you do SELECT event FROM events WHERE startDate then all but one of the results (the one with the greatest `startDate`) will also have an implicit end-date prior to 2021.

Until business tells you that endDate is not necessarily greater than startDate. <- real world experience

Post by nybble41 » Mon, Oct 05, 2020, 3:48 PM UTC

maest wrote: post #86

etripe wrote: post #3

This is a good introduction on a conceptual level. I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. To make unrepresentable states practical, Scott Wlaschin has an excellent write-up here (0). His book (plugged in that article) is also excellent. [0] https://fsharpforfunandprofit.com/posts/design…

Sum types are one of the main things I miss when working in Python. Is anyone aware of any good ways of adding sum types to Python?

    # data Pair a b = Pair a b
    def pair(x, y):
      return lambda f: f(x, y)

    # data Either a b = Left a | Right b
    def left(x):
      return lambda l, r: l(x)
    def right(y):
      return lambda l, r: r(y)

    v0 = pair(2, 3)
    v1 = left(7)
    v2 = right(9)

    # case v0 of { Pair x y -> x + y }
    print(v0(lambda x, y: x + y))

    # case v1 of { Left x -> x + 1; Right y -> y * 2 }
    print(v1(lambda x: x + 1, lambda y: y * 2))

Post by dahauns » Mon, Oct 05, 2020, 3:50 PM UTC

pdonis wrote: post #97

dahauns wrote: post #90

This line raised a huge red flag for me: "If the customer doesn’t have a fixed contract, it is assumed they are on a default contract" No. Don't assume, specify. Explicitly. If this is part of your specification, have a DefaultContract entity of some kind somewhere. And don't call this table just "Contracts", make it clear that those exist in addition to or overlay a default contract. It might sound like overkill, bu…

> If this is part of your specification, have a DefaultContract entity of some kind somewhere. Yes, but not in the database table for contracts. That's how I read this part of the post. I would expect the assumption that if the customer doesn't have a fixed contract, they are on a default contract to be encoded in business logic somewhere in an application that uses this database.

Post by lukasLansky » Mon, Oct 05, 2020, 3:52 PM UTC

jdmichal wrote: post #103

H8crilA wrote: post #65

So Google's protocol buffers have this feature called "required" fields, which enforce schema in the type system. You should never use it. Never. It's one of those things that sound good until you're a few years into the project. Similar to how you should never be using meaningful IDs as primary keys for objects, always use meaningless fingerprint-like integers. Or how all integers should be signed unless you're dead…

> And how many integers should actually be strings, unless you're dead sure this is a number. I phrase this as: If it doesn't make sense to do math on it, it's not a number. What does adding one to a customer account number mean? Absolutely nothing -- you get a completely different account number. So it's not a number, but a numeric string.

Post by pc86 » Mon, Oct 05, 2020, 3:58 PM UTC

chii wrote: post #52

ahoka wrote: post #43

Earlier quoted context omitted.

Then the code will be changed. Making up business requirements is the number one reason for instant legacy code. Code is not set in concrete, you can add that flexibility later when it is needed, but making everything overly generic to make it easier to "implement new requirements" only leads to code that is hard to change in my experience. Also don't forget that this is only an example.

The YAGNI (you aint gonna need it) principle overrides the DRY principle imo.