4 ms·

I can tell you why I don’t like it. Everyone’s subtle OCD seems to come out with Typescript. Instead of cutting down on the number of function arguments, people

I can tell you why I don’t like it. Everyone’s subtle OCD seems to come out with Typescript. Instead of cutting down on the number of function arguments, people don’t give a shit. They add more and more args, and maniacally define the types for every little thing. It’s like some odd version of list-making (many people get a kick out of compulsively making these detailed lists). It used to be that you think very carefully about how to keep a function simple, but Typescript is bringing out this dark side in people that allows them to just define 15 argument functions, so long as is has a nice exhaustive Type. Sometimes you have to save people from themselves. I’ll stay hyperbolic and say in several years time, we will all be drowning in type-inflated code bases. JavaScript people always find a way to make things hard.

mikevm 5y ago
Somehow people have been programming just fine in statically typed languages for decades without turning their code into a shitshow. It just appears that JS attracts a lot of poor programmers due to the low barrier to entry.
- holoduke 5y ago
  Poor programmers everywhere. Java, C++, PHP, JavaScript. I have seen them all. Like C in JavaScript is so flexible that it is hard to enforce certain (company) standards. That makes it a bit more prone to issues. But many great examples of good plain js programs
ballenf 5y ago
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

mikevm 5y ago

Somehow people have been programming just fine in statically typed languages for decades without turning their code into a shitshow. It just appears that JS attracts a lot of poor programmers due to the low barrier to entry.

holoduke 5y ago
Poor programmers everywhere. Java, C++, PHP, JavaScript. I have seen them all. Like C in JavaScript is so flexible that it is hard to enforce certain (company) standards. That makes it a bit more prone to issues. But many great examples of good plain js programs

ballenf 5y ago

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