Ah, folly of untyped systems. Tbh this behaviour makes sense given the rules implemented within the language. Anything passed to parseInt is casted to string and then parsed.
Is it shitty behaviour - yes. Does it make sense in given the language implementation - yes.
People give JS a lot of shit. And I do too. But it’s meant to continue running and not fail like C code would. It’s meant to basically go “yeah, sure I’ll fuck with that” and keep trucking.
So you can always make it do stupid shit when you use it a stupid way.
Is this bad? Maybe. Was it the intention of the language? Absolutely.
Typescript fixes a lot of these headaches. But I feel like JS is doing exactly what it was meant to do. Keep trucking even when the programmer asks it to do stupid shit.
If you’re using JS and don’t understand this then it’s your fault and not the languages fault.
Do we all want to live in a world of typedefs as strict as C and have our webpages crash with the slightest unexpected char input? Probably not.
We don’t notice all the time JS goes “yeah I can fuck with that” and it works perfectly. We only notice the times it does that and it results in something silly.
TLDR: JS does what it was made to do. And because of that it looks absolutely ridiculous sometimes.
The REAL problem is that the industry collectively uses JS almost exclusively for shit it was never meant to do. Like you say, it’s intended for it to not throw errors and kill your whole web page, because it was only ever intended to be used for minor scripts inside mostly-static HTML and CSS web pages. Then we all turned it into the most-popular language in the world for building GUI applications.
It’s meant to basically go “yeah, sure I’ll fuck with that” and keep trucking.
Yet, it lives in an insulated environment, with plenty of infrastructure to make sure errors do not propagate, with a standard error handling functionality on the spotlight with specialized syntax, and with plenty of situations where it just drops the ball and throws an error.
Nope, not falling for the gaslight. It’s a stupid feature that’s there because the language was created during a week and the author was trying to juggle the requirement of a rigid and typed semantics that looked like Java with his desire to make a flexible single-typed language that looks like Lisp.
And nobody fixed it, decades later, because everybody keeps repeating your line that the interpreter must always keep on.
People forget that crashes are a debugging tool indicating an error. Silent errors can be much more dangerous. C and C++ in particular need to be careful not to overwrite random memory for example.
Yes the consequences for JS failures are less severe and so JS can get away with it, but a crash is a way to know your program isn’t doing what you thought it was, properly.
It just so happens that JS is used in contexts where nobody really cares, and errors aren’t a big deal, cheap and fast wins.
That’s not why JS is a big pile of crap. It’s because the language was not thought through at the beginning (I don’t blame the inventors for that) and because of the web it spread like wildfire and only backwards compatible changes could be made. Even if with all your points in mind the language could be way nicer. My guess is that once wasm/wasi is integrated enough to run websites without JS (dom access, etc.) JS will be like Fortran, Cobol and Telefax - not going away any time soon, but practically obsolete.
Nah, it’s stupid either way.
“5e-7” is not an int to be parsed. Neither is “0.5”.
Ah, folly of untyped systems. Tbh this behaviour makes sense given the rules implemented within the language. Anything passed to parseInt is casted to string and then parsed.
Is it shitty behaviour - yes. Does it make sense in given the language implementation - yes.
People give JS a lot of shit. And I do too. But it’s meant to continue running and not fail like C code would. It’s meant to basically go “yeah, sure I’ll fuck with that” and keep trucking.
So you can always make it do stupid shit when you use it a stupid way.
Is this bad? Maybe. Was it the intention of the language? Absolutely.
Typescript fixes a lot of these headaches. But I feel like JS is doing exactly what it was meant to do. Keep trucking even when the programmer asks it to do stupid shit.
If you’re using JS and don’t understand this then it’s your fault and not the languages fault.
Do we all want to live in a world of typedefs as strict as C and have our webpages crash with the slightest unexpected char input? Probably not.
We don’t notice all the time JS goes “yeah I can fuck with that” and it works perfectly. We only notice the times it does that and it results in something silly.
TLDR: JS does what it was made to do. And because of that it looks absolutely ridiculous sometimes.
The REAL problem is that the industry collectively uses JS almost exclusively for shit it was never meant to do. Like you say, it’s intended for it to not throw errors and kill your whole web page, because it was only ever intended to be used for minor scripts inside mostly-static HTML and CSS web pages. Then we all turned it into the most-popular language in the world for building GUI applications.
Yet, it lives in an insulated environment, with plenty of infrastructure to make sure errors do not propagate, with a standard error handling functionality on the spotlight with specialized syntax, and with plenty of situations where it just drops the ball and throws an error.
Nope, not falling for the gaslight. It’s a stupid feature that’s there because the language was created during a week and the author was trying to juggle the requirement of a rigid and typed semantics that looked like Java with his desire to make a flexible single-typed language that looks like Lisp.
And nobody fixed it, decades later, because everybody keeps repeating your line that the interpreter must always keep on.
People forget that crashes are a debugging tool indicating an error. Silent errors can be much more dangerous. C and C++ in particular need to be careful not to overwrite random memory for example.
Yes the consequences for JS failures are less severe and so JS can get away with it, but a crash is a way to know your program isn’t doing what you thought it was, properly.
It just so happens that JS is used in contexts where nobody really cares, and errors aren’t a big deal, cheap and fast wins.
My main issue with JS is you can use it wrong, and it pretends to work, and often looks like it works.
But then shits its pants explosively the second you fall outside that.
That’s not why JS is a big pile of crap. It’s because the language was not thought through at the beginning (I don’t blame the inventors for that) and because of the web it spread like wildfire and only backwards compatible changes could be made. Even if with all your points in mind the language could be way nicer. My guess is that once wasm/wasi is integrated enough to run websites without JS (dom access, etc.) JS will be like Fortran, Cobol and Telefax - not going away any time soon, but practically obsolete.
Javascript: “They’re the same thing”
deleted by creator