Anonymous methods

John J Barton johnjbarton at johnjbarton.com
Wed Jan 11 13:42:40 PST 2012


On Wed, Jan 11, 2012 at 1:04 PM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 11/01/2012 19:10, John J Barton a écrit :
>
> The blog post  http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ makes
> the case for blocks that act like functions when passed as arguments but
> have loop-up rules more like nested blocks.
>
>  Of course these are called 'block lambdas', and I suggest that this is a
> problem. Given that very few programmers understand lambda calculus (and
> this will not change), the word 'lambda' is equivalent to "too difficult to
> understand".
>
>  When I looked up lambda on http://en.wikipedia.org/wiki/Lambda I read
>
>    In mathematical logic <http://en.wikipedia.org/wiki/Mathematical_logic>
>  and computer science <http://en.wikipedia.org/wiki/Computer_science>,
> lambda is used to introduce an anonymous function<http://en.wikipedia.org/wiki/Anonymous_function> expressed
> with the concepts of lambda calculus<http://en.wikipedia.org/wiki/Lambda_calculus>
> .
>
>  and then "Oh that is what they meant with all that 'block-lambda' stuff".
>
>  If the discussion here were on a new ES feature "anonymous methods",
> then I guess many more developers would be interested. If this feature had
> the properties outlined in the blog post, then I think many developers
> would understand the value of this potential feature. As it is I guess they
> stop reading as soon as they see the word 'lambda'.
>
> From your e-mail, it seems granted that "more developers interested" is a
> good thing. I can't really say whether I agree or not. So I guess I should
> ask the question: is more developers interested a good thing?
>

If your interest in language design ends with design, then No, it does not
matter how many developers are interested.

If your interest in language design extends to seeing that design in
practice by millions of developers, then Yes it does matter how many
developers are interested.


>
> Language design and evolution of a language are not necessarily things
> that are of everyone interest. I think that those who are actually
> interested in the evolution of JavaScript read proposals and strawmen
> regardless of how scary the name may sound.
> If just the name of a proposal is enough to scare someone out, then this
> person may just not be interested in the evolution of the language... and
> that's perfectly fine.
>

If you only care about proposals, sure. But if you care about seeing those
proposals implemented you need to investigate the implementation process.
It starts with an evaluation of cost/benefit: will the many person hours
invested in block lambda implementation result in my browser developers
using JavaScript block lambdas? Or should I put those hours elsewhere?


>
> Besides naming, I think that the important thing is explaining what these
> names are about. Brendan Eich gave a presentation on proxies at JSConf.eu.
> Before that, who in the JS community was aware of what proxies are? Not a
> lot I would guess.
> This presentation helped explaining the idea and sharing some knowledge on
> what "reflection" is. In my opinion, this kind of sharing is more important
> than the fact that the feature is named "proxy" or "tartanpion".
> I did some of it when documenting WeakMaps on MDN [1].
> The article you mention does this work too. There is no explanation on
> what a lambda is, but it does explain what JavaScript anonymous functions
> lack and how "block lambda" would be an improvement.
>
> As long as there are people doing this, names are not really important I
> think.
>

Of course I disagree. "Block Lambda" is like "sodium lauryl ether sulfate":
a technically correct name with complex connotations unrelated to the
end-users need.

Good names are hard to design, but they are important.

jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120111/73211482/attachment-0001.html>


More information about the es-discuss mailing list