I am surprised that the role of history in metaphysics was never mentioned on this forum, since many of you engage with some kind of “software philosophy”. I myself have been searching for the next philosophy that I can claim to be highly applicable to malleability. Today I am sharing some results with you. I want to be upfront that I have not prepared a complete explanation for many of these arguments, but I still think the content can be inspiring. I appreciate all critiques.
One important conclusion from my journey is that the process of understanding itself only makes the most sense in the context of a history. Admittedly, other factors such as documentation and design matter, but these are incomparable to history. History subsumes everything in a system and makes them meaningful to the user, producing a system that transcends the existing one. The new does not naturally fit within the old. If it is forced into the old one, it will most certainly end up with bad properties. This is just one way to state a class of the difficult ontological problems in our software and information world.
But computers are useful! We want to use it to manage information. How do we possibly manage both the old and the new in a symbolic way, without somehow fitting the new in a system we already know? Now I can see that it is possible with some imagination. The revelation? Symbolic representation does not entail structural submission.
Computer programmers are extremely familiar with finding information by structure. You have some new idea to write down? Open a file first, and write to it. This file is within a certain location in the filesystem, to which you navigate using steps defined according to the structure of the system. Did you see that current systems force users to think by structure? Because the inputs are immediately “type-checked” by the structure, there is no way to define anything outside.
Alternatively, the system could allow the user to:
- assert that the new is of its own kind
- pick out relevant information from history
- transcendentally maintain the new, as an additional aspect
This “picking out” is different from a structuralist reference as it is not stored in a field of the constructor. These picks are hints to a new reality, and their other aspects are soon to be established, again by attaching to the original objects themselves, at the current time rather than as a field of the original objects. Everything is added to this system at the current time “frontier”, and the effective environment is the cascaded result of the whole timeline.
For history to be real, it must be compulsory. The system will transparently record all nondeterministic procedures, and save the parameters as strictly additional data that cannot be manipulated by userspace code. The system does not overwrite or delete such data on behalf of the user. When data cannot be immediately “type-checked”, keeping a history is necessary for correctness, and this correctness is only judged by the user.
Perhaps it is not a coincidence that the process above resembles the progressive process of human intelligence. In my opinion, this exactly signifies its potential as a malleable system. It might be time for us to put aside structuralism, a fixed understanding of intelligence, and even some well-established constructs in computer systems.
As an additional benefit, programmers in this system will deal with significantly less I/O and multiplexing, as they are often handled by compulsory history. Many programs will only need to be pure functions. In my opinion, the bloat of boilerplate and multiplexing control flags is best addressed with system-level history. These features were usually requested to increase flexibility of use in the first place, but now a full history enables ultimate flexibility.
Finally and as always, there is a social aspect. A system with first-class history will also give users more control over what they use in a few ways:
- History subsumes everything it uses. When you think an app GUI might be manipulative, the ability to keep past and current content (even if only spanning a few minutes) side-by-side is a powerful countermeasure.
This should also make us consider our strategy with manipulation. If our interactions with external systems are not recorded, can any process of manipulation even be systematically clarified? Manipulation seems to always require a forgetful subject. - History demystifies the IT process. New types are no longer “new” things the user must pull out from thin air. As soon as relevant facts are identified within history, a type emerges without much difficulty.