From: arnold@skeeve.com
To: tuhs@tuhs.org, g.branden.robinson@gmail.com
Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)
Date: Tue, 01 Oct 2024 07:13:04 -0600 [thread overview]
Message-ID: <202410011313.491DD4ac421643@freefriends.org> (raw)
In-Reply-To: <20240928180138.aygrwqdwrvq3n6xt@illithid>
This is long, my apologies.
"G. Branden Robinson" <g.branden.robinson@gmail.com> wrote:
> [ screed omitted ]
Branden, as they say, Hindsight is 20-20.
But one needs to take into account that Unix and C evolved,
and in particular on VERY small machines. IIRC the original
Unix PDP-11s didn't even have split I/D spaces. Getting a decent
compiler into that small an address space isn't easy (and by now
is a lost art).
The evolution was gradual and, shall we say "organic", without
the pretension and formalisms of a language committee, but simply
to meet the needs of the Bell Labs researchers.
The value of a high level language for OS work was clear from
Multics. But writing a PL/1 compiler from scratch for the tiny
PDP-11 address space made no sense. Thus the path from BCPL to B to C.
Today, new languages are often reactions to older ones.
Java, besides the JVM portability, tried to clean up the syntax
of C / C++ and add some safety and modernism (graphics, concurrency).
C# was a reaction to (and a way to compete with) Java.
Go was very clearly in reaction to current C++, but headed back
in the direction of simplicity. Successfully, IMHO.
Would the word have been better off if Ada had caught on everywhere?
Probably. When I was in grad school studying language design, circa 1982,
it was expected to do so. But the language was VERY challenging for
compiler writers. C was easy to port, and then Unix along with it.
C'est la vie.
Larry wrote:
> I have a somewhat different view. I have a son who is learning to program
> and he asked me about C. I said "C is like driving a sports car on a
> twisty mountain road that has cliffs and no guard rails. If you want to
> check your phone while you are driving, it's not for you. It requires
> your full, focussed attention. So that sounds bad, right? Well, if
> you are someone who enjoys driving a sports car, and are good at it,
> perhaps C is for you."
This goes back to the evolution thing. At the time, C was a huge
step up from FORTRAN and assembly. Programmers who moved to C
appreciated all it gave them over what they had at the time.
C programmers weren't wizards, they were simply using the best
available tool.
Going from a bicycle to an automobile is a big jump (to
continue Larry's analogy).
Larry again:
> I ran a company that developed a product that was orders of magnitude more
> complex than the v7 kernel (low bar but still) all in C and we had *NONE*
> of those supposed problems. We were careful to use stuff that worked,
> I'm "famous" in that company as the guy was viewed as "that was invented
> after 1980 so Larry won't let us use it". Not true, we used mmap and used
> POSIX signals, but mostly true. If you stick to the basics, C just works.
> And is portable, we supported every Unix (even SCO), MacOS, Windows, and
> all the Linux variants from ARM to IBM mainframes.
This is also my experience with gawk, which runs on everything from
ARM (Linux) to Windows to mac to VMS to z/OS (S/390x). OS issues
give me more grief than language issues.
> All that said, I get it, you want guard rails. You are not wrong, the
> caliber of programmers these days are nowhere near Bell Labs or Sun or
> my guys.
This is a very important, key point. As more and more people have
entered the field, the quality / education / knowledge / whatever
has gone down. What was normal to learn and use back in 1983 is
now too difficult for many, if not most, people, even good ones, in
the field now.
The people I work with here (Israel) don't know who Donald Knuth is.
Two of the people in my group, over 40, didn't know what Emacs is.
Shell scripting seems to be too hard for many people to master,
and I see a huge amount of Cargo Cult Programming when it comes
to things like scripts and Unix tools.
Thus Go and Rust are good things, taking the sharp tools out of the
hands of the people who aren't qualified to use them. Same thing Python.
But for me, and I think others of my vintage, this state of affairs
seems sad.
My 4 cents,
Arnold
next prev parent reply other threads:[~2024-10-01 13:13 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-28 13:34 Douglas McIlroy
2024-09-28 16:58 ` G. Branden Robinson
2024-09-28 17:47 ` Luther Johnson
2024-09-28 17:52 ` Luther Johnson
2024-09-28 18:46 ` G. Branden Robinson
2024-09-28 22:08 ` Luther Johnson
2024-09-28 22:45 ` Luther Johnson
2024-09-28 22:50 ` Luther Johnson
2024-09-28 17:59 ` Bakul Shah via TUHS
2024-09-28 22:07 ` Douglas McIlroy
2024-09-28 23:05 ` Rob Pike
2024-09-28 23:30 ` Warner Losh
2024-09-29 10:06 ` Ralph Corderoy
2024-09-29 12:25 ` Warner Losh
2024-09-29 15:17 ` Ralph Corderoy
2024-09-30 12:15 ` Dan Cross
2024-09-28 18:01 ` G. Branden Robinson
2024-10-01 13:13 ` arnold [this message]
2024-10-01 13:32 ` Larry McVoy
2024-10-01 13:47 ` arnold
2024-10-01 14:01 ` Larry McVoy
2024-10-01 14:18 ` arnold
2024-10-01 14:25 ` Luther Johnson
2024-10-01 14:56 ` Dan Cross
2024-10-01 15:08 ` Stuff Received
2024-10-01 15:20 ` Larry McVoy
2024-10-01 15:38 ` Peter Weinberger (温博格) via TUHS
2024-10-01 15:50 ` ron minnich
2024-10-01 19:04 ` arnold
2024-10-01 16:49 ` Paul Winalski
2024-10-01 15:44 ` Bakul Shah via TUHS
2024-10-01 19:07 ` arnold
2024-10-01 20:34 ` Rik Farrow
2024-10-02 0:55 ` Steffen Nurpmeso
2024-10-02 5:49 ` arnold
2024-10-02 20:42 ` Dan Cross
2024-10-02 21:54 ` Marc Donner
2024-10-05 17:45 ` arnold
2024-10-06 12:20 ` Dan Cross
2024-10-06 12:29 ` [TUHS] UREP code (was Re: Re: Minimum Array Sizes in 16 bit C (was Maximum)) arnold
2024-10-01 16:40 ` [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) Paul Winalski
2024-09-28 18:05 ` Larry McVoy
2024-09-30 15:49 ` Paul Winalski
2024-09-29 16:56 Douglas McIlroy
2024-09-29 20:29 ` Rob Pike
2024-09-29 21:13 ` Rik Farrow
2024-09-29 22:21 ` Rich Salz
2024-09-29 23:56 ` Rob Pike
2024-09-30 0:36 ` Larry McVoy
2024-09-30 0:55 ` Larry McVoy
2024-09-30 1:09 ` Luther Johnson
2024-09-30 1:37 ` Luther Johnson
2024-09-30 3:52 ` ron minnich
2024-10-01 12:43 ` arnold
2024-09-30 19:12 ` Steffen Nurpmeso
2024-09-30 20:03 ` Rich Salz
2024-09-30 21:15 ` Steffen Nurpmeso
2024-09-30 22:14 ` Bakul Shah via TUHS
2024-10-01 1:42 ` Alexis
2024-09-30 20:14 ` Rik Farrow
2024-09-30 22:00 ` Steffen Nurpmeso
2024-10-01 12:53 ` Dan Cross
2024-11-18 12:00 ` Anton Shepelev
2024-11-18 12:46 ` Luther Johnson
2024-11-18 14:05 ` Steve Nickolas
2024-11-18 15:00 ` Anton Shepelev
2024-11-23 22:29 ` Alexander Schreiber
2024-11-18 14:55 ` Anton Shepelev
2024-11-18 16:52 ` G. Branden Robinson
2024-11-18 17:00 ` Anton Shepelev
2024-11-18 18:56 ` Luther Johnson
2024-11-22 1:53 ` Dan Cross
2024-11-22 2:55 ` Luther Johnson
2024-09-29 21:24 ` Ralph Corderoy
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=202410011313.491DD4ac421643@freefriends.org \
--to=arnold@skeeve.com \
--cc=g.branden.robinson@gmail.com \
--cc=tuhs@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).