5 ms·

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

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.
munificent 8y ago
> 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. It is actually not easy to design and implement a statically typed language that gives you all of the benefits of types when you want them while still allowing you to ignore them in some regions of your program. The gradual typing folks poured years of time into this and still haven't figured it out. Optional typing is more workable, but sacrifices many of the benefits (soundness, performance) of static types even in code that is fully typed.
- z3t4 8y ago
  You can have static types with type inference. I would actually prefer static typing if I did not have to annotate everything. But there are convenience trade-offs like not having to cast when you actually mean to concatenate the number with a string.
  - munificent 8y ago
    No, inference doesn't have anything to do with it. Inference is easy. The challenge is around the runtime representation of types. Almost all widely used statically typed languages maintain soundness by deferring some type checks to runtime. C++ has dynamic_cast. Java has ClassCastException and ArrayStoreException. C# has something similar. When you add gradual typing where values and functions from untyped code can flow into regions of typed code, you need even more runtime validation to ensure you don't get uncaught type errors in your typed code. The difficult then is figuring out how to represent those types efficiently, what types to reify, etc. It's really really difficult.
    - z3t4 8y ago
      Most people talk about catching errors, but I think the the biggest benefit with static types is performance - as it makes the code easier to optimize. With TypeScript you do not get that benefit. Maybe we will see a new variant of "use asm" for JavaScript, but more human friendly. I really wish TypeScript would have used type inference instead of annotations, and only have a type-checker, and not transpile. JavaScript is already strongly typed. And a completely static type system is a pipe dream, as anything connected to the real world have to deal with chaos.
machiaweliczny 8y ago
With Typescript you can set 'any' as default type and only type/document what you want. It really feels gradual.

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.

munificent 8y ago

> 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. It is actually not easy to design and implement a statically typed language that gives you all of the benefits of types when you want them while still allowing you to ignore them in some regions of your program. The gradual typing folks poured years of time into this and still haven't figured it out. Optional typing is more workable, but sacrifices many of the benefits (soundness, performance) of static types even in code that is fully typed.

z3t4 8y ago
You can have static types with type inference. I would actually prefer static typing if I did not have to annotate everything. But there are convenience trade-offs like not having to cast when you actually mean to concatenate the number with a string.
- munificent 8y ago
  No, inference doesn't have anything to do with it. Inference is easy. The challenge is around the runtime representation of types. Almost all widely used statically typed languages maintain soundness by deferring some type checks to runtime. C++ has dynamic_cast. Java has ClassCastException and ArrayStoreException. C# has something similar. When you add gradual typing where values and functions from untyped code can flow into regions of typed code, you need even more runtime validation to ensure you don't get uncaught type errors in your typed code. The difficult then is figuring out how to represent those types efficiently, what types to reify, etc. It's really really difficult.
  - z3t4 8y ago
    Most people talk about catching errors, but I think the the biggest benefit with static types is performance - as it makes the code easier to optimize. With TypeScript you do not get that benefit. Maybe we will see a new variant of "use asm" for JavaScript, but more human friendly. I really wish TypeScript would have used type inference instead of annotations, and only have a type-checker, and not transpile. JavaScript is already strongly typed. And a completely static type system is a pipe dream, as anything connected to the real world have to deal with chaos.

machiaweliczny 8y ago

With Typescript you can set 'any' as default type and only type/document what you want. It really feels gradual.