9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] kenc
Date: Wed,  2 May 2007 08:32:43 +0000	[thread overview]
Message-ID: <4637917B.19AC54E1@null.net> (raw)
In-Reply-To: <eff9d5240705010233w14bb2f74taf37e5437f0b123e@mail.gmail.com>

Saint Sexburga wrote:
> surely you can sympathise with those of us who feel that they are
> drowning in the rising tide of complexity of modern computing
> "standards". C99 is the least of our worries, but even here, do you
> feel that Dennis Ritchie was entirely wrong in his answer to the
> question "Are you satisfied with C99?", when he said, amongst other
> things:
> "I was satisfied with the 1989/1990 ANSI/ISO standard. The new C99
> standard is much bulkier, and though the committee has signaled that
> much of their time was spent in resisting feature-suggestions, there
> are still plenty of accepted ones to digest. I certainly don't desire
> additional ones, and the most obvious reaction is that I wish they had
> resisted more firmly" and "Of the new things, restricted pointers
> probably are a help; variadic macros and bool are just adornment."

It's certainly true that the bulk of C99 seems excessive; largely
it is due to having a parallel set of wchar_t-oriented functions
duplicating the functionality of the char-oriented ones (which I
predicted back in 1986 when we were still debating how to
accommodate extended character sets).  A lot has also been added
in areas such as floating-point that is of interest to a limited
portion of the programming community.  Unfortunately, a lot of
useful things naturally fall into the "limited interest" category;
we try to accommodate those interests with libraries when feasible,
but the key point is standardization so that applications are
readily portable across platforms (including Plan 9, to the extent
that it supports such standards).

Variadic macros are sufficiently useful (typically for printf-like
error handling) that GCC had already invented a form of them; we
would have liked to simply adopt that existing practice, but found
enough potential problems with it that we adopted a slightly
different solution.  

Bool is another example of numerous incompatible extensions to
achieve the effect (usually by programmers in this instance, rather
than in compilers), which is a good indication of a facility crying
out for a standardized solution.  It obviously isn't a "deep"
feature, which it can't be given the need to remain compatible with
existing C, but it is useful to have.

> Doug, I'm not getting at you, but do you never feel, enough is enough?

I understand the frustration.  Many standards and portions therefof
can be ignored if you don't need to use certain specified features.
Unfortunately, a very large amount of "infrastructure" has evolved
and a very large amount of current software has been built upon it.
Not long ago I tried to build GCC 4.0 on Solaris 8 and found that I
needed to install about a dozen nonstandard support libraries before
I could get it to build.  (I think that current releases of Solaris
and Linux are shipped with most or all of those libraries.)  In fact
I ran out of disk space and had to devise a workaround to get the job
done.  You can imagine that adapting such software is a problem due
to the large number of library interfaces that must be understood.

I don't see any way to undo the situation..


  parent reply	other threads:[~2007-05-02  8:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-01  9:33 Saint Sexburga
2007-05-01 10:48 ` Russ Cox
2007-05-01 11:48   ` Uriel
2007-05-02  8:32 ` Douglas A. Gwyn [this message]
2007-05-03  3:39   ` Roman Shaposhnick

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=4637917B.19AC54E1@null.net \
    --to=dagwyn@null.net \
    --cc=9fans@cse.psu.edu \
    /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).