51–60 of 94 posts
Earlier quoted context omitted.
Not all languages with getter/setter support will invoke them automatically like this. For example, it's not possible in Java or Objective-C to make an expression of the form a == b, where a and b are plain variables, have any side effects.
In Obj-C you can if you would allow `a.prop == b.prop`.
This took you 11 days?!
And now for exercise 2: Port the solution to Haskell
let a = 1; _ == _ = True in a == 1 && a == 2And 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.
The language used can hardly be blamed for that.
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 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. You get used to this as you get seasoned with javascript. Every language has it's quirks. The human brain is remarkably adaptable to using tools & dealing with intricacies. I personally utilize & appreciate the difference between == and…
I spent seven years as a Perl programmer. Like Perl, a language can be extremely productive in the hands of a veteran and dangerous with a newcomer due to the unnecessary confusion it generates. At least eq and == are syntactically easier to grok than == and ===.
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.
To be fair, this is breaking Javascript and that is something you could do in other languages, for instance here is a similar version for C++:
Earlier quoted context omitted.
Wasting other people's time is a negative, but deepening your understanding of a topic by examining edge cases is generally worthwhile, IMHO.
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…
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 they have time to pursue an answer) is not someone I want to work with or manage, and should probably find another career, because the one they are in isn't holding their interest. Work doesn't have to be the most important thing to you, but if you don't like your job, the people around you WILL notice.
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 this is why Javascript can be such an awful language." To be fair, this is breaking Javascript and that is something you could do in other languages, for instance here is a similar version for C++: http://pastebin.com/seySfpku
On some level, defending JS using C is like saying you can also make a souffle by instead cooking the chicken with the egg still inside it. Both JS and its bad paradigms came from C. You don't arrive at good design by showing that other people also got it wrong.
#include
//Floating point model: Strict:Precise:Fast
//Will code execute
float a = nanf("");
if (a == a)//S:No P:No F:Yes
(do something);
if (a != a)//S:Yes P:Yes F:No
(do something);
if (a 2.f)//S:No P:No F:Yes
(do something);
if (isnan(a))//S:Yes P:Yes F:Yes
(do something);
In the third statement an otherwise fine check is done to make sure the value in a is sane, it doesn't get changed but its certainly not what you'd want it to be.
Whole lots of fun can be had when serving this to game servers. :D
Earlier quoted context omitted.
>"And this is why Javascript can be such an awful language." To be fair, this is breaking Javascript and that is something you could do in other languages, for instance here is a similar version for C++: http://pastebin.com/seySfpku
Pedantry aside... are you really going to defend Javascript's core method of function handling as good design by using the C function pointer as an example? On some level, defending JS using C is like saying you can also make a souffle by instead cooking the chicken with the egg still inside it. Both JS and its bad paradigms came from C. You don't arrive at good design by showing that other people also got it wrong.