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.
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 === to reduce complexity in the code. I assume the reader also understands such differences.
I also find automated testing, logging, a module system like commonjs, and linters to be useful when programming in javascript. Once these are in place, systems written in javascript are remarkably maintainable & scale with complexity.
Except when I use JSLint. Talk about bringing you back to Earth when you think you've done something remarkable with JS.
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 ===.
The point is that side effects in code are dangerous, and can be used to mislead a reader.
If this happens, it is not the fault of JavaScript. Anyone who writes code like that for purposes other than demonstration or learning is a moron.
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.
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++:
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.
This makes it somewhat obvious that you can't change how basic types work in C++. On the other hand, JS's dynamicity makes for some interesting situations, as seen here. I wouldn't consider it "awful" but it's certainly a language with more "deep complexity" than appears at first glance.
Fortunately, at this stage, we get the best of both worlds with syntax validators and linters. Abuse as appropriate (whatever that means) and be warned about the rest.
class B(object):
def __eq__(self, other):
return True
b=B()
The language used can hardly be blamed for that.