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.

  • freagle@lemmygrad.ml
    link
    fedilink
    arrow-up
    0
    arrow-down
    1
    ·
    2 years ago

    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?