Lots of C code have already bitrotted because APIs it depends on have been abandoned. Resurrecting it isn't just a matter of compiling the code, but recreating the environment it ran in.

That was before storage become abundant and cheap; from a source code storage perspective. It will not become more expensive.

Nowadays storage capacity is developed to store video - this is really the only thing that needs a lot of new storage capacity.

Every line of sourcecode written by every programmer ever is a fart in the wind compared to what's being uploaded to Youtube in the next 60 seconds.

Which does nothing to address "it works on my machine" build related issues. And more modern languages have much more robust solutions to hermetic build and package management.

That's what docker images are for :-)

C is only about 50 years old. I'd say it remains to be seen (not in our lifetime).

you might be able to compile C89, but would you be able to debug it? What if there are incorrect assumptions about the word size in your computer?

As part of "C lore", the answer is yes. In C89:

int main() {

func('a');

}

func(c)

char c;

{

char * s = &c;

printf("%c\n", * s);

}

is, um, dangerous. c is an int, not a char. So on a big endian machine, s may end up pointing to the high byte. Taking the address of a parameter is dangerous, unless the widening is taken into account.

This does work on a little endian machine (tried it). On a 68000, it likely doesn't print 'a' (\0 is most likely).

On little-endian, this is a lot safer. ANSI C takes care of this as well. Yes, we can "debug it". There is a chance that all knowledge of this is lost. But, for now, those of us "in the know" have experience to keep the old alive.

And, for those who have been contemplating parameter widening: on the 68000, insert s += 3. For "portable" C89 code, declare the parameter an int (not char) -- then introduce char c2 = c and s = &c2 instead. This transformation is "safe" because parameters are copied by value and cannot be returned that way.

As to debugging -- many of these systems did not have "debuggers" -- an example would be Whitesmiths C in the late 70s and the 80s. We used a strategy of old-school paper validation, combined with function testing. Yes, things moved more slowly.

Code can be maintained. The above C89 code was just compiled with gcc 9.2.1 -- with gcc -std=c89 c89.c it compiled without warning, and ran (40 year old code).

The issue with (say) bring forward Whitesmiths C is that the Whitesmiths standard library is not POSIX. Not hard to convert, though. For example (as I recall) %d was %i

FORTRAN 77 (and FORTRAN IV) is in a similar category. As is COBOL and Common LISP.

SNOBOL4 is a bit of an outlier -- The original interpreter was written in macro assembler. That assembler is now converted to C, and the original interpreter can still be run:

The Macro Implementation of SNOBOL4 in C (CSNOBOL4BX) Version 2.0 by Philip L. Budne, January 1, 2015 SNOBOL4 (Version 3.11, May 19, 1975) BLOCKS (Version 1.10, April 1, 1973) Bell Telephone Laboratories, Incorporated EXTENSIONS (Version 0.25, June 16, 2015) Fred Weigel

No errors detected in source program

CODE (TUE AUG 4 10:28:58 EDT 2015) RUNNING ON CSNOBOL4 MAINBOL WITH SPITBOL, BLOCKS, EXTENSIONS ENTER SNOBOL4 STATEMENTS (TRY ? FOR HELP) 5,541,616 BYTES FREE CODE:

And, yes, I modified the original interpreter to add some extensions back in 2015. However, Budne has published the pattern matching engine in Javascript so there is an easy migration for those programs (https://github.com/philbudne/spipatjs).

In my opinion (and this is strictly my opinion), only Javascript appears to have this "lasting" property wrt modern languages. An important characteristic is simplicity, and forward-backward compatibility. As well, multiple implementations are important.

FredW

Elixir has just feature frozen itself and it looks like it won't 2.0 (the underlying erlang subsystems might change, though).

You might like zig which is shaping up to be a saner c, and Andy Kelly looks like he's staving off feature creep.