Re:38% of bugs at Airbnb could have been prevented by using ...
by hardwaresofton on Sunday February 10, 2019 @11:16PM
(#19132025)
> null/undefined is an inhabitant of every type in typescript, I would suggest purescript instead.
You're right -- but I've found in practice that strict null checking[0] is more than enough. Also I assume that Purescript has a similar bottom value as haskell[1] (please correct me if I'm wrong).
> I think you mean the ability to add explicit types to variable names. It always had types.
Yep -- I actually meant literally the `typing` module[2].
> Certainly.. iff you use dependent types.
You can get some good guarantees with container types (`newtype` in haskell terminology) that are constructed in a very specific way, assuming you have immutable values. For example, defining some type `NonZero<Int>` in typescript w/ `private readonly` interior value.
> Why specify types if they can be inferred? Why do work that our computers can do for us?
You're right -- I misspoke (misstyped?). By all means if inference is possible that is also fine.
Somewhat seperately, the statement stands as far as type signatures (i.e. `doThing :: Input -> Output` or `function doThing(in: Input): Output`) go -- they're great benefits to a codebase in my opinion.
You're right -- but I've found in practice that strict null checking[0] is more than enough. Also I assume that Purescript has a similar bottom value as haskell[1] (please correct me if I'm wrong).
> I think you mean the ability to add explicit types to variable names. It always had types.
Yep -- I actually meant literally the `typing` module[2].
> Certainly.. iff you use dependent types.
You can get some good guarantees with container types (`newtype` in haskell terminology) that are constructed in a very specific way, assuming you have immutable values. For example, defining some type `NonZero<Int>` in typescript w/ `private readonly` interior value.
> Why specify types if they can be inferred? Why do work that our computers can do for us?
You're right -- I misspoke (misstyped?). By all means if inference is possible that is also fine.
Somewhat seperately, the statement stands as far as type signatures (i.e. `doThing :: Input -> Output` or `function doThing(in: Input): Output`) go -- they're great benefits to a codebase in my opinion.
[0]: https://basarat.gitbooks.io/typescript/docs/options/strictNu...
[1]: https://wiki.haskell.org/Bottom
[2]: https://docs.python.org/3/library/typing.html