3 ms·

One defense of this point is that I see developers writing Typescript code with the constant hinting/intellicode from IntelliJ and somewhat blind to the readabi

One defense of this point is that I see developers writing Typescript code with the constant hinting/intellicode from IntelliJ and somewhat blind to the readability of the naked code. You get this tight coupling of code and editor/IDE with Typescript that I didn't see coming. The benefits from the coupling are very real and probably outweigh the costs, but there is a price to be paid. It means that you have to manually go line by line through new code in your editor instead of scanning only with your eyes. It also makes reviewing the code anywhere else harder -- GitHub, etc. This is made more painful when types are necessary to understanding code, but the types are found in a file far away. But this is coming from someone who sometimes gets nostalgic for the days of printing out code, moving over to a big empty desk with pen in hand. Then going back to the terminal to make those changes. I also have seen ballooning function signatures that would have otherwise resulting in refactoring to an options object or otherwise refactoring.

runawaybottle 5y ago
but the types are found in a file far away. Don’t even get me started on that. It seems, now more than ever, we need another ‘JavaScript the Good Parts: 2021 Update’. A lot has been introduced in the last decade, and not all of it should be used to the degree we are using them. I just don’t know who has the credibility to pull it off at this moment.
brundolf 5y ago
Something I've found that really helps is putting a soft-ban on named types with generic type parameters. You almost never truly need them if you aren't writing a library, and they add a whole lot to inscrutability.
afiori 5y ago
I am a strong believer that typed languages in general should have a compiler annotation mode that with configurable level of verbosity formats explicit types and structural info (dead code, exhaustive matching) into structured comments. This could maybe also be a pre-commit git hook transformation so that you could see how type changes propagate. The essential feature must be that the compiler overwrites them often and that they must be informative only.
- brundolf 5y ago
  This is a good idea. Languages with advanced type inference have only become mainstream in the last 5 years or so, so I bet we're going to see a lot of innovations like this crop up over time

runawaybottle 5y ago

but the types are found in a file far away. Don’t even get me started on that. It seems, now more than ever, we need another ‘JavaScript the Good Parts: 2021 Update’. A lot has been introduced in the last decade, and not all of it should be used to the degree we are using them. I just don’t know who has the credibility to pull it off at this moment.

brundolf 5y ago

Something I've found that really helps is putting a soft-ban on named types with generic type parameters. You almost never truly need them if you aren't writing a library, and they add a whole lot to inscrutability.

afiori 5y ago

I am a strong believer that typed languages in general should have a compiler annotation mode that with configurable level of verbosity formats explicit types and structural info (dead code, exhaustive matching) into structured comments. This could maybe also be a pre-commit git hook transformation so that you could see how type changes propagate. The essential feature must be that the compiler overwrites them often and that they must be informative only.

brundolf 5y ago
This is a good idea. Languages with advanced type inference have only become mainstream in the last 5 years or so, so I bet we're going to see a lot of innovations like this crop up over time