Hi all,

I agree about the importance of C and also with all the advantages
mentioned by Rajan. C is a minimalistic language and this is one
which brings many advantages. C++ obviously is not minimalistic
but rather complex (and also not WYSIWYG) and these differences
stem from different philosophies. Bjarne seems to think you can
have both at the same time, a minimalistic language and a rather
complicated one on top of it. That maybe be true in theory,
but to me it seems hard how the differences between the two
philosophies could be reconciled, as these philosophies
influence the design of language features
(see VLAs vs std::vector).

It is also the minimalistic language which is at risk here,
because once you add complicated features, you can not
get the simplicity back without breaking backwards
compatibility.

Quite frankly, I also do not see many C++ features (or other
features) which i think should be added to C.
C is mostly fine as it is, we should try to polish the
rough edges, make the specification clearer, work on
a sound (and formalizable) memory model, etc.
Yes, also improving compatibility with C++ if easily
possible. Maybe - very carefully - we could add some
features where existing practice indicates an important
need (e.g. existing widely used extensions), or we
the existing design of C is incomplete and can be
extended in a natural and coherent way. In particular,
this implies that we should work with the existing
logic of C when adding/extending features and not
simply integrate features from C++.

(more comments below)

Am Donnerstag, den 13.08.2020, 20:40 +0100 schrieb Niall Douglas via Liaison:
> On 13/08/2020 16:09, Rajan Bhakta via Liaison wrote:
>
> > Niall, we disagree on a lot of things, but in this I agree with you!
>
> It pleases me that we have actually found something substantial to agree
> upon. As you mention, very rare in our case!
>
> > I see two others:
>
> Yeah, I really have to disagree on these ...
>
> > 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)
>
> I know we've disagreed on this in the past, but to restate my position
> on this, there is in my opinion a yawning and ever growing gulf between
> C source code and the implementation. As a rough schematic:
>
> 1. The C compiler rewrites your C source code to your compiler's choice
> of interpretation of the C abstract machine for some target architecture.
>
> 2. The CPU rewrites the assembly opcodes to your CPU vendor's choice of
> interpretation of the architecture abstraction machine for some target
> silicon.
>
> 3. The target silicon is increasingly a stochastic stream computer which
> pseudo-emulates a PDP 11 with a floating point extension. In this,
> modern general purpose CPUs are becoming ever closer to GPUs, which are
> also increasingly emulating a PDP 11 so C targeting software runs well
> on them.

Interesting perspective, but I think WYSIWYG is relative to the
abstract machine (and I agree with Rajan, that this is an important
property of C).

It is true that the we now have a tower of abstractions maintained
in modern computer architecture. I would like to point out that the
C abstract machine is more abstract then what is provided by the CPU,
so not directly what it is targeted by them.

These abstractions - which are required to construct complex
systems - evolved over time and are extremely successful. People
experimented with a lot of different way to do things and
the abstractions we have now were the ones which were successful.
I do not think that this is only by change, but because these
abstractions do work in practice - even for parallel programming,
vector or stream computing.

Maybe there are better ways to do things, but I do not know any
(and I looked at quite a few).

Some notation for vector operations on arrays could be useful,
but with auto-vectorization this seems more for convenience than
necessity.

I also think atomics are broken (but fixable) and "it has to
work like C++" may have been part of the problem here
(not that it is impossible to make it work identically
in both languages, but the current design is not ideal
for C).

Best,
Martin


> Personally speaking, I don't find that C++ adds much to that gulf in
> aggregate, at least if you don't choose to write in obfuscated C++.
> Modern software and hardware is just layers upon layers of emulation.
> Same as your IBM mainframes Rajan!
>
> Me personally speaking, I think that when Moore's Law eventually goes
> completely linear, finally there will be incentive to design a
> programming language that maps to the bare metal of a stream processor.
> This will unlock perhaps thirty years of further exponential improvement
> in computer efficiency as software gets increasingly rewritten into the
> new abstraction. But I suspect all that will belong to a younger
> generation than any of us.
>
> > - 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.
>
> C++, especially as the safety critical folk gain more traction, will
> continue to eat C's lunch on this. And that's a good thing: a subset of
> C++ which is fully compatible with C++, but which avoids footguns you
> don't get in C, is an explicit goal for MISRA and many other folk.
>
> From the other end of things, Rust probably will eat some of C's lunch
> here too. I don't see many *major* projects genuinely considering a
> transition from modern C++ into Rust, but I have seen some genuinely
> considering a transition from C or legacy C++ into Rust.
>
> > 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.
>
> I know you'll disagree, but I think you overestimate this. I know of
> plenty of C code which once used to work, but does not on modern
> systems, whether due to compiler changes or hardware changes. Correctly
> written code shouldn't do this of course, but there is also plenty of C
> code which was very efficient on the hardware of the 1990s, and is now
> hideously inefficient on current hardware. I, personally, have rewritten
> bits of code last touched in 1992 and yielded 500x performance gains
> with very little work (tip: don't chase long sequences of pointer
> indirection chains!).
>
> In my opinion, all software is like a broom: it wears out over time, and
> requires constant renewal and replacement to remain fit for use. This is
> due to the ever shifting foundations upon which everything is built.
>
> 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/0196.php