The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Dan Cross <crossd@gmail.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>,
	Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
Subject: Re: [TUHS] run commands at login in v6 and stty
Date: Mon, 28 Feb 2022 14:26:46 -0500	[thread overview]
Message-ID: <CAC20D2McdPQ=uB-=EcaOf7_W1+CtyhQmsVkpiQ4=F=PPNK0RdQ@mail.gmail.com> (raw)
In-Reply-To: <CAEoi9W6-1MV-pBax8J1adQPCXCyXMjMsJFruUgea=gikoC6eyw@mail.gmail.com>

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

On Mon, Feb 28, 2022 at 1:49 PM Dan Cross <crossd@gmail.com> 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.

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

  parent reply	other threads:[~2022-02-28 19:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28  1:04 Douglas McIlroy
2022-02-28  7:22 ` Rob Pike
2022-02-28 14:07   ` Larry McVoy
2022-02-28 18:47     ` Dan Cross
2022-02-28 19:25       ` Dan Cross
2022-02-28 21:25         ` markus schnalke
2022-02-28 19:26       ` Clem Cole [this message]
2022-02-28 20:03         ` Adam Thornton
2022-02-28 18:18 ` Warner Losh
  -- strict thread matches above, loose matches on Subject: below --
2022-02-27  7:48 Noel Chiappa
2022-02-26 21:45 Brian Walden
2022-02-26 22:16 ` Rob Pike
2022-02-27 20:32 ` Sven Mascheck
2022-02-26 20:39 Will Senn
2022-02-26 21:03 ` Michael Kjörling
2022-02-26 22:49 ` Clem Cole
2022-02-26 23:12   ` Rob Pike
2022-02-27  0:46     ` Clem Cole
2022-02-27 15:01     ` Larry McVoy
2022-02-27 17:10       ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2McdPQ=uB-=EcaOf7_W1+CtyhQmsVkpiQ4=F=PPNK0RdQ@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=crossd@gmail.com \
    --cc=douglas.mcilroy@dartmouth.edu \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).