12 ms·

> Static Typing reduces bugs. At least to me, the big advantage of static typing is not that it (allegedly) reduces bugs, but that it aids my understanding and

• mlyle 4y ago
  And that's covered right there by the caveats.
• glouwbug 4y ago
  Until the types don't match the execution model... see: python type hints
  • slaymaker1907 4y ago
    I find that is a far less common problem than the documentation being wrong. Even if someone doesn't add documentation for some library, static types provide a lot more insight into how it works than dynamic languages (Racket style contracts are even better since they can check way more than static types while still working in a first class way with docs).
  • HL33tibCe7 4y ago
    That isn’t static typing That’s a dynamic typed language with comments
    • OJFord 4y ago
      They can be consumed by static analysis tooling, which assuming properly configured etc. makes it sort of 'dynamically typed language with the guarantees of a statically typed one', at least so far as the hints are complete.
    • semiquaver 4y ago
      Most statically typed languages compile down to object code which runs in one of the most dynamic runtime environments imaginable. What are the types in the source code but “comments”?
• _the_inflator 4y ago
  I agree. At least for JavaScript I would always use TypeScript now. The main reason is understanding of code as well as tooling, which means communication in the end. I remember working 2012 on a SaaS app, and I wasn't the only guy anymore doing frontend stuff with JS. I knew my objects, but my colleagues did not. How to you document object APIs? TypeScript really shines in large projects with lots of devs.
• dmitriid 4y ago
  As long as the types, variables and function names have proper names. And not `A -> A -> B -> [B, D]` (looking at you, Haskell).
• onion2k 4y ago
  that it aids my understanding and helps in navigating the program Static typing reduces bugs because it aids your understanding.
  • cloogshicer 4y ago
    Not necessarily. This increased ease of understanding could also simply result in faster development speed - so same number of bugs, but more features in less time. Not sure though.
    • lolinder 4y ago
      So fewer bugs per feature. Assuming that the total number of features required is the same either way, by the end you're still left with fewer bugs.
  • silisili 4y ago
    Well, it also fails to compile. Which to me is better than blowing up at runtime, or worse, not blowing up but giving weird results.
    • ghettoimp 4y ago
      This is a superpower during refactoring.
• CraigJPerry 4y ago
  Static typing has an undisputed benefit, performance. If i need to add dynamic thing a and thing b, I’ll always have the overhead of figuring out what add means first in this context, an overhead i dont have when asked to add some ints. All the other claims from readability to understandability to refactoring to less bugs, all come with an “it depends” caveat. Sometimes the claims are true, sometimes they’re not. It’s also not possible to say “but in most cases claim X holds”. The thing I’ve never understood yet in this debate is in my experience, the people who have argued about correctness have universally been below par at getting to the bottom of requirements. Which leads to “great, you correctly built the wrong thing. And you took forever to do it.” Which isn’t doing our profession any good in the eyes of other professions who depend on us.
• sumy23 4y ago
  It’s basically self-evident that static analysis reduces bugs. It’s trivial to construct an example of where type information would catch a bug. Unless there is some reason that including type information increases bugs, the existence of a single example where type information catches a bug would prove that overall type information reduces total bug count.
  • thom 4y ago
    One could argue that dynamically typed code is often shorter, and therefore both easier to reason about, and possessed of fewer bugs on a bugs-per-line basis. Not really keen to push that line of reasoning myself, just helping picture one possible argument.
    • mdtusz 4y ago
      This is true in a local context, but entirely breaks down when a codebase becomes larger than a single person can fit into their brain-RAM. Not arguing or saying you're wrong - just presenting the very quickly reached boundary where the argument breaks down.
      • BlargMcLarg 4y ago
        It's not just local context. Reading a dense book is still more difficult than reading a less dense book, given a fairly similar amount of information and style in conveying that information. Larger codebases suffer the same problem you mention in a different way, and cargocults in most static languages tend to advocate very verbose writing styles. Where this falls apart, the more verbose writing style hasn't been proven to convey more information or in a better way. That's an assumption still tossed around.
        • kangda123 4y ago
          It is just a fair bit harder to figure out the types as program grows.
• klysm 4y ago
  Refactoring with confidence that you didn’t forget somewhere.
  • repsilat 4y ago
    Yeah, a common mode when I'm making changes is "add a field to the type, run the type-checker, fix all the failures." In a sense "type coverage" is analogous to test coverage.
    • klysm 4y ago
      I use this workflow so frequently - writing it the first time is harder but, changing it is so much easier that it’s absolutely worth it to me.
  • Gigachad 4y ago
    This is the major one. I work on a 10 year old rails app and it has got to the point where we are terrified of making any change that has the potential to affect areas outside of the visible git diff. It's easy enough to manually verify regular changes by looking at the code. But something like a library update is impossible to verify and we constantly end up with production issues because of something changing in a library that wasn't mentioned in the upgrade guide and would be impossible to have considered beforehand. But that a type system would catch.
    • klysm 4y ago
      Sounds exactly like every dynamically typed code base I’ve ever worked on. Even if it’s not big. If you can’t grow out all the parts that matter (which is a lot of the time), you are screwed.
• OJFord 4y ago
  Allegedly? Have you ever written code in a dynamically typed language? I'm forever fixing TypeErrors and AttributeErrors and the like. I suppose it's not even necessary to argue about experience fixing them or not, just the fact that those are runtime errors rather than compile-time (and so we presume not shipped) shows it reduces bugs doesn't it?
  • moffkalast 4y ago
    I'd say it reduces bugs... in size, making them harder to find.
    • haswell 4y ago
      Reduces bugs in size, or only leaves smaller bugs behind? These are two very different outcomes. If the remaining bugs are unrelated to the class of bugs that were eliminated entirely, then the difficulty in finding them has little bearing on the outcome, since we’re now talking about an entirely different class of bugs.
      • moffkalast 4y ago
        This is conjecture, but in my experience you'd get the following: - in JS, your code will run with the bug then do something catastrophic during runtime that you can then notice and trace to the core issue - in Java it won't compile, so you fix it so it compiles and runs, then it'll hit you in like 2 hours of runtime with a NPE or something and you'll have no idea what caused it Maybe Kotlin, Rust, and the like solve that sort of thing better but I've yet to be convinced.
        • haswell 4y ago
          But is there any evidence that the NPE would have blown up catastrophically without type checking? Is the NPE even related to type checking? It seems you're describing an orthogonal issue, and it's unclear why type checking is a Bad Thing or even related to the NPE at all. Let's say I work on an assembly line, and must place physical parts into a machine that assembles a larger part. There are many ways this machine can break down - I could put the wrong parts in, leading to a complete failure, or some part of the machine could malfunction independently. - We could implement part validation on the assembly machine to make sure it's impossible to insert the wrong parts. This eliminates failures related to incorrect part insertion. - Unrelated to this, a drive belt starts to wear out and slips every so often, leading to a slight slowdown in a conveyor belt, which ultimately leads to a botched item. The way I read your argument, you would say that part validation is bad, because it's easier to diagnose a meltdown when incorrect parts are inserted by the operator than it is to determine that the drive belt is slipping. Except the drive belt slipping is not related to operator error, and would have happened whether part validation was happening or not. This is hopefully obviously nonsensical - better to reduce the overall error rate by implementing part validation than to leave two avenues for error. Before part validation, the machine could fail because of operator error (common) or drive belt failure (uncommon). After part validation, only the uncommon error occurs. This is better than no validation at all, even if drive belt failure is harder to identify than the machine screeching to a halt when the wrong parts are inserted. What am I missing?
• jacobsenscott 4y ago
  I've never found static typing to aid in my understanding of a program. For example: def add_item_to_cart(item) vs void add_item_to_cart(IItem item) They are equally easy to understand. The first is easier to read.
  • joeldo 4y ago
    What is an item in the first declaration? Is it an id? Is it an object (if so, what type of object? Id and qty or some other data)? I guess you now need to read through the implementation or docs. The first is much easier to read incorrectly.
    • bjourne 4y ago
      What is an item in the second declaration? That it has type "Item" doesn't help you unless you have contextual information. And if you have contextual information you can probably figure out what an item is in the first declaration too.
      • joeldo 4y ago
        I would argue that it isn't a zero-sum game. Extra context (that is enforced) is better than none at all.
      • kdtsh 4y ago
        An item is an IItem, as it says in the definition. You can always ‘figure out what an item is’ in a dynamic typing system, that’s not the problem. There’s an incredible amount of mental overhead in any non-trivial project which employs dynamic typing. Engineers who can work around this have my respect, but I find static typing to be the easiest solution to this problem by far.
        • bjourne 4y ago
          That fact is useless without any context. An "item" could have been an "Ifdkjsj" and you'd be none the wiser. "incredible amount of mental overhead" needs a citation and, as shown in TFA, no citation exists.
• fifticon 4y ago
  I'm not against studies and research - I have a computer science degree myself - but I'm a little tired of being told my personal anecdotal evidence is not sufficient to conclude that water is wet. As a professional software developer of 30+ years, the doubts on static types puzzle me. 8 years ago, I started dabbling more in javascript, for one of my continuous pet projects. I had it running and grew it to a considerable size, but after a year or two, I lost patience with debugging runtime issues, hunting for where I had forgot to update or initialize or remove stuff, during refactoring. I swore an oath never to use raw javascript again, and rewrote it from scratch in typescript. I am still working on it to this day, and I don't remember being angry at typescript a single day in the intervening 7 years. My working day jobs have been mostly C++, and these days C#. Periodically, I will temporarily inherit some of my younger colleagues' projects, if they move on to greener pastures in different companies, with the charter of "can you do something about the long-running issues this software has been having?" My go-to solution is to go through their typescript and add return types to their functions, and replace their anys with interfaces. After having done that, I fix the bugs that revealed, and then I'm usually done. Recently when I did that, I came across a central class/data structure, which turned out to exist in no less than 5 slightly different variants. i.e. different parts of their code adhered to 5 different assumptions about what fields would exist and be populated (but all expressed on the blank canvas of 'any').
  • bergenty 4y ago
    • shepherdjerred 4y ago
      JavaScript is a fantastic language once you understand how it really works. If you do truly understand the language then maybe you should use something that compiles to JS.
  • kraf 4y ago
    I think we need to be careful with trusting even our own anecdotal evidence because it's simply riddled with biases and bugs. 30+ years of experience is certainly impressive but I'd say you probably never worked in a senior team on a larger Clojure codebase for example which would give you quite the opposite impression. You should read the anecdotal evidence in that community, it's very different.
• koonsolo 4y ago
  This, and especially when you have a new person in the team that needs to dig through the code. function myFunction(user, security) { } good luck finding out what user and security actually is. In static typing, it's all there.
• danpalmer 4y ago
  > It's a tool for thinking and communicating. And when we understand this, we can weigh it up with alternative tools for thinking and communicating! Would this 10 line shell script be better in a statically typed language? Well maybe not because I can hold all of 10 lines in my head, there's nothing else to communicate. Would this CRUD app using Django/Rails be better with static types? Well the framework has defined a structure that communicates properties of the code to me, I don't need types written down because I already know them. Would this complex parsing process of untrusted data into a trusted and verified format benefit from static types? Yeah probably, testing will be tricky and code review for security is hard, types will help reason about the possible states of the system. There are lots of alternatives to static types: documentation, testing, frameworks, design patterns, code review, pair programming, error messages, and so much more. I'm generally a fan of static types and find them very useful in a lot of development, but they are a tool in a big toolbox.