On 22 April 2013 15:56, Brendan Eich <brendan at mozilla.com> wrote:
> Andreas Rossberg wrote:
>>
>> Just to be clear, what I suggested was having a single global
>> convention for the name of the 'anonymous' export in every module, say
>> ,"it". No need to know the "internals" of anything. Your Node example,
>
> You are imposing a tax on everyone using modules and anonymous export, today
> a large base of users (modules are predominately anonymous export by
> counting NPM modules).

Learning extra syntax is a tax, too. As far as Dave's proposal is
concerned, it seems higher to me, without any added value.

> You may be used to "it" conventions in ML, but we're talking about JS here.
> It's not ML and the communities using modules have already voted, and they
> will vote with their feet (run away from ES6) if it comes to it.

There are substantial differences between legacy modules and what will
be in ES6. People will have to adapt, whatever we do. Drawing the
"people running away screaming" card is unhelpful rhetoric as long as
no valid technical argument is involved. The logical conclusion of
your argument would be to just adopt the union of the existing
systems, so that nobody has to change their habits. There is good
reason why TC39 didn't choose that route.

The more convincing argument would be interop with those legacy
modules. But the magic for that will be in custom loaders, and AFAICS,
the problems (and solutions) will likely be the same in either
approach.

/Andreas

On 22 April 2013 15:56, Brendan Eich <brendan at mozilla.com> wrote:
> Andreas Rossberg wrote:
>
>> Just to be clear, what I suggested was having a single global
>> convention for the name of the 'anonymous' export in every module, say
>> ,"it". No need to know the "internals" of anything. Your Node example,
>
> You are imposing a tax on everyone using modules and anonymous export, today
> a large base of users (modules are predominately anonymous export by
> counting NPM modules).

Learning extra syntax is a tax, too. As far as Dave's proposal is
concerned, it seems higher to me, without any added value.

> You may be used to "it" conventions in ML, but we're talking about JS here.
> It's not ML and the communities using modules have already voted, and they
> will vote with their feet (run away from ES6) if it comes to it.

There are substantial differences between legacy modules and what will
be in ES6. People will have to adapt, whatever we do. Drawing the
"people running away screaming" card is unhelpful rhetoric as long as
no valid technical argument is involved. The logical conclusion of
your argument would be to just adopt the union of the existing
systems, so that nobody has to change their habits. There is good
reason why TC39 didn't choose that route.

The more convincing argument would be interop with those legacy
modules. But the magic for that will be in custom loaders, and AFAICS,
the problems (and solutions) will likely be the same in either
approach.