Comment on The birth of JS
rikudou@lemmings.world 1 year agoWhy? 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 to false 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