[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Noel Chiappa]

    > From: Bakul Shah

    > In hindsight Algol68 may have been the last committee designed language
    > that was good.

I do not grant your basic assertion. Hoare had it right: "ALGOL 60 [was] a
language so far ahead of its time that it was not only an improvement on its
predecessors but also on nearly all its successors." That would definitely
include Algol68, which was a classic committee-designed nightmare.

	Noel

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[John Cowan]

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

[migrating to coff]

On Tue, Mar 14, 2023 at 11:59 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:


> I do not grant your basic assertion. Hoare had it right: "ALGOL 60 [was] a
> language so far ahead of its time that it was not only an improvement on
> its
> predecessors but also on nearly all its successors." That would definitely
> include Algol68, which was a classic committee-designed nightmare.
>

Common Lisp came long after 1968, was committee-designed, and is by no
means a nightmare.  It's not a jewel like Scheme is said to be (wrongly
IMO), it's a ball of mud, but balls of mud are best for solving muddy
problems.

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

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Bakul Shah]

On Mar 14, 2023, at 8:59 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> 
>> From: Bakul Shah
> 
>> In hindsight Algol68 may have been the last committee designed language
>> that was good.
> 
> I do not grant your basic assertion. Hoare had it right: "ALGOL 60 [was] a
> language so far ahead of its time that it was not only an improvement on its
> predecessors but also on nearly all its successors." That would definitely
> include Algol68, which was a classic committee-designed nightmare.

You have to realize that even top-notch computer scientists
like Hoare, Dijkstra are/were still people just like us
and have their own biases! And the context matters.

The a68 fights were before my time. I learned about it at grad
school on my own and at the time I had no preconceptions about
it (or for that matter any other language).  Reading the
Algol68 Revised Report was hard but all became clear when I
read an introductory book by Brailsford and Walker, and
another by Pagan. I liked a68's uniform syntax and semantics
very much, in spite of surface syntax issues like DO .. OD. I
just think it got a very bad rap due to personalities, the
language of report itself, the strong opinions of its language
committee, the state of art computers at the time etc. etc.
Today it seems like a smaller language than today's C++, Rust,
Swift etc. If I were to write as many lines of code in it as I
have in C++, possibly I may dislike it but probably not as
much as C++.

Cowan made a point that CL is a committee designed language
that is "not a nightmare". I agree. I missed noting that.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Chet Ramey]

On 3/13/23 8:21 PM, Dan Cross wrote:

> It's a shame POSIX is keeping it around, but it appears you're right:
> https://pubs.opengroup.org/onlinepubs/9699919799/
> 
> In fairness, this does say it may be removed from a later standard.

It's been removed in the upcoming issue 8.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[G. Branden Robinson]

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

At 2023-03-13T22:49:23-0400, Theodore Ts'o wrote:
> As an OS engineer, I deeply despise these optimization tricks, since I
> personally I care about correctness and not corrupting user data far
> more than I care about execution speed ---- especially when the parts
> of the kernel I work on tend not to be CPU bound in the first place.

Alex has heard me say this before.

In the U.S., civilian air traffic controllers have a maxim.

Safe, orderly, efficient.[1]

You meet these criteria in order from left to right, and you satisfy one
completely, or to some accepted, documented, and well-known standard
measure, before you move on to the next.  The obvious reason for this is
that when aircraft meet each other at cruise altitudes, many people die.

I haven't yet settled on a counterpart for software engineering that I
like, but the best stab at it I've come up with is this.

Comprehensible, correct, efficient.

Incomprehensible code is useless.[2][3]  Even code that is proven
correct by formal methods is fragile if human maintainers are defeated
by its esoteric expression.[4]  (And formal verification can't save you
from incorrect specification in the first place.)  Richard Feynman once
said something along the lines of, if there is any phenomenon in physics
that he can't successfully explain to an audience of freshmen, then we
don't really understand it yet.  We use subtle, complex tools to solve
problems only when we haven't worked out ways to overcome them with
simple, straightforward ones.  Before we surrender to the excuse of
irreducible complexity we must have valid, verifiable, peer-reproducible
evidence that we've reduced the complexity as far as known methods will
allow.

But I'm junior to most of the grognards are on this list, so I'm
half-expecting the Joe Pesci opening statement from _My Cousin Vinny_...

Regards,
Branden

[1] https://www.avweb.com/features/say-again-8air-traffic-chaos/
[2] Literally useless, especially once that something that "just works"
    is ported to a new context.  "The real problem is that we didn't
    understand what was going on either."
    https://www.bell-labs.com/usr/dmr/www/odd.html
[3] Except for constructing streams of self-lauding horse puckey before
    promotion committees comprised of people who themselves attained,
    and will further advance, their status predicated on the audacity of
    their horse puckey.
[4] And once something's _that_ solid, it may be time to consider
    etching it in silicon rather than primary or secondary storage.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Theodore Ts'o]

On Mon, Mar 13, 2023 at 12:00:04PM -0400, Paul Winalski wrote:
> 
> Note that the goal of a programming language standards committee is
> very different from the goal of those who use the language.  The
> committee's goal is to standardize existing practice of the language
> in a way that is implementable on the widest range of hardware and OS
> platforms, and to provide a controlled way to add language extensions.

It's worse than that.  Programming language stanrds committees are
dominated by engineers working on compilers, and there are very few (I
personally know of only one) OS engineers who might be trying to *use*
the language in a kernel where you have interrupt handlers, etc., and
don't like the fact that the compiler might optimize the code in such
a way that it moves instructions out from a critical region, etc.

> The advantage of programming in strict ISO C is that the resulting
> code will run just about anywhere.  If you don't care about that (and
> I'd wager most programmers don't) then ignore the standard.

For a sufficiently important program, it's possible for the authors to
say --- the C standard is just ***insane*** and if you want us to
support compilation of say, the Linux kernel by your compiler, you
*must* provide knobs to turn off certain insane "features" of the C
language spec.  GCC and Clang have those knobs, so you could say that
it they support the Linux kernel "dialect".  And the fact that this
dialect isn't blessed by the ISO committee doesn't cause me to lose
any sleep at night.

> As someone pointed out, the three things that most programmers value
> are execution speed, execution speed, and execution speed.  Aliasing
> issues greatly hamper what a modern optimizing compiler can do and
> still generate semantically correct code.

Compiler companies who are playing benchmark wars care about execution
speed --- of benchmark programs.  I'm not sure how many programmers
actually care about some of these optimizations, because there aren't
*that* many programs that are really CPU bound, and many which appear
to be CPU bound are often hitting memory bandwidth / caching issues,
which are not necessarily the things which tricky compiler
optimizations can fix.

As an OS engineer, I deeply despise these optimization tricks, since I
personally I care about correctness and not corrupting user data far
more than I care about execution speed ---- especially when the parts
of the kernel I work on tend not to be CPU bound in the first place.

	    	     	     	      	 - Ted

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Bakul Shah]

On Mar 13, 2023, at 2:14 PM, Dan Cross <crossd@gmail.com> wrote:
> 
> On Mon, Mar 13, 2023 at 5:08 PM Bakul Shah <bakul@iitbombay.org> wrote:
>> On Mar 13, 2023, at 2:00 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
>>> 
>>> On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
>>>> 
>>>> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
>>>> requiring and fall back at least to K&R2 -- keep it simple.
>>> 
>>> I agree.  Every language has toxic features--things that seemed like
>>> good ideas at the time but turn out to have been mistakes when they're
>>> better understood.  Every good programming shop has its rules
>>> concerning certain language features or practices that are not allowed
>>> in the code, usually for safety or maintainability reasons.
>> 
>> You can't drop features from a widely deployed language; but while
>> we are dreaming, what I'd like to see is a total *ban* on any and
>> all optimizations. What you get is what you see!
> 
> Hey, they dropped `gets` from the standard library! Never say never.

It is easy to see that incorrect use of gets can lead to buffer
overflow problems so they "fixed" the easier downstream issue but
not the root cause! And that is the problem. Easy things are fixed
but nobody dares fix more fundamental problems.

And that was my point. All that standardization committees can do
is tweak a few things here and there. 

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Larry McVoy]

On Mon, Mar 13, 2023 at 04:48:04PM -0400, Paul Winalski wrote:
> On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
> >
> > Too many people try to "fix" programming languages, particularly academics
> > and folks working on a new PhD. Other folks (Gnu is the best example IMO)
> > want to change things so the compiler writers (and it seems like the Linux
> > kernel developers) can do something "better" or "more easily."  As someone
> > (I think Dan Cross) said, when that happens, it's no longer C. Without
> > Dennis here to say "whoa," - the committee is a tad open loop.   Today's
> > language is hardly the language I learned before the "White Book" existed
> > in the early/mid 1970s.  It's actually quite sad.   I'm not so sure we are
> > "better" off.
> 
> I'd rather see programming language standards committees restrict
> their activity to regularizing existing practice.  Let vendors and
> others innovate by adding non-standard extensions.  Then take those
> that are really useful and adopt them as part of the standard.  But
> the committee itself should not be doing design.  We all know what
> they say about "design by committee", and it's all too true.

I wish I had a magic wand and could upvote this more.  You are exactly
right, that is exactly what standards should do, maybe with a little
leeway to resolve conflicts between 2 good ideas, but no more than
that.

But ego gets involved and things go pear shaped.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[John Cowan]

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

On Mon, Mar 13, 2023 at 5:00 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

Dropping toxic features from a language does happen at standards
> committees, but it's rare.  The best case I know of where this
> happened was when the international standard for PL/I came out.  They
> started with IBM PL/I but then dropped a bunch of features that were
> either obsolete (e.g., sterling pictures) or downright dangerous
> (e.g., the DEFAULT statement).
>

That actually happened twice.  The 1976 standard removed features from IBM
PL/I; the 1981 Subset G standard removed even more features.  (A few were
added back in the 1987 revision of Subset G.)

> On the other side of the spectrum you have the BASIC standards
> committee.  BASIC has always had to live down a reputation that it's a
> "toy language" not suitable for "serious programming".  The standards
> committee seems to have suffered from an inferiority complex, and it
> seemed from my perspective that as fast as the PL/I committee chucked
> out toxic language, the BASIC committee adopted them.


There are two Basic standards as well: the smaller one came first.

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

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Dan Cross]

On Mon, Mar 13, 2023 at 6:47 PM Dave Horsfall <dave@horsfall.org> wrote:
>
> On Tue, 14 Mar 2023, Dave Horsfall followed himself up:
>
> > Trivia: I think it was OpenBSD that nobbled gets() to print a warning
> > whenever it was invoked :-)
>
> FreeBSD 10.4 (old, I know):
>
>     c.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] main()
>     ^~~~
>     c.c:2:3: warning: implicit declaration of function 'gets' is invalid in C99
>           [-Wimplicit-function-declaration]
>     { gets(); }
>       ^
>     2 warnings generated.
>     /tmp/c-36bc21.o: In function `main':
>     c.c:(.text+0x4): warning: warning: this program uses gets(), which is unsafe.
>     aneurin% ./c
>     warning: this program uses gets(), which is unsafe.
>     <CR>
>     aneurin%
>
> On the MacBook (10.13.6 High Sierra):
>
>     c.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
> main()
>     ^
>     c.c:2:3: warning: implicit declaration of function 'gets' is invalid in C99
>           [-Wimplicit-function-declaration]
>     { gets(); }
>       ^
>     2 warnings generated.
>     mackie:tmp dave$ ./c
>     warning: this program uses gets(), which is unsafe.
>     <CR>
>
>     And it core-dumped,,,

I should hope so! It takes a pointer to a buffer as an argument, and
it appears you elided that. :-D

> (I don't have access to my Penguin/OS lapdog right now.)
>
> I think that it's trying to tel me something :-)

gets: unsafe at any C.

        - Dan C.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Dan Cross]

On Mon, Mar 13, 2023 at 6:15 PM Dave Horsfall <dave@horsfall.org> wrote:
> On Mon, 13 Mar 2023, Dan Cross wrote:
> > Hey, they dropped `gets` from the standard library! Never say never.
>
> When did that finally happen?  Last I looked, gets() was still part of
> POSIX, and hence couldn't be dropped...

It was (finally!!) dropped from ISO C in C11.

It's a shame POSIX is keeping it around, but it appears you're right:
https://pubs.opengroup.org/onlinepubs/9699919799/

In fairness, this does say it may be removed from a later standard.

        - Dan C.

> Trivia: I think it was OpenBSD that nobbled gets() to print a warning
> whenever it was invoked :-)
>
> -- Dave

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Dave Horsfall]

On Tue, 14 Mar 2023, Dave Horsfall followed himself up:

> Trivia: I think it was OpenBSD that nobbled gets() to print a warning 
> whenever it was invoked :-)

FreeBSD 10.4 (old, I know):

    c.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] main()
    ^~~~
    c.c:2:3: warning: implicit declaration of function 'gets' is invalid in C99
	  [-Wimplicit-function-declaration]
    { gets(); }
      ^
    2 warnings generated.
    /tmp/c-36bc21.o: In function `main':
    c.c:(.text+0x4): warning: warning: this program uses gets(), which is unsafe.
    aneurin% ./c
    warning: this program uses gets(), which is unsafe.
    <CR>
    aneurin% 

On the MacBook (10.13.6 High Sierra):

    c.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main()
    ^
    c.c:2:3: warning: implicit declaration of function 'gets' is invalid in C99
	  [-Wimplicit-function-declaration]
    { gets(); }
      ^
    2 warnings generated.
    mackie:tmp dave$ ./c
    warning: this program uses gets(), which is unsafe.
    <CR>

    And it core-dumped,,,


(I don't have access to my Penguin/OS lapdog right now.)

I think that it's trying to tel me something :-)

-- Dave

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Alejandro Colomar (man-pages)]

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

On Mon, Mar 13, 2023, 21:27 Dan Cross <crossd@gmail.com> wrote:

> On Mon, Mar 13, 2023 at 3:16 PM Steve Nickolas <usotsuki@buric.co> wrote:
> > On Mon, 13 Mar 2023, Clem Cole wrote:
> > > Frankly, I'd probably rather see ISO drop a bunch of the stuff they
> are now
> > > requiring and fall back at least to K&R2 -- keep it simple. The truth
> is
> > > that we still use the language today is that K&R2 C was then (and
> still is)
> > > good enough and got (gets) the job done extremely well.    Overall,
> I'm not
> > > sure all the new "features" have added all that much.
> >
> > C99 did introduce one thing I use: <stdint.h>
> >
> > Beyond that, I still code strict C89.  I simply treat the language itself
> > as ossified.  I also still make assumptions about the compiler that might
> > not still be true, so for example
> >
> >   unsigned short a;
> >   unsigned char b;
> >
> >   b=0xFF;
> >   a=b<<8;
> >
> > I expect to return 0 even though the logical answer is 0xFF00,
>
> I don't know why one would expect that. `b` will be promoted to
> (signed!!) `int` before the shift, and then the result of that
> assigned to `a`, wrapping as needed to fit into the `unsigned short`;
> on most reasonable systems the UB gods won't be angered.
>

C23 will be adding new types that don't have this issue (default promotion
to in).  If a variable has 3 bits, it will have 3 bits (until you mix it
with a wider variable).

Another whole class of Undefined Behavior (in ISO C) or
implementation-defined behavior (K&R C) is 2's complement arithmetic which
has never been portable, until C23.  So it's not all bad.


> OTOH, `uint16_t mul(uint16_t a, uint16_t b) { return a * b; }` is a UB
> minefield on most systems.
>
> > and I
> > _always_ code it like this:
> >
> >   b=0xFF;
> >   a=b;
> >   a<<=8;
>
> Curiously, this will be subject to the same type promotion rules as
> the original.
>
> > or alternatively
> >
> >   b=0xFF;
> >   a=((unsigned short) b)<<8;
>
> As will this. In fact, the cast here is completely superfluous; the
> shift will still be done using after promotion to signed int.
>
> > and there's other defensive stuff I do.  I honestly don't see the point
> in
> > the other changes to the language and feel they take C away from what it
> > has always been.
>
> I think an issue is that there is what people _think_ C does, and what
> C _actually_ does, and the two are often discordant;


Indeed.  That's my feeling too.  When discussing about features that
programmers don't understand why they were added, it's rather often the
case that the feature has been there for longer than they thought (if not
since forever).

this is why I
> think you see people tweaking compiler options to create a dialect
> that's reasonable to program in: given a large-enough code base, you
> inevitably end up with a very peculiar dialect, which compounds the
> problem. For example, I'm quite sure that the C dialect that Linux
> uses is not the same as the C that Windows uses, and so on. The
> compiler writers now seem very much of the mind where you point this
> out and they look at you and say, "tough."
>

Even "safe" Rust is having its share of Undefined Behavior.  Let's see how
they deal with it.
<https://github.com/rust-lang/rust/issues/107975>


>         - Dan C.
>

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

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Dave Horsfall]

On Mon, 13 Mar 2023, Dan Cross wrote:

> Hey, they dropped `gets` from the standard library! Never say never.

When did that finally happen?  Last I looked, gets() was still part of 
POSIX, and hence couldn't be dropped...

Trivia: I think it was OpenBSD that nobbled gets() to print a warning 
whenever it was invoked :-)

-- Dave

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Paul Winalski]

On 3/13/23, Bakul Shah <bakul@iitbombay.org> wrote:
>
> You can't drop features from a widely deployed language;

It has been done, with advanced warning of the deprecation, and over
several iterations of the standard so that there's advanced warning.
But it's rare and not advisable.

But you can create new subsets of the full standard.

> but while
> we are dreaming, what I'd like to see is a total *ban* on any and
> all optimizations. What you get is what you see!
>
Be careful what you wish for.  That just won't fly on modern computer
architectures, with their many execution units and complicated memory
hierarchies.  Not if you want anything resembling reasonable
performance that is also maintainable.

-Paul W.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Dan Cross]

On Mon, Mar 13, 2023 at 5:08 PM Bakul Shah <bakul@iitbombay.org> wrote:
> On Mar 13, 2023, at 2:00 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
> >
> > On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
> >>
> >> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
> >> requiring and fall back at least to K&R2 -- keep it simple.
> >
> > I agree.  Every language has toxic features--things that seemed like
> > good ideas at the time but turn out to have been mistakes when they're
> > better understood.  Every good programming shop has its rules
> > concerning certain language features or practices that are not allowed
> > in the code, usually for safety or maintainability reasons.
>
> You can't drop features from a widely deployed language; but while
> we are dreaming, what I'd like to see is a total *ban* on any and
> all optimizations. What you get is what you see!

Hey, they dropped `gets` from the standard library! Never say never.

        - Dan C.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Bakul Shah]

On Mar 13, 2023, at 2:00 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
>> 
>> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
>> requiring and fall back at least to K&R2 -- keep it simple.
> 
> I agree.  Every language has toxic features--things that seemed like
> good ideas at the time but turn out to have been mistakes when they're
> better understood.  Every good programming shop has its rules
> concerning certain language features or practices that are not allowed
> in the code, usually for safety or maintainability reasons.

You can't drop features from a widely deployed language; but while
we are dreaming, what I'd like to see is a total *ban* on any and
all optimizations. What you get is what you see!

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Paul Winalski]

On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
>
> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
> requiring and fall back at least to K&R2 -- keep it simple.

I agree.  Every language has toxic features--things that seemed like
good ideas at the time but turn out to have been mistakes when they're
better understood.  Every good programming shop has its rules
concerning certain language features or practices that are not allowed
in the code, usually for safety or maintainability reasons.

Dropping toxic features from a language does happen at standards
committees, but it's rare.  The best case I know of where this
happened was when the international standard for PL/I came out.  They
started with IBM PL/I but then dropped a bunch of features that were
either obsolete (e.g., sterling pictures) or downright dangerous
(e.g., the DEFAULT statement).

On the other side of the spectrum you have the BASIC standards
committee.  BASIC has always had to live down a reputation that it's a
"toy language" not suitable for "serious programming".  The standards
committee seems to have suffered from an inferiority complex, and it
seemed from my perspective that as fast as the PL/I committee chucked
out toxic language, the BASIC committee adopted them.  The result is a
bloated, grotesque monstrosity that little resembles the simple, clean
Dartmouth BASIC 6 that was the first programming language I learned
(from the DTSS TEACH command).

-Paul W.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Bakul Shah]

In hindsight Algol68 may have been the last committee designed
language that was good. It got a lot of flack back then but its
imperfections seem tiny in comparison to most of the languages
designed since then.

> On Mar 13, 2023, at 1:48 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> I'd rather see programming language standards committees restrict
> their activity to regularizing existing practice.  Let vendors and
> others innovate by adding non-standard extensions.  Then take those
> that are really useful and adopt them as part of the standard.  But
> the committee itself should not be doing design.  We all know what
> they say about "design by committee", and it's all too true.
> 
> Programming language standards committees also tend to suffer from
> what I call the "dog and fire hydrant" problem.  The committee members
> are like a pack of dogs, with the standard being the fire hydrant.
> Each dog doesn't consider the fire hydrant "theirs" until they've
> pissed on it.  Programming languages get treated the same way by
> standards committee members.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Paul Winalski]

On 3/13/23, Clem Cole <clemc@ccc.com> wrote:
>
> Too many people try to "fix" programming languages, particularly academics
> and folks working on a new PhD. Other folks (Gnu is the best example IMO)
> want to change things so the compiler writers (and it seems like the Linux
> kernel developers) can do something "better" or "more easily."  As someone
> (I think Dan Cross) said, when that happens, it's no longer C. Without
> Dennis here to say "whoa," - the committee is a tad open loop.   Today's
> language is hardly the language I learned before the "White Book" existed
> in the early/mid 1970s.  It's actually quite sad.   I'm not so sure we are
> "better" off.

I'd rather see programming language standards committees restrict
their activity to regularizing existing practice.  Let vendors and
others innovate by adding non-standard extensions.  Then take those
that are really useful and adopt them as part of the standard.  But
the committee itself should not be doing design.  We all know what
they say about "design by committee", and it's all too true.

Programming language standards committees also tend to suffer from
what I call the "dog and fire hydrant" problem.  The committee members
are like a pack of dogs, with the standard being the fire hydrant.
Each dog doesn't consider the fire hydrant "theirs" until they've
pissed on it.  Programming languages get treated the same way by
standards committee members.

-Paul W.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Dan Cross]

On Mon, Mar 13, 2023 at 3:16 PM Steve Nickolas <usotsuki@buric.co> wrote:
> On Mon, 13 Mar 2023, Clem Cole wrote:
> > Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
> > requiring and fall back at least to K&R2 -- keep it simple. The truth is
> > that we still use the language today is that K&R2 C was then (and still is)
> > good enough and got (gets) the job done extremely well.    Overall, I'm not
> > sure all the new "features" have added all that much.
>
> C99 did introduce one thing I use: <stdint.h>
>
> Beyond that, I still code strict C89.  I simply treat the language itself
> as ossified.  I also still make assumptions about the compiler that might
> not still be true, so for example
>
>   unsigned short a;
>   unsigned char b;
>
>   b=0xFF;
>   a=b<<8;
>
> I expect to return 0 even though the logical answer is 0xFF00,

I don't know why one would expect that. `b` will be promoted to
(signed!!) `int` before the shift, and then the result of that
assigned to `a`, wrapping as needed to fit into the `unsigned short`;
on most reasonable systems the UB gods won't be angered.

OTOH, `uint16_t mul(uint16_t a, uint16_t b) { return a * b; }` is a UB
minefield on most systems.

> and I
> _always_ code it like this:
>
>   b=0xFF;
>   a=b;
>   a<<=8;

Curiously, this will be subject to the same type promotion rules as
the original.

> or alternatively
>
>   b=0xFF;
>   a=((unsigned short) b)<<8;

As will this. In fact, the cast here is completely superfluous; the
shift will still be done using after promotion to signed int.

> and there's other defensive stuff I do.  I honestly don't see the point in
> the other changes to the language and feel they take C away from what it
> has always been.

I think an issue is that there is what people _think_ C does, and what
C _actually_ does, and the two are often discordant; this is why I
think you see people tweaking compiler options to create a dialect
that's reasonable to program in: given a large-enough code base, you
inevitably end up with a very peculiar dialect, which compounds the
problem. For example, I'm quite sure that the C dialect that Linux
uses is not the same as the C that Windows uses, and so on. The
compiler writers now seem very much of the mind where you point this
out and they look at you and say, "tough."

        - Dan C.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Steve Nickolas]

On Mon, 13 Mar 2023, Clem Cole wrote:

> Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
> requiring and fall back at least to K&R2 -- keep it simple. The truth is
> that we still use the language today is that K&R2 C was then (and still is)
> good enough and got (gets) the job done extremely well.    Overall, I'm not
> sure all the new "features" have added all that much.

C99 did introduce one thing I use: <stdint.h>

Beyond that, I still code strict C89.  I simply treat the language itself 
as ossified.  I also still make assumptions about the compiler that might 
not still be true, so for example

  unsigned short a;
  unsigned char b;

  b=0xFF;
  a=b<<8;

I expect to return 0 even though the logical answer is 0xFF00, and I 
_always_ code it like this:

  b=0xFF;
  a=b;
  a<<=8;

or alternatively

  b=0xFF;
  a=((unsigned short) b)<<8;

and there's other defensive stuff I do.  I honestly don't see the point in 
the other changes to the language and feel they take C away from what it 
has always been.

-uso.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Larry McVoy]

> Dennis without here to say "whoa," - the committee is a tad open loop.   

Having someone who can say "no" is critical to any software project.  What
doesn't go in is easily way more important than what does go in.  You can
surround a really great idea with enough crap that all you really get is
crap.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Clem Cole]

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

On Mon, Mar 13, 2023 at 12:00 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> ... The committee's goal is to standardize existing practice of the
> language
> in a way that is implementable on the widest range of hardware and OS
> platforms, *and to provide a controlled way to add language extensions.*

Ah, the problem, of course, is right there.

Too many people try to "fix" programming languages, particularly academics
and folks working on a new PhD. Other folks (Gnu is the best example IMO)
want to change things so the compiler writers (and it seems like the Linux
kernel developers) can do something "better" or "more easily."  As someone
(I think Dan Cross) said, when that happens, it's no longer C. Without
Dennis here to say "whoa," - the committee is a tad open loop.   Today's
language is hardly the language I learned before the "White Book" existed
in the early/mid 1970s.  It's actually quite sad.   I'm not so sure we are
"better" off.

Frankly, I'd probably rather see ISO drop a bunch of the stuff they are now
requiring and fall back at least to K&R2 -- keep it simple. The truth is
that we still use the language today is that K&R2 C was then (and still is)
good enough and got (gets) the job done extremely well.    Overall, I'm not
sure all the new "features" have added all that much.
ᐧ

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

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Paul Winalski]

On 3/13/23, Alejandro Colomar <alx.manpages@gmail.com> wrote:
>
> Well, it depends on what you call "C".  There are many dialects,
> and I'm not sure there's any which I'd call "C".
>
> The 3 main dialects are "ISO C", "GNU C", and "K&R C".  And then
> there are subdialects of them.  We could say "C" is "ISO C", since,
> well, it's _the_ standard.

Note that the goal of a programming language standards committee is
very different from the goal of those who use the language.  The
committee's goal is to standardize existing practice of the language
in a way that is implementable on the widest range of hardware and OS
platforms, and to provide a controlled way to add language extensions.

The goal of users is to get their job done.

The advantage of programming in strict ISO C is that the resulting
code will run just about anywhere.  If you don't care about that (and
I'd wager most programmers don't) then ignore the standard.

> But then, ISO C shares the aliasing
> issues that GNU C has, so by avoiding the GNU C compiler you're
> not avoiding the issues we're talking about; moving to a compiler
> that only talks ISO C is going to keep the issues.  You'll need
> a compiler that talks K&R C, or some other dialect that doesn't
> have aliasing issues.

As someone pointed out, the three things that most programmers value
are execution speed, execution speed, and execution speed.  Aliasing
issues greatly hamper what a modern optimizing compiler can do and
still generate semantically correct code.

> At that point, since you already need a subdialect of C, GCC is
> one such compiler, since it provides a comprehensive set of flags
> to tune your dialect.

All the best commercial optimizing compilers do that these days.  It's
a way of having your semantic cake and being able to eat it (fast
execution speed), too.

-Paul W.

[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Dan Cross]

On Mon, Mar 13, 2023 at 8:43 AM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
> On 3/13/23 13:19, Dan Cross wrote:
> > On Mon, Mar 13, 2023 at 6:41 AM Alejandro Colomar (man-pages)
> > <alx.manpages@gmail.com> wrote:
> >> Or you can ask GCC to respect your view of the language with things like -fno-strict-aliasing, -fwrapv, and -fno-trapv.
> >
> > The problem that is that you are then no longer programming in "C",
> > but rather some dialect of "C" that happens to share the same syntax,
> > but with different semantics. That may be fine, or it may not, but it
> > can lead to all sorts of footgun traps if one is not careful.
>
> Well, it depends on what you call "C".  There are many dialects,
> and I'm not sure there's any which I'd call "C".

That's precisely the problem. :-)

        - Dan C.


> The 3 main dialects are "ISO C", "GNU C", and "K&R C".  And then
> there are subdialects of them.  We could say "C" is "ISO C", since,
> well, it's _the_ standard.  But then, ISO C shares the aliasing
> issues that GNU C has, so by avoiding the GNU C compiler you're
> not avoiding the issues we're talking about; moving to a compiler
> that only talks ISO C is going to keep the issues.  You'll need
> a compiler that talks K&R C, or some other dialect that doesn't
> have aliasing issues.
>
> At that point, since you already need a subdialect of C, GCC is
> one such compiler, since it provides a comprehensive set of flags
> to tune your dialect.
>
> Or you could move to a compiler that talks its own dialect
> (probably some subdialect of K&R C, as I expect Plan9 C is, but
> I never tried it).  But that's not much different from asking
> such dialect to GCC.
>
> Cheers,
>
> Alex
>
> >
> >         - Dan C.