Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nerdsniping: A glimpse into a stubborn mind

blog.andyet.com

Post reply on HN
Print view View original

61–70 of 94 posts

Re: Nerdsniping: A glimpse into a stubborn mind

#61

Post by blt »

ssharp wrote: post #16
cowsandmilk wrote: post #6

Earlier quoted context omitted.

I think the goal was if (a==='80' || (b==='443'&&http===false)) {...}

I think you're right, but it's funny that both the code and the written explanation do not make that clear. Missing parenthesis in one case and missing comma in the other. I feel like I tend to use parenthesis when they are not required, but I err on the side of caution and I think it makes things more readable.

I use a lot of unneeded parentheses. Makes the intent of the program clear. If the expression gets ugly, factor out subexpressions into boolean variables. If you are depending on short circuiting to avoid computing costly subexpresions, make the dependency explicit with a nested `if`.

I had a thought the other day: Complicated code should look complicated. Don't try to hide your convoluted logic. In the end, someone will have to mentally unpack it into the multi-line verbose version to understand it anyway.

Re: Nerdsniping: A glimpse into a stubborn mind

#62

Post by gsg »

lmkg wrote: post #49
mfonda wrote: post #44

I think there was a more general question here that was missed: can a == x && a == y ever be true for any arbitrary values of a, x, and y, where x != y. From a logical point of view, no, this can never be true. I would suspect this can never be true in javascript, and could only be made true in a language where you can override == to always return true. I think when most developers use the word "never", what they rea…

I think there are a few cases of non-transitive equalities in JavaScript, specifically around falsey values. Part of it also has to do with whether x is the right-side input or the left-side input, because that changes type coercion rules. Aha, found one: ['0'] == 0 > true [0] == 0 > true [0] == ['0'] > false Transitivity of equality can also never be relied upon when dealing with Floating Point numbers. This is corr…

That's not due to transitivity: ['0'] == ['0'] (and for that matter, ['0'] === ['0']) is also false. These operators compare objects for identity, not structural equality.

Re: Nerdsniping: A glimpse into a stubborn mind

#63

Post by methodover »

blt wrote: post #61
ssharp wrote: post #16

Earlier quoted context omitted.

I think you're right, but it's funny that both the code and the written explanation do not make that clear. Missing parenthesis in one case and missing comma in the other. I feel like I tend to use parenthesis when they are not required, but I err on the side of caution and I think it makes things more readable.

I use a lot of unneeded parentheses. Makes the intent of the program clear. If the expression gets ugly, factor out subexpressions into boolean variables. If you are depending on short circuiting to avoid computing costly subexpresions, make the dependency explicit with a nested `if`. I had a thought the other day: Complicated code should look complicated. Don't try to hide your convoluted logic. In the end, someone…

That's an excellent thought.

I feel like programmers too often try to make something complicated "pretty" -- but really this just usually has the effect of making it that much more difficult to understand.

Re: Nerdsniping: A glimpse into a stubborn mind

#64

Post by philip_roberts »

neil_s wrote: post #34
wambotron wrote: post #23

I think the answer to "can something be fuzzy equal to one value and strictly equal to another in JS?" has an easy answer that doesn't take much effort to find. This might be cooler in another language, though. var b = 2; b == '2'; // true b === 2; // true

This is what I was gonna say! I don't know much JS, but after @sgdesign 's recent primer, the answer to the first two conditions seems obvious, b=="2" and b===2. Herpderp is just a cop out, since you could have infinite other variables that b equals, if you set the value to the same thing!

Except the question was b==1 && b===2

Re: Nerdsniping: A glimpse into a stubborn mind

#65

Post by mikeryan »

wambotron wrote: post #23

I think the answer to "can something be fuzzy equal to one value and strictly equal to another in JS?" has an easy answer that doesn't take much effort to find. This might be cooler in another language, though. var b = 2; b == '2'; // true b === 2; // true

I think you missed a bit of his point which was to make that exact expression evaluate as true

(b == 1 && b===2 && b === herpderp)

Re: Nerdsniping: A glimpse into a stubborn mind

#66

Post by marknutter »

mncolinlee wrote: post #27

And this is why Javascript can be such an awful language. Leaving off a single equals has such a profound effect, often without a new coder even realizing it while reading the code. Imagine what happens to your code when someone tries to write a function for its side effects similar to the example seen in the blog post. Then releases it in production for it to break in six months with a feature change.

And then you realize that javascript runs everywhere and you smile to yourself and continue coding away.

Re: Nerdsniping: A glimpse into a stubborn mind

#67

Post by Orangeair »

kbenson wrote: post #20
romanovcode wrote: post #3

I was working with this guy - he always tried to prove that everything is possible wasting time. He ALWAYS over-complicated simple things. He was horrible to work with and everyone hated him. Not to say you are just like him etc. but this post reminded me of him because it was probably exactly what he would do.

Wasting other people's time is a negative, but deepening your understanding of a topic by examining edge cases is generally worthwhile, IMHO.

I think the difference really lies in WHEN you do the examining. If you think to yourself, "Hey, that's cool, I'll check it out later," then there's no problem. However, when it gets to the point where you're thinking, "My code must be 110% correct! This is an immediate priority!" then maybe you should be re-evaluating your decision making process.

Re: Nerdsniping: A glimpse into a stubborn mind

#68

Post by spenuke »

kbenson wrote: post #57
spenuke wrote: post #35

Earlier quoted context omitted.

Is it really fair to call poor code an edge case? If not for the double-equals typo, which most code reviews would fix, this wouldn't work. I'm more interested that this team has conversations where person A asks a really simple question that should be able to be tested in 11 seconds, person B gives a patently false answer that mistakes && for ||, which is the very thing person A is asking about. Meanwhile person C g…

No, person C saw an interesting question, and decided to go on an exploratory journey to see what's possible. In any job requiring mental aptitude, you'll find natural curiosity an asset, as long as you keep it within bounds. To be clear, anyone that's presented a question about a tool they are using that may pertain to it's use (be it efficiency or correctness) that shows zero interest in the answer (whether or not…

I'm not sure your second paragraph is clear, to me, at least. Person C admitted that their only contribution to the conversation was to announce that they had been nerd-sniped. Which means that they showed zero interest in the "question they were presented with", because they were sidetracked by another, more interesting (to them) problem.

Meanwhile, person A's question went unanswered. I would consider this a case of not keeping curiosity within bounds. Wouldn't you?

I agree wholeheartedly that curiosity is a great motivator, one that I would want driving all my coworkers. But as this blog presents it, the curiosity suffers from the greatest threat to curiosity, which is a lack of discipline that ensures the curious person never rises above a dilettante. I speak from first hand knowledge here - I've wasted more than my share of time doing something just for fun that benefits nobody.

If it were not the case that Person B, the implicit authority figure in the scenario, gave a totally backwards answer to Person A, OR ( || ) if it were not the case that Person C failed to alleviate the confusion of Persons A and B, then I would not see any problem with going off on a trip down pedantry lane. As it is, the whole organization looks like a gang of clowns. Nobody can answer the most basic of syntax questions, and one person even takes a faulty intuition ("b can be both 80 and 443") and follows it on a Quixotic quest into the arcana of the language spec. It's almost as though he stumbled on the real value of the quest (how evaluations of == and === are actually implemented) by sheer accident, in spite of himself. Luckily, many quests follow this pattern.

For what it's worth, I do find the discussion interesting. But it's interesting in way different than that of edge cases. Deliberately breaking something by using it in a way it was never intended to be used can be enlightening if you want to fend off would-be attackers. It exploits the system's implementation constraints. On the other hand, an edge case highlights the edges of legitimate use which the system was never designed to account for. It exploits the system's lack of comprehensiveness. The distinction is a good one, I think.

For example, consider a chair. An edge case might be a 600-pound man. The engineers didn't take this legitimate use of the chair into account when they determined the thickness of the material. That's an edge case. It's not quite the same as saying that the engineers didn't take into account that wood is flammable. This example is not the best, but I'm now well too far into my own trip down pedantic lane to spend any more time trying to improve it. :)

Re: Nerdsniping: A glimpse into a stubborn mind

#70

Post by MatthewWilkes »

mncolinlee wrote: post #27

And this is why Javascript can be such an awful language. Leaving off a single equals has such a profound effect, often without a new coder even realizing it while reading the code. Imagine what happens to your code when someone tries to write a function for its side effects similar to the example seen in the blog post. Then releases it in production for it to break in six months with a feature change.

Yeah, just use python!

  class B(object):
      def __eq__(self, other):
          return True

  b=B()
It's much more expressive
Post reply on HN