6 ms·

Well, people have always been fanatical about thing a they are attached to emotionally, rather than rationally. Fact is: the “types lead to fewer bugs” claim i

• purpleblue 3y ago
  It leads to fewer bugs of a certain type, but there are plenty of bugs being generated in statically typed languages in different ways.
  • mpweiher 3y ago
    The overall bug burden does not change. Why this is we do not know. But we do know that it is true.
• Chabsff 3y ago
  "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.
  • mpweiher 3y ago
    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.
    • Chabsff 3y ago
      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.
      • mpweiher 3y ago
        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.
        • Chabsff 3y ago
          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.
          • mpweiher 3y ago
            > 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.
            • spion 3y ago
              https://www.bmj.com/content/363/bmj.k5094 https://www.bmj.com/content/363/bmj.k5094
  • taeric 3y ago
    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.
    • Chabsff 3y ago
      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.
      • mpweiher 3y ago
        > the matter is settled enough Based on what evidence? Apart from emotion?
        • taeric 3y ago
          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.
  • nurple 3y ago
    "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.
    • Chabsff 3y ago
      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.
      • mpweiher 3y ago
        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.
        • Chabsff 3y ago
• nercury 3y ago
  The argument for static types is that it makes type bugs impossible because the types are static. There is no emotional attachment other than rage when faced with "but but it does not eliminate ALL the bugs!!!!!!".
  • mpweiher 3y ago
    Please read the article. The objection is not that all bugs aren’t eliminated. The objection is that there is no empirical reduction in bugs.
    • nercury 3y ago
      Your article says "there is no empirical reduction in bugs" and nothing else.
  • ReflectedImage 3y ago
    Type bugs are so rare in regular code that it's significantly insignificant when measured during research studies. From a code correctness point of view, static typing is simply speaking useless. You should have spent the time statically typing your code on writing more tests.
    • ReflectedImage 3y ago
      *statistically insignificant
• iopq 3y ago
  Heartbleed is not a type error in C, but it's a type error in Rust Rust has a more powerful type system that actually fixes MOST of the memory bugs in production
  • mpweiher 3y ago
    And you simply can't have that sort of error in Smalltalk. ¯\_(ツ)_/¯
    • jjnoakes 3y ago
      You absolutely can.
      • mpweiher 3y ago
        That turns out not to be the case. Smalltalk is memory safe and dynamically type-safe. That is, you cannot invoke an inappropriate operation. You can try to do that, but the system will refuse to do so.
        • jjnoakes 3y ago
          It's trivial to store sensitive data in a collection, for example, and then index it with the wrong index when trying to access and export adjacent non-sensitive data.
          • iopq 3y ago
            That's assuming you're mixing sensitive data and insensitive data in one collection. Heartbleed was access of random memory, a much more serious exploit
• miloignis 3y ago
  You're making a very strong statement, so we might as well look at extreme cases, namely the formally verified middle-end of CompCert: https://users.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf https://users.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf I believe this would count as empirical evidence of very strong static typing reducing bugs. I think this points to what many other comments have been getting at, which is that typing is not a binary yes/no question, but a large, multi-axis (static/dynamic, strong/weak) spectrum with lots difference between type systems, as well as big differences in how people apply those type systems to their problem. You could still work in a static, strongly typed language and represent everything as strings, converting back and forth as necessary, but that's essentially working in a dynamically typed language. You could also take advantage of the tools the type system gives you in order to reap the benefits, creating classes representing the legal values and asserting important invariants.
• unstruktured 3y ago
  The author of that link references the top 25 bugs, one (#12) of which is Null pointer dereferencing- static typing outright eliminates that bug. Not to mention that range checking is also fixable by using optionals rather than assuming the existence of a value.
• fnfjfk 3y ago
  Academic papers are often very disconnected from industry reality. I’ve worked on reliability at a company everyone has heard of for software that billions use daily. So many bugs would have been blocked by having a type system at all (dynamic languages on backend or JS on web) or by having a less bad type system (changing ObjC to Swift and Java to Kt on mobile). Null pointers/references alone have created so many bugs for us. Bugs that could have been compiler errors.
• magicalhippo 3y ago
  The fact that strong static types makes the code self-documenting is the reason I vastly prefer it. It makes me so much more productive, by orders of magnitude. And I say this as someone who has worked extensively in several different languages which covers large parts of this spectrum, like C, C++, Java, Python, JavaScript, TCL and others. It makes it much easier for me to reason about code I have not recently worked on, be it in the current project or in dependencies. It also means I can be way more focused on the problem at hand, since I'm not constantly having to go on tangent goose chases to figure out what exactly I can do with this object that some function returns. Sure there's the good, fuzzy feeling when the compile doesn't error out. But that's secondary.
  • ReflectedImage 3y ago
    Statements like: "The fact that strong static types makes the code self-documenting is the reason I vastly prefer it." is exactly the reason why you shouldn't be use static typing. We have a developer here who doesn't document any of their code and thinks that a good thing. Whereas in the dynamic typing world, they would be forced to use the good practice of documenting their code. Code is never self-documenting, there are research studies on it.
    • magicalhippo 3y ago
      You misunderstand. I'm not advocating you shouldn't comment or document your code. Sure I can see you multiplied that gross weight by a factor of two, but why? That usually needs to be documented. But the types provides for let's say code-level self-documentation. I can look at a function definition and see it returns an IReadOnlyStream. Well if I'm familiar with IReadOnlyStream I already know what I can do with that. If not I can quickly find the declaration, and based on that I can get a good overview of what I can do. If not I have something explicit to search the documentation for. With languages such as JavaScript I learn nothing by looking at the function definition, and almost always have to dig deeper. If it's an unfamiliar code-base, then often much, much deeper.
      • ReflectedImage 3y ago
• mrkeen 3y ago
  > Well, people have always been fanatical about thing a they are attached to emotionally, rather than rationally. How would you feel if I claimed that you could make emotional arguments faster than you could make rational arguments? Because that is how this debate feels! I want the simple rationality of my compiler saying "no" if I try to treat my hashmap like an Apple or a String.
• tomtheelder 3y ago
  Research on this topic is beyond impossible and should be completely disregarded. You cannot possibly attempt to control for variables sufficiently, and I don’t think even the most fervent supporters of type systems would argue that they are a dominant factor in code quality and correctness.