Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

On Sep 27, 2009, at 4:15 PM, Maciej Stachowiak wrote:

> On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote:
>> But there's no point pretending the Web (ES, DOM, etc.) is an  
>> example of a well-designed toolkit for building user-facing  
>> distributed apps!
>
> But we're not really free to discard compatibility. So I'm not that  
> excited about the exciting opportunities we could have if we did.  
> The Web is a duct tape design but it works. Dropping compatibility  
> would kill one of its biggest advantages.

Sure. You didn't see me proposing dropping Web compatibility (suicide  
for browser vendors) -- rather, I'm talking about doing end-to-end  
design as we go, and meeting in the middle.

Too many short hops via a standard body incurs high costs in the spec  
process (some essential, some not) while tending to enshrine mistakes  
over time due to compatibility. Whereas taking big hops risks mission  
creep, or mission cliff-dive into second-system death-beach ;-), or  
even the old mistake of targeting a market foreseen five years out  
that never arrives (the real world zigged instead of zagging).

We've all seen these problems, I think, over our careers. And it's not  
as if the proprietary languages and stacks can break compatibility  
excessively (search for "Visual Fred"). But they can and do provide  
new and more coherent API-sets that help deprecate old ones.

To avoid proprietary stack examples, consider Python's from __future__  
import mechanism:

http://www.python.org/dev/peps/pep-0236/

This precedent is attractive if one can push out new versions of the  
language implementation, with carrots to induce people to upgrade, as  
well as the stick of unsupported ancient versions. It helps that C- 
Python is source-as-spec, but let's say that is a non-issue with good- 
enough ES specs.

The "carrots instead of sticks" idea is more critical from what I have  
seen, for Python and for JavaScript -- we can't get people to stop  
doing what worked if there's no new and better way (the recent  
arguments.callee in strict mode thread highlighted this point).

Of course, the web is too big to try to get away with deprecation/ 
obsolescence cycles on any predictable near-term release schedule.  
Never mind coordination among browser vendors on their next versions  
-- IE6 is still Out There.

But perhaps once past IE6, though, with modern browsers auto-updating,  
we'll see the downrev implementations go away faster. There's a  
chance, anyway, from what I see of IE8 replacing IE7, and of course  
faster updating for other, "fresher" browsers ;-).

If we do see a world where browser version uptake is faster, and the  
downrev problem shrinks or becomes more tractable somehow, then we  
will want shinier duct tape without bits of lint and trash stuck to  
the edges of the tape roll, over time. Every compatibility constraint  
costs non-linearly when refracted through the whole-language design  
process.

So part of ECMAScript "Harmony" is not just "ES6", a prematurely- 
triaged, shortest-path evolutionary jump, but longer-term "end to end"  
design that ultimately puts the TC39 committee out of the language- 
extension business by empowering developers to bootstrap new language  
versions by themselves.


> Systems that discard compatibility can also deliver an unusable  
> Second System, especially when designed by committee. I would point  
> to certain W3C specs that chose to break compatibility with existing  
> practice. They are often not only undeployable but also not very  
> compelling on their own terms.

Agreed.


> I think compatibility constraints, even though they impose messy and  
> illogical quirks, can also act as a healthy counterweight to flights  
> of design fancy. Constraints make for good art.

We seem to have some unnecessary constraints, which are bad for art  
and science. Let's try to get rid of the foo(i) for foo[i] or  
foo.item[i] non-mandatory compatibility cruft and see how that goes.

/be

Received on Sunday, 27 September 2009 23:57:09 UTC