Es4-discuss Digest, Vol 8, Issue 44
nmix at pandora.com
Tue Oct 30 21:04:28 PDT 2007
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
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
- 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.
More information about the Es4-discuss