25 ms·

38% of bugs at Airbnb could have been prevented by using types

• deleted 8y ago
  [deleted]
• Alex3917 8y ago
  This is probably a side effect of the type system preventing bugs involving js's terrible type coercion system. I doubt that Python would have the same level of bugs preventable by typing, even though it is similarly untyped by default.
  • wenc 8y ago
    Python is actually strongly typed and dynamically typed, not untyped. Even Javascript is not untyped -- it is weakly typed. (not that any of these concepts have watertight definitions, but there's a general notion of what they mean) That said, having used a statically typed language for large scale development, I've come to prefer for static typing even as a Pythonista. Mypy is a partial solution for this -- we'll see what the uptake on that is.
    • Alex3917 8y ago
      Yup my bad, my untyped I meant dynamically typed.
  • ggregoire 8y ago
    Even if it doesn’t help to find bugs, static typing is still worth it. I’ve been fixing some stuff in an existing Python codebase in the last weeks. Most of the time, when I see a new function, I have no idea what’s the type of its parameters...
    • mrfusion 8y ago
      I like to think of python as a language that’s great for responsible adults. If everyone is a good engineer and comments things and tests things you’re going to have a great time. But if you start getting bad practices they’re going to be multiplied.
      • johnfn 8y ago
        Heh. I’d counterargue by asking how many times you’ve heard of someone joining a new job and looking at the code and saying, “Ah, this is clearly written by responsible adults!”
        • Daishiman 8y ago
          Don't be cynical; I've definitely looked for work in companies that have good codebases.
      • doktrin 8y ago
        > I like to think of python as a language that’s great for responsible adults. Not a disagreement, but an observation : verbatim the exact same thing has been said about Ruby, and - I imagine - every other widely used dynamically typed language on the planet. IMO, maintainability is a well understood weakness of dynamic typing - hence every responsible Ruby/Python/JS/Perl codebase including a mountain of unit tests that do nothing but cover typing (in addition to the rest of the tests that would be present irrespective of implementation language) At the end of the day there's no silver bullet : either we let the compiler handle type checking, or we cover it ourselves with unit tests. Doing neither isn't really much of an option, but it is probably where a lot of these type-related bugs come from.
      • weberc2 8y ago
        You also have to unfailingly keep comments up to date. Our org struggles a lot with this, but I wouldn’t say we are irresponsible apart from the fact that we’re using a language that makes humans do error-prone tasks that are already solved by automation. :)
    • dasm 8y ago
      I have very strong opinions on docstrings; they are simple to implement and completely solve this issue.
      • macintux 8y ago
        I wouldn’t say “completely”, because they’re not guaranteed to be accurate, even when first created, much less down the road.
        • yyyymmddhhmmss 8y ago
          Listing arguments and their types in docstrings always feels likea bad idea for this reason.
    • sonnyblarney 8y ago
      "static typing is still worth it. " Or maybe 'flex typing' as we have in TS. I love that TS has 'any' type, because it really allows for some flex in development when you 'haven't figured the dam type out yet' - OR - you're dealing with untyped JSON-ish data. A completed system has 'strong typing'. But a system is always in development. You're trying to do A, but in the meantime, B, C and D need types! And you didn't even know C and D needed to exist. Oops! So you can tweak tsc to be a little lose with the facts and then as the module matures, tighten it up. It's actually kind of interesting that TSC is one of the few 'compilers' (yea I know it's a transpiler) that actually gives you that amount of power over things.
      • int_19h 8y ago
        C# has "dynamic", which is similar in spirit.
      • machiaweliczny 8y ago
        I use TS with transpileOnly flag (compile even if type errors). This is great, because I can prototype fast even if thing's don't yet typecheck and when I have idea what I'm trying to a chieve I can document all code and polish rough cases without leaving the editor.
    • crdoconnor 8y ago
      I usually write code in the ipython console and copy it back once it's in a fit state. Type lookup in that environment is trivial.
    • Alex3917 8y ago
      > Most of the time, when I see a new function, I have no idea what’s the type of its parameters... For that reason I usually use types for defining utility functions that get re-used in multiple places throughout the app. For everything else I just name the variables according to what the thing is, e.g.: user_model, user_model_list, user_id_set, user_id_to_user_model_dict, etc. If you have a good style guide, there really should only be one allowable name for any given variable, and it should be immediately clear what type each variable is from the suffix on the name.
      • cstejerean 8y ago
        Ah yes, the old Hungarian notation (or variation on that idea). Makes sense in some contexts.
      • kaoD 8y ago
        Isn't that just ad-hoc typing? What's the point of naming based on types, instead of just declaring types so they can be programmatically analyzed by your tools?
        • Alex3917 8y ago
          > What's the point of naming based on types More readable. When declaring a type you only see the type when the variable is declared or when it's passed into a function, whereas when putting the type in the name it's obvious in each line where it's used so you don't need to waste working memory on remembering what things are.
    • cstejerean 8y ago
      If you’re using a new enough version of Python 3 then you can add type annotations now. Not great by any means but it’s made working with a large-ish python codebase tolerable (together with PyCharm).
    • Guthur 8y ago
      And so how can you even be sure it does what you think. The types are only part of the equation.
    • xkgihu7r 8y ago
      That's what Hungarian notation is for.
  • mrfusion 8y ago
    Can you explain that idea a bit more? Sounds interesting.
    • int_19h 8y ago
      In JavaScript, "1"+2 is 12. In Python, it's a TypeError. Same goes for most other types. JS is generally happy to convert everything to everything, often via strings. So even utter nonsense, like multiplying a function by an array, still works (the result is NaN). Conversely, in Python, such implicit conversions are rarely in the play - the one you see most is int/float.
  • ernst_klim 8y ago
    Any bug can be caught by the typesystem providing the ability to encode your intention. For example in Rust writing a closed fd could be a type error, not catching all the "exceptions" in OCaml could be a type error, writing out of an array's bounds in Ada could be a type error etc.
• ajxs 8y ago
  There's been some discussion regarding what these Javascript devs are calling "The Typescript Tax" ( Presumably the perceived increased cost of development in a statically typed language ). What greater 'tax' could you possibly conceive of than a whopping 38% of your development time on an enterprise product being spent debugging problems caused by type inference/coercion? You can directly quantify the costs, and it'd probably make management's heads spin. Surely Node.js is going to be looked back upon as one of the worst mistakes in the history of 21st century programming.
  • marcinzm 8y ago
    >What greater 'tax' could you possibly conceive of than a whopping 38% of your development time on an enterprise product being spent debugging problems caused by type inference/coercion? Is there a link where they say they spent 38% of their development time on this? The slide just says 38% of bugs and fixing bugs is not the only way development time is spent and not all bugs are equal in terms of time to debug.
    • macintux 8y ago
      You’re correct, but it’s also true that debugging is often a greater percentage of time/effort than the original coding, so 38% of bugs is nothing to sniff at.
      • shhehebehdh 8y ago
        Although typing bugs are often the simpler type of bugs to fix.
        • Operyl 8y ago
          Until they’re not. I’ve had some codebases where it took 3-4 hours to figure out that some really bizarre issue was really just a type bug. And I don’t consider myself a terrible debugger.
          • 8y ago
• latch 8y ago
  Whenever I hear someone promote static typing for the type of thing you'd use JavaScript for, my first thought is: they aren't testing [properly]. I think static typing unquestionably helps if you have a young and undisciplined team. There are a couple indicators that this is a problem for AirBnB. We know their switch from PG to MySQL was at least partially due to lack of discipline. They're also rely on strict linting, which in my experience, a well gelled well led team doesn't need. UPDATE: My mistake. I confused AirBnB with Uber for the DB switch.
  • bearjaws 8y ago
    Linting and code formatting checks should be strict to help keep people writing to one standard. I don't think its a matter of engineer experience, its more related to 1) time wasted in code reviews because of trivial errors. 2) Scaling a team can be done far more quickly if you aren't having to explain what should be commented, what spacing to use etc.
  • lallysingh 8y ago
    In terms of mistakes caught, type checking can catch errors far before (and far cheaper) than a test can.
    • latch 8y ago
      I don't think you're wrong, but if you believe (like I do) that tests are a time saver, even in the short term, once you have good tests, typing doesn't save 38% anymore..it saves, maybe 1%. I'll add that, in my experience, in an untyped language, you don't need more or even different tests. Why? Because your in either world your boundaries are untrusted (and more than likely untyped) and then everything internal you can trust. User data, external systems, possibly internal systems, queues, storage..all that data is going to be varying degrees of unsafe and untyped. Those entry/exit points need to be fuzzed, unit and integration tested. Again, I don't you're wrong, I just think you want/need the tests anyways (because typing isn't remotely enough).
      • nicoburns 8y ago
• franciscop 8y ago
  I think there's a bigger issue with the narrative here. Sure, types (and tests) help avoiding bugs, and they are definitely useful in large projects like Airbnb. However, they also add a cost that is always ignored, and it's even taboo to talk about it. You don't want to be labeled as an "anti-good-practice" person. But for some cases, this cost is tremendously important IMHO: - Startups: being X% faster at launching your product might mean the difference between life or death for the company. This includes Airbnb back in the day! - Early libraries: not being forced to use a specific type makes it easier to change your mind midway and experiment. Later when the library API is more stable, sure, feel free to add types. Thinking too structured is dangerous when trying to innovate. - Personal projects: where it just doesn't matter if it breaks in some situations and having to build a whole babel tower might discourage you from getting started for fun. As an example, doing "horrible" things I could launch a fullstack prototype in a couple of days, or a decently working prototype in a week. Granted, I would not want to work with that code after 1 month and there would be some bugs, but the ability to get something quick-and-dirty is also very important and something categorically ignored. As an added benefit, this also allows you to iterate quickly, and throw whole pieces of code altogether because you avoid the "sunk cost fallacy" both from yourself and 3rd parties. Please use types, and tests, and other good practices in principle. But also learn when it's good to break those! I get the chills when I think on someone who blindly believes on only using X for everything and anything.
  • bandushrew 8y ago
    " not being forced to use a specific type makes it easier to change your mind midway and experiment." Is that really true? whether the original declaration is strongly typed or not, its likely that changes to the type will result in code changes needed wherever the value is being used. The only thing that no typings does is make it impossible for the compiler to help you find where it is being used.
    • franciscop 8y ago
      Yes, through duck typing. At some parts of my code near the entry point I might not care about what the input "file" is, but later (or the underlying library) for instance might accept both a path or an object for instance. This is specially useful for options that are not used near the entry point, but instead are passed down. If the later implementation changes, you'd have to change the middle implementation as well to accept the new/different types.
• je42 8y ago
  a statement like this doesn't make much sense. if they are not writing good unit tests and integration tests then may be the statement : "X% of bugs airbnb could have been prevented by writing better unit tests and integration tests". is true as well...
  • singron 8y ago
    I think the significant difference between those two statements is that static typing is concretely achievable for relatively cheap effort (i.e. use a language with static typing), but "better tests" is something you will never finish doing. Even if you have 100% code branch coverage, your tests don't necessarily cover all the combinatorial cases that could cause bugs, so you could continue to write "better tests" to prevent further bugs. If the code is non-trivial, the combinatorial explosion is so big that you could probably write 100 times as much test code as implementation code, and you will still have bugs that could be solved by "better tests".
    • je42 8y ago
      like tests - types come with a cost. they are not free and the category of errors they catch are quite simply. also, in my experience, people that depend on types usually skip writing automated tests go directly to manual testing skipping the rest of the testing pyramid.
    • je42 8y ago
      you battle combinatorial explosion by making a risk analysis on the code. you split your code in pieces and unit test those. with unit-tests usually you can get full line + branch coverage, easily and quickly. then you go one level up with the integration tests which these you test highly critical paths where the unittests work together. and finally a black-box e2e test to make sure the pieces work regardless of the implementation details.
• hardwaresofton 8y ago
  Relatively recently I've adopted the stance that JS (via V8+NodeJS) has the best feature set of the "scripting language" tier of interpreted programming languages, assuming ecosystems for your problem are comparable. The combination of compile time type-checking support (via Typescript), parallelism support (recently in v11 w/ worker threads), and built in async IO paradigms give Node a huge leg up over ruby, python, and perl. Weirdly enough, JS is the best in my opinion precisely because it does so much to not be itself. The crazy iteration speed of the JS ecosystem means that people have done crazy things, but the good stuff has remained. Python relatively recently added typing[0], and Matz has mentioned that ruby has no plans to include types in the language proper (though people are working on it). Perl might be the closest in terms of features since it has thread support but... If you enjoyed this hot take, here are a few others you might enjoy: - "extensive" unit testing is a poor man's type checker - developers that don't think specifying types is helpful are still early in their careers (those who suffered in the dungeons of Java get some slack) [0]: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html
  • raverbashing 8y ago
    Wanna do typechecking in Python? Use pylint. No type hints needed
    • dunefox 8y ago
      That's a linter, not a type checker.
  • jaabe 8y ago
    We stopped solely using strong-types after decades of only doing JAVA and C#, and it hasn’t decreased our code-quality. I think most people who’ve spent a significant amount of time with strong-types do them by heart. We didn’t leave strong-typing to leave strong-typing btw, we just started doing more and more with Python.
    • 01100011 8y ago
      Lots of things work when your people and processes are good enough. We don't need seatbelts if we never crash. That can lead to problems with scaling your team if needed, however. At some point you might have to let a moron in, and stronger typing just might be the thing that prevents a catastrophic bug. I did Python for embedded systems for a year. Python is so expressive and well equipped, but the lack of pre-execution type analysis leaves you vulnerable to severe defects unless your testing coverage is 100%. I would prefer Java over Python just for the safety the compilation step provides(and I don't care for Java). I love programming in Python, but system reliability trumps my personal desires in this case.
• brlewis 8y ago
  That 38% -- what strictness level of TS would have prevented those bugs? This question is at the center of the debate surrounding the benefit:cost ratio of using TS. Side note: The article title says TypeScript specifically. The HN title says types.
  • seattle_spring 8y ago
    JS bugs specifically, and it's with strict mode enabled.
• wellpast 8y ago
  It's also possible that even those same bugs could have been prevented by hiring more experienced programmers. Or using non-static verification tools or testing processes or many other tools in the toolbelt. Static typing is an ideology, almost a religion[1]. Not to say that religions aren't bad. They can keep a whole group of people under control. But I really don't like when people say, "See! A static type would have fixed this issue." and then from there conclude that static typing is a good idea. [1] This might piss you off, but it's objectively true. Here's how you know. Because static typing could be easily left as an optional choice throughout the code base but no mainstream statically type PL I know of leaves it optional. That's the definition of an ideology: it says this tool/thing/what-have-you is the right thing to employ for all contexts at all times, regardless of what your own judgement might conclude in the moment.
  • ihm 8y ago
    Types are definitely an ideology of sorts, but that’s not a good argument: gradual typing is complicated and creates a lot of challenges for e.g., compiling fast code.
  • AnaniasAnanas 8y ago
    > Because static typing could be easily left as an optional choice throughout the code base Could it? It is necessary if you use things such as typeclasses for example. Nevertheless, at least haskell has the ability to ignore type errors.
  • sa46 8y ago
    > Static typing is an ideology, almost a religion Dynamic typing is also an ideology by your definition. The ideology is that you must never add static types to your source code. > Because static typing could be easily left as an optional choice throughout the code base but no mainstream statically type PL I know of leaves it optional. I thought TypeScript, Flow, and Python 3 (MyPy) all support optional static typing. Plus, most languages have an escape hatch to treat an object as untyped or as a general type. >"See! A static type would have fixed this issue." and then from there conclude that static typing is a good idea. Why is that not a good conclusion? In the context of the article, static types would have prevented 38% of bugs at Airbnb.
• LaserToy 8y ago
  Each language was created as a tool to solve some specific sets of problems. Saying - this is the only and the best one is a receipe for the disaster and a sign of emotional attachement. Use a proper language for a job be it c, java or python. Don’t try to do silly things, like using JavaScript for all the backend
  • martin_a 8y ago
    > Use a proper language for a job be it c, java or python. Don’t try to do silly things, like using JavaScript for all the backend But all the cool kids are using JS these days! Why would one choose a solid language that doesn't break this easily, when you can just use the cool stuff?
    • Brometheus 8y ago
      Yeah, because Python and C and Java work so well in the browser ;D
      • martin_a 8y ago
        We're not explicitly talking about browser stuff here but developing in general. Seems like the proverb has to be changed: When you only know JS, every job looks like a JS job.
• ragini 8y ago
  I appreciate your efforts because it conveys the message of what you are trying to say. It's a great skill to make even the person who doesn't know about the subject could able to understand the subject . Your blogs are understandable and also elaborately described. I hope to read more and more interesting articles from your blog. All the best. <a href="https://www.besanttechnologies.com/training-courses/python-training-institute-in-chennai">python https://www.besanttechnologies.com/training-courses/python-t... Training institute in Chennai</a>
• deleted 8y ago
  [deleted]
• jakespracher 8y ago
  38% of bugs at Airbnb could have been prevented by better unit tests
  • kurtisc 8y ago
    Yet they didn't have them. Fallible humans didn't see the missing coverage. If they had that hindsight, they could have just not written the bugs at all.
  • starfush 8y ago
    1,000 engineers working on the same pile. there's bound to be bugs and missing coverage.
• _robbywashere 8y ago
  You spend more time reading code than writing code. Something like 80/20; forgive me since I cannot point to a study. Sure more types will mean _more code_ but isn't it nice that code is now explicitly typed; for you to read and understand more? If anything, I think types reduce stress :D
  • z3t4 8y ago
    I used to be a proponent for type annotations in JavaScript. But figured out the reason was because I took C# code and translated it to JavaScript, which surprisingly works well, all you have to do is to remove the type annotations. But without the type annotations I could no longer understand what the code did. To make the code understandable in JavaScript I had to rewrite it, and name things properly. Example: Vector:x * Vector:s vs position.x * speed.x
• cryptica 8y ago
  38%? This is bullshit. Even if that statement were true (which I highly doubt), it is still deceptive because it does not account for: - The 2x to 3x extra time that it will take to complete projects using TypeScript instead of JavaScript. This is time which could have been spent on writing more tests. - The new bugs which TypeScript introduces that JavaScript did not have related to things like source mapping issues, outdated DefinitelyTyped definitions, TypeScript version mismatches, the illusion of runtime type safely when dealing with parsed JSON data from remote clients, etc... I could talk at lengths about the problems but there are so many that it would take me about an hour to write them down. I have over 1 year of experience with TypeScript in multiple projects and earlier in my career I used ActionScript 3.0 (also typed ECMAScript) for over 3 years so unlike the people who make the decision to move to TypeScript, I know what I'm saying. It's going to kill collaboration between projects. I really hope that browser vendors are smart enough to wait for all the hype to die before adding native TypeScript runtime in browsers. I'm certain that the hype will die when people realize that TS is just the same as Java. During the most difficult time in their existence, companies like AirBnb could rely on JavaScript to build high quality software. I think that in reality this move to TypeScript has nothing to do with software quality and everything to do with keeping their employees busy and degrading their skill level so that they will not be able to join a competing startup in the future. This is just a strategy to turn their employees into corporate cattle and keep them locked into some kind of internal AirBnb private module ecosystem which will be completely disjoint from any universal module ecosystem. Developers will use less and less open source modules and more and more private company modules to do their work. The reason is because the company's type system will eventually conflict with the type systems of all third party open source modules.
  • austincheney 8y ago
    > The 2x to 3x extra time that it will take to complete projects using TypeScript instead of JavaScript. I think you are doing something wrong. I switched over to TypeScript for my personal projects 2 years ago and never experienced that. If anything there are a few rare cases where I run into problems up front due to type conflicts, but really each of these cases likely would have resulted in expected maintenance down the road. Problems down the road were pushed much forward. The increase of effort was tiny, and its possible to really say, but this could have been a cost savings over the costly concerns of debugging an embedded problem. > I have over 1 year of experience with TypeScript in multiple projects and earlier in my career I used ActionScript 3.0 (also typed ECMAScript) for over 3 years so unlike the people who make the decision to move to TypeScript, I know what I'm saying. That isn't very much experience for the claims you are making.
• IloveHN84 8y ago
  That's why I hate JS You need 10-12 tools and frameworks to do something and then you are full of bugs everywhere because of the poor designed language. Large systems should rely on industry-proof languages (derived/based on C) to be safe. Not a casa that there are approved coding standards that work (SERT for instance)
  • ernst_klim 8y ago
    >rely on industry-proof languages (derived/based on C) to be safe looking at the CVS list with the amazement C is the Javascript of system programming: weakly typed, everything is an int, error prone, popular, nobody knows all the pitfalls.
    • IloveHN84 8y ago
      I said based on C, not C. Alone C11 brings much more compared to C89. But C++ and C# are pretty solid and robust. Rust is the newcomer, perhaps Go..
      • ernst_klim 8y ago
        C++ and Rust borrow their good parts from ML and Ada, not from C.
        • zozbot123 8y ago
          The "good part" of Rust compared to its closest alternatives is the machine model, which is straight C. You can even directly transpile C into Unsafe Rust.
  • z3t4 8y ago
    The reason why I love JS is that you do not need any frameworks, only the runtime. All you need is a text editor and an API reference (Node.JS, Web browser). All JS code is open source, so you can look at the code of the libraries you are using to see how it does stuff and learn a lot from it.
• jondubois 8y ago
  It's funny how TypeScript proponents seem to acknowledge that Java is bad and yet they consistently fail to point out in what way it's inferior to TypeScript. I've worked with TypeScript for over a year and before that, I worked with Java for about 2 years at university and if anything, Java is superior to TypeScript because it has a much more consistent type ecosystem. Pretty much every Java project uses the same URL class to represent URLs for example. TypeScript has no consistency between libraries and projects - This will be TypeScript's demise; once developers realize how empty and meaningless supposedly universal type names are as an abstraction, they'll be begging to go back to JavaScript. Enforcing a type system which is consistent between all projects is as pretentious as using global variables and yet that is the only way forward for TypeScript as an ecosystem.
  • doktrin 8y ago
    Do TS folks really attack Java specifically? Why? That doesn't make much sense to me. By and large when I hear TS aficionados speak they compare TS to vanilla JS and don't mention Java at all.
    • cryptica 8y ago
      They use this excuse to try to convert experienced Java developers who've seen the light after switching to JavaScript and who are desperate to not go back to the static typing hell hole that they came from. I'm one of these people (2 years of Java at university). The thing is that I know exactly why so many developers like statically typed languages. I've been there in 2006 when I switched from ActionScript 2 to ActionScript 3; I remember clearly the following 2 years of ActionScript 3 when I really thought I loved static types. Unfortunately, I also remember the years after switching back to JavaScript and the huge productivity increase that followed. The problem was not dynamic types, it was my lack of experience. That's why I cannot go back. I'm using TypeScript at work now and although I really love the company mission and I feel that I'm producing really great work, I don't think that I can stay there much longer because TypeScript slows me down and makes me hate coding.
      • 8y ago
• a_imho 8y ago
  If bugs can be caught by using types, can type checking called some form of testing?
  • machiaweliczny 8y ago
    Yes it't test usage of all you functions. But I would say documentation part is more important. This need for typesystem grows with longer feedback loop. You can maybe iterate on react component in playground fast without types, but it's expensive to crash rockets to check if forgot about handling some case.
• egometry 8y ago
  This was Brie Bunge from AirBNB at JSConf Hawaii this past weekend, btw. Great talk, should be online in a few weeks. https://www.jsconfhi.com/schedule/ https://www.jsconfhi.com/schedule/ for reference.
• tziki 8y ago
  This is a surprisingly high percentage. Usually studies have found about 15% reduction when moving from untyped to typed.
  • z3t4 8y ago
    source ?
• gigatexal 8y ago
  Yeah as a python guy myself for years and years I still like languages that are typed. I don’t understand why people hate to define them and rely on constructs like the compiler just to save some keystrokes. I think explicit types make code easier to read and reason about.
  • Rotareti 8y ago
    I'm a Python guy too, and what I like about Python is that I can choose between using it dynamically typed or statically typed. When I start a new script/app, I usually start without type annotations and as soon as the data-model becomes clear, I add type annotations and static type checking via 'typing' and 'mypy'. This is a worklflow I enjoy a lot and I'm very productive with.
    • deleted 8y ago
      [deleted]
• no_gravity 8y ago
  The slide says by 'TypeScript'. Not by 'Types'. So the static code analysis of the typescript compiler would have catched the bugs. Without examples of those bugs it's hard to say if types play a role here. It could very well be that most of these bugs would have been prevented by any static code analysis. Independent of the usage of types.
  • bluepnume 8y ago
    Sure -- but the majority of that static analysis (in the absence of type annotations) is inferring types and then running everything through the type-checker, right?
  • danpalmer 8y ago
    Furthermore, a stronger type system than TypeScript's, Elm's for example, may have caught even more than 38%. For advanced type systems, it's often quite difficult to conceive of bugs that could not be caught by them, although they add a very large overhead.
• amai 8y ago
  But the fashion in programming languages (Scala, TypeScript, Python) to write the type behind the variable name has a disadvantage: When writing code an IDE cannot suggest a variable name based on the type. This is an inconvenience one will notice immediately when you are used to it from programming in Java, where types are defined before the variable name.
  • AzzieElbab 8y ago
    Ummm reassignment is a rare thing in scala
  • sime2009 8y ago
    Most of the time in TS you just rely on type inference and don't write out the type at all.
• robbick 8y ago
  38% seems insanely high. Other estimates I've seen suggest more like 10%. If a code base has an unusually large amount of bugs caught by types it feels like it is missing basics like decent code review or unit tests. * I am a huge TS fan I just don't think 38% of bugs a well written JS app should be type based
• deleted 8y ago
  [deleted]
• z3t4 8y ago
  100% of all bugs would be prevented if you could travel into the future and look at the bug patches - postmortem analysis.
  • Forge36 8y ago
    Well sure, but what are the corrective steps? 38% of bugs could have been caught sooner/prevented with types. The question to ask: What percentage of the 38% would have been avoided? Similar problems have been solved in the past: what percentage of index out of bounds errors were caught because the concept was adopted by the language?
    • z3t4 8y ago
      Can you give more context. What language are you talking about ? What if I spent five minutes extra looking at the commit, would that have spotted the bug ? In order to give a fair conclusion, you should also look at commits without any bugs, like a blind test to reduce bias, and measure false-positives (errors that are not bugs). Maybe also use modern tools like inference engines that did not exist back when the bug was made. And compare with other techniques like unit testing to see which one is more effective, and to see if there are any synergistic effects.
• mcv 8y ago
  The arguments in that threat aren't very good. Everybody makes mistakes[0], types or not, and a type system doesn't prevent all errors. Every system that prevents errors comes with its own overhead. I think there are situations where explicit types are good, and situations where they're unnecessary or get in the way. Java's use of generics is a good example of the latter: ArrayList<String> list = new ArrayList<String>(); One of those just shouldn't be there. (Edit: Java 10 apparently added type inference, which means this is not necessary anymore.) But in function parameters, it's incredibly useful to be able to ensure that the parameters are of the type you expect (and preferably not null, which most languages don't offer). That prevents a lot of unnecessary boilerplate checking whether you actually have the right type in your hands. Basically I don't need explicit types for stuff I declare locally, because I can see in the code what type it is. But for parameters and other data I get from other parts of the system (ajax calls, for example), enforced types are incredibly useful. [0] Except Donald Knuth, who apparently cannot make mistakes.
  • woah 8y ago
    Do you know about type inference?
    • mcv 8y ago
      I do. I thought Java didn't have it, but apparently starting with Java 10, it does. Type inference isn't always good, though. Scala's type system can be quite horrible in places, although I think the idea is generally good, particularly for local variables.
  • hocuspocus 8y ago
    Local variable type inference was brought to Java with the version 10.
    • mcv 8y ago
      Ooh, nice. That sinks that part of my argument, I guess. Still, it doesn't change the fact that some type systems are cumbersome in some places, yet valuable in other places. I think we're currently seeing a movement towards type systems that do more for you while getting in the way less, and that's certainly useful.
• danaliv 8y ago
  To me the biggest benefit of static types, type hints, annotations, etc. is their documentation value. I don't have a particularly strong opinion on the issue of static typing generally, but if you don't use types, you damn well better document what your functions expect to receive and what they produce. It is so frustrating to jump into a codebase and have to read every single line to figure out what the inputs and outputs are. Think about how much time is wasted. It's like an anti-multiplier. One engineer decides they don't want to take a few minutes to annotate types or write a comment, and now every other engineer on the team has to waste time figuring out what's happening. It makes me want to scream.
• drderidder 8y ago
  The typescript fever smells like most of the other herd stampedes over the past several years. Check out this talk from a few years ago by Eric Elliot "Static Types are Overrated". He goes over how types don't mean fewer bugs, and if you're getting a lot of type-related problems it's probably got more to do with your testing hygiene. He also just wrote a summary of 2+ years using TypeScript and why it turned out to be more of a liability than a benefit.
• iblaine 8y ago
  And this is ok. A shift away from strongly typed languages encourages laziness. A shift towards resilient micro services accommodates laziness. It’s good enough to get by and allow large companies like airbnb to grow. Clean code vs time to market is a debate that’ll never end.
• tonymet 8y ago
  One thing I've always liked about typing systems is the compiler basically shaming me with "do you really know what you're doing". also small refractors are more graceful
• deleted 8y ago
  [deleted]
• sharno 8y ago
  We use Purescript at work. I don't remember the last time anyone on the team needed to fix a bug in the Purescript code. Our team had to fix around 4-5 bugs in the JS code in the past week alone. The Purescript code is really well designed with proper usage of types everywhere possible. Refactoring is done in Purescript fearlessly, if it compiles it'll run correctly or there's a bug in the JS or backend code that sends wrong data to it. I really wonder how the ecosystem of frontend would be if Purescript became a widely adopted language