|
|
|
|
|
|
by caladri
5096 days ago
|
|
|
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. Is age an issue in its own right, or is it what informs what you perceive as a poor implementation that precludes the implementation of "modern" features? Also, I wonder if you perceive any possibility that progress might actually occur in the form not of accumulating more features on top of the modern fashionable designs but of starting from an earlier base and pursuing an alternate path of evolution to that of extant runtimes — do you? For example, is it possible that there is some innovation which could occur on top of C which would not be possible in the context of some modern language and its modern runtime which would make it a more desirable platform than the modern alternatives? As someone who works primarily in C (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!) I would say that's certainly the case, because there are already things that make C more appealing than C#, Java, etc. 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. If it isn't that age precludes the possibility of progress, then what's the problem with age? Code rot is an illusion. |
|
|
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.