Re: [TUHS] v7 K&R C

[Rob Pike <robpike@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

Perhaps for the first time in my career, I am about to disagree with Doug
McIlroy. Sorry, Doug, but I feel the essence of object-oriented computing
is not operator overloading but the representation of behavior. I know you
love using o.o. in OO languages, but that is syntax, not semantics, and OO,
not o.o., is about semantics.

And of course, the purest of the OO languages do represent arithmetic as
methods, but the fit of OO onto C was never going to be smooth.

-rob


On Fri, May 15, 2020 at 4:42 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> > o operator overloading
> >
> > I never could figure out why Stroustrup implemented that "feature"; let's
> > see, this operator usually means this, except when you use it in that
> > situation in which case it means something else.  Now, try debugging
> that.
>
> Does your antipathy extend to C++ IO and its heavily overloaded << and >>?
>
> The essence of object-oriented programming is operator overloading. If you
> think integer.add(integer) and matrix.add(matrix) are good, perspicuous,
> consistent style, then you have to think that integer+integer and
> matrix+matrix are even better. To put it more forcefully: the OO style
> is revoltingly asymmetric. If you like it why don't you do everyday
> arithmetic that way?
>
> I strongly encouraged Bjarne to support operator overloading, used it
> to write beautiful code, and do not regret a bit of it. I will agree,
> though, that the coercion rules that come along with operator (and
> method) overloading are dauntingly complicated. However, for natural uses
> (e.g. mixed-mode arithmetic) the rules work intuitively and well.
>
> Mathematics has prospered on operator overloading, and that's why I
> wanted it. My only regret is that Bjarne chose to set the vocabulary of
> infix operators in stone. Because there's no way to inroduce new ones,
> users with poor taste are tempted to recycle the old ones for incongruous
> purposes.
>
> C++ offers more features than C and thus more ways to write obscure code.
> But when it happens, blame the writer, not the tool.
>
> Doug
>
>

[-- Attachment #2: Type: text/html, Size: 2595 bytes --]