Summary: Programs seem to be instruction sets that are limited by a contradiction in data ownership.
2/1 (CONTRADICTION DIALECTICAL-MATERIALISM DATA OWNERSHIP)
A noticeable inner contradiction between programs is in data ownership. Programs must maintain ownership of their data to maintain stable; otherwise their data (and by extension code) could be arbitarily modified, thus destabilizing the system. (Binary data is publically accessible through a controller, so the program itself will not be the only subject.)
The data ownership contradiction can only be formed when two or more programs exist in the environment.
Zettelkasten NIL
An example of the data ownership contradiction <zettelkasten:2/1> is a program being executed through a program read-eval-print-loop (abbreviated to REPL, also termed a "shell"). There is an inner contradiction of control between the program REPL and the executed program; the executed program commonly maintains most control over its data, while the shell only maintains control of the program's execution.
The development of the data ownership contradiction
===================================================
In the early stages of computer development (the time period 1920 to 1960), programs were not designed with data protection methods; computer hardware could only allow for one program to run; so the idea of multitasking programs was not thought about. Programs were executed directly on computer hardware.
2/1/1 (CONTRADICTION DATA OWNERSHIP)
The contradiction of data ownership cannot be reconciled by both programs. A program that held the most ownership of data would need to be developed to maintain stability among other programs. As a consequence, data would need to be developed to secure the ownership of data.
Zettelkasten (2/1)
Modern computers have been developed to operate with an "operating system", a type of program that manages other programs. The operating system must become the dominant force among the contradiction of data ownership <zettelkaten:2/1> in the system of programs to maintain stability.
2/1/2 (EXCLUSIVE-CONTROL CONTRADICTION MECHANIC)
Compilers developed ownership of data out of neccesity; When multiple programs can be executed in a computer environment; programs must be able to reliably read and write data, otherwise the program would not work reliably and thus produce useless goods (information).
Zettelkasten NIL
2/1/3 (EXAMPLE CONTRADICTION)
Compiler<->Program
------------------
One instance of this contradiction is the compiler<->program-code contradiction. When the compiler is run, the compiler seizes control over the program data. After compilation, the compiler relieves control of the program and thus the generated machine code program has control over it's data.
Zettelkasten NIL
2/1/4 (EXAMPLE CONTRADICTION DATA-OWNERSHIP)
Interpreter<->Program
---------------------
A similar instance is the interpreter<->program-code contradiction. The interpreter seizes ownership over the program upon execution; but the interpreter does not relinquish it's ownership over the program.. instead the interpreter itself executes the program's code.
Zettelkasten NIL
The result of the data ownership contradiction <zettelkasten:2/1> can vary depending on the target the contradiction applies to.
2/2 (RESULT DATA-OWNERSHIP JUNCTIONARY-PROGRAM)
When the data ownership contradiction between programs is applied to storage data (files and streams); the result is a junctionary program to compromise the data with multiple programs.
Examples:
* The concept of files are a result of programs being inable to resolve the data ownership contradiction. The operating system often becomes the winner of the contradiction (in practice, it becomes the manager of files.)
* Streams are the product of programs being unable to access byte storage; programs must assume that they do not have ownership over storage data.
Zettelkasten NIL
Program code is made of data; so the data ownership <zettelkasten:2/1> contradiction can be applied to program data. When applying this contradiction to program code; we find that a stable program owns it's program code. If the program can not maintain ownership of it's code; the program will become unstable. (The instability manifests often as security vulnerabilities.
A program becomes the state.
----------------------------
As the result of the data ownership contradiction <zettelkasten:2/1> ; it would be logical for humans to develop a program to maintain the most control over the other programs to keep a computer stable.
2/3/1 (CONTRADICTION PATTERN)
The contradictions of data ownership among programs and the introduction of multithreading form a qualitative contradiction of governance over data; a similar pattern to the states
* Windows and UNIX OSes both police data ownership in a decentralized manner; programs lacking the neccessary data ownership must call program code to retrieve operating systems' data.
Zettelkasten NIL
Here is the document as Common Lisp code. (The original formatting.)
Use my typesetter.lisp to run the code.
I don’t understand what this is trying to say. If I interpreted this correctly, you’re saying that there’s a contradiction in storing data, wherein programs want to own their data, and this is a bad thing?
If so, there isn’t a way to get around this. If multiple programs are running and all expect to do stuff with their data, they must be sure that data is never modified without their knowledge, or they will end up with errors or incorrect results. You could say in that case, that only one program should run and it should run on bare metal, except then you get into issues where the data could be changed in the hardware itself, either by a person, or by something like a bit flip. Also, OSes do a lot more than protecting data, and they control a lot more than just programs. They have access to and directly control all hardware connected to your computer. They then provide access to it through syscalls. Without an OS, you’d basically need to implement an integrated OS into your bare metal program in order for it to be able to do the tasks expected of a modern computer.
Is the contradiction limited to those instances where instructions are data? Does the contradiction disappear when one stops conceiving of a program as a real thing and instead sees the entire Von Neumann system as the subject of analysis, comprising only storage, computation, and transfer?
deleted by creator
The Vonn Neumann systems relies on the processor having its own memory, which it secludes from other hardware.
Is it a contradiction that I have a brain and a notebook?
Separately, is it a contradiction that that you and I do not have direct access to each other’s memories?
Obviously, the first question maps to the classes of storage: primary (on-chip), secondary (off-chip volatile), tertiary (off-chip non-volatile).
The second question maps to the concept of collaboration among actors.
I have to say I’m not fully convinced by your argument that programs and the VNA represent contradictions. I’m asking questions in an attempt to see if I can understand better the insight you’re trying to expose.
