On Thu, Jan 30, 2014 at 9:40 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 1/30/14 8:25 AM, Domenic Denicola wrote:
>
>> since I find that style more precise and idiomatic
>>
>
> It's not clear to me that the former is true (and in fact, making sure
> that an ES-style spec is not fundamentally buggy in the "doesn't have the
> desired behavior" sense is _much_ harder than doing it for a WebIDL spec,
> in my experience).
>
> It's also _much_ harder to read and understand in my experience, and the
> experience of many other people I've talked to.
>

I am going through the process of implementing Domenic's spec in ES5 for
Node as a way of validating my understanding of the spec (in reality, the
only Nodeisms in my implementation is my use of CommonJS modules), so maybe
I can shed a little light on this.

So far, this has been a very straightforward spec to implement. The spec
language is imperative and concrete, so it is easy both to turn into
JavaScript and to point to the correspondences between the implementation
code and the relevant line items in the spec. So far, it has also been easy
to use the code to illuminate inconsistencies or identify problems with the
spec, and using the nomenclature of ES-262 makes very clear from context
how to distinguish between the public interface of the API and its internal
properties and methods.

I've been surprised (and pleased) by how easy it has been to implement the
spec thus far, and most of the issues I've raised with Domenic have been
down to either minor misunderstandings on my part or judgment calls without
objectively right or wrong answers. To me, this feels like the appropriate
sort of issues to be coming out of working with a draft specification. Much
of the credit for that goes to Domenic and his collaborators (and probably
also to my familiarity with other JavaScript streams implementations), but
I appreciate not having to spend a lot of time translating between WebIDL's
abstract hybrid of C++, Java and JavaScript type models and the code I'm
working on.

As an implementor, I find this all a refreshing contrast to trying to wrap
my head around WebIDL, which, in my blunt opinion, does a poor job of
capturing any real operational model used on the web. I have nothing
against formal specification methods per se, but, at least for things that
are implementable in pure JavaScript (as Domenic's proposal is), I think
ECMASpeak is preferable to WebIDL.

F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140130/55c8262a/attachment.html>

On Thu, Jan 30, 2014 at 9:40 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> It's not clear to me that the former is true (and in fact, making sure
> that an ES-style spec is not fundamentally buggy in the "doesn't have the
> desired behavior" sense is _much_ harder than doing it for a WebIDL spec,
> in my experience).
>
> It's also _much_ harder to read and understand in my experience, and the
> experience of many other people I've talked to.

I am going through the process of implementing Domenic's spec in ES5 for
Node as a way of validating my understanding of the spec (in reality, the
only Nodeisms in my implementation is my use of CommonJS modules), so maybe
I can shed a little light on this.

So far, this has been a very straightforward spec to implement. The spec
language is imperative and concrete, so it is easy both to turn into
JavaScript and to point to the correspondences between the implementation
code and the relevant line items in the spec. So far, it has also been easy
to use the code to illuminate inconsistencies or identify problems with the
spec, and using the nomenclature of ES-262 makes very clear from context
how to distinguish between the public interface of the API and its internal
properties and methods.

I've been surprised (and pleased) by how easy it has been to implement the
spec thus far, and most of the issues I've raised with Domenic have been
down to either minor misunderstandings on my part or judgment calls without
objectively right or wrong answers. To me, this feels like the appropriate
sort of issues to be coming out of working with a draft specification. Much
of the credit for that goes to Domenic and his collaborators (and probably
also to my familiarity with other JavaScript streams implementations), but
I appreciate not having to spend a lot of time translating between WebIDL's
abstract hybrid of C++, Java and JavaScript type models and the code I'm
working on.

As an implementor, I find this all a refreshing contrast to trying to wrap
my head around WebIDL, which, in my blunt opinion, does a poor job of
capturing any real operational model used on the web. I have nothing
against formal specification methods per se, but, at least for things that
are implementable in pure JavaScript (as Domenic's proposal is), I think
ECMASpeak is preferable to WebIDL.