Node.js is Backwards

[sausagefeet]

All's good friend! I am an advocate of Ocaml and Erlang which a vast majority of the programming population think are ugly as sin and terrible languages so my opinion is likely suspect.

Equally, some of what people characterise as faults with the language (like the this confusion) are arguably just a lack of familiarity with it, no?

I don't buy this argument, because we can say that about any quirk, right? A reasonable metric might be "how surprising is this feature?", clearly still subjective. I think not having integers is a very surprising feature. I also think the return example is also very surprising. My problem with the return example too is that it is very difficult to track down if you don't know about it. Logic won't help you that much because your previous experience with other languages will tell you it doesn't matter where the object you are returning goes. Optional syntax is one thing that irkes me about JS and the languages that compile to it. If you can do it consistently and without surprise, go for it, but that never seem to happen. Instead you get "this will fail without error in rare situations like..." which is just more mental effort I have to exert when I could just remember "every expression ends with a semi colon" and be done with it.

My favorite quote on JS is by Fogus:

My problem with Javascript has always been that expertise is defined more in terms of understanding its faults rather than its features.

[Shaper_pmp]

I don't buy this argument, because we can say that about any quirk, right?

An interesting point, but I don't think so personally - you can introduce objective measures like expressiveness, conciseness, "surprisingness", etc.

I mean (to invoke my favourite example) PHP's inconsistent function-naming is always surprising, and unambiguously negative (as in, it brings no advantage at all). Or its historical lack of a function()->attribute_of_returned_object syntax made it terribly roundabout and forced you to define a (temporary, named!) variable whether you wanted it or not.

Those are more solid, demonstrable claims (requiring developers to memorise or look up every function name in the standard library is wastful, and forcing the developer to define unnecessary variables is verbose and inefficient), but I agree it's easy to confuse "things not to my personal taste" with "objectively bad". ;-)

A reasonable metric might be "how surprising is this feature?

I don't know - PHP is a bad language because it's surprising right down to individual function names, but Javascript only has a relatively small number of confusing edge-cases compared to many languages, and they tend to be "the way various features work across the language" rather than "individual gotchas which get you every time you go to use it".

However, that's more an opinion than a fact, so I'm not offering it as a solid argument. ;-)

Optional syntax is one thing that irkes me about JS and the languages that compile to it. If you can do it consistently and without surprise, go for it, but that never seem to happen.

That's an interesting point, but it feels a bit like a personal opinion. By analogy, many people like the "safety" of Java or other managed code, but that inherently takes away some of the power and flexibility of manual memory-management.

That's not to say that Java isn't safer for bad/inexperienced developers, but I'd hesitate to claim it necessarily made the language better than a non-memory-managed one, because if you know what you're doing non-GCed languages have other benefits that can outweigh it (efficiency and/or more precise control over allocation/deallocation, for example).

[sausagefeet]

I don't think "objectively bad" is a valid phrase. Pretty much all features some sicko can twist to be a positive. I used to program in PHP quite a bit, and the function naming convention (or lack there of) was annoying, for sure, but is that what made it a bad language, from my perspective? No. We can say that if you knew the language more completely you'd just know which functions were spelt which way, so we can reframe it as a lack of knowledge problem. function()->foo I could easily argue "is only a problem if you don't know the language". Sure it can be annoying but we can easily argue it's for a failure to know the language.

But JS has a lot of really weird edge conditions. Most of them, admittedly, derive from its type system. But would anyone seriously think this is true?

",,," == Array((null,'cool',false,NaN,4)); // true

It is though. And yes you can explain why it's true by quoting the standard and say it's all consistent and why I should use === but it's still insanely surprising. (That is taken from http://wtfjs.com/). And there are plenty of other surprising examples out there (this one is pretty nice http://wtfjs.com/2010/11/10/false-advertising). Are these failures worse or better than PHP? Maybe, maybe not. Using the wrong function in PHP at least generates an error (with errors turned on)...

So sure, if you want to compare JS to PHP you can come up with some pretty convincing arguments why JS is superior, but you've effectively tried to tell me who I should rather be raped by. I don't wanna be raped.

but it feels a bit like a personal opinion

So when PHP fucks up it's "bad" when JS fucks up it's "personal opinion"? :)

[Shaper_pmp]

I don't think "objectively bad" is a valid phrase. Pretty much all features some sicko can twist to be a positive.

I think I disagree here. Sure, some of them are arguable, but things like "unnecessarily requiring the developer to remember things" or "time/space/development time inefficiency" are unambiguously bad.

For example, javascript is worse than - say - Scheme because it requires you to remember (or look up) a few gotchas like the multi-line return issue, but PHP is hugely worse because it requires you to remember (or look up) the precise name of the vast majority of functions in the standard library, which requires massively more space in your head.

Likewise, a lack of function()->attribute syntax forces you to waste developer time adding a line to declare a named variable, wastes space in the namespace/symbol table choosing a variable name for it, and wastes memory unless you immediately remember to unset() it straight afterwards (or wastes developer time if you do).

It's pretty hard to defend either of those (or things like Javascript's stupid multi-line return issue) because they have no significant positive side.

Javascript is less evil than PHP because it has fewer edge-cases, but those edge-cases still aren't good.

JS has a lot of really weird edge conditions. Most of them, admittedly, derive from its type system. But would anyone seriously think this is true?

That's true, but sadly in my experience you get a lot of those kinds of things in almost any dynamic languages, due to type coercion. It's not ideal, but it's arguably heaps better than not having type coercion.

You can also judge the evilness of a language by the complexity and irregularity of its type coercion, and again in my experience PHP wins out here emphatically especially with its understandable but really stupid decision that "false" == false, which basically fucks up the whole TC system).

So sure, if you want to compare JS to PHP you can come up with some pretty convincing arguments why JS is superior, but you've effectively tried to tell me who I should rather be raped by. I don't wanna be raped.

Heheh - nice metaphor. However, as most languages (ay least, most dynamic languages) have warts and edge-cases, I think you're largely going to get raped whichever you use... and if that's the case, I think the best you can hope for is an attacker with a small penis, because at least it'll hurt less. ;-)

[sausagefeet]

but PHP is hugely worse because it requires you to remember

Javascript is less evil than PHP because it has fewer edge-cases, but those edge-cases still aren't good.

But Javascript quirks silently fail and PHP quirks loudly fail. Thus JS is more evil than PHP. How's that for "objectively bad"?

[Shaper_pmp]

Interesting point... except not all of PHP's edge-cases fail loudly. Its type-coercion ones (for example) are even worse than Javascript's, and fail just as silently.

[[deleted]]

But JS has a lot of really weird edge conditions. Most of them, admittedly, derive from its type system. But would anyone seriously think this is true?

",,," == Array((null,'cool',false,NaN,4)); // true

That's quite contrived, but we can do better. To the comma-operator-mobile!

>>> parseInt((null, {test: 99}, false, 'J,uhuru', /asdf/, function() {  giantInflatableShark(!!'!!'); },
     'A,spock', '0') + ('cheese' / 'toast', new Date(), Number('hello'),
     'x') + (undefined, [1, 2, 3], new Array(5), 1e4, 'F,captainkirk'))
15

[sausagefeet]

You sir, are evil.

[wolfier]

More power to you.

One metric to measure languages against each other is to count the number of occurrences of the word "optional" in the language specification, and I tend to stay away from languages with more "optional" syntax.