Hacker News Reader

There are quirks in every languages - python obviously included. And please, don't forget that you're using a very old version of the Javascript language. It's a little bit like if I'm arguing about the errors and quirks of Python 1.5. Languages evolve and learn from their mistakes. Unfortunately, old browsers are stuck with old javascript versions. Some people have to write code in java 1.4 or python 1.5, they aren't People who are good at [python or java] like [python or java] because it makes them special.

And that being said, most people coming from [name your favorite language] believe that Javascript works the same way as their language. It's a different language and require a different knowledge. In fact, javascript' similarity to algol might be one of the biggest problem of the language. Have you tried working with C++ without learning the language?

And here are some Python cool "features":

  def foo(x=[]):
    x.append(2)
    print x

  foo()
  foo()

Guess x? To take your term "You lose".

  print 3/2

What's the result? If you answered 1.5, sorry, you're wrong. We're using Python <2.2 here, and it gives 1.

Here's another one, what does it do:

  for i in range(10): print "*",
  print

Is it ""? Sorry, a comma at the end doesn't include a "\n" but automatically insert a space.

Anyhow, have fun here: http://stackoverflow.com/questions/530530/python-2-x-gotchas...

No language is perfect, but if those are the worst examples you can come up with for Python, there really is no comparison with the insane JavaScript WTF's I've seen.

Default list/dictionary arguments are plain evil in Python, no disagreeing there. I've been bitten by something like the following before, which is similar to your snippet:

  x = y = []
  x.append(2)
  print x
  print y

As for your other examples: except for Pascal/Delphi, I have never used a language that has separate division operators for floats and integers, so at least for me it's only natural that 3/2 == 1, how else would I do integer division?

The print example is just very weak, I can hardly even call it a WTF. Yes it's a little odd, but you're not going to hit weird runtime bugs like when you are comparing things in JavaScript, for example.

I'm frankly very surprised by the almost complete absence of real Python WTF's in the Stack Overflow discussion you linked, I would have expected more. If anything, it actually shows how clean and predictable Python is.

Maybe I wasn't clear. The gotcha with 3/2 == 1 isn't that it's giving 1, it's that the behavior changes depending of the version of python.

The worst one for me with JavaScript lately is trying to build some form of object orientation into my code. There's no canonical way to even implement a constructor, for christ's sake. I haven't even dared to touch trying to use it for polymorphism. Or composition, for that matter. I'm staying the hell away from it for anything simpler than UI code.

If JavaScript was a nicer language I would be spending more time in Node.JS, but it's not, so I'm sticking with Rails.

I actually don't mind this problem much, although that might be my "functional programming" bias.

You only really need a "canonical" way to do things if you will be wanting to use features that depend on your classes being implemented in a predictable way. For example, class inheritance or implementing "super" method functionality.

> I haven't even dared to touch trying to use it for polymorphism.

Its not at hard as it sounds, since you have first class functions and closures. You can often handle functions directly instead of needing to create objects for everything.

You're forcing class based inheritance onto a language that specialises in prototypical inheritance... however, try http://tobyho.com/2010/11/22/javascript-constructors-and/

Define "natural". Firstly, == is indeed for comparison, just with an implicit cast beforehand. You don't need to wrap all your code in an anonymous self calling function, but to get the most out of it you need to - given the way it was designed, this makes sense.

You speak like C syntax is "natural" - I remember grappling with pointers and references, it took some time for me to get it fully. It's not like Python doesn't have it's quirks.

I find it ironic that those who use Python/Ruby/Clojure/etc want to often ridicule those who use JavaScript. They've got their own form of elitism. Get over it, seriously.

What the parent was saying regarding the == vs === is that unlike other languages it's very easy to get burned if you don't know the difference and when to properly use it. I'm hardly proficient at JS and not knowing that would've screwed me over.

Can you give me a concrete example?

  0 == false

or even better

  "0" == false

edit: I should note that I don't think JS is a horrible language or anything, but it does have more than its share of oddities.

I guess I'm still confused... Where abouts in your code will you be comparing a string or integer to a Boolean?

Incidentally, there are quirks - the worst is with having to define a "that" variable, I guess I just don't see these JavaScript issues as all that terrible. Unlike PHP's type coersion system, Javascript's is quite sensible.

The point is that comparisons between things of different types should be errors. Implicit coercion is never sensible.

4 / 2.5 should be an error?

Okay, then. Never mind that essentially no language in widespread use enforces that.

That case is also potentially problematic, but perhaps better solved by having float division / and integer division // as separate operators.

Perhaps my "never" was too strong.

If you have a function which returns an integer or false.

That, I would hazard to advance, is a very poorly written function.

The most common `==` problem is `0 == ""`, IMO

As if that wasn't bad enough on it's own.

"0" == false and "" == false but "0" != ""

Edit: Or maybe a less defendable example of my point:

"0" == 0 and "" == 0 but "0" != ""

>People who are good at JS like JS because it makes them special. They can lord their knowledge of the quirks over "lesser" developers who come to JS expecting it to act like a sane language. It took an entire industry about a decade just to learn how to tame it. Sure, JS turned out to be really extensible to new paradigms, but hey, so is the lambda calculus.

All those points are moot. It's like pointing C's many flaws (or PHP's myriads). Or Ruby's. Or Javas. All languages have several syntactic or semantic issues.

It didn't "took the industry a decade to learn Javascript". It took the industry a decade to have:

1) Mostly compatible implementation of JS and the DOM. 2) Powerful enough computers and JS VM so it can be used for fancy stuff. 3) A reason to use it (AJAX and involved web apps).

Nothing of which has anything to do with Javascript's "difficulty" or "quirkiness" as a language.

>Oh, what, you thought == was for comparison? Wrong.

Actually true. And truer to the dynamic spirit of Javascript than ===. Sometimes things don't have to be absolutely equal to be equal, "1" and 1 will do just fine. You can sanitise at another level.

>Oh, you didn't wrap your all your code in an anonymous, self-calling function? You lose.

You loose nothing. You merely expose some names to the global namespace. Which might just be just one name, anyway, sans the anonymous self-calling function. (e.g

window.ns = {}, ns.doSomething = function() ...

>Oh, what you thought it was okay to leave off semicolons and var statements because they aren't required? Sorry.

Sorry for nothing much. A lot of people leave them off with no problem at all. The few edge cases are not unlike any other language's edge cases.

>Hmm, you didn't know how to manage dependencies between scripts? Should have studied harder.

Or not. If you got the result you want.

>You tried to iterate over an array? Ridiculous.

You probably mean the "for i in" idiom. Which is perfectly fine over an array. The only problem arises if someone has extended the Array prototype, which you shouldn't do anyway. And even that can be bypassed with one extra hasOwnProperty check. Not to mention it's solved in ES6.

>Your brain exploded when trying to write a series of asynchronous functions in continuation style? A pity, really.

Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs.

> Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs.

If async programming in JavaScript "isn't supported by the language": what good is it, then?

The basic idea of having a framework full of nonblocking async calls for stuff and using simple cooperative threading is a reasonable design decision depending on what you want to do. The problem is that Node forces you to write code in continuation passing style and that is a very "low level" way to write things, missing many of the niceties languages tend to have right now.

* If you want an async value you need to give it a name and put it in a callback argument. Instead of `f() + g()` you end up doing `f(function(a){ g(function(b){ ballback(a+b) } ) })`

* You need to explicitly tell the order of execution of everything (as shown in the previous example)

* It can very laborious to refactor a non-CPS subroutine if part of it needs to become async, specially if you have many loops or call other subroutines. Ideally you shouldn't have to do large "boilerplate" rewrites of your code just because of a small local change.

If you are curious what the better alternative for to CPS style is, my opinion is that the way to have the language do the work of breaking the code into the callbacks for you, either via dialects that compile to JS or via features such as generators. While you can get away with many of the very nice async programming libraries out there, they still can't solve all the problems with CPS style (specially the refactoring one)

Who said Javascript is good for async programming?

It was designed to be easy to use with callbacks for website UI style events (which is not quite the same as async programming).

The Node async is just a half-thought implementation of async on top of a VM that doesn't really support it. The thing it has going for it is traction (and some people new to async are amused by the callback style and find it "challenging", whatever).

Scala/Dart/Go/Rust/Haskell/etc have a better async story.

ES6 will add some promising stuff in the future (no pun intended).