From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10476 invoked from network); 15 May 2020 02:45:26 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 15 May 2020 02:45:26 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id DEEBF9C96D; Fri, 15 May 2020 12:45:21 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 90AE19C677; Fri, 15 May 2020 12:44:46 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="UET5TVLU"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id C094D9C668; Fri, 15 May 2020 12:44:43 +1000 (AEST) Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by minnie.tuhs.org (Postfix) with ESMTPS id 652779C668 for ; Fri, 15 May 2020 12:44:42 +1000 (AEST) Received: by mail-vk1-f169.google.com with SMTP id o8so185086vkd.12 for ; Thu, 14 May 2020 19:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HtNx/sO9dgqqEbmf9o1xCUnF7VpM3OiY3AYDBpZ4rsQ=; b=UET5TVLUxp2F5XMe5teosOWDkigtGyj14k2wRgfLsXgBirST3M1ot5P7yvEHnFS2oM fyDj3FL+nmg5vFsXS/5+MWkcPf/IFa951UxZ0lLbER2A245eLsxb2r5eZLGkxlkl/vyb 87ea4L6GXOdY5t+hXbgxz3G0t/n9djfsefIm7/Ggc0amhdnCDV7KYJqZcPJ+AhI2OYbL Lcg4vd4Detl4rD8oUeZvheQXtvBdTjiiD0hHQh9grGHdCgxSudyhepFmeEKlzYrmyRcY pOno2ROEUfcHlOy8qCdIeUcjGGJYolSsvXBBFC1Pn04l3M0FcqvVhherh3h9J8n6rGV9 OKdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HtNx/sO9dgqqEbmf9o1xCUnF7VpM3OiY3AYDBpZ4rsQ=; b=KtgAHzNrh9sSslK3oy7FKTw8a8zOM4PE7W22Uygk6bwf4tY6Wjzb07erMSuvW9jq5S 1kqMpT1B5AFikZRXBMtXJGEQKkDFIQJgg4CSRUTabnvh73NN82SVYnylyDTmqq8YdArR 8iS6w7ScYrYRZ5enKPIyf29AvZCHZgiDinEnC22atxeN9jDCvOj4oS5hkPawpML8t89E RAj2oUR1CXJtwyAmKu4N3iSdcYTE8kbJlkd2Bw20uXIZ+eXRmuzbg3UhsbaEKV973Ch3 8iKnpgNCdcU1bYkxtG6SakFz5P8AZZQ4ijrAOGKbt7/4QqVJX019r1YtZiEiFHpQixkw PGgA== X-Gm-Message-State: AOAM533OrouEIGZMt21PlpdzYodA30lQDJCUdV8qfDZUv1OAxgfduNSt HDUEFaidJMZmY/SPh7/0Wos3D/N85iA2ge2Rp4I= X-Google-Smtp-Source: ABdhPJwNBZ75COGbtRn7qWgBRAyaftSwJhZcRb95IJOUaa2wEec65DoRSa64q7e3s64waB6NBGAJ5tGkVGNB2PM7iuk= X-Received: by 2002:a1f:2a13:: with SMTP id q19mr1069202vkq.73.1589510681370; Thu, 14 May 2020 19:44:41 -0700 (PDT) MIME-Version: 1.0 References: <202005141841.04EIfvEZ063529@tahoe.cs.Dartmouth.EDU> In-Reply-To: <202005141841.04EIfvEZ063529@tahoe.cs.Dartmouth.EDU> From: Rob Pike Date: Fri, 15 May 2020 12:44:30 +1000 Message-ID: To: Doug McIlroy Content-Type: multipart/alternative; boundary="00000000000087a2bd05a5a6cbdc" Subject: Re: [TUHS] v7 K&R C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000087a2bd05a5a6cbdc Content-Type: text/plain; charset="UTF-8" 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 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 > > --00000000000087a2bd05a5a6cbdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps for the first time in my career, I am about to dis= agree with Doug McIlroy. Sorry, Doug, but I feel the essence of object-orie= nted computing is not operator overloading but the representation of behavi= or. I know you love using o.o. in OO languages, but that is syntax, not sem= antics, and OO, not o.o., is about semantics.

And of cou= rse, 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 o= perator 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<= br> > situation in which case it means something else.=C2=A0 Now, try debugg= ing that.

Does your antipathy extend to C++ IO and its heavily overloaded << an= d >>?

The essence of object-oriented programming is operator overloading. If you<= br> 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,<= br> 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

--00000000000087a2bd05a5a6cbdc--