Re: [9fans] kenc - Plan9

This is a discussion on Re: [9fans] kenc - Plan9 ; 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, ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: [9fans] kenc

  1. Re: [9fans] kenc

    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..

  2. Re: [9fans] kenc

    On Wed, 2007-05-02 at 08:32 +0000, Douglas A. Gwyn wrote:
    >
    > I don't see any way to undo the situation..


    C at least has a luxury of vectoring off all the eager beavers
    to a C++ committee, where languages like Fortran don't have
    a Fortress to protect them from mutilation yet (pun intended).

    Thanks,
    Roman.


+ Reply to Thread