Hacker News Reader

Comment by wycats | Hacker News Reader

He then proposes a wholesale change to function semantics in the language.

Actually, I linked to a proposal by Brendan Eich, the creator of JavaScript.

I mean, come on, this is the same guy who wrote a reopenClass function in Ember.js

JavaScript's open prototypes suffer from the inability to define a number of new properties at once using an object literal. reopen (not reopenClass), provides that functionality.

This is nothing but a post glorifying Ruby and bashing JS for not being Ruby

Nope. It's a post glorifying the correspondence principle, which Smalltalk and Lisp had before Ruby, and arguing that JS would be better with it.

View on HN

...glorifying the correspondence principle, which Smalltalk and Lisp had before Ruby...

But Lisp doesn't need two different kinds of lambda (at least neither Common Lisp nor Scheme has anything like that).

I'd be interested to know exactly what about JavaScript forces it to need blocks to obey the CP, when Lisp doesn't need them - I haven't quite wrapped my head around that yet. Is it just the problems with 'return' and 'this'? Could that be fixed by instead adding Common Lisp's 'return-from', and fixing 'this' somehow, instead of by adding blocks?

Well, it does need two kinds of lambda, in a sense. In Lisp, something like with-file would be a macro, which solves the same problem that "blocks" are solving here.

Also, Lisp has (return-from) which lets you do a non-local return by specifying which enclosing function to return from by name.

In Common Lisp, LAMBDA doesn't automatically define a return point; you have to use BLOCK NIL (or some macro (like DO or LOOP) whose expansion includes a BLOCK NIL) in order to be able to use RETURN.

  > (defun foo ()
      (block nil
        (funcall (lambda () (return 3)))
        4))
  FOO
  > (foo)
  3

So the problem is that JavaScript's `function' always creates a return point.

Your example does not make much sense, because you can return-from foo in lambda, without enclosing it in a block.

The solution proposed by OP (distinguishing "lambda" callables from "block" callables) is in my opinion misguided, because it only solves a problem partially, in a confusing way and creates new, unnecessary entities. The return-from mechanism is simpler and more intuitive.

> Actually, I linked to a proposal by Brendan Eich, the creator of JavaScript.

Naming names doesn't change the idea: It is surely a wholesale change to function semantics in the language.

> JavaScript's open prototypes suffer from the inability to define a number of new properties at once using an object literal. reopen (not reopenClass), provides that functionality.

Sure, that's why you use a general-purpose merge function, prototypes just being objects themselves.

  var merge = function(o, o2, force) {
      for (var p in o2)
          if (o2.hasOwnProperty(p) && (!(p in o) || force))
              o[p] = o2[p];
      return o;
  };

  var C = function() { /* ... */ };  
  merge(C.prototype, {
      foo: function() { /* ... */ },
      bar: function() { /* ... */ }
  });

In any case a name like reopenClass() sounds very much like an attempt to make JS smell like Ruby even if all the function does is perform a merge.

  I can't take Katz' suggestions for JavaScript seriously.
  ...
  Naming names doesn't change the idea.

I’m confused! Are we judging ideas by the source or by their merits?

He named a name rather than challenge the suggestion ... I named a name to show that I am noticing a common quality in Katz' recent foray into JavaScript, that being his desire that it be like Ruby, the language for which he's best known.

That's not what happened. You started out with "I can't take Katz' suggestions for JavaScript seriously." and he pointed out that it wasn't his, but Brendan Eich's proposal.

To which you answered "Naming names doesn't change the idea."

For what it's worth, I've been writing JavaScript for longer than I've been writing Ruby, and have contributed rather extensively to JavaScript libraries over a number of years.

And when you look at the Ember source this is basically what reopen is doing.

But (!) writing

  C.reopen({
    foo: function() { /* ... */ },
    bar: function() { /* ... */ }
  })

instead of

  /*window.*/merge(C.prototype, {
    foo: function() { /* ... */ },
    bar: function() { /* ... */ }
  })

makes for easier reading, which is worth a lot in my opinion.

It's the same as Cocoa providing -[NSMutableArray removeLastObject] in addition to -[NSMutableArray removeObjectAtIndex:] and -[NSMutableArray length]

Sure you can express one with the other, but readability matters.

"""Naming names doesn't change the idea"""

Oh, but it does. First, it shows that you didn't understood what you read (re: who wrote the proposal).

Second, it shows that the thing that you deemed as unfit for the language is considered as fit by the VERY CREATOR of said language.

"""It is surely a wholesale change to function semantics in the language."""

So what, if it's needed?

Reply on news.ycombinator.com