[mncolinlee]

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.

[briantakita]

> 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 === 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.

[mncolinlee]

Nothing you said actually differs from what I said.

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 ===.

[at-fates-hands]

>> I also find automated testing, logging, a module system like commonjs, and linters to be useful when programming in javascript

Except when I use JSLint. Talk about bringing you back to Earth when you think you've done something remarkable with JS.

[mrkipling]

Try JSHint instead. It catches actual problems and everything else is customisable, so you're not forced to change your coding style to fall in line with the whims of a stubborn author.

[maxbucknell]

At the end of the article, it is demonstrated that this can happen even with strict equality by overriding the getters. Any language with getter/setter support can do this. Operator overloading can be used for even nefarious ends.

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.

[mikeash]

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.

[tyilo]

In Obj-C you can if you would allow `a.prop == b.prop`.

[mikeash]

Sure, but then it's obvious that you're doing something beyond an equality comparison.

[jacalata]

Do you mean it is obvious to people who know objective C? I've never used the language, but its not obvious to me just from the other c-family languages I know.

[mikeash]

Yes, if you know Objective-C. If you don't know it, I wouldn't expect you to immediately grasp anything about the behavior implied by a snippet of it.

[pmelendez]

>"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

[userbinator]

> #define int INT

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.

[j2kun]

Now do it in Haskell.

[mncolinlee]

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.

[pmelendez]

I think you are missing my higher point. I am not defending JS or C++ for that matter (please note that I was not using C), but the fact that giving enough time you can break most languages to do something silly, in which case I don't blame the tool but the people using it.

[rmrfrmrf]

There are ways to do stupid things in any language. I don't think anyone would ever tell you that redefining an integer as an object and overwriting its prototypes is an acceptable way to solve...any? problem.

[sisk]

I'm glad that you said, "can be" because language flexibility is a two way street. You can abuse dynamic typing for good and for evil. I, personally, don't think that's a case for declaring it not worthwhile, rather it reenforces investing the time to properly understand the language.

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.

[MatthewWilkes]

Yeah, just use python!

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

  b=B()

It's much more expressive

[vernie]

Okay.

[cruise02]

> Imagine what happens to your code when someone tries to write a function for its side effects...

The language used can hardly be blamed for that.

[marknutter]

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