Niall, we disagree on a lot of things, but in this I agree with you!

I am pretty sure some WG14 members don't think like we do even now though,
so this is my two cents/pence.

For me, C has basically 3 pillars that make it what it is.
You hit one:
1) Base ABI for everything.

I see two others:
2) What You See Is What You Get (macros notwithstanding). C code can be
*read* easily and understood almost 1-1 to your machine language, whatever
that happens to be. (Ex. No auto, no namespaces, no templates generating
code you don't see)
- This gives rise to simplicity of compilers which explains why there are
hundreds of C compilers, from one-pass to multi-pass, simple translators,
to beasts that do static and dynamic analysis, etc., and rarely so many
compilers for other langauges
- Makes it perfect for the embedded world where there are no surprises
like exceptions causing stack unwinding to callers who had no idea there
could be a return that way.
3) Backwards compatibility (Existing C code will continue to work 10, 20,
100 years from now).
- This gives rise to a large body of C code that keeps it in the top 3 on
TIOBE for years. It lets people invest in C and not be worried.

Of course all of these pillars are under attack regularly and things
change, but that's my view of some of the "uniqueness" and "value
proposition" of C that may be a part of what Bjarne was looking for.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta_at_[hidden]

IBM



From: Niall Douglas via Liaison <liaison_at_[hidden]>
To: liaison_at_[hidden]
Cc: Niall Douglas <s_sourceforge_at_[hidden]>
Date: 08/13/2020 09:05 AM
Subject: [EXTERNAL] Re: [wg14/wg21 liaison] Designated initializers
in C++ and C
Sent by: "Liaison" <liaison-bounces_at_[hidden]>



On 13/08/2020 14:19, Bjarne Stroustrup via Liaison wrote:

> People talk about C's "separate identity" and (as above) C "has
> different use cases, and serves a different group of users" from C++. I
> have never seen C's separate identity clearly articulated, nor have I
> seen articulation of fundamental reasons for there being separate use
> cases. Such articulation might simplify the discussions about which
> incompatibilities are deliberate and essential and which are accidental.

With respect, I think you are looking at C all wrong. You're thinking in
terms of one programming language amongst many to be compared against
other programming languages as equals.

However no language is equal to C: C is the bedrock which anchors all
other programming languages. It defines the lingua franca for all
programming languages everywhere - if you want Python to talk to Rust,
it does so via C. It defines what CPUs are and do, and increasingly GPUs
as well. This is because it defines what memory is, how it is to be
addressed, how success and failure are to be communicated, what a basic
block is and how logic describes dispatch amongst those. If, for
example, C changes the definition of a pointer, that change affects
every C speaking and C implemented programming language everywhere. It
also affects all CPUs and GPUs to be designed. C is enormously,
terrifyingly, powerful and important.


I completely agree that this didn't used to be the case. For a decade or
two after C other programming languages could define their own rules, do
their own thing, define their own abstract machines. However, when CPU
designers started to design hardware around a C-like abstract machine,
the ground shifted: today's new programming languages start out a priori
assuming a C foundation, and then embrace or reject from there. LLVM is
utterly embedded into a C assuming abtract machine - every language
implemented using LLVM therefore is so as well. This has caused
originally non-C-orientated languages such as Erlang or Haskell to have
become ever more C-flavoured over time. Their adherents don't like this
at all, but if they want the LLVM shiny new toys, that's the price of
admission.

I hate to put this so bluntly, but "C has won" the contest of "what
ought all software assume about the hardware, and hardware about the
software". In this, it has been enormously and tremendously successful,
and much of C++'s initial and ongoing success is due to C source
compatibility.


So what then about the future? Me personally, I'd like C to become like
the POSIX of all other programming languages: standardisation of the
portable common aspects of all programming languages, CPUs, and GPUs.

To that end, those parts of C++ which are extremely useful to all other
programming languages ought to be merged from C++ into C. Same goes for
Rust, Erlang, Haskell, whatever.

And I don't think C should become a working group of WG21. If anything,
I think WG21 ought to become a working subgroup of WG14. That's how
important C is, and could become very much more so, if properly
resourced and placed in the correct exalted position it ought to be in,
for the global industry's benefit.

I appreciate that my opinion above will be shared by nobody else here.
And probably considered ridiculous by many. Still, I dream, and I would
urge WG14 to have the ambition to recast their future role into a more,
not less, ambitious standardisation proposition.

Niall
_______________________________________________
Liaison mailing list
Liaison_at_[hidden]
Subscription:
https://lists.isocpp.org/mailman/listinfo.cgi/liaison

Link to this post:
http://lists.isocpp.org/liaison/2020/08/0194.php