Things I Was Wrong About: Types

Don't conflate the inability to measure productivity with the conclusion that for this one issue the differences can't be that large. That's like saying, "just because we can't measure distance or velocity, rockets and cars probably are similar speeds, or it depends on the driver's personality." It's empirically unsolved how productive an engineer even is, therefore all other discussions are 100% subjective.

We don't know if there's an effect, because we have no way at all to measure it without costs so staggeringly large no one will ever try. We'd need similar engineers, doing all the same practices, with the same stories, and just one difference. But then the engineers would need to have been selected to be similar skill and speed previously, which would require doing other projects with all fixed practices and languages to measure developer skill relative to peers. This also doesn't take into account team cooperation and morale, creative thinking around problem solving, etc. It's a bummer, but without some breakthrough in AI research allowing developers to be measured based on the code they write, it's seeming more and more like an unsolvable problem.

Static types are great for Fungeable Programmer at Big Co. where you can be dropped into a project and it sort of gives you a way to figure out what's present in the code.

However, if you need to get somewhere fast, be it a side project where you've only got so much time due to other constraints in life, or it's a product you're trying to get to market first with a small team, then you're not going to benefit from ossifying statically typed languages - you're going to reach for something that's interactive, powerful, and not bogged down in edit/compile/test cycles. You're going to instead reach for something like Common Lisp, Ruby, Python etc.

Once you're making $COMFY_DOLLARS_PER_MONTH you can then pass it off to some re-write team, though.

Scala is the closest I've gotten to FP at work. I'd love to play with Haskell/F#/etc in a professional setting, it just hasn't come up. Yet.

For that to work, you have to import those explicitly:

    use something\Http;
    use something\Http\Method;
    use something\Http\URL;
    $body = Http::request(Method.GET, URL.Parse('https://example.com'))->body;

Now you have a bunch of lines instead of one. And have "Method" and "URL" in your current scope.

And all of that instead of this beauty:

    $body = Http:request('GET', 'https://example.com')['body'];

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats.

With that said, it's important to note that type inference is not new. I was doing type inference with Scheme nearly 20 years ago. I believe the reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Types are meant to document code. Without the annotations, you can't look at code and know what is going on. Which, ironically, is the complaint against dynamic typing. In addition to that, you get the pain in the ass of having the compiler always complaining. And because it's inferring types, the error messages are towers of baffling nonsense. It's the worse of both worlds.

One thing that never comes up in these discussions is the idea that creating good types is a skill itself. Much like naming variables, if you don't design your types correctly, your entire code base suffers. It's much easier in a dynamically typed code base to "nudge" the data in a certain direction than in a static type system where all types are locked down at initial design time. In addition, certain type systems are much harder to master than others. I've worked with dozens of TypeScript developers and not a single one really knew what they were doing. They were appeasing the compiler and little more than that. There are also plenty of footguns in TypeScript that even TypeScript experts continually forget. I could continue on the weakening of the value of TS (via "any" and "ts-ignore", etc.) and how these completely muddy any sort of metrics one may have on deciding whether types are "worth it" or not (or the fact that such metrics do not, in fact, exist). But that's enough ranting for one day.