Anonymous methods
On Wed, Jan 11, 2012 at 10:10 AM, John J Barton <johnjbarton at johnjbarton.com
wrote:
The blog post 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 en.wikipedia.org/wiki/Lambda I read
In mathematical logic en.wikipedia.org/wiki/Mathematical_logic and computer science en.wikipedia.org/wiki/Computer_science, lambda is used to introduce an anonymous functionen.wikipedia.org/wiki/Anonymous_function expressed with the concepts of lambda calculusen.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'.
For what it's worth, C#, Python, Ruby, Java (in JDK 8), and C++ (in C++11) all use "lambda" to roughly mean "anonymous closure". It's a strange term but it's becoming widespread. "lambda" is a keyword in Ruby, Python, and Scheme (where "keyword" -> "special form" in Scheme for the nitpickers).
On Jan 11, 2012, at 10:10 AM, John J Barton wrote:
The blog post 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 en.wikipedia.org/wiki/Lambda I read
In mathematical logic and computer science, lambda is used to introduce an anonymous function expressed with the concepts of 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'.
Except that they aren't "methods" (a function that is associated with an object).
If you want a name without "lambda" you might consider "block function" or "functional block" indicating that we are talking about code blocks that may be passed and invoked as function values.
I believe when we talk about lambda here, we don't exactly mean addressable anonymous functions :-)
python lambda
g = lambda x: x*x g(8) # 64
// JS lambda function lambda(exp) { var body = exp.split(":"); return Function(body[0], "return " + body.slice(1).join(":")); }
var g = lambda("x: x*x"); g(8); // 64 g.name; // anonymous
Le 11/01/2012 19:10, John J Barton a écrit :
The blog post 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 en.wikipedia.org/wiki/Lambda I read
In mathematical logic en.wikipedia.org/wiki/Mathematical_logic and computer science en.wikipedia.org/wiki/Computer_science, lambda is used to introduce an anonymous function en.wikipedia.org/wiki/Anonymous_function expressed with the concepts of lambda calculus 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?
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.
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. Another part (which is not that widely accepted at least in western countries) is also that people acknowledge when they don't know something and either go read or ask questions. I think I have asked here my fair share of questions and I have always been answered appropriately. I've never been thrown rocks at, or made fun of.
In my opinion, everyone staying open-minded seems more important than choosing nice-looking feature names.
David
[1] developer.mozilla.org/en/JavaScript/Reference/Global_Objects/WeakMap
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 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 en.wikipedia.org/wiki/Lambda I read
In mathematical logic en.wikipedia.org/wiki/Mathematical_logic and computer science en.wikipedia.org/wiki/Computer_science, lambda is used to introduce an anonymous functionen.wikipedia.org/wiki/Anonymous_function expressed with the concepts of lambda calculusen.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
On Wed, Jan 11, 2012 at 1:42 PM, John J Barton <johnjbarton at johnjbarton.com>wrote: [...]
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.
How about "first class blocks" or "callable blocks"?
Le 11/01/2012 22:42, John J Barton a écrit :
On Wed, Jan 11, 2012 at 1:04 PM, David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:
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.
I think I disagree with the approach with which you're taking this issue. From your response I understand that JavaScript language maintainer are responsible for bringing more developers to the discussion. To some extent, I agree and they actually do too apparently. There is an open mailing-list, a wiki. Some of the TC39 folks go at conferences, present what ES.next will be, present open questions, and do Q&A. So far, I have probably seen 10 40-60 minutes-long videos of this kind over the last 3 years.
But this is not enough? Features would also need to have cute names to not scare developers? I'm sorry, but I think it's asking too much. I think there is also an effort on the developers side to show interest in the evolution of the language, understand its history, its flaws, etc.
I agree that bringing more developers to the discussion is a good thing and I think the door is wide open for that. If anyone disagrees with this, find es-discuss hostile in some way, please raise your concerns. But there is also an effort on developers to be done. If someone stops reading an idea just because of its name, I'm sorry, but this person is not really motivated and I don't really know why hours should be spent renaming a feature just to encourage people to read ideas.
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?
That's an interesting question. And I think that the developers who care about the evolution of the language will provide valuable feedback. Those who are annoyed by what changes when you turn a loop body into an anonymous function as a forEach argument will speak up. Or not. But those who care will tell you. And you'll never hear about those who don't care and since they don't care, it does not matter that much.
And then, there is the fence. Those who are "sort-of-interested". I would say that their own motivation is what will put them on what side of the fence.
Motivation-based selection is a good way of selecting people. Have a low entry-barrier and let those who care come to you, rather than trying to bring everyone to you. I have observed several such systems at work and have always been amazed by how efficient it was.
The remaining question is "how low should the barrier be?" and in this case "should proposal names be changed to stop scaring some people out?". This is where I would say "no", because I consider that the name of a proposal is not enough to demotivate someone who care. This is subjective (and of course, I am also not in position of making a decision anyway :-p ).
In order to lower the barrier to entry, why not considering starting to translate the wiki in Mandarin, Spanish, French, Portuguese? There are a lot of developers IN THE ENTIRE WORLD who do not bring feedback just because they are not proficient enough in English. They will be affected by changes made to the JavaScript language.
On the good side of thing, English-speaking developers still have the ability to read the strawman written in English even if "Lambda" sounds latin to them. They just need to click the link. How low is the barrier for them?
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.
Good ideas are hard to understand, regardless of their name and I think it's important for people to make the effort to understand the idea and forgetting about the label it carries. If "block lambda" were called "anonymous method" or "first-class block" or "callable blocks", would that help to better understand the underlying idea? The problem it solves? how it is different from "anonymous functions"? I don't think so, it would just be a slightly less scary label.
Are we in 2012 seriously saying the word "lambda" is scary to developers? This sounds ridiculous. The word lambda is widely used by programmers in a variety of communities.
On Jan 11, 2012, at 2:11 PM, Mark S. Miller wrote:
How about "first class blocks" or "callable blocks"?
I also suggest "callable blocks" in a private email. Also a couple of others: functional block and block function.
I like "callable blocks" in that it emphasizes the block-ness (and implicitly, Tennent’s Correspondence Principle) rather than the function-ness.
On Wed, Jan 11, 2012 at 3:27 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
On Jan 11, 2012, at 2:11 PM, Mark S. Miller wrote:
How about "first class blocks" or "callable blocks"?
I also suggest "callable blocks" in a private email. Also a couple of others: functional block and block function.
I like "callable blocks" in that it emphasizes the block-ness (and implicitly, Tennent’s Correspondence Principle) rather than the function-ness.
+1
jjb
cc es
I named block-lambdas and wrote the proposal that Yehuda's blog is about, and I'm with Nathan and David here. If we approve block-lambdas then in clear contexts, most users will probably just say "block" and not "lambda".
But lambda is pretty well-known and I do not agree that John's dichotomy between language design interest groups (design in abstract vs. in practice by millions of developers) is a hard-edged and overriding split. Block-lambdas will be learnt by people moving between the two groups (if such groups really exist as segregations of people, instead of modes or "hats" many people can wear interchangeably or even at the same time).
Callable block is awkward (the ll-ble combination in the first word), and likely to be shortened to "block" in context anyway. Block statements are second class anyway, so not often mentioned by name (and then sometimes called compound statements or block statements in full).
I chose block-lambda to have a clear and pithy handle that would not be confused with either block statements or other lambda sketches or proposals, and I suggest we stick with it for now.
/be
Nathan Stott <mailto:nrstott at gmail.com> January 11, 2012 3:19 PM Are we in 2012 seriously saying the word "lambda" is scary to developers? This sounds ridiculous. The word lambda is widely used by programmers in a variety of communities.
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss David Bruant <mailto:bruant.d at gmail.com> January 11, 2012 3:14 PM Le 11/01/2012 22:42, John J Barton a écrit :
On Wed, Jan 11, 2012 at 1:04 PM, David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:
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. I think I disagree with the approach with which you're taking this issue. From your response I understand that JavaScript language maintainer are responsible for bringing more developers to the discussion. To some extent, I agree and they actually do too apparently. There is an open mailing-list, a wiki. Some of the TC39 folks go at conferences, present what ES.next will be, present open questions, and do Q&A. So far, I have probably seen 10 40-60 minutes-long videos of this kind over the last 3 years.
But this is not enough? Features would also need to have cute names to not scare developers? I'm sorry, but I think it's asking too much. I think there is also an effort on the developers side to show interest in the evolution of the language, understand its history, its flaws, etc. ...
The blog post 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 en.wikipedia.org/wiki/Lambda I read
In mathematical logic en.wikipedia.org/wiki/Mathematical_logic and computer science en.wikipedia.org/wiki/Computer_science,
lambda is used to introduce an anonymous functionen.wikipedia.org/wiki/Anonymous_function expressed
with the concepts of lambda calculusen.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'.
jjb