Re: Pick operator

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

Pick operator

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.

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

> > 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 des

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

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.

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

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

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

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 p

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

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:

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

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 ___

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

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-Discu

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

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?

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-ba

Move es-discuss to discuss.webplatform.org?

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

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

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 proposa

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

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) throu

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

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.

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

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

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

"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

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

> > 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

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

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 bre

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

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

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

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 platfor

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

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" > ver

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

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 tha

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

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 jsc

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

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, ==,

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

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

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

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 un

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

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

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

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