1. 6

    A long time ago trains were hot and new. Everyone saw all things through trains and steam. Ocean problems were train solutions and so they imagined crossing the ocean on trains. And it’s not that we can’t currently build ocean crossing trains, it’s that planes happened so we don’t want to. So today, when graphics are hot, we are presuming that if a civilization can make a simulation they will. What if they make something else eventually? What if the sim runs for a while but it is overcome by something else where a sim isn’t needed? Where the train is perfect for train problems but no one could have predicted flying? A simulation I guess is a solution to all problems because you have mastery over the environment and all perception is perfect. But I could imagine mastery of the host environment or something.

    I like the logic behind destruction vs advancement but I don’t like the presumption of future projects. Of course these people have thought about this idea a lot more than me, I was just chewing on this recently and realized: “wait, what if they don’t build a sim?”.

    1. 1

      If you create a bunch of types in typescript and then try to have the typechecker catch all possible error states so that it wouldn’t compile a runtime error (but maybe a functional bug would still happen), isn’t this Elm? You model out your problem and you lean heavily on the types of that model. Then you write functional/business-y tests?

      I’m not declaring this, I’m more like asking. :) I’ve done way more typescript than Elm but not years and years of either.

      1. 3

        This is indeed the idea behind type systems like Elm’s, and Elm takes the idea a bit further than comparable languages by being very restrictive about sources of non-determinism. So if you try to utilize types to their fullest, then I’d say you’re doing things in the spirit of Elm but you won’t be able to get the same guarantees from a language that wasn’t designed from the ground up to be able to make strong guarantees the way Elm was. And in any case, having a strong type checker doesn’t obviate the need for unit tests (or unit-level tests, whether they are classical example-based tests or not), although you’ll probably not need to write as many, since their are fewer degrees of freedom in the interactions between the units/modules in your system.

        1. 3

          isn’t this Elm?

          Hi! I’m the blog post author and yes this concept is heavily encouraged in Elm! I have a few other blog posts that go into more detail if you’re interested to learn more. With* Functions, Phantom Types, The Never Type, and Opaque Types are all related to being deliberate about modeling data and defining function / module interfaces.

          Also, Richard Feldman gave a good talk a few years ago you may find interesting - Making Impossible States Impossible

          I hope that helps!

        1. 4

          Yeah, I use Makefiles across languages and projects. It’s a classic. I wouldn’t mind some modern replacement but a structured Makefile might introduce complexity or something. There’s a lot of weird annotation syntax and exit code behavior or something … I don’t remember the details. Cmake, scons, I’ve never used them as a dev. It’d be cool to have some language’s flexible/easy/obvious/least-surprise/intuitive tool extracted out of the language ecosystem.