Short Functions

Isaac Schlueter i at
Sun May 22 17:21:06 PDT 2011

On Sun, May 22, 2011 at 16:05, Brendan Eich <brendan at> wrote:
>> Cutting out many kilobytes of code from JavaScript programs by
>> streamlining the single-most commonly-used idiom is hardly frivolous.
> The counterargument, I don't share it but you seem to be focused on bandwidth, is transfer-encoding compression, gzip.

I think you and I agree on this point.  Syntax should be judged based
on the costs to fingers and brains.  In this regard, I think that
writing and reading a lot of bytes for a frequent idiom is a bad
thing.  It's about bandwidth across neurons, not wires.

Towards that end, I see a lot of promise in the arrow-function proposal.

>> In fact, I'd argue that it should be one of the main goals of this
>> list and of TC-39.
> We should have short syntax as a main goal? That hits return too.

Indeed it does!  That being said, implicit returns are a bit thornier
problem for their security implications.

> It arguably means block lambdas, since they are more concise
> and more expressive. But you demur from them below, so brevity
> can't be the top "main goal".

I don't think that brevity should be the primary goal of Harmony or
es-next, no.  But I do think it should be an important consideration.

Brevity is not a value in itself.  It is a value when the shorter
syntax reduces the overall cognitive burden.  Code that is easier for
humans to think about, tends to also be easier for humans to not mess

>> The complications have not been very well explored, and are not
>> trivial, in my opinion.
> They have been explored in other dynamic languages. They're not that bad.

Yes, I guess we are pushing opinions at each other.  I'd say that they
are that bad.

I have experience only with Ruby, not SmallTalk or E.  Maybe they're
handled better in the other two?

>> I am also unconvinced by the "looks like a block" argument.  The body
>> of a es-current function also "looks like a block",
> No. That's not the relevant comparison. The issue is whether the whole
> function-or-block-lambda-expression "looks like a block".

That was the point I was trying to make.  Having block-lambdas behave
like functions is not a hazard.  "||" is enough of a differentiator,
just like "function ()" is, only with a little less to look at.

On Sun, May 22, 2011 at 16:36, Brendan Eich <brendan at> wrote:
> To reverse the argument you made: if function body looking like a block
> were a source of confusion, we'd already have trouble:

I'm not saying it's a source of confusion.  I'm saying "this callable
thing is dramatically different than that other callable thing" is a
bigger hazard than "this curly-brace is dramatically different from
that other curly-brace".

> But people do not read the return above as returning from function outer. Why not?

Perhaps because callables in JavaScript are all the same, and only
ever return out of themselves, never their parent scope.  (Of course,
ctors called with "new" aren't quite identical to normal functions,
because of the implicit "return this".  But that is a determined by
the call style, not by the function type, and is a much smaller

> More likely, the distinctive function () head syntax before the
> body block made it clear.

As |arg| would as well.

My point there was that "looks like a block" is something of a stretch
as an argument for or against anything.  Object-literals look like
blocks with labelled lines, but we don't seem to have any problems
with those (except when we do, of course; qv. every JS repl.)

Here's the sort of thing that I'm driving at:

function abc (cb) {
  if (Math.random() < 0.5) cb(100)
function xyz () {
  abc( {|x| return x } )
  return 10
var p = xyz()

The fact that a conditional in abc() can trigger a return in xyz,
without transferring control back to the calling function first, seems
surprising to me.

The situation is further complicated when dealing with asynchronous
code.  If I'm not mistaken, the following will throw if readyToGo()
returns false, yes?

function abc (cb) {
  if (readyToGo()) cb()
  else setTimeout(cb, 100)
function xyz () {
  abc( {|x| return x } )
  return 10
var p = xyz()

Changes to flow control semantics have subtle implications.  Perhaps
user-testing will bear out that my taste is in the minority, and that
the abuses are lesser or no worse than what we already deal with, I
don't know.

More information about the es-discuss mailing list