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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17722 invoked from network); 28 Feb 2022 19:38:30 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 28 Feb 2022 19:38:30 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 8D6389CFC0; Tue, 1 Mar 2022 05:38:29 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 759749CE49; Tue, 1 Mar 2022 05:36:46 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="Ulq/KBJD"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 2E5DA9CC02; Tue, 1 Mar 2022 05:27:14 +1000 (AEST) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by minnie.tuhs.org (Postfix) with ESMTPS id 914B19CBCE for ; Tue, 1 Mar 2022 05:27:13 +1000 (AEST) Received: by mail-qk1-f179.google.com with SMTP id v5so11191965qkj.4 for ; Mon, 28 Feb 2022 11:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DPQQaQEAqQ7PIaKZ9IbTSHuoZ6V6AYzI/R1hMfYbpb4=; b=Ulq/KBJDWNSJPNsB7lJICYZveB1FAw+CCrXioR3MVyQPZIaMZaQYFVcVoi892rpWGg M8gFkWWAHaebd5j8CoNOgWv3DoDRUhtSg9KYRoZ0+mqjXOMTNDmLq6ac5gPXRNd/UiYd qTyd89IA6CymvtUF+Qx+3kJtziv1ZwHv1+fmE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DPQQaQEAqQ7PIaKZ9IbTSHuoZ6V6AYzI/R1hMfYbpb4=; b=BKa228aagkiSjHjqXaCRjcd4VkIDRNkjkwubyuygIBExnCU03qaTpN/N1HTkyE5M2P zbT466BAVp2IqvaXUxRBOrFWSai9EQTsJAXyaLevpp/wv3Od6CA2p31c/35MdPk69xFr RA+fm+qK0rjeZZnyPF91lsW6HLG/pZmmyQtDUmAmpRmgtf6IbAa1k1NeLF5vKMipI58h t6z7OL8OYGSmWfv5r7bRfqM0hlEWhLWt1FqtKIakO57QbniWlRmshGiIhosiUELf4YAT 7ctcLj2TkJ/hNJ0RPWQGxZ5uOzrXPLTHDxmOmXTBayCWWxOTNT3FnaxuiD0K9ORWQV3R p6fA== X-Gm-Message-State: AOAM532v2d2XwiAAx5nULO7xXpIZIsGLvTU2O/ZtAGApGBX9A5UfEmw+ 1msikScNbCkwXfOtHzreq9FkfkI5J12lGAv/fqS1uw== X-Google-Smtp-Source: ABdhPJzr4gj/pMhTmjra0Uj3a9rWwYW2gtKA6BuksDHA+U33BIrxEK/NTAqWmj7sUukXoQEYtzxmKJuirknwQXL86Xg= X-Received: by 2002:a05:620a:1992:b0:649:56f3:6451 with SMTP id bm18-20020a05620a199200b0064956f36451mr12231373qkb.84.1646076432433; Mon, 28 Feb 2022 11:27:12 -0800 (PST) MIME-Version: 1.0 References: <20220228140715.GQ21168@mcvoy.com> In-Reply-To: From: Clem Cole Date: Mon, 28 Feb 2022 14:26:46 -0500 Message-ID: To: Dan Cross Content-Type: multipart/alternative; boundary="000000000000075d8105d9190943" Subject: Re: [TUHS] run commands at login in v6 and stty 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: TUHS main list , Douglas McIlroy Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000075d8105d9190943 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 28, 2022 at 1:49 PM Dan Cross wrote: > > #ifdef has more or less always struck me as the solution to the wrong > problem. "We have all this code and we want to shoehorn it into a new > environment," instead of, "we have many environments, so we carefully > structure the code to accommodate the differences." Of course, the latter > is harder than the former, but it also pays larger dividends over time as > compared to the former. > Absolutely - but the problem is the development process (more in a minute). > > The biggest problem with #ifdef wasn't so much that it existed, but rather > that it was used for too many things that it wasn't well-suited for. > Agreed. > The second biggest problem was that it was semantically unaware of the > language; it was purely textual. Bummer. > Dan - I'll argue with you on that one actually. One of the reasons why C was successful in a professional language is that it could be easily preprocessed, which other languages like Pascal and even Ada sucked when you tried. There are times when a preprocessor is just really handy as Larry said, particularly in a product programming house. And here is the issue ... Doug and Rob are 100% right about Plan 9 but .. it's not a fair comparison. Plan9 was a research system. X started out as that, but by the time of X11 it was a production system and very different types of programmers. When you are porting code, particularly when under type constraints, Larry described exactly how it's done ... #ifdef NOTDEF ... ok this works.... and off you go the next issue with the product. In my experience, the development process often (tends to) reinforce this behavior. Note I am not telling you that's a good idea ... but *it is a typical behavior* (*a.k.a. *whiskey to teenagers). You intend to go back and redo it, but it never gets done. The next person adds their hack and pretty soon you have the BSD kernel if #ifdef FASTVAXl or #ifdef BIG_ENDIAN scattered all over the code base. As Larry and others have pointed out, an abstraction layer, when you can enforce it, clearly is the best. But to be fair, one of the reasons why C was so popular, is that so much code could be moved. One of the things I hated about Pascal, was that so much code had been written that assumed 36 or 40 integers, or that string limits varied depending on byte or work size and how the len was encoded -- yeech. The problem, as Larry said, is that it is a powerful tool that was easy to and often was, abused by both neophytes and people that should have known better. --000000000000075d8105d9190943 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 28, 2022 at 1:49= PM Dan Cross <crossd@gmail.com&= gt; wrote:

#ifdef has more or less always struck me as the solut= ion to the wrong problem. "We have all this code and we want to shoeho= rn it into a new environment," instead of, "we have many environm= ents, so we carefully structure the code to accommodate the differences.&qu= ot; Of course, the latter is harder than the former, but it also pays large= r dividends over time as compared to the former.
Absolutely - but the problem is the developm= ent process (more in a minute).

The biggest problem with = #ifdef wasn't so much that it existed, but rather that it was used for = too many things that it wasn't well-suited for.
Agreed.

= =C2=A0
The second biggest problem was that it was semantically unaware of the = language; it was purely textual. Bummer.
<= font color=3D"#0000ff">Dan - I'll argue with you on that one actually. = =C2=A0 One of the reasons why C was successful in a professional language i= s that it could be easily preprocessed, which other languages like Pascal a= nd even Ada sucked when=C2=A0you tried.=C2=A0 There are times when a prepro= cessor is just really handy as Larry said, particularly in a product progra= mming house.

And here is the issue ...

Doug and Rob are 100% right a= bout Plan 9 but .. it's not a fair comparison.=C2=A0 Plan9 was a resear= ch system.=C2=A0 X started out as that, but by the time of X11 it was a pro= duction system and very different types of programmers. =C2=A0 When you are= porting code, particularly when under type constraints, Larry described ex= actly how it's done ... =C2=A0 #ifdef NOTDEF =C2=A0... =C2=A0 ok this works.... and off you go t= he next issue with the product. In my experience, the development process o= ften (tends to) reinforce=C2=A0this behavior.

Note I am not telling you that= 's a good idea ... but it is a typical behavior (a.k.a. whiskey to teenagers= ).=C2=A0 You intend to go back and redo it, but it never gets done.=C2=A0 T= he next person adds their hack and pretty soon you have the BSD kernel if #ifdef FASTVAXl or= =C2=A0=C2=A0#ifdef BIG_ENDIAN=C2=A0scattered all over the co= de base.

As La= rry and others have pointed out, an abstraction layer, when you can enforce= it, clearly is the best. =C2=A0 But to be fair, one of the reasons why C w= as so=C2=A0popular, is that so much code could be moved.=C2=A0 One of the t= hings I hated about Pascal, was that so much code had been written that ass= umed 36 or 40 integers, or that string limits varied depending=C2=A0on byte= or work size and how the len was encoded -- yeech.

The problem, as Larry said, is that = it is a powerful tool that was easy to and often was, abused by both neophy= tes and people that should have known better.=C2=A0
--000000000000075d8105d9190943--