This post is part of another I'm detailing out as an extension of my discussion of the ontology of software, I thought it might be a good idea to slip this in as a seperate post so it can be consumed in isolation and built up on / referenced future posts, enjoy!
If we should consider that there is such a thing as an input/data to a program, what would that be? In the common cognition this is something you enter into the program/software for computation. But how is this "entered"? What does a software do to "accept" input/data? What is input/data
What is program Input? Or Program Data?
If we should consider that there is such a thing as an input/data to a program, what would that be? In the common cognition this is something you enter into the program/software for computation. But how is this "entered"? What does a software do to "accept" input/data? What is input/data
Input/data is something that must change the state of a software/program deterministically and uniquely (2).
We know that a given input/data was been computed because there is a deterministic pattern of states that is assumed by the software after "accepting" the input (a kind of "response"). If a completely arbitrary set of states are assumed in response to any input, there would be no way of knowing whether the program is responding to a given input OR if it has even stopped or started responding to inputs, and when it begins responding etc. [~]Not distinguishing between responses to inputs means the inputs do not noticeably affect the program and every input is equal in its value and signature from the respect of the software that is accepting it. The software is like a child throwing a tantrum, no matter what you dangle in front of it the child cries insistently What this means is; you may think the things you are dangling a different in some way but they child has completely ignored them and isn't aware what you are showing it or even how many things you are showing it. To drive it home; the inputs are under treatment of the software exactly the same. This means the software actually only has a single input. This single input does not affect the software at all, which means it is itself not input at all according to our definition of input. It follows that input must change the state of a software/program deterministically and uniquely.
Okay... so what is a Program Instruction then?
We can then talk of what is an instruction and what that would lead you to say almost intuitively is:
an instruction is something that must change the state of a software/program deterministically and uniquely (3).
(snuck that one in like a ninja)
Ironically for exactly the same reasons (of horrid indistinguishability), instructions must be unique and deterministic and they must definitely change the state of the software. They do exactly the same thing to the software as input does, and must do the exact same thing. If they do any less than each other they lose indistinguishability and collapse into a single instruction/data and stop existing instantly[~].
Software Recursion Onotology...
So we know they must both be able to achieve the same thing. To firm up the concept that data and instruction is entirely exchangeable ontologically and therefore exactly the same; I will do something a bit off the cuff and say:
why not write a program entirely composed of input/data {1}?
According to the definition of what input/data can do, it is entirely possible not only to write (produce definition of behavior for; produce instruction for) programs entirely out of data; but I will prove here that we in fact always program programs with data and only data.
If we consider the situation of any program being interacted with at a "user level" i.e. when a person is interacting with what is identified as a piece of software. What happens is the person gives the software input; the software accepts it, and changes its state accordingly. But then you must think: "if I am giving input to a program that is running, what is running the program running my program?" This program must surely exist since my program doesn't run on "nothing", and it must be a program that runs my program*.
There are programs that host or run other programs, think: operating system. The program you are interact with was very literally entered into "something" by "someone" at some point. The programmer inputs its program into a program that programs programs. I purposefully iterate the word program so that it is obvious there is a recursive theme to this argument. Every program is itself an input to a "hosting" program; this means that any program is also part of a composite of another program. This is called recursion[*] and it follows that
There are programs that host or run other programs, think: operating system. The program you are interact with was very literally entered into "something" by "someone" at some point. The programmer inputs its program into a program that programs programs. I purposefully iterate the word program so that it is obvious there is a recursive theme to this argument. Every program is itself an input to a "hosting" program; this means that any program is also part of a composite of another program. This is called recursion[*] and it follows that
Every program is by itself part of a recursion of programs(4).
Quiet easy to see of course because other fields in software engineering employ this concept in order to manufacture code reuse culture and simplify program component dependencies. Therefore; because programs are always inputs to other programs, working the other way up the queue:
Every input to a program is itself then also a program(5).
You are by extension a programmer of the programmers program. When you enter a status into facebook you are actually instructing or programming facebook to respond in a deterministic way. You are in part literally controlling facebook's behavior, we call people who do that to programs, programmers! The reality we have stumbled on here is that:
all input/data is also a program/collection of instructions that change the state of a computer
It is also follows then that every program is composed of smaller programs (i will prove this in a later post).
So then we go the other way and ask:
What happens? Well according to my imagination this doesn't change anything because if you want to have someone use a program you merely offer them a host program to enter their program into in order to achieve its task that doesn't itself require any form of input [proof by construction]. What happens here is you quickly see that the need for input can be full filled completely by instructions. And again for the same properties instructions are capable of replacing inputs entirely, and vice versa. If follows then that there is no meaningful difference between input and instruction!
why not just write all the programs on earth out of purely instructions and make it so that they do not have any input at all {2}.
What happens? Well according to my imagination this doesn't change anything because if you want to have someone use a program you merely offer them a host program to enter their program into in order to achieve its task that doesn't itself require any form of input [proof by construction]. What happens here is you quickly see that the need for input can be full filled completely by instructions. And again for the same properties instructions are capable of replacing inputs entirely, and vice versa. If follows then that there is no meaningful difference between input and instruction!
* programs must run programs because, what ever runs the program accepts the program itself as input and allows it to be executed on a computer. Things that accept input and run them on a computer are called programs.
Thoughts in closing
Given that we can see it is easy to demonstrate rhetoric that easily and in my view concretely establishes the inseparable definitions of input/instruction and how it rhetorically projects into a ontological gluing of the concepts of program(software) and input-data; it is important to realize that this very realistically means you are in-control of a program with your input and interaction.
Controlling the program although is misleading in some contexts. Yes ontologically' when you give it input it makes you a programmer; but if you don't have real information on how the program treats your input you are still a programmer just a one with a severely damaged freedom of choice (due to the missing information on the reality of the options presented i.e. you don't know what your input does in some contexts therefore you are not empowered to effectively choose what it does when you employ it; it could do things you do not choose as a result; this means you did not choose them and you had no choice!).
So in order to fully benefit from free and fair interaction with a program you are strictly required to be able to know what your input does! In any other circumstance you loose a lot of your ability to "program correctly" and thus loose you ability to be a "user" in the true sense of the word.
Comments
Post a Comment