While many other languages have rapid development, such as Python, which has come out with a whole new version in the past few years, or to use a framework, Rails, which evolves super-fast (A book that was published in early 2011 is now obsolete), it seems that there are no updates for C. Why is this?
7
-
4Related: Why hasn't a faster, “better” language than C come out? & When to use C over C++, and C++ over C?– yannisApr 1, 2012 at 12:56
-
2because people who still use c don't want to upgrade (partial sarcasm).– KevinApr 2, 2012 at 1:54
-
2I don't see this as a real question, since there have been three C standards, in 1989/90, 1999, and 2011, and numerous offshoot languages.– David ThornleyApr 2, 2012 at 15:49
-
6You know, I don't see things like "A book that was published in early 2011 is now obsolete" as a virtue; if a language or framework is evolving that quickly, then there's a problem somewhere.– John BodeApr 2, 2012 at 15:55
-
2Industry needs standardized languages that do not become obsolete from one version to another...– NikkoApr 2, 2012 at 16:08
|
Show 2 more comments
5 Answers
There was a new revision of the C standard just a few months ago (C11, ratified 8th December 2011). I wouldn't be surprised if all of the latest releases of the GNU C compiler slightly modifies the lanuage it accepts (add and remove language extensions, possibly add more C11 features, possibly remove support for ancient cruft). True, that's slow, incremental changes rather than a revolution, but the language still evoles.
But apart from that, C is quite old - it had more than enough time to be refined. C as it is now is pretty close to what the language is intended to be: A super-simple, ultra-portable, low-overhead, extremely stable [in a backwards combability sense] system programming language. There have been some attempts to re-invent sytem programming (such as D, Go, and the much more obscure BitC) but they all drop some of C's goals - most importantly backwards combability - and are sufficently different to stop light-hearted adoption.
-
1In addition to latest standards, there are also non-standard additions being introduced and proposed for merger back into the standard version, like Apple's blocks extension.– user4051Apr 1, 2012 at 14:46
A new standard for the C programming language (C 2011) was ratified just a few months ago, and has some significant additions over the previous version (such as a built-in threading library).
Previous standards were released in 1999 and 1989.
It takes WG14 a while to agree on a new standard for the following reasons:
There's over 40 years' worth of legacy code running out there, and the standards committee is understandably reluctant to break any of it;
There's a very large and varied community of C implementors and users, and keeping everybody happy isn't easy;
There's a desire to avoid creeping featuritis -- C's major virtue is its relative ease of implementation, and tacking on too many doo-dads may make implementation difficult (indeed, the addition of variable-length arrays in C99 caused some consternation, and IINM are now optional under the 2011 standard);
Say what you will about the virtues of Java and C#, but at least C reference manuals don't require a forklift to carry.
-
The way to avoid creeping featuritis would be to recognize a concept of a "Selectively-Conforming" program--one which uses optional features or guarantees. Implementations would be allowed (and required!) to reject any program that uses features their authors do not wish to support. The fact that some implementations would have trouble usefully implementing a feature is a strong argument against making it mandatory, but should not be an argument against defining it as an optional feature.– supercatMay 28, 2016 at 17:18
-
Implementers could ignore features that users aren't interested in, so the cost of adding a feature that nobody ends up using would be minimal; if ignoring a feature would make an implementation incapable of running popular programs, that would suggest that the feature would have enough value to be worth implementing.– supercatMay 28, 2016 at 17:21
There is a point which is missing in the current answers:
Stability is a virtue for any production programming language. C is standardized not only in its syntax, but also in its ABI, which allows other system to easily call dlls compiled from c code. Try to do the same with c++: you will see that you will have to implement one interface for each existing compiler. This is only possible because the language is very stable.
This is why python 3 new features developpement was frozen at some point: in order to gain serious adoption you need to have stability, because shops will want to keep existing source code while upgrading their toolchains.
At this point c is probably one of the more stable language out there, and this is a good thing.
EDIT
More details about my opinion on stable languages: When a given language is stable AND used by some known projects AND actively maintained, you are pretty sure that the implementation is solid. If new features are continously added, you are not sure that they have received enough testing simply because time has not allowed QA to happen. Most of the time the last cornercases and bugs will be found by users pushing an implementation to its limits by using it on several platforms and in different contexts. Time allows the maintainers to fix the bugs they want to fix and document the other ones.
answered Apr 2, 2012 at 9:06
-
3Actually, there is no ISO standardized ABI for C. There are platform ABI's, but that can equally be said for C++. The only difference is that more platforms have a C ABI, in particular MS Windows.– MSaltersApr 2, 2012 at 13:10
-
Also, the Python Language Moratorium in Python 3.x was not intended to ease adoption of the language by programmers/shops - it'd be the wrong tool for that job, as post-3.0 Python releases are once again fully backwards-compatible! And as the "rationale" section states, it was intended to help other language implementations and distributors catch up. Moreover, you're out of date - the "moratorium" ended with the release of Python 3.2 (Feb. 2011); 3.3 is coming this summer and has language changes (such as
yield from).– user7043Apr 2, 2012 at 14:36 -
@delnan Thank you for your comment. I have corrected the python3 freeze part. Still, an important purpose of the python 3 moratorium was to focus on python 3 adoption (as stated in the link you provide) by working on bugfixes and STL improvements. Apr 2, 2012 at 14:40
-
Where does it state that? As I said, this makes little to no sense (at least the way you put it in your answer) because Python 3.0 code should run unmodified under Python 3.{1,2,3} and future 3.x versions.– user7043Apr 2, 2012 at 14:51
-
1
As it is expected that Python 2.7 be the effective "end of life" of the Python 2.x code line, with Python 3.x being the future, it is in the best interest of Python core development to temporarily suspend the alteration of the language itself to allow all of these external entities to catch up and to assist in the adoption of, and migration to, Python 3.xApr 2, 2012 at 15:00
C was developed with systems programming in mind, a more useable assembler. For this application C is widely usee in e.g. embedded programming. A lot of new application areas for programming have emerged, e.g. the web. New programming languages emerged more suitable for these new application areas, limiting the need for C to extend into these areas. In regard to books, new books tend to emerge more early in the life cycle of a language as tge developments and expansion of the language are strongest at that time. C is very mature, explaining why C books are not coming out every week, only to be outdated very soon.
-
Ironically, C is evolving in ways that are increasingly hostile toward the embedded and systems programming purposes for which it was first invented. If some action would have a natural and consistent behavior on some platforms, but ensuring consistent behavior on other platforms might be expensive, the Standard would leave the behavior Undefined so that implementations could define it or not. Today, however, it is fashionable for compilers to aggressively seek out ways to jump the rails if code does any action for which the Standard doesn't mandate behavior, even if...– supercatFeb 10, 2017 at 18:36
-
...the underlying platform would define the behavior in a useful fashion.– supercatFeb 10, 2017 at 18:36
-
There must be ways to configure compilers to not show this behavior right? Or even compilers specialized for this purpose? Feb 13, 2017 at 13:45
-
Compilers that add new "optimizations" generally provide ways of disabling them, but unfortunately they tend to treat them on an "opt-out" basis, and compilers generally don't define ways of preventing optimizations that they haven't implemented yet. Thus, if today's version of a compiler regards x<<y as multiplication by 2^y even when x is negative, there won't be any setting one can apply today to guarantee that tomorrow's compiler won't regard x<<y as an excuse to omit tests elsewhere that would see if x is negative.– supercatFeb 13, 2017 at 14:59
I would argue that one of C's most important features is its simplicity. Any "evolution" that adds complexity is not an advancement. I just shake my head when I hear about object-oriented COBOL -- one of the reason COBOL has enjoyed so much success is because OOP languages don't offer any compelling advantages in its niche (high-speed batch data processing). Likewise, I don't think that adding closures or making functions first-class elements will improve C. Best to leave it clean and simple, and use it as a base for new languages with new features. That strategy worked well for C++ and Objective-C, while still preserving C's value as a small, simple language.
