Item — HN Reader

Hot take: Static typing is often touted as the end all be all, and all you need to do is "parse, don't validate" at the edge of your program and everything is fine and dandy.

In practice, I find that staunch static typing proponents are often middle or junior engineeers that want to work with an idealised version of programming in their heads. In reality what you are looking for is "openness" and "consistency", because no amount of static typing will save you from poorly defined or optimised-too-early types that encode business logic constraints into programmatic types.

This is also why in practice alot of customer input ends up being passed as "strings" or have a raw copy + parsed copy, because business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program.

6 comments

> no amount of static typing will save you from poorly defined or optimised-too-early types that encode business logic constraints into programmatic types.

That's not a fault of type systems, though.

> because business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program

That's a problem with overly-tight coupling, poor design, and poor planning, not type systems

> In practice, I find that staunch static typing proponents are often middle or junior engineeers

I find people become enthusiastic about it around intermediate stages in their career, and they sometimes embrace it in ways that can be a bit rigid and over-zealous, but again it isn't a problem with type systems

> overly-tight coupling, poor design, and poor planning

yeah imagine if you could foresee the future five years in advance. People overestimate their ability to use type systems correctly, as shown in your reply here.

It has worked out well for me for 15 years or so.

> I find that staunch static typing proponents are often middle or junior engineeers

I wouldn't go this far as it depends on when the individual is at that phase of their career. The software world bounces between hype cycles for rigorous static typing and full on dynamic typing. Both options are painful.

I think what's more often the case is that engineers start off by experiencing one of these poles and then after getting burned by it they run to the other pole and become zealous. But at some point most engineers will come to realize that both options have their flaws and find their way to some middle ground between the two, and start to tune out the hype cycles.

This is such a tired take. The burden of using static types is incredibly minimal and makes it drastically simpler to redesign your program around changing business requirements while maintaining confidence in program behavior.

People keep saying this and yet in the decades of my career the industry bounces between being fully dynamic and fully typed according to the affordability of senior engineers. What you are saying are covered by tests, not types.

> What you are saying are covered by tests, not types.

You know Haskell programmers write tests, right?

how does this square with very senior people putting in a lot of effort to bolt fairly good type systems onto Python and JavaScript?

> business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program.

I just don't understand how this is the case. Fields or methods or whatever are either there, or they are not. Type systems just expose that information. If you need to change the types later on, then change the types.

Example: Kotlin allows you to say "this field will never be null", and it also allows you to say "this field will either be null or not null". Java only allows the latter. If you want the latter in Kotlin, you can still just do that, and now you're able to communicate that (or the other option) to all of your callers.

Typed Python allows you to say "yeah this function returns Any, good luck!" and at least your callers know that. It also allows you to say "this function always returns a str".

"good type systems" in Python and Javascript has a escape hatch via dicts/objects, and are frankly, not "good" compared to FP via haskell etc, but it is realistic, reliable, open and consistent, which is exactly my point!

You could spend more time understanding Pydantic before you make this comment however.

> staunch static typing proponents are often middle or junior engineeers

While we're sharing anecdotal data, I've experienced the opposite.

The older, more experienced fellows love static types and the new ones barely understand what they're missing in javascript and python.

python, js, ruby, clojure, erlang etc are created by senior engineers who are fully aware that haskell etc exists, so have you considered that people you claim are "senior" aren't senior enough?

You are yet another person who is misguided in exactly the way described in this article by the same author: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...

> static types are not about “classifying the world” or pinning down the structure of every value in a system. The reality is that static type systems allow specifying exactly how much a component needs to know about the structure of its inputs, and conversely, how much it doesn’t.