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
