>I guess your post might have been received better
You assume that I'm primarily optimizing for that.
I optimize for being able to express my opinion in sufficient detail that people actually bother to try to show me things that I don't know, just because they're mildly outraged at my audacity to say, "but some things are very not ok" :)
>Where I'm from...
...they stopped putting people in cages not even for believing outrageous things, but for holding outrageous disbeliefs, about a generation ago. So it's also about maintaining the capability to express dissent.
>I'm clear about this being my opinion, not an universal truth.
God forbid I claim to know any universal truth! Therein lies the way to True Madness. Anything anyone says can at most be their subjective truth - if they can reproduce from memory the things that make them believe what they're saying. Snippet battle was fun
>If the compiler tells me I'm passing a string to a function expecting a number, I find that error pretty easy to grasp, and I don't need to run the code to know how to proceed from that error-message.
And if the compiler happens not to? Back to runtime validation, considering priorities it remains ad-hoc, so the mess gets even unholier.
(where's my authomatic runtime validation layer based on parsing the type definition? holla at me)
>Javascript as a language has lots of quirks. Lots of quirks which are unexpected to most developers not coming from Javascript. That is to say, Javascript behaves differently than most other programming-languages.
>I'm not saying it's wrong or "not sane", but programmers coming from other languages will make assumptions and those assumptions will be wrong for "plain" Javascript, leading to buggy code.
I'm not saying it's wrong for JS to be like that either (I put forward a couple good reasons for the contrary and know a couple more), but I am saying that it is already "not sane" enough - in the sense that the hidden assumptions and unexpected behavior impair one's immediate ability to reason about the codebase.
The transpiler ecosystem doesn't help with that, either - TS, Babel, CLJS or whatever else, if I have to run scripts through a compiler it smells like someone isn't managing complexity right and it sure as hell it ain't every downstream developer who just uses whatever has the most mindshare (so that the quirks are at least googlable). Though I guess you could approach it from that angle too
>rather trust the correctness of your own code, than having a compiler check it for you
Rather verify the correctness of my code by running it, than trust the half-assed third-party static analyzer that's manipulated itself between my editor and runtime, yes
>Where Typescript tries to force you to make formal declarations for your code, you find those limiting or getting in your way.
That's a deficiency of TypeScript. The only option is not to use TypeScript, which is in many cases not an option.
>Me (and many others) on the other hand, are just human, and we like a compiler to tell us about obvious errors in our code without having to discover them at runtime, or even worse, in production.
I'm all in for this! I just wish it worked well enough to justify the drawbacks.
>To me it seems like you're one of those people who prefers to work with all the quirks that Javascript provides and considers those to be good things,
Prefer to know things that will not become invalidated by progress? Who doesn't. I already have to reason about a whole stack of "quirks" from the user's brain to the CPU and back. I would've preferred for Microsoft not to add 2322 more of those out of sheer community goodwill but there you have it.
>But if you (and that's up to you!)
It's up to me on my down time. Rest of my life it's up to the economy lol
>decide to write your code using types and allow TypeScript to check them
"decide to buy into the TypeScript language and ecosystem" because "writing your code using types and allowing TypeScript to check them" by manually writing a .JS + .D.TS is also not a practical option.
>That's why people use it.
My guess is most devs adopted it on their down time to stay relevant, "join us or fade away" hahahaah
>at least you know that your code in isolation is unaffected by whatever dynamic runtime it will end up being run on.
Where did that even come from. You mean like how it's now 4x harder to publish an isomorphic library because the CJS->ESM migrations and TypeScript doing its own things with modules have mangled the packaging surface in further sanity-reducing ways
>Be a superstar if you like.
One does not reach a position of power simply by doing what one wants. You also gotta tell others what not to do :)
You assume that I'm primarily optimizing for that.
I optimize for being able to express my opinion in sufficient detail that people actually bother to try to show me things that I don't know, just because they're mildly outraged at my audacity to say, "but some things are very not ok" :)
>Where I'm from...
...they stopped putting people in cages not even for believing outrageous things, but for holding outrageous disbeliefs, about a generation ago. So it's also about maintaining the capability to express dissent.
>I'm clear about this being my opinion, not an universal truth.
God forbid I claim to know any universal truth! Therein lies the way to True Madness. Anything anyone says can at most be their subjective truth - if they can reproduce from memory the things that make them believe what they're saying. Snippet battle was fun
>If the compiler tells me I'm passing a string to a function expecting a number, I find that error pretty easy to grasp, and I don't need to run the code to know how to proceed from that error-message.
And if the compiler happens not to? Back to runtime validation, considering priorities it remains ad-hoc, so the mess gets even unholier.
(where's my authomatic runtime validation layer based on parsing the type definition? holla at me)
>Javascript as a language has lots of quirks. Lots of quirks which are unexpected to most developers not coming from Javascript. That is to say, Javascript behaves differently than most other programming-languages. >I'm not saying it's wrong or "not sane", but programmers coming from other languages will make assumptions and those assumptions will be wrong for "plain" Javascript, leading to buggy code.
I'm not saying it's wrong for JS to be like that either (I put forward a couple good reasons for the contrary and know a couple more), but I am saying that it is already "not sane" enough - in the sense that the hidden assumptions and unexpected behavior impair one's immediate ability to reason about the codebase.
The transpiler ecosystem doesn't help with that, either - TS, Babel, CLJS or whatever else, if I have to run scripts through a compiler it smells like someone isn't managing complexity right and it sure as hell it ain't every downstream developer who just uses whatever has the most mindshare (so that the quirks are at least googlable). Though I guess you could approach it from that angle too
>rather trust the correctness of your own code, than having a compiler check it for you
Rather verify the correctness of my code by running it, than trust the half-assed third-party static analyzer that's manipulated itself between my editor and runtime, yes
>Where Typescript tries to force you to make formal declarations for your code, you find those limiting or getting in your way.
That's a deficiency of TypeScript. The only option is not to use TypeScript, which is in many cases not an option.
>Me (and many others) on the other hand, are just human, and we like a compiler to tell us about obvious errors in our code without having to discover them at runtime, or even worse, in production.
I'm all in for this! I just wish it worked well enough to justify the drawbacks.
>To me it seems like you're one of those people who prefers to work with all the quirks that Javascript provides and considers those to be good things,
Prefer to know things that will not become invalidated by progress? Who doesn't. I already have to reason about a whole stack of "quirks" from the user's brain to the CPU and back. I would've preferred for Microsoft not to add 2322 more of those out of sheer community goodwill but there you have it.
>But if you (and that's up to you!)
It's up to me on my down time. Rest of my life it's up to the economy lol
>decide to write your code using types and allow TypeScript to check them
"decide to buy into the TypeScript language and ecosystem" because "writing your code using types and allowing TypeScript to check them" by manually writing a .JS + .D.TS is also not a practical option.
>That's why people use it.
My guess is most devs adopted it on their down time to stay relevant, "join us or fade away" hahahaah
>at least you know that your code in isolation is unaffected by whatever dynamic runtime it will end up being run on.
Where did that even come from. You mean like how it's now 4x harder to publish an isomorphic library because the CJS->ESM migrations and TypeScript doing its own things with modules have mangled the packaging surface in further sanity-reducing ways
>Be a superstar if you like.
One does not reach a position of power simply by doing what one wants. You also gotta tell others what not to do :)