14 ms·

> via Typescript null/undefined is an inhabitant of every type in typescript, I would suggest purescript instead. > Python relatively recently added typing I

> via Typescript null/undefined is an inhabitant of every type in typescript, I would suggest purescript instead. > Python relatively recently added typing I think you mean the ability to add explicit types to variable names. It always had types. > "extensive" unit testing is a poor man's type checker Certainly.. iff you use dependent types. > developers that don't think specifying types is helpful Why specify types if they can be inferred? Why do work that our computers can do for us?

smt88 8y ago
> null/undefined is an inhabitant of every type in typescript This isn't true as far the way you stated it. TypeScript types are not nullable by default. How can you use existing JS libraries without supporting null anyway?
wwwigham 8y ago
> null/undefined is an inhabitant of every type in typescript, I would suggest purescript instead. If you want absolute certainty in your types with TS, you should be using the `--strict` flag, which makes it so this is not the case.
- evmar 8y ago
  "absolute" is a bit of a funny qualifier to use here, given the many soundness holes in TS. For example (included with --strict): https://www.typescriptlang.org/play/#src=class%20Base%20%7B%0D%0A%20%20f(x%3A%20string%20%7C%20null)%20%7B%20%7D%0D%0A%7D%0D%0Aclass%20Derived%20extends%20Base%20%7B%0D%0A%20%20f(x%3A%20string)%20%7B%20x.charAt(3)%3B%20%7D%0D%0A%7D%0D%0Alet%20b%3A%20Base%20%3D%20new%20Derived()%3B%0D%0Ab.f(null)%3B https://www.typescriptlang.org/play/#src=class%20Base%20%7B%... (I like TS, I just don't think it fully solves this problem!)
hardwaresofton 8y ago
> 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. [0]: https://basarat.gitbooks.io/typescript/docs/options/strictNullChecks.html https://basarat.gitbooks.io/typescript/docs/options/strictNu... [1]: https://wiki.haskell.org/Bottom https://wiki.haskell.org/Bottom [2]: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html

smt88 8y ago

> null/undefined is an inhabitant of every type in typescript This isn't true as far the way you stated it. TypeScript types are not nullable by default. How can you use existing JS libraries without supporting null anyway?

wwwigham 8y ago

> null/undefined is an inhabitant of every type in typescript, I would suggest purescript instead. If you want absolute certainty in your types with TS, you should be using the `--strict` flag, which makes it so this is not the case.

evmar 8y ago
"absolute" is a bit of a funny qualifier to use here, given the many soundness holes in TS. For example (included with --strict): https://www.typescriptlang.org/play/#src=class%20Base%20%7B%0D%0A%20%20f(x%3A%20string%20%7C%20null)%20%7B%20%7D%0D%0A%7D%0D%0Aclass%20Derived%20extends%20Base%20%7B%0D%0A%20%20f(x%3A%20string)%20%7B%20x.charAt(3)%3B%20%7D%0D%0A%7D%0D%0Alet%20b%3A%20Base%20%3D%20new%20Derived()%3B%0D%0Ab.f(null)%3B https://www.typescriptlang.org/play/#src=class%20Base%20%7B%... (I like TS, I just don't think it fully solves this problem!)

hardwaresofton 8y ago

> 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. [0]: https://basarat.gitbooks.io/typescript/docs/options/strictNullChecks.html https://basarat.gitbooks.io/typescript/docs/options/strictNu... [1]: https://wiki.haskell.org/Bottom https://wiki.haskell.org/Bottom [2]: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html