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

On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote:

> On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote:
>
>>> I'm musing a bit here, bear with me. If we only hack  
>>> incrementally, and preserve backward compatibility with frankly  
>>> dumb (or merely hasty) design decisions (many mine!) then we'll  
>>> probably make less progress than if we try to rationalize old and  
>>> new in a better systematic design.
>>
>> That's a little too abstract for me to tell if I agree or not.
>
> Shortest-path evolution can walk uphill only a little bit at a time,  
> and get stuck at local minimal points in a design space, when over  
> the big hill is a much better, richer valley to evolve in. This path  
> dependency problem bits many real-world systems.
>
> I experience this point as hard and painful, like concrete -- it' s  
> not abstract. I've been around too long to ignore it, as it's all  
> around us on the web, and it has been since 1994 if not earlier.
>
> Compatibility concerns in the form of graceful degradation or  
> progressive enhancement are not unmixed blessings. More coherent  
> stacks from Microsoft, Adobe, and Sun can rightly claim to solve  
> problems more cleanly and simply than the web. Of course these  
> stacks have other problems, mainly from being single-sourced if not  
> proprietary, but also from not progressing compatibly, and for other  
> reasons I won't digress on.
>
> 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.

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.

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.

Regards,
Maciej