Re: Pick operator

[Edwin Reynoso]

Wow Bob that's really neat. I really like it. Because it returns an object
instead of assigning like destructuring. So it's very useful. So LGTM now
as I kept reading I got a little confused, just give me a moment I will.
But +1 for me. :)

On Sat, Jun 20, 2015 at 12:30 AM, Bob Myers  wrote:

> In the spirit of the discussion about language complexity and
> extensibility, consider the following brain-addled, pre-strawman proposal
> for a new pick operator.
>
> http://rtm.github.io/boberator.html
>
> I wonder if whatever macro-like facilities make their way into ES 20XX
> will be able to handle this. I suspect this is beyond the capabilities of
> sweet, but haven't really tried.
>
> Bob
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Pick operator

[Bob Myers]

In the spirit of the discussion about language complexity and
extensibility, consider the following brain-addled, pre-strawman proposal
for a new pick operator.

http://rtm.github.io/boberator.html

I wonder if whatever macro-like facilities make their way into ES 20XX will
be able to handle this. I suspect this is beyond the capabilities of sweet,
but haven't really tried.

Bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Greg McLeod]

>
> On Fri, Jun 19, 2015 at 7:23 AM, Scott Sauyet  wrote:
> I think the difference between your list and mine exemplifies the tragedy
> of the commons as so well described by Mark.  Although we both share a
> liking for modules and imports, my favorite ES6 feature is the arrow
> functions, with destructuring near the top.   The very bottom of my list,
> the only one I really, really wish n not been included is `class`.
>
> Covering the desires of both users like you and users like me is what can
> so easily leaf to bloat.
>
I think we're actually on the same page in terms of where a lot of the
problems lie in these discussions (though personally I've at least conceded
to ES6 at this point, since for me the core issue is more about
interpreting other people's code than it is about using it myself where I
can control its readability). It's probably not possible to add something
to a language that everyone likes, so the only option seems to be
compromise. In a way that's kind of a double-edged sword, where both
parties might benefit individually but at the cost of inhibited
conversation between the opposing sides (e.g. "i don't mind you getting X
so long as I can Y"). But I imagine as more people pick up ES6 it might
become clearer what the average dev is getting the most benefit from, and
those areas might be worth putting extra attention.

On Fri, Jun 19, 2015 at 8:18 PM, Mark S. Miller  wrote:
>
>> Someone just brought  to
>> my attention. It says:
>>
>
> I agree completely, and I fully apologize. Starting the thread this way
> was inappropriate, at least without some mitigating text which I did not
> think to add. I like the fact that we are all civil to each other here and
> try to keep the environment welcoming and friendly. Please no one take my
> message as precedent in the other direction.
>

Despite your opening I think you still fired up a much needed conversation.
This is the most critical thread I've read in awhile, and in a way it feels
a bit like a post-mortem for the recent release. Speaking of which, a
retrospective thread might be a good thing to have on a regular basis after
any ECMAScript release to get people's lingering thoughts out in the open
before moving on.

On Fri, Jun 19, 2015 at 7:23 AM, Scott Sauyet  wrote:

>
> Greg McLeod  wrote:
>
> > I really really love JS (it's so fun!), and while there are many
> features in ES6 that I think are great (such as classes, modules, and
> import syntax) there are things that quite frankly scare me quite a bit.
> Such examples include destructuring and arrow functions, which make sense
> when used in simple use cases but I find confusing to interpret when
> reading someone else's code due to their terseness.
>
> I think the difference between your list and mine exemplifies the tragedy
> of the commons as so well described by Mark.  Although we both share a
> liking for modules and imports, my favorite ES6 feature is the arrow
> functions, with destructuring near the top.   The very bottom of my list,
> the only one I really, really wish n not been included is `class`.
>
> Covering the desires of both users like you and users like me is what can
> so easily leaf to bloat.
>
>   -- Scott
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[Rick Waldron]

On Fri, Jun 19, 2015 at 5:12 PM C. Scott Ananian 
wrote:

> No, thank you.​
>
> Email clients are the ultimate forum aggregators.
>

I'm with Scott. Regardless, this conversation is a non-starter.

Rick

>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[Jonathan Kingston]

Discourse has the options to keep the same level of email reporting, daily
aggregation and allowing for responses via mail.

I'm not sure I see the need for a new category there either, there are
already:
- JS
- asm.js
- APIs
- Architecture

There are a fair few structured conversations there that would merit both
communities working together.

Perhaps hooking in Robin into the conversation here might help.

On Fri, Jun 19, 2015 at 11:15 PM Matthew Robb 
wrote:

> Yes, please. Also if like to take issue with everyone who prefers email
> clients for the following reason: it's easier to allow people who want to
> keep using email to do so while enabling a richer and more aggressive
> experience for those who want it than it is the other way around
> On Jun 19, 2015 5:21 PM, "// ravi"  wrote:
>
>> On Jun 19, 2015, at 5:12 PM, C. Scott Ananian 
>> wrote:
>> >
>> > No, thank you.​
>> > Email clients are the ultimate forum aggregators.
>>
>>
>> +1 on “No, thank you". Email works, email has are full-featured clients,
>> do not force browser use, etc, etc.
>>
>> —ravi
>>
>>
>> >  --scott
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Mark S. Miller]

Someone just brought  to my
attention. It says:

I like the author’s remarks and philosophy about keeping JavaScript small,
but I thought the opening was remarkably uncharitable. The specific person
and the specific feature are quite irrelevant to the point he’s making here.

I am left with some admiration for his goals, but also a great deal of
trepidation about ever suggesting anything or even talking about
JavScript.next. Will I be the next one called out by name if I make the
mistake of asking whether traits might be a good addition to JavaScript?


I agree completely, and I fully apologize. Starting the thread this way was
inappropriate, at least without some mitigating text which I did not think
to add. I like the fact that we are all civil to each other here and try to
keep the environment welcoming and friendly. Please no one take my message
as precedent in the other direction.

-- 
  Genuinely sorry,
  --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[Matthew Robb]

Yes, please. Also if like to take issue with everyone who prefers email
clients for the following reason: it's easier to allow people who want to
keep using email to do so while enabling a richer and more aggressive
experience for those who want it than it is the other way around
On Jun 19, 2015 5:21 PM, "// ravi"  wrote:

> On Jun 19, 2015, at 5:12 PM, C. Scott Ananian 
> wrote:
> >
> > No, thank you.​
> > Email clients are the ultimate forum aggregators.
>
>
> +1 on “No, thank you". Email works, email has are full-featured clients,
> do not force browser use, etc, etc.
>
> —ravi
>
>
> >  --scott
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[// ravi]

On Jun 19, 2015, at 5:12 PM, C. Scott Ananian  wrote:
> 
> No, thank you.​
> Email clients are the ultimate forum aggregators.


+1 on “No, thank you". Email works, email has are full-featured clients, do not 
force browser use, etc, etc.

—ravi


>  --scott

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[Edwin Reynoso]

The only thing I don't like is the fact it's mixed with what's on
discourse.specifiction.org. I post more on discourse.specifiction.org than
on ES-Discuss, meaning I'm more comfortable bothering the people with my
ideas there than on ES-Discuss.

Plainly because it's not always ES related. ES-Discuss sticks to Ecmascript
related things. While on discourse.specifiction.org we can talk about a
whole bunch of other things. Unless you guys plan on adding another
category. But even then I don't think most will like that.

On Fri, Jun 19, 2015 at 5:12 PM, C. Scott Ananian 
wrote:

> No, thank you.​
>
> Email clients are the ultimate forum aggregators.
>  --scott
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[C. Scott Ananian]

No, thank you.​

Email clients are the ultimate forum aggregators.
 --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[Edwin Reynoso]

OMG Yes please!!!

On Fri, Jun 19, 2015 at 5:04 PM, Axel Rauschmayer  wrote:

> http://discourse.specifiction.org/t/upcoming-migration/805
>
> Would it make sense to move es-discuss to that upcoming site? I’m not
> particularly fond of mailing lists and much prefer forums, especially
> discourse-based ones.
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Move es-discuss to discuss.webplatform.org?

[Axel Rauschmayer]

http://discourse.specifiction.org/t/upcoming-migration/805 


Would it make sense to move es-discuss to that upcoming site? I’m not 
particularly fond of mailing lists and much prefer forums, especially 
discourse-based ones.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Kevin 
Smith

> I think the yearly release plan encourages too much "feature racing".

I would state it somewhat differently. I think it encourages too much "feature 
marketing". That is, there are a number of complicated proposals which are 
often presented at conferences as "ES7" (or named as such by Babel). In 
reality, very few proposals are likely to make it to stage 4 ( = two 
tests-passing shipping implementations) in the relatively few months we have 
left. People are marketing their feature as something that is racing toward the 
finish line, even though in reality it is far from it.

My expectation is that this will self-correct. I don't expect TC39 to be any 
less deliberate than usual; moderately complex features will take a couple 
years or more to bake. So, as the champions of those features get quickly 
embarrassed by watching the ES2016 spec (and probably the ES2017 spec) get 
published without their feature, they'll modulate their marketing to something 
more reasonable. Then it will feel less like a race and more like the 
deliberate process it always has been.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[// ravi]

On Jun 19, 2015, at 2:53 PM, Allen Wirfs-Brock  wrote:
> On Jun 19, 2015, at 11:24 AM, Kevin Smith wrote:
> 
>> ES needs to evolve more rapidly than once every 5-15 years.  The yearly 
>> update plan is good, but that doesn't mean we should be rushing proposals 
>> (particularly complex ones) through the process in order to catch the next 
>> yearly release. Bake time is good.  There are numerous ES6 features that are 
>> much better because their design had a chance to evolve over a a two or 
>> three year period.
>> 
>> I think the yearly release plan encourages too much "feature racing".
> 
> It can and we are probably already seeing some signs of that.  But it doesn't 
> have too, if we are disciplined  within TC39 collectively develop the 
> understanding that yearly release is more about opening doors and closing 
> them.
> 

This could make a big difference, out here in user land, to alleviate the pain 
of waiting for simpler language features like Template Strings.

—ravi



> Regardless, I think that long term thinking is really important for TC39 
> participants. A language standards body is usually not the place to get 
> immediate solutions to immediate problems.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Allen Wirfs-Brock]

On Jun 19, 2015, at 11:24 AM, Kevin Smith wrote:

> ES needs to evolve more rapidly than once every 5-15 years.  The yearly 
> update plan is good, but that doesn't mean we should be rushing proposals 
> (particularly complex ones) through the process in order to catch the next 
> yearly release. Bake time is good.  There are numerous ES6 features that are 
> much better because their design had a chance to evolve over a a two or three 
> year period.
> 
> I think the yearly release plan encourages too much "feature racing".

It can and we are probably already seeing some signs of that.  But it doesn't 
have too, if we are disciplined  within TC39 collectively develop the 
understanding that yearly release is more about opening doors and closing them.

Regardless, I think that long term thinking is really important for TC39 
participants. A language standards body is usually not the place to get 
immediate solutions to immediate problems.

Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[William Edney]

Indeed Mark.

It took some of us longer to unwind those features out of our codebase than
others.

One of my biggest concerns in switching to the "yearly" numbering system is
the same as Allen & Kevin: there will be pressure to ship new features
every year (as if we're a software company that wants to get our users on
the upgrade treadmill).

Insofar as breaking changes, "use strict" in E5 was basically hitting the
low-hanging fruit. Now things get much more tricky. As has been endlessly
stated, you can't break the web. Therefore, I would anticipate future
versions of this spec to continue to be what they have been in the past:
mostly additive, except where clarifications are required. Anything else is
incredibly disruptive - much more so than the switch from IPv4 to IPv6 and
we see how long that has taken - and only under the threat of running out
of addresses. JS faces no such threat.

Cheers,

- Bill

On Fri, Jun 19, 2015 at 1:32 PM, Mark S. Miller  wrote:

> "use strict" was only a breaking change regarding ES3 code that
> coincidentally happened to use exactly this literal string as a do-nothing
> expression statement in exactly this position. In all of the web, we have
> not run across a single incident of this happening accidentally.
>
>
> For the record, not only have we successfully deprecated one feature, we
> have even wounded it sufficiently that I expect most of us will outlive it:
>
> function.caller, function.arguments, arguments.caller,
> arguments.callee.
>
> But note the effort it took to wound it and the time it is taking to die.
>
>
>
>
> On Fri, Jun 19, 2015 at 11:23 AM, Alexander Jones  wrote:
>
>> In all of the examples I mentioned there are other, more predictable
>> alternatives already in the language. Do we really expect JavaScript
>> programmers in 2025 to remember to use Number.isNaN instead of isNaN? I
>> really don't understand why people think "use strict" was OK to pull off,
>> but further breaking-change evolutions of the language are not.
>>
>>
>> On Friday, June 19, 2015, Andreas Rossberg  wrote:
>>
>>> On 19 June 2015 at 10:06, Alexander Jones  wrote:
>>>
 If people are unable to internalize the whole language, then surely we
 need a way to remove cruft and idiosyncracies in it, lest the language
 stagnate beyond repair.

 Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
 enumerable properties, are just a few examples of things we should not be
 frightened to talk about.

 While I don't personally see a need for the proposed let syntax, I
 think that concerns about the language growing uncontrollably should be
 directed at its apparent lack of deprecation strategy, rather than shutting
 down discussion of new ideas that might help us write better programs.

>>>
>>> While I agree that the impossibility of deprecating features is a
>>> problem (without a solution in JS), it's also fair to say that deprecation
>>> doesn't really work or help. Take C++ as the obvious example. They do
>>> deprecate occasionally, with difficulties. Yet the language had already
>>> blown complexity out of any sane proportion 25 years ago. Let alone today.
>>> Not a chance that there is a single person who _even remotely_ understands
>>> the full language, and there probably hasn't been one for 3 decades at
>>> least.
>>>
>>> Deprecation doesn't solve the problem because new cruft typically gets
>>> added orders of magnitude faster than old cruft can ever be removed. That
>>> is true for almost all production languages. Because it's so much easier to
>>> add stuff.
>>>
>>> Thus, the only way to keep a language small (if at all) is being extra
>>> careful about adding features. Just about any terrible feature can be
>>> justified by "use cases", but that's insufficient reason to add it.
>>> Especially "convenience" features are a slippery slope. (I could make a
>>> list of ES6 additions that already violate this principle.)
>>>
>>> The art in language design isn't what to add, but what to leave out.
>>>
>>> /Andreas
>>>
>>>
>>>
>>>
 On Thursday, June 18, 2015, Allen Wirfs-Brock 
 wrote:

>
> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
>
> On 18 June 2015 at 19:26, Benjamin Gruenbaum 
> wrote:
>
>> This is a mailing list comprised of people who typically have a much
>> better understanding of the language and its corners than most (even
>> professional) developers have (and dare I say, are interested in or care
>> about having). With ES6 the language already got a *lot* bigger and I'd
>> argue that it's now harder to learn the whole. The tradeoffs were
>> worthwhile but it's definitely an issue.
>>
>
> I dare say that at this point Allen probably is the only person in the
> world who actually fully knows and understands the complete language. I
> won't hesitate to admit that I don't. ;)
>
>
> And I occasionally have to

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Mark S. Miller]

"use strict" was only a breaking change regarding ES3 code that
coincidentally happened to use exactly this literal string as a do-nothing
expression statement in exactly this position. In all of the web, we have
not run across a single incident of this happening accidentally.


For the record, not only have we successfully deprecated one feature, we
have even wounded it sufficiently that I expect most of us will outlive it:

function.caller, function.arguments, arguments.caller,
arguments.callee.

But note the effort it took to wound it and the time it is taking to die.




On Fri, Jun 19, 2015 at 11:23 AM, Alexander Jones  wrote:

> In all of the examples I mentioned there are other, more predictable
> alternatives already in the language. Do we really expect JavaScript
> programmers in 2025 to remember to use Number.isNaN instead of isNaN? I
> really don't understand why people think "use strict" was OK to pull off,
> but further breaking-change evolutions of the language are not.
>
>
> On Friday, June 19, 2015, Andreas Rossberg  wrote:
>
>> On 19 June 2015 at 10:06, Alexander Jones  wrote:
>>
>>> If people are unable to internalize the whole language, then surely we
>>> need a way to remove cruft and idiosyncracies in it, lest the language
>>> stagnate beyond repair.
>>>
>>> Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
>>> enumerable properties, are just a few examples of things we should not be
>>> frightened to talk about.
>>>
>>> While I don't personally see a need for the proposed let syntax, I think
>>> that concerns about the language growing uncontrollably should be directed
>>> at its apparent lack of deprecation strategy, rather than shutting down
>>> discussion of new ideas that might help us write better programs.
>>>
>>
>> While I agree that the impossibility of deprecating features is a problem
>> (without a solution in JS), it's also fair to say that deprecation doesn't
>> really work or help. Take C++ as the obvious example. They do deprecate
>> occasionally, with difficulties. Yet the language had already blown
>> complexity out of any sane proportion 25 years ago. Let alone today. Not a
>> chance that there is a single person who _even remotely_ understands the
>> full language, and there probably hasn't been one for 3 decades at least.
>>
>> Deprecation doesn't solve the problem because new cruft typically gets
>> added orders of magnitude faster than old cruft can ever be removed. That
>> is true for almost all production languages. Because it's so much easier to
>> add stuff.
>>
>> Thus, the only way to keep a language small (if at all) is being extra
>> careful about adding features. Just about any terrible feature can be
>> justified by "use cases", but that's insufficient reason to add it.
>> Especially "convenience" features are a slippery slope. (I could make a
>> list of ES6 additions that already violate this principle.)
>>
>> The art in language design isn't what to add, but what to leave out.
>>
>> /Andreas
>>
>>
>>
>>
>>> On Thursday, June 18, 2015, Allen Wirfs-Brock 
>>> wrote:
>>>

 On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:

 On 18 June 2015 at 19:26, Benjamin Gruenbaum 
 wrote:

> This is a mailing list comprised of people who typically have a much
> better understanding of the language and its corners than most (even
> professional) developers have (and dare I say, are interested in or care
> about having). With ES6 the language already got a *lot* bigger and I'd
> argue that it's now harder to learn the whole. The tradeoffs were
> worthwhile but it's definitely an issue.
>

 I dare say that at this point Allen probably is the only person in the
 world who actually fully knows and understands the complete language. I
 won't hesitate to admit that I don't. ;)


 And I occasionally have to go and look up details.

 Allen


> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Kevin Smith]

>
> ES needs to evolve more rapidly than once every 5-15 years.  The yearly
> update plan is good, but that doesn't mean we should be rushing proposals
> (particularly complex ones) through the process in order to catch the next
> yearly release. Bake time is good.  There are numerous ES6 features that
> are much better because their design had a chance to evolve over a a two or
> three year period.
>

I think the yearly release plan encourages too much "feature racing".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Alexander Jones]

In all of the examples I mentioned there are other, more predictable
alternatives already in the language. Do we really expect JavaScript
programmers in 2025 to remember to use Number.isNaN instead of isNaN? I
really don't understand why people think "use strict" was OK to pull off,
but further breaking-change evolutions of the language are not.

On Friday, June 19, 2015, Andreas Rossberg  wrote:

> On 19 June 2015 at 10:06, Alexander Jones  > wrote:
>
>> If people are unable to internalize the whole language, then surely we
>> need a way to remove cruft and idiosyncracies in it, lest the language
>> stagnate beyond repair.
>>
>> Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
>> enumerable properties, are just a few examples of things we should not be
>> frightened to talk about.
>>
>> While I don't personally see a need for the proposed let syntax, I think
>> that concerns about the language growing uncontrollably should be directed
>> at its apparent lack of deprecation strategy, rather than shutting down
>> discussion of new ideas that might help us write better programs.
>>
>
> While I agree that the impossibility of deprecating features is a problem
> (without a solution in JS), it's also fair to say that deprecation doesn't
> really work or help. Take C++ as the obvious example. They do deprecate
> occasionally, with difficulties. Yet the language had already blown
> complexity out of any sane proportion 25 years ago. Let alone today. Not a
> chance that there is a single person who _even remotely_ understands the
> full language, and there probably hasn't been one for 3 decades at least.
>
> Deprecation doesn't solve the problem because new cruft typically gets
> added orders of magnitude faster than old cruft can ever be removed. That
> is true for almost all production languages. Because it's so much easier to
> add stuff.
>
> Thus, the only way to keep a language small (if at all) is being extra
> careful about adding features. Just about any terrible feature can be
> justified by "use cases", but that's insufficient reason to add it.
> Especially "convenience" features are a slippery slope. (I could make a
> list of ES6 additions that already violate this principle.)
>
> The art in language design isn't what to add, but what to leave out.
>
> /Andreas
>
>
>
>
>> On Thursday, June 18, 2015, Allen Wirfs-Brock > > wrote:
>>
>>>
>>> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
>>>
>>> On 18 June 2015 at 19:26, Benjamin Gruenbaum 
>>> wrote:
>>>
 This is a mailing list comprised of people who typically have a much
 better understanding of the language and its corners than most (even
 professional) developers have (and dare I say, are interested in or care
 about having). With ES6 the language already got a *lot* bigger and I'd
 argue that it's now harder to learn the whole. The tradeoffs were
 worthwhile but it's definitely an issue.

>>>
>>> I dare say that at this point Allen probably is the only person in the
>>> world who actually fully knows and understands the complete language. I
>>> won't hesitate to admit that I don't. ;)
>>>
>>>
>>> And I occasionally have to go and look up details.
>>>
>>> Allen
>>>
>>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Allen Wirfs-Brock]

On Jun 19, 2015, at 10:29 AM, Alex Russell wrote:

> I do not share Mark's view. Contra his sentiment, I was using the "small" 
> version of JS for many years and noted that most non-trivial uses required 
> finding or building a library. That choice of library (which exist to fill in 
> platform and language deficiencies) leads to a a split in common use that's 
> just as pernicious as "choosing a subset". 
> 
> Writing JS in the large continues to need more help.

I agree with parts of both Mark's and Alex's positions.

It isn't clear that any "small" language has ever seen the sort of industry 
dominance that languages like C/C++ achieved.   I'd even argue that the an 
unwilling (or inability) to grow  was one of the reasons that (Pascal and 
Smalltalk) both sputtered out after some initial success. Pragmatic growth is 
probably essential for achieving and maintaining broad adoption.

On the other hand, curation of language growth is really important.  Not every 
good idea can be fit into a language and not evert seemingly valuable features 
has long term utility or durability.

ES needs to evolve more rapidly than once every 5-15 years.  The yearly update 
plan is good, but that doesn't mean we should be rushing proposals 
(particularly complex ones) through the process in order to catch the next 
yearly release. Bake time is good.  There are numerous ES6 features that are 
much better because their design had a chance to evolve over a a two or three 
year period.

This isn't a contest to see who can or can't get their favorite feature into 
the language. Nobody should take it personally if their good idea doesn't make 
it. I've probably had dozens of of really good ;-) ideas for making ES better 
that haven't made it into the language. 

Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Mark S. Miller]

On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell 
 wrote:

> I do not share Mark's view. Contra his sentiment, I was using the "small"
> version of JS for many years and noted that most non-trivial uses required
> finding or building a library. That choice of library (which exist to fill
> in platform and language deficiencies) leads to a a split in common use
> that's just as pernicious as "choosing a subset".
>
> Writing JS in the large continues to need more help.
>
>
On Fri, Jun 19, 2015 at 10:42 AM, Mark Volkmann 
wrote:

> It sounds like you are advocating for a larger standard library in JS. I
> think many on this thread are focusing on whether more syntax features
> should be added.
>


First, from many arguments with Alex, I am indeed confident that Alex and I
have different views about these matters.

In my post, I definitely meant more than syntax, but I also agree that the
force of my point gets weaker as we move from core language to
standardizing libraries. The overall standard language can be seen as
consisting of these major parts:


  * fundamental syntax -- the special forms that cannot faithfully be
explained by local expansion to other syntax
  * semantic state -- the state than computation manipulates
  * kernel builtins -- built in library providing functionality that, if it
were absent, could not be provided instead by user code.
  * intrinsics -- libraries that semantic state or kernel builtins depend
on. For example, with Proxies, one might be able to do Array in user code.
But other kernel builtins already have a dependency on Array specifically,
giving it a privileged position over any replacement.
  * syntactic sugar -- the syntax that can be explained by local expansion
to fundamental syntax.
  * global convenience libraries -- could be implemented by unprivileged
user code, but given standard global naming paths in the primordial global
namespace.
  * standard convenient library modules


I have listed these in order, according to my sense of the costs of growth
and the urgency for minimalism. For all of these we still need to exercise
discipline. But it is only for the last one that we should consider growth
of absolute size to be unbounded; restricting ourselves only to the rate of
growth as we wait for candidates to prove themselves first by the de facto
process. Ideally, TC39 should stop being the bottleneck on the last bullet
anyway, as external de facto and de jure processes should be perfectly
capable of independently arguing about and evolving standard convenience
modules.


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Mark Volkmann]

It sounds like you are advocating for a larger standard library in JS. I
think many on this thread are focusing on whether more syntax features
should be added.

On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell 
wrote:

> I do not share Mark's view. Contra his sentiment, I was using the "small"
> version of JS for many years and noted that most non-trivial uses required
> finding or building a library. That choice of library (which exist to fill
> in platform and language deficiencies) leads to a a split in common use
> that's just as pernicious as "choosing a subset".
>
> Writing JS in the large continues to need more help.
>
>
> On Thu, Jun 18, 2015 at 11:27 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I like Mark's post too, and if I might ...
>>
>> > Features like classes and `let` are very often criticised and often
>> languages that did not add these features and are considered 'well
>> designed' are given in comparison (Python's lack of block scoping for
>> instance).
>>
>> thing is, ES6 brought in many things that took years to explain in the
>> "JS way" and when finally developers started knowing and appreciating
>> `prototypal` inheritance and started understanding the `var` behavior, to
>> name just few, "we" started promoting ES6 as the universal problem solver
>> for every dev so that `let` is the new `var` (most developers still don't
>> even know what does it mean) and `const` is the better `let` and `class`
>> finally is in the language, something that desugar anyway to prototypal
>> inheritance, something developers still need to understand.
>>
>> So I agree we should really stop going fancy with syntax, probably think
>> about sweet.js like approches, and fix all the things that will need to be
>> fixed in ES6, improving and finalizing classes bringing in composition like
>> it has always been possible before through prototypal inheritance. I really
>> do hope traits will be highly prioritized and binary/typed data/shapes too
>> 'cause I don't think JS needs many more changes as it is today.
>>
>> Just my lil'rant and keep up the good work.
>>
>> Best Regards
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 18, 2015 at 6:26 PM, Benjamin Gruenbaum > > wrote:
>>
>>> First of all, brilliant post Mark.
>>>
>>> > As a community, we need more of a shared sense of panic about the size
>>> that ES6 has already grown to. Ideally, that panic should increase, not
>>> decrease, with further growth from here as our size approaches the point of
>>> no return.
>>>
>>> As a community, we do - if you look at HackerNews or Reddit or
>>> StackOverflow people are constantly hating on JS getting larger. Features
>>> like classes and `let` are very often criticised and often languages that
>>> did not add these features and are considered 'well designed' are given in
>>> comparison (Python's lack of block scoping for instance).
>>>
>>> This is a mailing list comprised of people who typically have a much
>>> better understanding of the language and its corners than most (even
>>> professional) developers have (and dare I say, are interested in or care
>>> about having). With ES6 the language already got a *lot* bigger and I'd
>>> argue that it's now harder to learn the whole. The tradeoffs were
>>> worthwhile but it's definitely an issue.
>>>
>>> It's easy to forget here what traps the average user might fall into,
>>> and it's easy to forget what they care about and what confuses them.
>>>
>>> Fwiw, there are examples of big languages that are well liked, the
>>> "canonical" example of a big but very well liked (and well designed imho)
>>> language is C#. It has a lot of cruft now (delegates and events, array
>>> covariance etc) but it is still a very well liked language in general.
>>>
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Alex Russell]

I do not share Mark's view. Contra his sentiment, I was using the "small"
version of JS for many years and noted that most non-trivial uses required
finding or building a library. That choice of library (which exist to fill
in platform and language deficiencies) leads to a a split in common use
that's just as pernicious as "choosing a subset".

Writing JS in the large continues to need more help.


On Thu, Jun 18, 2015 at 11:27 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I like Mark's post too, and if I might ...
>
> > Features like classes and `let` are very often criticised and often
> languages that did not add these features and are considered 'well
> designed' are given in comparison (Python's lack of block scoping for
> instance).
>
> thing is, ES6 brought in many things that took years to explain in the "JS
> way" and when finally developers started knowing and appreciating
> `prototypal` inheritance and started understanding the `var` behavior, to
> name just few, "we" started promoting ES6 as the universal problem solver
> for every dev so that `let` is the new `var` (most developers still don't
> even know what does it mean) and `const` is the better `let` and `class`
> finally is in the language, something that desugar anyway to prototypal
> inheritance, something developers still need to understand.
>
> So I agree we should really stop going fancy with syntax, probably think
> about sweet.js like approches, and fix all the things that will need to be
> fixed in ES6, improving and finalizing classes bringing in composition like
> it has always been possible before through prototypal inheritance. I really
> do hope traits will be highly prioritized and binary/typed data/shapes too
> 'cause I don't think JS needs many more changes as it is today.
>
> Just my lil'rant and keep up the good work.
>
> Best Regards
>
>
>
>
>
>
>
>
>
>
> On Thu, Jun 18, 2015 at 6:26 PM, Benjamin Gruenbaum 
> wrote:
>
>> First of all, brilliant post Mark.
>>
>> > As a community, we need more of a shared sense of panic about the size
>> that ES6 has already grown to. Ideally, that panic should increase, not
>> decrease, with further growth from here as our size approaches the point of
>> no return.
>>
>> As a community, we do - if you look at HackerNews or Reddit or
>> StackOverflow people are constantly hating on JS getting larger. Features
>> like classes and `let` are very often criticised and often languages that
>> did not add these features and are considered 'well designed' are given in
>> comparison (Python's lack of block scoping for instance).
>>
>> This is a mailing list comprised of people who typically have a much
>> better understanding of the language and its corners than most (even
>> professional) developers have (and dare I say, are interested in or care
>> about having). With ES6 the language already got a *lot* bigger and I'd
>> argue that it's now harder to learn the whole. The tradeoffs were
>> worthwhile but it's definitely an issue.
>>
>> It's easy to forget here what traps the average user might fall into, and
>> it's easy to forget what they care about and what confuses them.
>>
>> Fwiw, there are examples of big languages that are well liked, the
>> "canonical" example of a big but very well liked (and well designed imho)
>> language is C#. It has a lot of cruft now (delegates and events, array
>> covariance etc) but it is still a very well liked language in general.
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[C. Scott Ananian]

An interesting wrinkle in language design has been the rise of
sophisticated linting and style tools like `jscs`.  If you wish to
deprecate `var` for instance, it is straightforward to write a jscs module
to enforce that.  Further, several large communities (node, wikipedia, etc)
have published jscs "presets" that effectively define the subset of the
language they use.

So in a meaningful way we are getting the tools to voluntarily deprecate
features in a community-driven way.  Certain quirks may always exist in the
spec (although perhaps more and more they will migrate to compatibility
appendixes), but can be effectively ignored for communities opting in to
jscs presets.

I note that certain ES6 features have also been written specifically to
allow opt-in to sane behavior.  For example, a `SaneArray` subclass of
Array is often discussed here.  Use of SaneArray instead of stock Array
could also be enforced by jscs-like tools.  (Although this means giving up
Array literal syntax?  So there's still a bit of awkwardness.  And API
boundaries are tricky.  Future work!)

Anyway, I look forward to a continued process of community-driven feature
deprecation, and hope that we will continue to look for ways in ES7 to
allow further opt-in fixes to our warts. (I also look forward to continued
development of interesting rule sets and analyses in jscs and similar tools
to shave off warts.)
  --scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Andreas Rossberg]

On 19 June 2015 at 10:06, Alexander Jones  wrote:

> If people are unable to internalize the whole language, then surely we
> need a way to remove cruft and idiosyncracies in it, lest the language
> stagnate beyond repair.
>
> Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
> enumerable properties, are just a few examples of things we should not be
> frightened to talk about.
>
> While I don't personally see a need for the proposed let syntax, I think
> that concerns about the language growing uncontrollably should be directed
> at its apparent lack of deprecation strategy, rather than shutting down
> discussion of new ideas that might help us write better programs.
>

While I agree that the impossibility of deprecating features is a problem
(without a solution in JS), it's also fair to say that deprecation doesn't
really work or help. Take C++ as the obvious example. They do deprecate
occasionally, with difficulties. Yet the language had already blown
complexity out of any sane proportion 25 years ago. Let alone today. Not a
chance that there is a single person who _even remotely_ understands the
full language, and there probably hasn't been one for 3 decades at least.

Deprecation doesn't solve the problem because new cruft typically gets
added orders of magnitude faster than old cruft can ever be removed. That
is true for almost all production languages. Because it's so much easier to
add stuff.

Thus, the only way to keep a language small (if at all) is being extra
careful about adding features. Just about any terrible feature can be
justified by "use cases", but that's insufficient reason to add it.
Especially "convenience" features are a slippery slope. (I could make a
list of ES6 additions that already violate this principle.)

The art in language design isn't what to add, but what to leave out.

/Andreas




> On Thursday, June 18, 2015, Allen Wirfs-Brock 
> wrote:
>
>>
>> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
>>
>> On 18 June 2015 at 19:26, Benjamin Gruenbaum 
>> wrote:
>>
>>> This is a mailing list comprised of people who typically have a much
>>> better understanding of the language and its corners than most (even
>>> professional) developers have (and dare I say, are interested in or care
>>> about having). With ES6 the language already got a *lot* bigger and I'd
>>> argue that it's now harder to learn the whole. The tradeoffs were
>>> worthwhile but it's definitely an issue.
>>>
>>
>> I dare say that at this point Allen probably is the only person in the
>> world who actually fully knows and understands the complete language. I
>> won't hesitate to admit that I don't. ;)
>>
>>
>> And I occasionally have to go and look up details.
>>
>> Allen
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Scott Sauyet]

Greg McLeod  wrote:

> I really really love JS (it's so fun!), and while there are many features
in ES6 that I think are great (such as classes, modules, and import syntax)
there are things that quite frankly scare me quite a bit. Such examples
include destructuring and arrow functions, which make sense when used in
simple use cases but I find confusing to interpret when reading someone
else's code due to their terseness.

I think the difference between your list and mine exemplifies the tragedy
of the commons as so well described by Mark.  Although we both share a
liking for modules and imports, my favorite ES6 feature is the arrow
functions, with destructuring near the top.   The very bottom of my list,
the only one I really, really wish n not been included is `class`.

Covering the desires of both users like you and users like me is what can
so easily leaf to bloat.

  -- Scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Benjamin Gruenbaum]

I don't think anyone is "frightened" about removing these things. The TC
has a commitment not to "break the internet", by removing something like
`var` or `typeof` you're disabling *billions* of people who are using the
internet - it would very much literally "break the internet". Even if the
TC unanimously votes on removing 'var' - this is not something browser
vendors would do anyway.

This issue has been discussed on the list several times before and even the
modest attempt to fix `typeof null` failed when it was attempted. Here is
some discussion about it https://esdiscuss.org/topic/typeof-null

The way forward is pretty much to avoid features like `with` for the most
part, understand older code but gradually write newer code. Any breaking
changes to the language require extensive research which will likely
conclude in not making the change (like `var`) anyway.

Note that strict mode already fixes a lot of things (quirkiness of
arguments, with, non-lexical scope, globals, etc). Classes have safe
defaults (non enumerability of properties), for... of loops typically do
the correct thing based on the new iteration protocol and so on.


On Fri, Jun 19, 2015 at 11:06 AM, Alexander Jones  wrote:

> If people are unable to internalize the whole language, then surely we
> need a way to remove cruft and idiosyncracies in it, lest the language
> stagnate beyond repair.
>
> Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
> enumerable properties, are just a few examples of things we should not be
> frightened to talk about.
>
> While I don't personally see a need for the proposed let syntax, I think
> that concerns about the language growing uncontrollably should be directed
> at its apparent lack of deprecation strategy, rather than shutting down
> discussion of new ideas that might help us write better programs.
>
> Just my 2p.
>
>
>
>
> On Thursday, June 18, 2015, Allen Wirfs-Brock 
> wrote:
>
>>
>> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
>>
>> On 18 June 2015 at 19:26, Benjamin Gruenbaum 
>> wrote:
>>
>>> This is a mailing list comprised of people who typically have a much
>>> better understanding of the language and its corners than most (even
>>> professional) developers have (and dare I say, are interested in or care
>>> about having). With ES6 the language already got a *lot* bigger and I'd
>>> argue that it's now harder to learn the whole. The tradeoffs were
>>> worthwhile but it's definitely an issue.
>>>
>>
>> I dare say that at this point Allen probably is the only person in the
>> world who actually fully knows and understands the complete language. I
>> won't hesitate to admit that I don't. ;)
>>
>>
>> And I occasionally have to go and look up details.
>>
>> Allen
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Alexander Jones]

If people are unable to internalize the whole language, then surely we need
a way to remove cruft and idiosyncracies in it, lest the language stagnate
beyond repair.

Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
enumerable properties, are just a few examples of things we should not be
frightened to talk about.

While I don't personally see a need for the proposed let syntax, I think
that concerns about the language growing uncontrollably should be directed
at its apparent lack of deprecation strategy, rather than shutting down
discussion of new ideas that might help us write better programs.

Just my 2p.



On Thursday, June 18, 2015, Allen Wirfs-Brock  wrote:

>
> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
>
> On 18 June 2015 at 19:26, Benjamin Gruenbaum  > wrote:
>
>> This is a mailing list comprised of people who typically have a much
>> better understanding of the language and its corners than most (even
>> professional) developers have (and dare I say, are interested in or care
>> about having). With ES6 the language already got a *lot* bigger and I'd
>> argue that it's now harder to learn the whole. The tradeoffs were
>> worthwhile but it's definitely an issue.
>>
>
> I dare say that at this point Allen probably is the only person in the
> world who actually fully knows and understands the complete language. I
> won't hesitate to admit that I don't. ;)
>
>
> And I occasionally have to go and look up details.
>
> Allen
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Benjamin Gruenbaum]

This is just a heads up for context that someone published a link to Mark's
post in HN here: https://news.ycombinator.com/item?id=9738866 in case we
get any more new people posting in the thread.

-

> > Features like classes and `let` are very often criticised and often
languages that did not add these features and are considered 'well
designed' are given in comparison (Python's lack of block scoping for
instance).

> thing is, ES6 brought in many things that took years to explain in the
"JS way" and when finally developers started knowing and appreciating
`prototypal` inheritance and started understanding the `var` behavior, to
name just few, "we" started promoting ES6 as the universal problem solver
for every dev so that `let` is the new `var` (most developers still don't
even know what does it mean) and `const` is the better `let` and `class`
finally is in the language, something that desugar anyway to prototypal
inheritance, something developers still need to understand.

I completely agree - I think that classes and let as ways to standardise
the best practice way of something most people are already doing. This is a
noble and very important thing that really helps. By letting wisdom of the
masses show us what people need and letting user-land solutions spearhead
progress and then specifying the parts that work is an excellent approach -
having a TC in charge is really nice and ensures vision and order. The
reason I'm trying to get more involved in the process is because I like the
way things are heading and the discussions held (and I'm learning a lot).

I don't know about additional syntax - but the fact the bar is raised is
very important.

On Fri, Jun 19, 2015 at 3:03 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> > And I occasionally have to go and look up details.
>
> You know nothing Allen Wirfs-Brock (cit)
>
> On Thu, Jun 18, 2015 at 8:55 PM, Allen Wirfs-Brock 
> wrote:
>
>>
>> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
>>
>> On 18 June 2015 at 19:26, Benjamin Gruenbaum 
>> wrote:
>>
>>> This is a mailing list comprised of people who typically have a much
>>> better understanding of the language and its corners than most (even
>>> professional) developers have (and dare I say, are interested in or care
>>> about having). With ES6 the language already got a *lot* bigger and I'd
>>> argue that it's now harder to learn the whole. The tradeoffs were
>>> worthwhile but it's definitely an issue.
>>>
>>
>> I dare say that at this point Allen probably is the only person in the
>> world who actually fully knows and understands the complete language. I
>> won't hesitate to admit that I don't. ;)
>>
>>
>> And I occasionally have to go and look up details.
>>
>> Allen
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss