On 31/10/2019 17:38, Rick C. Hodgin wrote:
On Thursday, October 31, 2019 at 11:37:08 AM UTC-4, james...@alumni.caltech.edu wrote:
On Wednesday, October 30, 2019 at 9:29:28 PM UTC-4, Rick C. Hodgin wrote: >>> This is what I'm talking about with the C committees being reaction-
ary rather than visionary. They don't move in ways that make sense.
They move trailing others who are moving in ways they think makes
sense, effectively codifying what's seen in the real world.
It should be more than that. The C committee should be steering.
Once something has been standardized, it's extremely difficult,
bordering on the impossible, to remove it if it later turns out to have
been a mistake.
Deprecation is wide-spread in every language I've ever used. Even
in Java used for mobile Android development.
A very important feature of C as a language is that it does /not/
deprecate anything without very good reason. C does not gain new
features easily - and it loses features even more reluctantly. This is
both a benefit and a limitation - but the C community (compiler vendors, programmers, and standards committee) have taken the view that C is to
be a stable language. This means - unlike many other languages - you
can take old C code, compile it with a new C compiler (on a platform
that didn't exist when the code was written), and have a good chance of everything working correctly. The disadvantage is that the language
does not gain much in the way of new features - C is what it is, and
your choice is to accept that or find a different language.
I have personally made updated versions of C programs I wrote over
twenty years ago, and the language still works the same on modern tools.
From the C99 Rationale:
"""
The Committee is content to let C++ be the big and ambitious language.
While some features of C++ may well be embraced, it is not the
Committee’s intention that C become C++.
"""
Indeed, I'd recommend reading the entire introduction to the C99
Rationale to get an idea of how C changes.
It is expected that things will migrate / morph over time as newer
and better and different technologies, abilities, features, or what-
ever the cue is, change, that the tools used previously can still
be used if you want those older features, but if you want to move
forward some features need to be faded out.
That is common, but not necessary - and while it is often not a problem,
it is not always desirable. That is why there is a place for a stable
language like C, as well as more innovative and faster-changing languages.
"auto" is a prime example of this. Therefore, the
committee generally prefers not to standardize a new feature until after
it has been successfully implemented and put to use as an extension, so
they can get a better idea of whether or not it can work. As a result, C
is generally steered by the implementors, who in turn are often pushed
by their users, rather than being steered by the committee. I don't see
this as a particularly bad thing.
That's what I disagree with. C should be a steering committee,
as well as a codifying body.
The C community as a whole disagrees with you. You may want a more
top-down for your own languages (and top-down has its benefits too), but
that is not the way C works.
I think your fundamental problem with this process is not who's doing
the steering, but rather the fact that the people who are doing the
steering are, in general, too competent, sane, and wise to steer the
language in the directions you want it to go (which is not to say that
they're unusually competent, sane, or wise).
It's that there is a direction C needs to go.
Why? C is fine as it is, receiving mostly just small fixes or improvements.
It needs the class.
No, it does not. That would give you a different language. There are
already plenty of languages that are a bit like C, but have classes -
there is no need for C to become one of them.
It needs to have an option to tighten up type checking. It needs
some relaxations like not requiring the keyword struct on refer-
ences, single-line comments, anonymous unions, and I think the 2nd
biggest feature: should not REQUIRE forward declarations. The
compiler should be allowed to morph into an n-pass compiler where
unresolved forward declarations can be set aside on pass 0, and
then become resolved for pass 1.
Single-line comments were added in C99, and anonymous unions moved from
a very common extension to standard in C11. Surely it is a good idea to
learn what the C language and the C standards say, before criticising it?
To me, these are absolutely fundamental aspects of the nature of
the language.
Then you are not talking about C. They may well be features you like to
see in programming languages - everyone has their own preferences and
opinions. But you cannot call them "absolutely fundamental aspects of
the nature of the language", given that the C language has been in heavy
use for about 50 years and does not have these features!
It calls out for it by its own voice, and not even
by my direction. When I sit back and look at what a C-like pro-
gramming language needs, this is what IT tells me.
This is all your personal opinion and preferences, nothing more. If you
feel that strongly, then use a different programming language that has
the features you want, not C. You can't blame C for not being the
language you want to use - that's just silly. It's like blaming an
apple pie for not tasting chocolaty when chocolate cake is your favourite.
That's why C++ was able to give "auto" a new meaning, one that probably >>>> broke your code when you compiled it in C++.
There was no code. It was a fictitious example conjured up to
prove a point. It would work with any keyword that was later
added to the language.
With the exception of "restrict" all new keywords since C99 have been
chosen from the name space reserved for implementations. It looks like "restrict" is not only the best example you could use, but also probably
the only one. The addition of the other keywords has not broken any
existing strictly conforming code, belying your claim that such breakage
is inevitable.
Then use restrict as the example to prove my point.
Deprecation exists for a reason. You cycle it out 2 or 4 or n
generations, allowing it to be used all that time with the flag
that it's been deprecated, and then remove it. That gives all
actively software projects / developers plenty of time to make
the changes. And those that aren't actively developed still run
their old binary code just like always.
It's a different philosophy of use, a different vision I have
for C and C++. It's why CAlive will be successful. Many devel-
opers out there have the same wishes I do, they just don't real-
ize it yet because all they have is what they've been given.
But you can look at several new programming languages lately
and the features they incorporate and you can see I'm no alone
in this vision. My goals are just to keep it closer to C than
other goals. I want CAlive to compile existing C code with zero
changes and no errors when using a compatibility mode. It will
just do so with the CAlive LiveCode (edit-and-continue) features,
as well as new ABI features like the inquiry, and several others.
C will be relegated to niche areas increasingly as time goes on.
Odd - C has existed for 50 years or so, and is still hugely popular and important. Most other languages either remain niche, or are popular for
a few years before fading away. Your claims are completely disconnected
from reality.
Other languages running on today's incredibly fast hardware, are
sufficient for 99% of apps. And in those cases where developers
want more, they won't want to stay at C's low level.
No one has ever suggested that C is the best language choice for all
use. Most people use C for coding problems that suit C, and other
languages for coding problems best solved in other languages.
And they
won't want to learn C++'s endless features and nuances to write
clean, efficient C++ code.
One of the few challengers to C for a long-lived and endlessly popular language, is C++.
They want something simple, useful,
powerful, flexible, easy to develop in/for, easy to update and
maintain, etc.
People who want that, use other languages. There are lots to choose from.
Enter CAlive's direct target / goals / focus,
coupled also to a faith in Christ applied to the product and its
license, bringing the reality of God back into our daily lives,
yes even our programming lives. *GASP!* Yes, we are supposed
to have God active in ALL areas of our lives, not just at a
church on Sundays and Tuesdays for Bible Study. All the time He
is to be maintained AHEAD of all of our efforts, including every-
thing we do day-in / day-out.
If that's what you want, that's fine for /you/ - and anyone who shares
your opinions and preferences. But it does not mean there is something
wrong with C (or any other language).
CAlive is coming into existence for a reason. And oh how I wish
those associated with C would've been more accommodating to new
ideas, having a vision, pushing forward rather than following be-
hind. It would've saved me years of work.
Did it never occur to you that no one who works with C was interested in
any of your ideas? An idea being "new" does not automatically make it a
good idea - and even an idea that is good for some programming languages
is not automatically good for other languages. I have heard countless
ideas from you over the years, and there were barely two or three that I
ever thought had useful potential for any programming language - none
that made sense for C. (There were more that could have been turned
into good ideas, had you been open to discussion.) If you think your
ideas will let you build a wonderful new language "CAlive", then great -
go for it. But please cut out the delusion that you alone know what is
good for C.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)