Operator overloading revisited

Mark S. Miller erights at google.com
Tue Jun 30 14:44:41 PDT 2009

> I certainly agree that it's good to have a more complete enumeration of the
> pros and cons. I think we largely agree on many of these but disagree on the
> weights. JavaScript today has adequate support for modularity and
> abstraction, and is mostly understandable. ES5/strict even more so. Common
> Lisp and PL/1 never were understandable. And Common Lisp is highly
> immodular. I agree that ES6 should grow some compared to ES5, but I highly
> value retaining ES5/strict's modularity, simplicity, understandability.

I withdraw the seeming comparison to Common Lisp. I was trying to make a
more general point, but the implied comparison is not fair. Let's take Cecil
instead, since it was designed by people with extraordinarily good taste
(cc'ed), and since you recommended it as an example of multimethods done
right. On your recommendation, I read it. Because of its pedigree, I really
wanted to like it. In the end, I was reluctantly repelled by its complexity.
If it is representative of the complexity costs of multimethods done right,
I consider these costs to far outweight the benefits. Other things being
equal, I would chose not to program in Cecil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090630/7c14e82c/attachment.html>

More information about the es-discuss mailing list