3 ms·

Printing the source out on paper would probably be the most long-lasting storage method (aside from engraving it into large pieces of stone, maybe). But typing

by Kadin 4y ago

Printing the source out on paper would probably be the most long-lasting storage method (aside from engraving it into large pieces of stone, maybe). But typing the source code back in for most non-trivial pieces of software would be really painful. "Here's the source code, go type it in" hasn't been a very popular method of distributing software, for good reason, in a long time. Maybe there's some way that you could include the true source code (in C or some other well-understood language) of a small decoder program, which would then take as input some more-compact representation of the desired programs? Something minified and compressed, but kept in a form that would make it relatively quick to type in? Maybe you could have the user type in groups of characters (6-7 or so at a time, because that's generally assumed to be the number of abstract symbols a person can easily hold in working short-term memory) and get a checksum back, that they could verify against the input book. Actually, you should probably have checksums per-line, per-page, and per-chapter/section. That way if you had a decoding problem, you could quickly drill down to the error without manually checking each character.

cardanome 4y ago
Or you could just use APL, which already has a high information density. Lot's of useful APL programs are very small, easily fitting on a single stone table and would not be much trouble to retype. In fact good APL programmers are even able to memorize them easily.
jeremysalwen 4y ago
You might be interested in this superuser question: https://superuser.com/questions/415451/how-to-transfer-a-file-over-pen-and-paper-with-error-correction https://superuser.com/questions/415451/how-to-transfer-a-fil... I was thinking forward error correction would make interactivity unnecessary.
Banana699 4y ago
Saving the source alone hardly solves anything, the comment you're replying to highlights the real problem : The Stack. Everything from the compiler\VM to the OS to the instruction set architecture and everything in between. You have to save and store all of that. You need a format other than text, text is extraordinarily inefficient and lossy at anything that is not declarative factual information. There has to be artifacts.
- AstralStorm 4y ago
  What you need is a C compiler, an assembler and maybe a basic linker, then you're set. It does not need to be very good either. In a pinch, an interpreter might do. From there, getting an OS running is relatively quick. Remember back when PCs came with nothing but BASIC and machine code? People typed in complex machine code via that interface and ran quite complex apps.
  - Banana699 4y ago
    This really only works if the programs you want to preserve are already written in C or can be transformed readily into comprehensible C source, which is not the most elegant or comprehensible language even in the best of times. What if you want to preserve Python ? now you have to type the entirety of Cpython before you even get to write the main preserved program (in python). What if you want to preserve browser JS ? (for a taste of why this might be useful, see the conversation on Flash. You can crticize and hate it till the cows come home, but it's a substantial part of human cultural heritage regardless.), now you need to type in a browser or at least a JS engine on top of the JS program. For a self-hosted compiled implementations of languages like Haskell or Rust, you would type in an irrelevant bootstrapping compiler in C first then type in the self-hosting compiler then type in the program. That's... tedious and unscalable. The amount of work you would spend to think and implement workarounds for all of this is better spent thinking and implementing language-, OS-, and hardware- independent specifications and VMs that are minimal and long-lasting, to better support a huge variety of the software and media and languages that make up our cultural heritage now, C being just one language among many. ------- You mention in an aside that a C interpreter would better suit preservation efforts than a heavy-duty overkill like today's optimizing C compilers, that's a good idea, naive interpreters are easy, much more so than complex compilers or runtimes. BUT, C is horrifically full of undefined behaviour and implementation-defined behaviour, and the spec is a natural language document so even if a behaviour is defined it's not really *defined* in the mathematical well-behaved sense, because you know how natural language is, you're always one tricky test case away from a bug. This is important, you never know you're depending on this or that behaviour until the applications fails or runs very strangely when running on another toolchain. That's why I argue we need formal specifications and VMs, and minimal ones at that. Indeed, we need a hierarchy of such specifications and VMs, becase hierarchies are efficient at compressing an otherwise-exponential amount of data (think of deep neural networks or search trees, why are they so efficient?). A sequence of bootstrapping minimal VMs is better and easier to preserve than one large heavy VM, eggs and baskets and all. Furthermore, designing new VMs and specifications specifically for preservation would force us to think about the framework we use to formalize and talk about them : maybe we can use $HOT_NEW_THING fresh from CS academia, or maybe we can use a natural numbers- or a boolean circuits- based approach, as those things are not fancy and easier to explain when you don't have a lot of shared context, they are - in a sense - the "bare minimum" you need to understand or talk about computers.

by Kadin 4y ago

cardanome 4y ago

Or you could just use APL, which already has a high information density. Lot's of useful APL programs are very small, easily fitting on a single stone table and would not be much trouble to retype. In fact good APL programmers are even able to memorize them easily.

jeremysalwen 4y ago

You might be interested in this superuser question: https://superuser.com/questions/415451/how-to-transfer-a-file-over-pen-and-paper-with-error-correction https://superuser.com/questions/415451/how-to-transfer-a-fil... I was thinking forward error correction would make interactivity unnecessary.

Banana699 4y ago

Saving the source alone hardly solves anything, the comment you're replying to highlights the real problem : The Stack. Everything from the compiler\VM to the OS to the instruction set architecture and everything in between. You have to save and store all of that. You need a format other than text, text is extraordinarily inefficient and lossy at anything that is not declarative factual information. There has to be artifacts.

AstralStorm 4y ago
What you need is a C compiler, an assembler and maybe a basic linker, then you're set. It does not need to be very good either. In a pinch, an interpreter might do. From there, getting an OS running is relatively quick. Remember back when PCs came with nothing but BASIC and machine code? People typed in complex machine code via that interface and ran quite complex apps.
- Banana699 4y ago
  This really only works if the programs you want to preserve are already written in C or can be transformed readily into comprehensible C source, which is not the most elegant or comprehensible language even in the best of times. What if you want to preserve Python ? now you have to type the entirety of Cpython before you even get to write the main preserved program (in python). What if you want to preserve browser JS ? (for a taste of why this might be useful, see the conversation on Flash. You can crticize and hate it till the cows come home, but it's a substantial part of human cultural heritage regardless.), now you need to type in a browser or at least a JS engine on top of the JS program. For a self-hosted compiled implementations of languages like Haskell or Rust, you would type in an irrelevant bootstrapping compiler in C first then type in the self-hosting compiler then type in the program. That's... tedious and unscalable. The amount of work you would spend to think and implement workarounds for all of this is better spent thinking and implementing language-, OS-, and hardware- independent specifications and VMs that are minimal and long-lasting, to better support a huge variety of the software and media and languages that make up our cultural heritage now, C being just one language among many. ------- You mention in an aside that a C interpreter would better suit preservation efforts than a heavy-duty overkill like today's optimizing C compilers, that's a good idea, naive interpreters are easy, much more so than complex compilers or runtimes. BUT, C is horrifically full of undefined behaviour and implementation-defined behaviour, and the spec is a natural language document so even if a behaviour is defined it's not really *defined* in the mathematical well-behaved sense, because you know how natural language is, you're always one tricky test case away from a bug. This is important, you never know you're depending on this or that behaviour until the applications fails or runs very strangely when running on another toolchain. That's why I argue we need formal specifications and VMs, and minimal ones at that. Indeed, we need a hierarchy of such specifications and VMs, becase hierarchies are efficient at compressing an otherwise-exponential amount of data (think of deep neural networks or search trees, why are they so efficient?). A sequence of bootstrapping minimal VMs is better and easier to preserve than one large heavy VM, eggs and baskets and all. Furthermore, designing new VMs and specifications specifically for preservation would force us to think about the framework we use to formalize and talk about them : maybe we can use $HOT_NEW_THING fresh from CS academia, or maybe we can use a natural numbers- or a boolean circuits- based approach, as those things are not fancy and easier to explain when you don't have a lot of shared context, they are - in a sense - the "bare minimum" you need to understand or talk about computers.