4 ms·

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 comm

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 https://news.ycombinator.com/item?id=15141495

21 9y ago
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".
- kcorbitt 9y ago
  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.
  - seanwilson 9y ago
    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.
Silhouette 9y ago
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.
sidlls 9y ago
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.
- l0b0 9y ago
  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`)?
seanwilson 9y ago
> 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.
elihu 9y ago
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.
- mcphage 9y ago
  > 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?
  - mercurial 9y ago
    The thing is, it's pretty good at telling you when you haven't been paying enough attention.
  - Terr_ 9y ago
    > 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.
    - mcphage 9y ago
      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".

21 9y ago

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".

kcorbitt 9y ago
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.
- seanwilson 9y ago
  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.

Silhouette 9y ago

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.

sidlls 9y ago

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.

l0b0 9y ago
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`)?

seanwilson 9y ago

> 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.

elihu 9y ago

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.

mcphage 9y ago
> 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?
- mercurial 9y ago
  The thing is, it's pretty good at telling you when you haven't been paying enough attention.
- Terr_ 9y ago
  > 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.
  - mcphage 9y ago
    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".