Hacker News Reader

Comment by Chabsff | Hacker News Reader

"Types lead to fewer bugs when making changes to long-lived codebases" is not up for much of a debate in my opinion. Preventing regressions is arguably a lot more important than writing a correct first pass, which is what you are evaluating when looking at non-evolving code.

Concretely-speaking, an example of a bug being preventd by a typing system: Removing a field from an object in a large vanilla JavaScript project is inherently a minefield that has caused many bugs in the past, whereas the same alteration in a full Typescript project can be made with confidence.

View on HN

It’s no longer up for debate, true.

But not in the way you fervently want to believe.

Once again: people have tried to show the truth of this for a long time, and they have consistently failed.

I'm arguing that the studies linked in that blog post are fundamentally flawed because they only take into account first-pass development, and fail to take long-term maintainability into consideration. And this is silly because that's where the main value of type systems reside.

> This paper presents an empirical study with 49 subjects that studies the impact of a static type system for the development of a parser over 27 hours working time.

That is not true.

There are some studies like that, but there are others as well.

And remember that all these studies were trying to find a positive effect, but failed to do so.

Well... It is true of everything in that blog post.

But I am wiling to have my mind changed. I would be really interested in seeing a study that failed to find a benefit of type systems for refactoring tasks in large projects. The example I posted in my initial comment seems pretty open-and-shut to me, so I'm curious.

> Well... It is true of everything in that blog post.

That turns out not to be the case.

> I would be really interested in seeing a study that failed to find a benefit of type systems for refactoring tasks in large projects.

You're inverting the burden of proof here. People who claim that something is beneficial are the ones who have to show that it is.

Making a claim and then shouting "prove me wrong!" is not how science works. Not even computer science.

https://www.bmj.com/content/363/bmj.k5094

And yet, if the signal was that strong, it should be clear. It's not.

It... should be up for debate? I'm fine taking it as a given in projects I'm running. But I do expect people that have the ability to do so, to debate it. Preferably to study it and find concrete evidence.

Admittedly, that was a bit hyperbolic on my part.

What I meant to convey is that the matter is settled enough from my point of view that there needs to be a very strong case being made for me to be willing to engage in that conversation.

Thanks for pointing this out, I've amended the comment to clarify a bit.

> the matter is settled enough

Based on what evidence?

Apart from emotion?

Charity to the idea, when boots are on the ground to do the actual work is a terribly place for running that debate. :D Is why I'm in agreement enough for projects I'm working on. I am open to the idea that we find more evidence and/or change our minds for the next project, but "when in Rome" is a good reason to drop the debate and basically declaim what your driving idea is at the start.

"Types let me make changes to code I haven't taken the time to understand" is hardly the proof you seem to think it it's.

Removing a field in a data structure is such a big problem, even in typed systems, that the most ubiquitous serialization IDLs, and customer-facing API conventions, don't even allow it.

And I would contend that anyone claiming "I am capable of taking everything about the code I am tasked to change into consideration" is delusional when it comes to non-trivial projects, including single-dev endeavors.

As far as serialization IDLs and API conventions go, they have the very special constraint of having to provide both forward and backwards compatibility across multiple applications, making them a very poor universal example.

Is there anyone making that claim? Apart from straw-men?

As an example, I was once refactoring a Java system. The compiler was happy after about a day, the unit tests after three days.

So if you claim your type system is going to keep your refactoring safe, I'd say that I'm not the one being delusional.

And of course unit tests also tend to, in practice, catch the errors that are caught by types. If you check that a value is equal to 10 rather than 9, you've also implicitly checked that it is not of type PinkElephant.

Now I perfectly understand the feeling that people who are used to the safety-net that static typing appears to give have when encountering a code-base without types. I have the same feeling when encountering a code-base without reasonably comprehensive unit tests (that fail when I poke into the code-base).

The feeling is absolute terror.

I just contend, with reasonably good justification, that this feeling is not particularly justified in the case of static types, because the evidence is just not there.

I haven't checked what the evidentiary status is for unit tests. But then again, I don't make these sorts of categorical claims for unit tests. I just make claims for my experience with unit tests.

> Is there anyone making that claim? Apart from straw-men?

For every intent and purpose, the person I'm replying to is, with an equivalent level of straw-man-ness, which is why I phrased it this way.

> So if you claim your type system is going to keep your refactoring safe, I'd say that I'm not the one being delusional.

No, I'm claiming that there are entire categories of bugs that are protected this way, not that it provides universal safety.

> And of course unit tests also tend to, in practice, catch the errors that are caught by types. If you check that a value is equal to 10 rather than 9, you've also implicitly checked that it is not of type PinkElephant.

It provides that if and only if the code invoking the tested function is called with arguments using the same semantics as the ones exercised in the tests, which is impossible to enforce in a dynamic language. I'd even go so far as saying that it is axiomatically impossible for unit testing to be a truly reliable tool in such languages because of the lack of precondition enforcement.

> the person I'm replying to is [making that claim]

Er, no. I certainly wasn't, and the person you were replying to above that was making the opposite claim: that it's harder than that.

And no, the type system doesn't really help all that much, once you have unit tests. Because unlike the unit tests, which checks values (and obviously the types as well, incidentally) the type system only checks the types.

So, trivially, if you mix up addition and subtraction, your unit tests will rightfully balk, whereas your type system is going to be "works for me".

As I wrote elsewhere in this thread, in my personal experience the type system was happy during a large refactor long before the unit tests were. Which means that there was a lot of stuff that the type system missed.

And so if you feel your type system is going to make your refactors safe, well, good luck to you and the poor people who have to use your code.

To address the unit test stuff: I'm not saying that type systems replace unit tests. I'm saying that unit testing in dynamically typed languages is fundamentally deficient. Or in other words: unit tests are made more reliable by type systems.

Unit tests can only check outputs for the inputs that are provided during testing. Leaving the input unbounded means that they can only provide guarantees for code that conforms to the tested subset of inputs.

I may be able to test that `foo(3) == 4` and foo("foo") == "bar", but since I can't guarantee that `foo({})`, or literally anything else, will never be called, there will always be holes in the safety net they provide. This is something type systems directly address.

> And so if you feel your type system is going to make your refactors safe, well, good luck to you and the poor people who have to use your code.

safer. It makes them safer, not automatically safe.

I often rename a field in a typed language, just as a way to ask the compiler which parts of the code are affected by or use that field then I continue my reading there.

Its like a grep, except it can, for example, differentiate between "name" (of user) and "name" (of project)

> "Types let me make changes to code I haven't taken the time to understand" is hardly the proof you seem to think it it's.

I don't think you even understood the point at all here. "Types let me make guided and exhaustive changes to code that's much easier to understand due to the types and compiler support"

Reply on news.ycombinator.com