>your definition of a “sane” developer is not as universal as you may have thought
Where I'm from, sanity has historically been the minority opinion, so we don't really have a word for this, but I think the English one is... "gaslighting"? "TS is a superset of JS", "there are 4/5 lights", "this line is longer/shorter", etc. (Look those up if you haven't, Microsoft marketers surely have.)
What I'm saying is, I am well aware that I represent a minority, and guess what, getting downvoted (not nearly as much as expected) still beats keeping silent about the things that have been fucking with my head for the past, what, year and a half? Considering I've been writing Node for barely 6, the fact that every year the number of software developers doubles [cit needed] probably has a lot to do with it.
No matter if we're talking about a very simple or a very complex system: if there are a lot of subtle inconsistencies in it, and you have to gradually learn your way around them, your ability to keep a consistent mental model of it in your head, and reason about what you're doing, will be impaired: -1 sanity.
Ironically this is the same as people's gripes about the original JS type system. IMHO `==` and `===` should've been the other way around, and 1000 ships wouldn't've been launched. This unwieldy choice of notation (implicit type coercion on `==`) made it just enough subtly different for people expecting C-like strict equality, to create a feeling of confusion and distress.
But since the underlying design principle was not clarified (in browsers all input comes from text boxes, as strings, anyway; and the original "source of truth" was only the HTML file, where element attributes are also strings; so in some limited sense it makes sense to have convert-from-string by default), we get all these (generations of) people with the impression that JS is a "low sanity" language... and that it needs, of all possible features, even more of a type system.
>Personally I almost never see any value in running known broken code.
That's completely subjective. Personally, I don't know how to fix a piece of code without being able to see with my own eyes how/where/why it breaks, but surely that's just my deficiency and everyone else is just telepathic. Boo, shame on me! (I'm also the guy with the months-long pull request because guess what, TypeScript did not make it easier for me to see what I'm doing wrong, just looped me into a waves of type refactors, sometimes causing me to break working code to get dat "spellcheck" out of everyone's faces. I do semver, but most libs on NPM don't ...)
So, in my experience, TypeScript prevents me from running known good code way more often than it prevents me from running known/unknown broken code. As for what value you see in either, sure - that's a matter of style.
Rust was mentioned elsewhere in the thread. It's great to work in a language where "compiles"="works". But TS is not a static language, where types actually matter; it's a restrictive "sanity checker" overlay on top of a dynamic language. And not one that's good enough for me to sacrifice the expressivity that JavaScript allows.
Maybe it's good enough for many other people who never came to rely on JavaScript's flexibility that much in the first place. Thoughts and prayers to 'em. Each one has to make the choice which is the right tool for a job - and when there's an incipient monoculture trying to make that choice for me, I'm bound to make a ruckus.
> If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose.
Amen to that! Thing is... you see how elsewhere in the thread, it's mentioned that people use TS annotations as an excuse not to write documentation? Well, in my purely anecdotal personal experience, they also use it for an excuse not to write unit tests! And considering what unit testing in JS looks like... well, no surprise there, either. "Ubiquitous JS" is supposed to be accessible. Instead, we have a number of onramps to it covered with rusty razor blades,
TypeScript is not without its good parts, but overall my journey with it has been one of frustration and, as I'm sure you can see from miles a way, a whoooooole lot of mismatched expectations. Like, ESM working...
Hence the exaggerations, and generally the lots of writing. I like JS/Node, I consider them simple I've been round the block just enough to see it evolve a bit, I gotta adapt to what others are doing (TS) because otherwise good luck getting help, right? So this is my honest perspective about that and I'm here to represent it because it's gotta amount to at least as much as the usual "nah bruh everything ok... u ok?"
> Where I'm from, sanity has historically been the minority opinion
You are conflating santity for your subjective opinion. I guess your post might have been received better if you showed more awereness of that.
> That's completely subjective.
Yes. Which is why i prefixed "Personally I...". I'm clear about this being my opinion, not an universal truth.
> Personally, I don't know how to fix a piece of code without being able to see with my own eyes how/where/why it breaks
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.
> But TS is not a static language, where types actually matter; it's a restrictive "sanity checker" overlay on top of a dynamic language.
Sure. But if you (and that's up to you!) decide to write your code using types and allow TypeScript to check them, at least you know that your code in isolation is unaffected by whatever dynamic runtime it will end up being run on.
> And not one that's good enough for me to sacrifice the expressivity that JavaScript allows.
So you prefer to go full iron, and rather trust the correctness of your own code, than having a compiler check it for you.
That's your choice, ofcourse, but if that's how you do things, you cannot come afterwards and claim that TypeScript is a bad language based on that. It's a bad match for you, and how you would rather manually be in control of everything.
But just tells us about how you like things, it says nothing about the language itself.
> we get all these (generations of) people with the impression that JS is a "low sanity" language...
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.
Typescript embraces the modern parts of Javascript, and makes them easy to work with, and makes your code easier to prove correct than plain Javascript would. That's why people like it. That's why people use it.
> and that it needs, of all possible features, even more of a type system.
This is not specific to JS. I think any language used to build bigger systems benefits from having a type-system to ensure the components interacting are always interacting in a known good way.
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, even though they are (much) harder to formally verify.
Where Typescript tries to force you to make formal declarations for your code, you find those limiting or getting in your way. Great. Be a superstar if you like.
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 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 :)
Where I'm from, sanity has historically been the minority opinion, so we don't really have a word for this, but I think the English one is... "gaslighting"? "TS is a superset of JS", "there are 4/5 lights", "this line is longer/shorter", etc. (Look those up if you haven't, Microsoft marketers surely have.)
What I'm saying is, I am well aware that I represent a minority, and guess what, getting downvoted (not nearly as much as expected) still beats keeping silent about the things that have been fucking with my head for the past, what, year and a half? Considering I've been writing Node for barely 6, the fact that every year the number of software developers doubles [cit needed] probably has a lot to do with it.
No matter if we're talking about a very simple or a very complex system: if there are a lot of subtle inconsistencies in it, and you have to gradually learn your way around them, your ability to keep a consistent mental model of it in your head, and reason about what you're doing, will be impaired: -1 sanity.
Ironically this is the same as people's gripes about the original JS type system. IMHO `==` and `===` should've been the other way around, and 1000 ships wouldn't've been launched. This unwieldy choice of notation (implicit type coercion on `==`) made it just enough subtly different for people expecting C-like strict equality, to create a feeling of confusion and distress.
But since the underlying design principle was not clarified (in browsers all input comes from text boxes, as strings, anyway; and the original "source of truth" was only the HTML file, where element attributes are also strings; so in some limited sense it makes sense to have convert-from-string by default), we get all these (generations of) people with the impression that JS is a "low sanity" language... and that it needs, of all possible features, even more of a type system.
>Personally I almost never see any value in running known broken code.
That's completely subjective. Personally, I don't know how to fix a piece of code without being able to see with my own eyes how/where/why it breaks, but surely that's just my deficiency and everyone else is just telepathic. Boo, shame on me! (I'm also the guy with the months-long pull request because guess what, TypeScript did not make it easier for me to see what I'm doing wrong, just looped me into a waves of type refactors, sometimes causing me to break working code to get dat "spellcheck" out of everyone's faces. I do semver, but most libs on NPM don't ...)
So, in my experience, TypeScript prevents me from running known good code way more often than it prevents me from running known/unknown broken code. As for what value you see in either, sure - that's a matter of style.
Rust was mentioned elsewhere in the thread. It's great to work in a language where "compiles"="works". But TS is not a static language, where types actually matter; it's a restrictive "sanity checker" overlay on top of a dynamic language. And not one that's good enough for me to sacrifice the expressivity that JavaScript allows.
Maybe it's good enough for many other people who never came to rely on JavaScript's flexibility that much in the first place. Thoughts and prayers to 'em. Each one has to make the choice which is the right tool for a job - and when there's an incipient monoculture trying to make that choice for me, I'm bound to make a ruckus.
> If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose.
Amen to that! Thing is... you see how elsewhere in the thread, it's mentioned that people use TS annotations as an excuse not to write documentation? Well, in my purely anecdotal personal experience, they also use it for an excuse not to write unit tests! And considering what unit testing in JS looks like... well, no surprise there, either. "Ubiquitous JS" is supposed to be accessible. Instead, we have a number of onramps to it covered with rusty razor blades,
TypeScript is not without its good parts, but overall my journey with it has been one of frustration and, as I'm sure you can see from miles a way, a whoooooole lot of mismatched expectations. Like, ESM working...
Hence the exaggerations, and generally the lots of writing. I like JS/Node, I consider them simple I've been round the block just enough to see it evolve a bit, I gotta adapt to what others are doing (TS) because otherwise good luck getting help, right? So this is my honest perspective about that and I'm here to represent it because it's gotta amount to at least as much as the usual "nah bruh everything ok... u ok?"