1. 20
  1.  

  2. 9

    A good list.

    Alas, it’s often not reasonable to “Make Invalid States Unrepresentable”. It’s an excellent aim, but not always feasible/practical.

    However, it’s close relative, “Make it impossible to create an instance of type in, or mutate it into an invalid state, by strict encapsulation and only providing public interfaces that do not do so.”

    That’s always possible and always practical and should be rigidly strict standard programming practice.

    “Data Consistency Makes Systems Simpler”

    On one project using sqlite, I decided to take CJ Date at his word.

    I created a data dictionary table. Every field name, it’s type and meaning was in there.

    I rigidly stuck to that.

    The tables were fully normalised.

    There were no nulls anywhere ever.

    I only used natural joins.

    The resulting sql was orders of magnitude simpler, faster and more understandable and I haven’t had issues with it for years.

    1. 3

      I’m happy to hear success stories taking Date seriously. I would love to hear more.

      1. 2

        I’m unfamiliar with the technique you describe for SQL. Is there a write up?

        I came to a similar conclusion as you when I’m writing Clojure. A hash map can have anything, but if you have a schema for it, and your tools only can ever create valid maps, then you get much of the benefit. And obviously if you need exactly one of something, use a set or map, etc.

        1. 2

          https://www.oreilly.com/library/view/sql-and-relational/9781449319724/

          Basically I wrote SQL as if everything he said about Relational Algebra was gospel. Oh yes, I nearly forgot, every projection “select” was a “select distinct”

        2. 1

          Shoot for the moon, because even if you miss you…

          Cheesy cliches aside, I agree with you that with “make invalid states unrepresentable” there is a tipping point into complexity. When you start using Peano numbers you might have gone too far. However, I intended it in a much broader sense than types. If you squint, normalisation is just a way of making invalid states unrepresentable.

          1. 2

            Actually, you don’t have to squint hard at all. DB normalization is all about that.

          2. 1

            On one project using sqlite, I decided to take CJ Date at his word.

            I created a data dictionary table. Every field name, it’s type and meaning was in there.

            I rigidly stuck to that.

            The tables were fully normalised.

            There were no nulls anywhere ever.

            I only used natural joins.

            The resulting sql was orders of magnitude simpler, faster and more understandable and I haven’t had issues with it for years.

            I’d love to see this code.

            1. 1

              Unfortunately it doesn’t stand alone, but is a debug and analysis tool for the obscurer innards of a much much larger proprietary system.

              Another “oddity” which isn’t an oddity from a relational point of view…

              No auto increment keys anywhere. If the table doesn’t have a clear primary key, you haven’t thought your data model through.