Es4-discuss Digest, Vol 8, Issue 44

[Neil Mix]

On Oct 30, 2007, at 6:45 PM, Ric Johnson wrote:

> Doug is correct: as a product manager, it is bad to add more  
> features: it
> increases our risks with reduced ROI

I sympathize with the concern behind this statement, but I would  
argue its analysis is incomplete on the following grounds:
1) Programming language design is very much different from consumer  
product design
2) The risks of adding feature always needs to be carefully balanced  
against the risk of *not* adding them

Programming language design is historical in focus; stick to what has  
worked in the past, avoid things that have not.  Innovation in  
language design is glacial compared to consumer product design.   
Languages that experiment in features without historical precedent do  
so at their own risk.  By comparison, consumer product design seeks  
to specifically do things that have not been done before, and to  
avoid that which is well-known and "mundane".

Brendan has mentioned this, but it's worth repeating: there is  
nothing "new" in the ES4 design.  All of the features mentioned have  
appeared previously in well-known languages.  The features have been  
fully researched, implemented and deployed in production systems, and  
withstood the test of time.

I'm a product guy, not a PLT guy, so when I first started reading the  
ES4 proposals, I was just as worried about scope and feature creep.   
Having now spent a year or so absorbing the content and learning  
about this || much about PLT, it's sunk in that the proposal is not  
as big as it looks.

(And this doesn't account for the fact that ES4 will be the most  
precise specification of ECMAScript yet, with a reference  
implementation no less!)

When concerned about "bloat", there are specific problems one worries  
about:

- backward compatibility: ES4 is backward compatible, choosing only  
to add to the language.  If one is still scared by this, then one  
must consider, what number of features would be "safe"?  If you have  
an API with 5 methods and you add 10 more, but you're worried about  
backward compatibility, what's the difference between 1 new method  
and 10 new methods?  Why is the greater number of methods inherently  
a bigger risk to backward compatibility?

- size of implementation: while I consider this a valid fear, I must  
also point out that several of the TG1 members are incredibly  
experienced in building JS interpreters for embedded systems.  And  
those members are in favor of ES4.  I, JS hacker, cannot claim  
knowledge enough to undermine their domain expertise.  If other  
experts in the field were concerned about this, that would be another  
story.  But thus far I have not seen any such objectors.

- time to completion: again, I must defer to the expert language  
implementors of TG1.

The only remaining claim to featuritis is that developers will find  
the new language unwieldy and hard to use.  Valid concern, but how  
can any developer claim this without actually having tried the  
language?  As I said above, you can find all these features in other  
well-known languages, and they've worked well.  Historical precedent  
is on the side of ES4 on this one.

On a more personal note: I've spent the past 3 years building a JS  
application from scratch; I've watched the application grow from  
programming-in-the-small to programming-in-the-large, growing along  
side a startup whose product has grown successful and accumulated  
users and features at a rapid pace.  I used to scoff at strong data- 
typing -- who needs it when you've got good tests?  These days I'm  
not laughing.  *Every* feature in ES4 would be a great help in  
scaling this application out.  If asked to name a "least useful  
feature," I wouldn't name any.  The feature set feels right.

So is the large feature set of ES4 risky?  I don't believe so, but  
even more importantly, so what?  We're drowning out here (though not  
all of us realize it).  Without these features, JS apps are doomed to  
scale (of codebase) limitations that will fundamentally inhibit the  
growth of web-based applications.  The "play it safe" strategy is  
penny-wise and pound-foolish.  When I hear concerns that ES4 will  
"break the web," I can't help but think of how many times I've heard  
that the web is already broken!  The risks of *not* adopting the ES4  
surely must factor into this calculus, too.

   -Neil