5 ms·

> In Python, I've even heard of people writing types in source code but never checking them This is my main approach. Type hints are wonderful for keeping code

> In Python, I've even heard of people writing types in source code but never checking them This is my main approach. Type hints are wonderful for keeping code legible/sane without going into full static type enforcement which can become cumbersome for rapid development.

josephg 2y ago
You can configure typescript to make typing optional. With that option set, you can literally rename .js files to .ts and everything "compiles" and just works. Adding this feature to nodejs means you don't even have to set up tsc if you don't want to. But if I were putting in type hints like this, I'd still definitely want them to be statically checked. Its better to have no types at all than wrong types.
- jaggederest 2y ago
  Yeah I start projects by explicitly typing `any` all over the place and gradually refining things, so every type that's specified is explicit and checked, I'm really enjoying that style.
  - crabmusket 2y ago
    Combine this with an eslint config that nudges you about explicit any, and the typescript compiler option to disallow implicit any, and you're well taken care of.
- pansa2 2y ago
  > Its better to have no types at all than wrong types. I agree - but the type systems of both Python and TypeScript are unsound, so all type hints can potentially be wrong. That's one reason why I still mostly use untyped Python - I don't think it's worth the effort of writing type annotations if they're just going to sit there and tell lies. Or maybe the unsoundness is just a theoretical issue - are incorrect type hints much of a problem in practice?
  - zoul 2y ago
    In my experience unsoundness is almost never a problem in practice, see here for details: https://effectivetypescript.com/2021/05/06/unsoundness/ https://effectivetypescript.com/2021/05/06/unsoundness/
    - hajile 2y ago
      Unsound types are never a problem until they are at which point you are staring at code that SHOULD be working, but is somehow breaking.
  - lolinder 2y ago
    I've been using TypeScript professionally for 6+ years and have only ever run into issues at the border between TypeScript and other systems (usually network, sometimes libraries that don't come with types). There are a few edge cases that I'm aware of, but they don't really come up in practice.
  - kcrwfrd_ 2y ago
    Is this “unsound”-ness that you’re referring to because it uses structural typing and not nominal typing? Fwiw I’ve been working with TypeScript for 8+ years now and I’m pretty sure wrong type hints has never been a problem. TS is a God-send for working with a codebase.
    - nyssos 2y ago
      There's not much connection. Typescript's record types aren't sound, but that's far from its only source of unsoundness, and sound structural typing is perfectly possible.
      - lolinder 2y ago
        Soundness is also a highly theoretical issue that I've never once heard a professional TypeScript developer express concern about and have never once heard a single anecdote of it being an issue in real-world code that wasn't specifically designed to show the unsoundness. It usually only comes up among PL people (who I count myself among) who are extremely into the theory but not regularly coding in the language. Do you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application? Or an anecdote you can link to from someone else?
- black3r 2y ago
  Or you can configure the TS compiler to allow JS imports, then everything also compiles and works, but you can slowly convert your codebase from JS to TS file by file and be sure that all TS files are properly typed and all JS files are untyped instead of having everything as TS files where some are typed and some are not.
pansa2 2y ago
With this approach, do you still use Python's standard syntax for type hints? def mersenne(p: int): return 2**p - 1 Or, given there's no need for the type hints to be checker-friendly, do you make them more human-friendly, e.g: def mersenne(p: 'prime number'): return 2**p - 1
- LordKeren 2y ago
  While it’s not common (from the source code I’ve reviewed over the years), some people make a new type with a name and use that in the definition: ``` from typing import NewType # Create a new type for some_prime SomePrime = NewType('SomePrime', int) def process_prime(value: SomePrime) -> int: return value ``` However, this isn’t nearly as common as simply using a more descriptive argument name like “prime_number : int” One of the big advantages to type hinting in Python is that it feeds the IDE a lot of information to increase auto-complete functionality, so you want to avoid things like p:”prime number”
  - pansa2 2y ago
    > One of the big advantages to type hinting in Python is that it feeds the IDE a lot of information to increase auto-complete functionality Yeah, until this discussion I thought the main benefit of type hints was earlier detection of bugs via static checking. Now though, I'm getting the impression that the bigger benefit is enabling IDE features such as autocomplete. That helps me understand better why I haven't found type hints as useful as others seem to - I don't use an IDE. My use of Python is limited to small scripts which I write in a simple text editor.
    - LordKeren 2y ago
      There’s a fair argument to make that better IDE autocomplete does prevent many type-related issues even before a static type checker is run
Humphrey 2y ago
Exactly. And if you use a library that does lots of meta programming (like Django) then it's impossible to pass all type errors. Hopefully one day the type system will be powerful enough to write a Django project with passing tests.
edflsafoiewq 2y ago
IME if you aren't checking them, they're eventually going to be out of date.
rlt 2y ago
I don't find TypeScript to be burdensome when rapidly iterating. Depending on how you've configured your dev environment you can just ignore type errors and still run the code.

josephg 2y ago

You can configure typescript to make typing optional. With that option set, you can literally rename .js files to .ts and everything "compiles" and just works. Adding this feature to nodejs means you don't even have to set up tsc if you don't want to. But if I were putting in type hints like this, I'd still definitely want them to be statically checked. Its better to have no types at all than wrong types.

jaggederest 2y ago
Yeah I start projects by explicitly typing `any` all over the place and gradually refining things, so every type that's specified is explicit and checked, I'm really enjoying that style.
- crabmusket 2y ago
  Combine this with an eslint config that nudges you about explicit any, and the typescript compiler option to disallow implicit any, and you're well taken care of.
pansa2 2y ago
> Its better to have no types at all than wrong types. I agree - but the type systems of both Python and TypeScript are unsound, so all type hints can potentially be wrong. That's one reason why I still mostly use untyped Python - I don't think it's worth the effort of writing type annotations if they're just going to sit there and tell lies. Or maybe the unsoundness is just a theoretical issue - are incorrect type hints much of a problem in practice?
- zoul 2y ago
  In my experience unsoundness is almost never a problem in practice, see here for details: https://effectivetypescript.com/2021/05/06/unsoundness/ https://effectivetypescript.com/2021/05/06/unsoundness/
  - hajile 2y ago
    Unsound types are never a problem until they are at which point you are staring at code that SHOULD be working, but is somehow breaking.
- lolinder 2y ago
  I've been using TypeScript professionally for 6+ years and have only ever run into issues at the border between TypeScript and other systems (usually network, sometimes libraries that don't come with types). There are a few edge cases that I'm aware of, but they don't really come up in practice.
- kcrwfrd_ 2y ago
  Is this “unsound”-ness that you’re referring to because it uses structural typing and not nominal typing? Fwiw I’ve been working with TypeScript for 8+ years now and I’m pretty sure wrong type hints has never been a problem. TS is a God-send for working with a codebase.
  - nyssos 2y ago
    There's not much connection. Typescript's record types aren't sound, but that's far from its only source of unsoundness, and sound structural typing is perfectly possible.
    - lolinder 2y ago
      Soundness is also a highly theoretical issue that I've never once heard a professional TypeScript developer express concern about and have never once heard a single anecdote of it being an issue in real-world code that wasn't specifically designed to show the unsoundness. It usually only comes up among PL people (who I count myself among) who are extremely into the theory but not regularly coding in the language. Do you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application? Or an anecdote you can link to from someone else?
black3r 2y ago
Or you can configure the TS compiler to allow JS imports, then everything also compiles and works, but you can slowly convert your codebase from JS to TS file by file and be sure that all TS files are properly typed and all JS files are untyped instead of having everything as TS files where some are typed and some are not.

pansa2 2y ago

With this approach, do you still use Python's standard syntax for type hints? def mersenne(p: int): return 2**p - 1 Or, given there's no need for the type hints to be checker-friendly, do you make them more human-friendly, e.g: def mersenne(p: 'prime number'): return 2**p - 1

LordKeren 2y ago
While it’s not common (from the source code I’ve reviewed over the years), some people make a new type with a name and use that in the definition: ``` from typing import NewType # Create a new type for some_prime SomePrime = NewType('SomePrime', int) def process_prime(value: SomePrime) -> int: return value ``` However, this isn’t nearly as common as simply using a more descriptive argument name like “prime_number : int” One of the big advantages to type hinting in Python is that it feeds the IDE a lot of information to increase auto-complete functionality, so you want to avoid things like p:”prime number”
- pansa2 2y ago
  > One of the big advantages to type hinting in Python is that it feeds the IDE a lot of information to increase auto-complete functionality Yeah, until this discussion I thought the main benefit of type hints was earlier detection of bugs via static checking. Now though, I'm getting the impression that the bigger benefit is enabling IDE features such as autocomplete. That helps me understand better why I haven't found type hints as useful as others seem to - I don't use an IDE. My use of Python is limited to small scripts which I write in a simple text editor.
  - LordKeren 2y ago
    There’s a fair argument to make that better IDE autocomplete does prevent many type-related issues even before a static type checker is run

Humphrey 2y ago

Exactly. And if you use a library that does lots of meta programming (like Django) then it's impossible to pass all type errors. Hopefully one day the type system will be powerful enough to write a Django project with passing tests.

edflsafoiewq 2y ago

IME if you aren't checking them, they're eventually going to be out of date.

rlt 2y ago

I don't find TypeScript to be burdensome when rapidly iterating. Depending on how you've configured your dev environment you can just ignore type errors and still run the code.