this post was submitted on 07 Sep 2023
1023 points (98.9% liked)
Programmer Humor
19551 readers
1020 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Why? IMO that's perfectly valid. The various type coercions are sometimes crazy, but IMO the rule that non-empty string is coerced to
trueand empty string tofalseis 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.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. Any time I have to spend thinking about the peculiarities of the way the language handles something is time wasted.
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