| > Can you expand on "shows its age"? Code entropy doesn't increase as a function of time alone. An ANSI C "Hello, World!" from 1990 doesn't show its age in the context of C today, for example. I was referring to the particular C programming approaches of the 1990s, rather than any notion of bitrot. If you were to explore a more complex ANSI C application from 1990, you would be more likely than not to find all state managed through globals, possibly significant use of goto, a slew of poorly documented and difficult to trace implementation functions, and an over reliance on exposed structure definitions and simplistic data models that would be exceedingly difficult to iterate on without breaking the code base. Additionally, the code almost certainly wouldn't be re-entrant, much less thread-safe. You also wouldn't have found unit tests, although some people would include a commented out test () function in some of their sources. > ... and is a little tickled by commentary elsewhere on this item about C programmers in the '80s and '90s that suggests everyone moved "up" from C to C++; very Microsoft! My own position here is that we learned to write better C, not that we moved "up" to C++. > An extension to the type system to do optional, minimalistic reference counting rather than having to use GC in a modern language or the STL's reference-counted containers (or something home-grown) in C++ would be a huge step forward for example. The locking annotations available with Clang and GCC have removed much of the value-add for using a language which does more hand-holding around synchronization It is very difficult to maintain pure backwards compatibility with C while adding any significant functionality. This is what Apple discovered with GC, and when implementing ARC, they had to go the route of outright restricting certain previously supported usage, eg: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#o... If we pick your idea apart in more detail, how would you represent reference-counted entities in this C environment? You couldn't do so without defining higher-level structures (such as objects, or glib gobjects), at which point you very quickly find yourself heading away from C. This is effectively what Apple was forced to do to add blocks to C, and is also why it seems quite unlikely that blocks will ever see inclusion in the C specification. |