Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.std.c |
| Subject | Re: Addition of nocode keyword |
| Date | 2019-10-31 19:50 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <qpfadc$q2o$1@dont-email.me> (permalink) |
| References | (8 earlier) <qpaiee$7fr$1@dont-email.me> <1fe7bd3f-1dc4-4fd6-b222-e59868ce1f56@googlegroups.com> <qpdddi$ipb$1@dont-email.me> <f5c12616-5c33-443a-a3a7-a6c1cdd41c4a@googlegroups.com> <64635a7b-9c3b-4b14-8d0f-341ca1ebe82f@googlegroups.com> |
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.
Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 05:26 -0700
Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2019-10-25 15:53 +0200
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 07:26 -0700
Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2020-08-04 11:00 +0200
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 11:04 -0700
Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-25 23:42 +0100
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 22:20 -0400
Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-26 22:52 +0100
Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-26 23:27 +0100
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-26 17:19 -0700
Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-25 22:10 -0300
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 19:02 -0700
Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-28 23:45 -0400
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 08:15 -0400
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 08:42 -0400
Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-29 22:37 -0400
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:10 -0700
Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 18:45 +0200
Re: Addition of nocode keyword Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2019-10-28 10:42 +0100
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-28 18:13 -0700
Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 02:55 +0000
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 07:58 -0400
Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 20:21 +0000
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 13:31 -0700
Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-29 14:47 -0700
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 19:36 -0400
Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-29 22:13 -0400
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:03 -0700
Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 09:48 +0100
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:13 -0700
Re: Addition of nocode keyword Keith Thompson <kst-u@mib.org> - 2019-10-30 08:40 -0700
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 09:44 -0700
Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 18:30 +0100
Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-30 08:12 -0700
Re: Addition of nocode keyword Nick Bowler <nbowler@draconx.ca> - 2019-10-30 16:47 +0000
Re: Addition of nocode keyword James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-30 13:30 -0400
Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 18:37 +0100
Re: Addition of nocode keyword Nick Bowler <nbowler@draconx.ca> - 2019-10-30 18:34 +0000
Re: Addition of nocode keyword Keith Thompson <kst-u@mib.org> - 2019-10-31 10:14 -0700
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 21:29 -0400
Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-31 08:37 -0700
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-31 09:38 -0700
Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-31 19:50 +0100
Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2020-08-04 11:18 +0200
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-11-01 07:20 -0700
Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 23:46 +0000
Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 21:41 -0400
Re: Addition of nocode keyword guinness.tony@gmail.com - 2019-10-30 04:36 -0700
Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-31 00:19 +0000
Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-29 14:32 +0100
Re: Addition of nocode keyword Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2019-10-29 17:41 +0100
Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-29 23:24 +0100
csiph-web