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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
