Hacker News Reader

Comment by michaelfeathers | Hacker News Reader

At the same time that this is showing on HN there is an article about an ESPN Analyst walking away after being upset at trauma on a football field [1]. The comments are very interesting in that they point out that football helmets may actually exacerbate injury because they their protection leads to players feeling protected enough to risk harder hits.

I don't think we have that same effect in software but I think there is an related one: when you don't have the protection of a static type system, you may become more careful.

[1] https://news.ycombinator.com/item?id=15141495

View on HN

I find the opposite happens. Without the protection of the compiler enforcing rules before execution can occur we get "engineers" writing a mountain of fragile, dynamically typed mess quasi-protected by untold numbers of unit tests (themselves fraught with peril) half of which implement (poorly) type checking.

Ditto. After learning Java at uni I harboured a dislike for it for over 10 years while using dynamic languages. Now, having used it to implement microservices in an actually sane development environment, I love it to bits. Static typing gets rid of a crap-ton of subtly broken code which can only be guarded against with a ridiculous amount of over-testing. You basically need 800% coverage to handle all the special input and output which is handled in frankly insane ways. For example, how many methods treat zero as falsy (`if index`) and how many do the opposite (`if index != false`)?

I don't think we have that same effect in software but I think there is an related one: when you don't have the protection of a static type system, you may become more careful.

It's an interesting theory. On the other hand, the amount of time and money lost to null pointer bugs over the years suggests that we still aren't careful enough.

> I don't think we have that same effect in software but I think there is an related one: when you don't have the protection of a static type system, you may become more careful.

You could use that reasoning to argue we should be writing in assembly. I want all the automated checks I can get to get as close to bug free as possible. If you have to be careful about everything, you're going to exhaust yourself and miss even more bugs. It's much better when bugs are limited to smaller areas and you know where to be extra careful.

I've heard many times something along the line "I can just start hacking on a big refactoring because the compiler will tell me all the places that need fixing".

Well, that doesn't mean it's wrong. I'm far less likely to introduce bugs when "just hacking" on a Flow-typed JS project than I am when carefully (and tediously) trying to refactor an untyped one.

Agree with this. I recently refactored a TypeScript code base for around 3 hours (renaming things, moving functionality into new classes, reducing duplication) without running the code once and it nearly worked first time. Simply renaming a variable in plain JavaScript can be a challenging refactor in comparison.

We all have an attention budget. If a static type system frees us from thinking about certain types of errors, then we can direct that attention to other areas of the task at hand. That's usually a good thing.

Having to be careful because there's no type system checking your work is a useful skill to learn in some contexts, but I think the current state of the software industry is a pretty good argument that human programmers will never be careful enough. So, we should do what we can to accommodate human fallibility and use machines to check our work early and often.

> We all have an attention budget. If a static type system frees us from thinking about certain types of errors, then we can direct that attention to other areas of the task at hand.

A static type system also requires continuous attention. The question is, does it free attention faster than it consumes it?

> A static type system also requires continuous attention.

I'm not sure what you mean by this, or how it constitutes an increase over the demands of a runtime or weak type system.

It means that every time you define a function, or declare a variable, or build a class, you need to explain to the compiler what exactly it is. And if your needs for that variable or class or function change, you need to explain to the compiler the differences. Some languages make it easy to explain to the compiler what's going on, some make it very difficult.

> how it constitutes an increase over the demands of a runtime or weak type system

It's the difference between "I understand X", and "I have to figure out how to describe X in my language". And the difference between "my understanding changed", and "I have to figure out all of the places in my program where I need to update the code because of my new understanding".

> you need to explain to the compiler what exactly it is

I would not call that "continuous attention", because most of the time you're simply writing down a decision you've already made, and would have had to make even in a dynamic language.

In contrast, I think "continuous attention" is having to remember the current kinds of data being held in different variables in a long data-flow.

> And if your needs for that variable or class or function change, you need to explain to the compiler the differences.

Yes, but that's because the compiler is remembering your "checklist" for you. In a dynamic language you'd need to make all the same decisions, but you'd have to waste more brainpower (or introduce more bugs) by trying to manage it all yourself.

> but you'd have to waste more brainpower (or introduce more bugs) by trying to manage it all yourself.

I'll be honest, I've never wasted much brainpower trying to remember the difference between covariant and contravariant, or whether I want Try[Future[String]] or Future[Try[String]], or anything like that, when working in a dynamic language. You just don't do shit like that.

Yeah, but that's because all the wasted-brainpower goes into preventing even dumber errors, like a method that can't quite decide whether a variable is a string or an object or an array.

Part of my job is maintaining a PHP/JS codebase that's 10+ years old, and I wish I had days where it was all about covariance, rather than the stupid stuff.

The thing is, it's pretty good at telling you when you haven't been paying enough attention.

Reply on news.ycombinator.com