Thread by @geoffreylitt

by far my favorite thing about typescript is that i can still run the code when it's not typechecking.

beyond the productivity benefits when working on UI, feels like it changes the emotional relationship from "blocking me" to "helping me"

with some other type checkers it's like "ughhh I just want to RUN the code 😡"

and with typescript it's like "ok nice I ran the code, now the typesystem will help me perfect it 😄"

Obviously error message quality affects the emotional tone too, but whether I can run the code also seems like a huge factor

https://twitter.com/geoffreylitt/status/1192090987771912192

I've sometimes been able to attain the Zen of Fixing the 800 Compiler Errors, but feels like it just drains my willpower over time, and I remember just often giving up as a beginner

https://twitter.com/geoffreylitt/status/1192090986928840710

Related to this topic, this is a lovely paper on finding concrete example data to explain type errors. (even if the lang can't actually run without typechecking)

Eg in this figure: "Ahh, it tries to run 1 * true, I see why that is wrong!"

ranjitjhala.github.io/static/dynamic…

At the end of the day, I really identify with this principle from the Scratch team:

https://twitter.com/geoffreylitt/status/1192090985318289408

The OCaml compiler is the pedantic person in the meeting who won't let us proceed until we resolve every tiny detail

The Typescript compiler is the helpful detail-oriented person who says "FYI this detail matters, let's come back to it later when the time is right"

If we're defusing a bomb, would happily hire the OCaml compiler

But if we're doing exploratory design work, nothing could possibly kill the flow more.

Programming tools for sketching must allow us to paint in broad strokes and defer the details!

https://twitter.com/geoffreylitt/status/1156957117699506176