Comments on: JavaScript 2: Everything but the Kitchen Sink http://www.numenware.com/article/565 Religion. Brain. Dogen. Language. Japan. Mon, 12 May 2008 09:27:57 +0000 http://wordpress.org/?v=2.5 By: Brendan Eich http://www.numenware.com/article/565#comment-3026 Brendan Eich Wed, 05 Dec 2007 00:55:57 +0000 http://www.numenware.com/article/565#comment-3026 I should add that your example is fine JS2, closer to Python or Scheme than the JS1 version: bar = function(z,x){return z*x} foobar = function(){return 666} function foo(x) { return x * bar(x,foobar()) } Now why are those curly braces and return keywords, and two lines instead of one for the bar and foobar assignments, so necessary once you learn about destructuring and expression closures? Learning new shorthands is sanity, not madness. But to each his own. BTW, JS1.8 in Firefox 3 supports your version already. Run and hide! :-P /be I should add that your example is fine JS2, closer to Python or Scheme than the JS1 version:

bar = function(z,x){return z*x}
foobar = function(){return 666}
function foo(x) { return x * bar(x,foobar()) }

Now why are those curly braces and return keywords, and two lines instead of one for the bar and foobar assignments, so necessary once you learn about destructuring and expression closures? Learning new shorthands is sanity, not madness. But to each his own.

BTW, JS1.8 in Firefox 3 supports your version already. Run and hide! :-P

/be

]]> By: Brendan Eich http://www.numenware.com/article/565#comment-3025 Brendan Eich Wed, 05 Dec 2007 00:48:26 +0000 http://www.numenware.com/article/565#comment-3025 laurent V.: you are faking confusion, and not fooling anyone. Your examples prove my points: 1. You know how to write ES4 without confusion, and read it. 2. You chose to write the new forms, but you are not required to -- they're optional, backward compatible extensions. Cut out the crocodile tears and intentional use or abuse of new forms, and you have no objection. As for addressing issues in the 3rd edition -- we're doing that, we have a list of bug fixes to track what real browser implementations do, or where those disagree and ES3 still was broken (two cases of note), to do something better. See the compatibility doc at http://ecmascript.org/ and quit whining :-/. /be laurent V.: you are faking confusion, and not fooling anyone. Your examples prove my points: 1. You know how to write ES4 without confusion, and read it. 2. You chose to write the new forms, but you are not required to — they’re optional, backward compatible extensions. Cut out the crocodile tears and intentional use or abuse of new forms, and you have no objection.

As for addressing issues in the 3rd edition — we’re doing that, we have a list of bug fixes to track what real browser implementations do, or where those disagree and ES3 still was broken (two cases of note), to do something better. See the compatibility doc at http://ecmascript.org/ and quit whining :-/.

/be

]]> By: laurent V. http://www.numenware.com/article/565#comment-2032 laurent V. Mon, 05 Nov 2007 13:48:52 +0000 http://www.numenware.com/article/565#comment-2032 Funny, our user choice will not be “diktat” to everyone but yours (brendan’s one, as the father of the language) will “diktat” our use of the language. You keep saying everywhere that’s everything in ES4 is optional. But in reality it is not, your are just creating a lot more of confusion and code nightmare with ES4. ES4, <span class="caps">IMO</span>, is not needed, a much better thing would have been to adress the issues in 3rd edition. This is madness. Sorry to say but you, at the TG1, are turning a simple language to a confusing one. [bar,foobar] = [function(z,x) z*x, function() 666]; function foo(x) x * bar(x,foobar()) Total madness, confusing like hell. Funny, our user choice will not be “diktat” to everyone but yours (brendan’s one, as the father of the language) will “diktat” our use of the language. You keep saying everywhere that’s everything in ES4 is optional. But in reality it is not, your are just creating a lot more of confusion and code nightmare with ES4.

ES4, IMO, is not needed, a much better thing would have been to adress the issues in 3rd edition.

This is madness. Sorry to say but you, at the TG1, are turning a simple language to a confusing one.

[bar,foobar] = [function(z,x) z*x, function() 666];
function foo(x) x * bar(x,foobar())

Total madness, confusing like hell.

]]> By: Brendan Eich http://www.numenware.com/article/565#comment-1436 Brendan Eich Sun, 28 Oct 2007 04:22:53 +0000 http://www.numenware.com/article/565#comment-1436 One more point: class is not equivalent to prototype/closure-based <span class="caps">OOP</span> in JS today. There is no way today to make an instance that is sealed against mutation by addition of new properties. The private properties you can create by capturing constructor closures, e.g., is costly and verbose to write (besides being alien to most programmers—many can learn, but the other costs hurt; why be different?). For high-integrity abstractions that can compile to the metal, classes are the right fit, dogmatic objections aside. My point here, though, is that it simply is not true that class in ES4 can be simulated in ES3/JS1. Simulated in some ways, but mutation in JS1 is a bitch, and class controls it along several axes. /be One more point: class is not equivalent to prototype/closure-based OOP in JS today. There is no way today to make an instance that is sealed against mutation by addition of new properties. The private properties you can create by capturing constructor closures, e.g., is costly and verbose to write (besides being alien to most programmers—many can learn, but the other costs hurt; why be different?).

For high-integrity abstractions that can compile to the metal, classes are the right fit, dogmatic objections aside. My point here, though, is that it simply is not true that class in ES4 can be simulated in ES3/JS1. Simulated in some ways, but mutation in JS1 is a bitch, and class controls it along several axes.

/be

]]> By: Brendan Eich http://www.numenware.com/article/565#comment-1442 Brendan Eich Sun, 28 Oct 2007 04:11:01 +0000 http://www.numenware.com/article/565#comment-1442 The “Just plain weird” objection to syntactic extensions needs more than expostulations about madness. Try expression closures (in Firefox 3’s forthcoming beta), you will like them. Here’s another clue: Python had nothing to do with the destructuring assignment proposal, which was implemented in Opera before it was submitted to the group (destructuring has a long provenance in ML and other languages; the idea did not begin with Python, which anyway calls it “unpacking”). About your “If I’d wanted a typed programming language, I’d have chosen one to start with”—did you really “choose” JS? In browsers there is no choice, and however much you detest types (don’t write them if you don’t want to, type annotations are optional), others absolutely will use them. Especially at <span class="caps">API</span> boundaries, in lieu of piles of error-prone and bulky argument and result checking/normalizing code. The thread at http://lambda-the-ultimate.org/ is worth a read in full, if you are willing to give ES4 half a chance. If you simply prefer to keep using JS as it is, no problem. Your choice will not be <i>diktat</i> to everyone, however. /be The “Just plain weird” objection to syntactic extensions needs more than expostulations about madness. Try expression closures (in Firefox 3’s forthcoming beta), you will like them.

Here’s another clue: Python had nothing to do with the destructuring assignment proposal, which was implemented in Opera before it was submitted to the group (destructuring has a long provenance in ML and other languages; the idea did not begin with Python, which anyway calls it “unpacking”).

About your “If I’d wanted a typed programming language, I’d have chosen one to start with”—did you really “choose” JS? In browsers there is no choice, and however much you detest types (don’t write them if you don’t want to, type annotations are optional), others absolutely will use them. Especially at API boundaries, in lieu of piles of error-prone and bulky argument and result checking/normalizing code.

The thread at http://lambda-the-ultimate.org/ is worth a read in full, if you are willing to give ES4 half a chance. If you simply prefer to keep using JS as it is, no problem. Your choice will not be diktat to everyone, however.

/be

]]>