So, uh, first example, the developer decided instead of comparing based on type, he rather converts the values? Why?!
Comment on The birth of JS
devious@lemmy.world 1 year ago
This is one of the most educational and entertaining reads on the internet, if you are into that kind of thing:
MonkderZweite@feddit.ch 1 year ago
rikudou@lemmings.world 1 year ago
Has anyone actually read through that? Reading the first few examples and it’s just not understanding how languages work half of the time:
Wow, no shit, non-empty string coerces to true, who would’ve guessed! Did you know that
!!“bullshit” === !!“true”
as well? Mind=blown.NaN === NaN; // -> false
Again, no shit, that’s in the NaN specification and the page even mentions it, so why even include it?
noli@programming.dev 1 year ago
Which is why I’m of the opinion that dynamically typed languages are evil. !!“false” should either be caught at compile time or raise an exception.
I’m thoroughly convinced that the only use of dynamically typed languages is to introduce bugs
Camilo@discuss.tchncs.de 1 year ago
I am with you. To me these are non-obvious details, just a bug waiting to silently happen in production.
marcos@lemmy.world 1 year ago
Dynamically typed doesn’t imply it’s monotyped. And monotyped languages can work just fine, you just have to not hide different operations under the same symbols just differing by type like JS does.
The entire problem with JS is that it both is monotyped and it isn’t.
Pipoca@lemmy.world 1 year ago
Isn’t the whole point of dynamic languages that they’re monotyped? They’re equivalent to a type system with only one type,
any
. Really, most dynamic languages are equivalent to having a single tagged union of all the different sorts of values in the language.If you add additional types, you get into gradual type systems.
rikudou@lemmings.world 1 year ago
Why? IMO that’s perfectly valid. The various type coercions are sometimes crazy, but IMO the rule that non-empty string is coerced to
true
and empty string tofalse
is very simple to follow. The snippet is not even a gotcha, I don’t see anything worth failing over. Putting “true” or “false” in a string doesn’t change that.noli@programming.dev 1 year ago
I am dumb. The more things I need to think about when reading code that is not the logic of the code, the worse it is.
I’ll give a very simple example, think like you’re trying to find a bug. Assume we’re in a dynamic language that allows implicit conversion like this. We can write our code very “cleanly” as follows: `if(!someVar) doSomething();’ -> ok, now we gotta check where someVar’s value is last set to know what type of data this is. Then I need to remember or look up how those specific types are coerced into a bool.
When trying the same code in a statically typed language that doesn’t do implicit coercion that code will fail to run/compile so probably you’ll have something like this:
if(someVar.length() == 0) doSomething();
-> this time I can just look at the type of someVar to see it’s a string and it’s clear what the condition actually means.The second option is both easier to read and less bug prone even without the type system. It takes maybe 3 seconds longer to type, but if your productivity in coding is that limited by typing speed then I envy you
darcy@sh.itjust.works 1 year ago
NaN===NaN
is the fault of the floating point standard tho i believe.rikudou@lemmings.world 1 year ago
Yes, that’s my point.
icesentry@programming.dev 1 year ago
Also, a huge proportion of the list is just not understanding IEEE floats behaviour and blaming the language for it. Exactly like this post is doing. All those weird number things js does is because it only uses floats for everything and every language that uses floats will behave the exact same way.