"1) Isn't it just (!isNaN(num) && isFinite(num))? I know that's pretty far from intuitive, but it's not as bad as you made it sound. That being said, i'd love an `isNumber` function at some point..."
You just proved my point!
A) Even if you are correct - it's terrible. This is completely ridiculous that there's no basic check for extremely common and mundane type-checking. Moreover, it's the same issue for other types!
B) Worse: you're wrong.
isNaN('100') = false
isFinite('100') = true
The string '100' would pass your check as a Number :)
Underscore uses:
"toString.call(number) === '[object ' + Number + ']';"
So noodle on that for a while: I'm assuming you're an experienced JS programmer and you can't test to see if something is a number! Embarrassed? It's ok. 9/10 JS programmers would get it wrong. I had to look it up! Which is my point - it's really bad!
2) Prototyping is not bad because it's prototyping - it's bad because it's really confusing. Point: nobody has - or will 'borrow' this idea form JS. Again - almost zero JS devs really understand how it works.
3) Again I disagree. There definitely should be a 'true way' for the most common operations. There should only be one 'true way' to test to see if something is a Number (!) - and for basic things like string operations - 'one true way' is better. For so, so many reasons.
4) "For the most part I don't need to worry about someone writing code that will run on version X on platform Y" - sure you do. You cannot use 'const' or 'let' in Safari/iOS. You can in Chrome. That's just the tip of the iceberg. There are dozens of such mismatches - and it's a fragmentation nightmare.
Now - I agree with your point about 'competing versions' hey, that's great. But they are 'not the same platform' - which is totally destructive.
Well that's because this is checking if a value may be a valid number.
It's not safely converting the value to a number.
That's done after a parseFloat()
1) well look at that! I guess i've gotten a bit spoiled relying on lodash as much as I do!
2) There are aspects of prototypes that JS makes much worse (mainly the whole "this" clusterfuck), but the base is pretty sane and easy to understand. But at that point i'm not even talking about javascript any more, so I guess you are right here too.
3) I still disagree with you here. Yeah, there should be a way for the stdlib to do simple low level things (like isNumber()), but for others "one true way" isn't the best. I'd love a better stdlib, but I don't want something like Go's stdlib. I'd rather the language define a "bare minimum" and let libraries take over the rest. Now, as with anything in life this should be taken in moderation, if there are massive gains to be had by including something, then it probably should be included.
Maybe this is stockholm syndrome setting in, but I'd rather have the choice of implementation of something in-language, because there are so many different engine implementations.
4) I was more speaking of things like a python library that only runs on 2.7, or a java application that only works on 6. For the most part, those things just don't happen in javascript. Yeah, you need to not use newer features until they roll out everywhere, but once they do, you are safe in using them for a pretty damn long time. In your example, you can't use const/let right now because safari is the last big holdout here. iOS 10 was just released, and with it Safari 10. In another month, i'd feel comfortable using const/let without transpiling it, and I won't need to worry about it again.
But another benefit of multiple different implementations is they are free to optimize for different things. For example, Espruino is a JS engine that runs on microcontrollers and is EXTREMELY low power. Chakra (Edge's engine) shoots for really fast startup speed. V8 is pretty much the king in terms of raw execution speed. Contrast this with the Java way of having a million settings, knobs, options, and flags in the engine to tune the system the way you want. Yeah, you can do that, but most don't because of the complexity and risk involved. And there is only so much that you can do while having to support every option in the same engine.
Like i said earlier, i'm not sure if it's stockholm syndrome taking effect, but JS is by far my favorite language, and despite all it's flaws, issues, problems, and mistakes, it's also the language i'm most productive in. And with ES2015+ it's only getting better. (although i'm dreading the time when modules start getting into implementations, and how they conflict with current solutions, that's going to be a NIGHTMARE in just about every way).
"But another benefit of multiple different implementations is they are free to optimize for different things."
Every language has that. There are different JVM's, different C/C++ compilers, different python interpreters.
JS is not 'at any advantage' here - and again - the drawback is the ridiculous fragmentation we see across browsers - which is ... bad - at least compared to other languages.
But I wouldn't even say that. Look at the C/C++ situation. Microsoft as a platform doesn't support a ton of C, every compiler has it's own ways of using undefined behavior, there are tons of extensions and "only works on compiler X". Look at python where even if you ignore the 2/3 split, you have ironpython, cpython, pypy, and more that all have their own quirks, differences, and incompatibilities. It's pretty often you see a python library that only works on cpython.
For all it's issues, JS has mostly moved past that. It's pretty rare to see a javascript program or library (that's not just a tech demo) that only works on one implementation. Hell Microsoft released a node.js fork that runs on chakra, and to my surprise every single one of our node applications runs on it without a single change or hitch. (i haven't looked up if this is "normal" or if i got lucky though, so take it with a grain of salt).
Now obviously it's not perfect, and we should strive to be better, to fix these issues, but it's not like javascript is in some unprecedented scenario here. I actually think that the IE6 days have pushed JS to fix a lot of the problems that are plaguing other languages in this area.
You just proved my point!
A) Even if you are correct - it's terrible. This is completely ridiculous that there's no basic check for extremely common and mundane type-checking. Moreover, it's the same issue for other types!
B) Worse: you're wrong.
isNaN('100') = false isFinite('100') = true
The string '100' would pass your check as a Number :)
Underscore uses:
"toString.call(number) === '[object ' + Number + ']';"
So noodle on that for a while: I'm assuming you're an experienced JS programmer and you can't test to see if something is a number! Embarrassed? It's ok. 9/10 JS programmers would get it wrong. I had to look it up! Which is my point - it's really bad!
2) Prototyping is not bad because it's prototyping - it's bad because it's really confusing. Point: nobody has - or will 'borrow' this idea form JS. Again - almost zero JS devs really understand how it works.
3) Again I disagree. There definitely should be a 'true way' for the most common operations. There should only be one 'true way' to test to see if something is a Number (!) - and for basic things like string operations - 'one true way' is better. For so, so many reasons.
4) "For the most part I don't need to worry about someone writing code that will run on version X on platform Y" - sure you do. You cannot use 'const' or 'let' in Safari/iOS. You can in Chrome. That's just the tip of the iceberg. There are dozens of such mismatches - and it's a fragmentation nightmare.
Now - I agree with your point about 'competing versions' hey, that's great. But they are 'not the same platform' - which is totally destructive.