The type system is still really bad, and apparently TypeScript gets mixed with native libraries in common practice, which makes a bad situation worse when something breaks.
The typing system is just a “quirk”. As long as you understand the (admittedly annoying) exceptions to the way your brain expects typing to work, everything works quite well.
And tbh, transpiled TypeScript libraries can be called from JavaScript as if it was JavaScript… because it is JavaScript. There’s no need to worry about typing unless you’re doing something like passing a string into a function that expects an int, and you’d run into those same problems if the function was originally JavaScript.
I mean, sure, but taking that argument to it’s logical extreme we should still be programming in assembly, because you can if you just know enough to do it.
A language is a tool. If it’s harder to use successfully than the next tool it’s a worse tool.
No? How is that the logical conclusion? You need to understand any language, and any quirk of that language, in order to effectively write in it. JavaScript is powerful, and moving farther every iteration. Strong typing is just not something it takes into consideration. In the same way that C# doesn’t take white space into consideration, and python doesn’t terminate its instructions with semicolons.
Each language is different, each language has its own quirks that you need to understand and get used to. If that wasn’t the case, we would have one objectively “perfect” programming language to use in all situations, on all machines, for every use case.
You need to understand any language, and any quirk of that language, in order to effectively write in it.
That seems to imply they all have the same amount of quirks, which I think most people here would agree is untrue
Something like Haskell has far, far fewer quirks than x86 assembly code. It really only has quirks to do with interactivity; everything else is very predictable and visible in the code. Meanwhile, assembly code is but a maximally useful set of quirks in a specific electronic circuit.
Ditto if you look at older languages. FORTRAN is unpleasantly quirky, which is why it’s almost obsolete.
If that wasn’t the case, we would have one objectively “perfect” programming language to use in all situations, on all machines, for every use case.
I mean, I hold out hope that that will eventually happen, at least for the vast majority of use cases and machines. Obviously we’re not there yet.
There have been languages that basically dominate their own niche. C/C++ was almost the only game in town for performance coding until someone discovered a way to compile mid-level code while also guaranteeing memory safety. Memory errors were a terrible quirk, so now Rust might steal its crown.
I personally don’t think that’s the issue with the typing system. With vanilla js if I’m looking at a function that has say four parameters that are not trivial objects like strings but are actually complex (think dependency injection) it’s very difficult for me to know what these objects are other than reading through the code of the function.
Actually, even if the parameters are simple, I’m not sure of that until I look into the function and see what it’s doing. This is a huge pain in the ass most the time, because I just wanna look at the function name its parameters and move on. However, that being said, most of this can be remedied with jsdocs and a good linter/lsp.
The type system is still really bad, and apparently TypeScript gets mixed with native libraries in common practice, which makes a bad situation worse when something breaks.
Edit: Messed up the name, fixed.
The typing system is just a “quirk”. As long as you understand the (admittedly annoying) exceptions to the way your brain expects typing to work, everything works quite well.
And tbh, transpiled TypeScript libraries can be called from JavaScript as if it was JavaScript… because it is JavaScript. There’s no need to worry about typing unless you’re doing something like passing a string into a function that expects an int, and you’d run into those same problems if the function was originally JavaScript.
Edit: a word
I mean, sure, but taking that argument to it’s logical extreme we should still be programming in assembly, because you can if you just know enough to do it.
A language is a tool. If it’s harder to use successfully than the next tool it’s a worse tool.
No? How is that the logical conclusion? You need to understand any language, and any quirk of that language, in order to effectively write in it. JavaScript is powerful, and moving farther every iteration. Strong typing is just not something it takes into consideration. In the same way that C# doesn’t take white space into consideration, and python doesn’t terminate its instructions with semicolons.
Each language is different, each language has its own quirks that you need to understand and get used to. If that wasn’t the case, we would have one objectively “perfect” programming language to use in all situations, on all machines, for every use case.
That seems to imply they all have the same amount of quirks, which I think most people here would agree is untrue
Something like Haskell has far, far fewer quirks than x86 assembly code. It really only has quirks to do with interactivity; everything else is very predictable and visible in the code. Meanwhile, assembly code is but a maximally useful set of quirks in a specific electronic circuit.
Ditto if you look at older languages. FORTRAN is unpleasantly quirky, which is why it’s almost obsolete.
I mean, I hold out hope that that will eventually happen, at least for the vast majority of use cases and machines. Obviously we’re not there yet.
There have been languages that basically dominate their own niche. C/C++ was almost the only game in town for performance coding until someone discovered a way to compile mid-level code while also guaranteeing memory safety. Memory errors were a terrible quirk, so now Rust might steal its crown.
I personally don’t think that’s the issue with the typing system. With vanilla js if I’m looking at a function that has say four parameters that are not trivial objects like strings but are actually complex (think dependency injection) it’s very difficult for me to know what these objects are other than reading through the code of the function.
Actually, even if the parameters are simple, I’m not sure of that until I look into the function and see what it’s doing. This is a huge pain in the ass most the time, because I just wanna look at the function name its parameters and move on. However, that being said, most of this can be remedied with jsdocs and a good linter/lsp.