prototype for operator proposal for review

Dean Landolt dean at
Wed May 18 09:25:18 PDT 2011

On Wed, May 18, 2011 at 11:53 AM, Allen Wirfs-Brock
<allen at>wrote:

> On May 17, 2011, at 11:59 PM, Luke Hoban wrote:
> >>>
> >>> And of course this would also make it harder for IDEs and such to give
> good first-class syntax highlighting here, because the syntax for this would
> be ambiguous with user-created stuff.
> >
> > What kind of syntax highlighting would you want to offer?  Distinguishing
> normal arrays from arrays with non-standard prototypes would be more
> difficult, but this doesn't seem like a common syntax highlighting need.
> >
> In general declarative constructs are easier for tools to analyze than
> imperative processes built out of function calls.  All the complications
> that were brought up for optimizing the imperative forms also apply to tools
> and tools don't have any dynamic context available to verify any inferences
> they may make.  This applies to more than just syntax highlighters.
>  Refactoring tools, reference engineering tools, and anything else that
> wants to statically source code generally will have an easer time with
> declarative constructs.

I think the argument for ease of static analysis applies just as well to
human analysis (after all, our wetware makes for a poor interpreter). But I
think the counter-argument is more compelling -- this is yet another
construct our *tooling* would have to understand, and every new construct
*substantially* ups the ante for fluency (ISTM the tax for each new syntax
is approximately combinatorial for inexperienced developers).

The imperative alternative, on the other hand, only requires learning the
semantics of a new API, not whole new constructs and how they compose
(regardless of how nicely they compose). I personally believe this matters a
great deal, and not just for newcomers. As I've heard /be suggest, some of
javascript's success can be owed to its lack of syntactical novelty. I'm not
saying all new syntax is bad syntax, but at the very least the committee
should be optimizing for humans first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list