4 ms·
There seems to be a mixing of definitions going on here that is confusing people. You've got an algorithm, a finite sequence of unambiguous instructions that,
by nonameiguess 3y ago
There seems to be a mixing of definitions going on here that is confusing people.
You've got an algorithm, a finite sequence of unambiguous instructions that, given some initial conditions, will produce some end state that is interpreted as either correct or incorrect.
You've got a function, which is some mapping of elements from a domain to elements of a codomain such that the mapping is unique for each element of the domain.
Then you've got a "program." This one doesn't come from mathematics, so I guess that means it doesn't get a rigorous, clear, agree-upon definition. So what does the writer himself mean? He wrote an earlier post linked to from this post that provides his definition: https://blog.charliemeyer.co/code-doesnt-happen-to-you/ https://blog.charliemeyer.co/code-doesnt-happen-to-you/.
My definition is a sequence of instructions provided to a machine allowing the machine to do work partially or fully autonomously once it has been started. If we limit ourselves to the kind of machine the people of 2023 commonly called programmers typically program, we've got electronic boolean state machines that receive fixed-length sequences of bits either as operands to a boolean circuit or instructions telling the state machine which boolean circuit to execute in this cycle. The instructions and operands are either persistently stored as firmware, fetched from NVRAM in the case of a bootloader, or fetched from volatile memory in the case of most other programs. These were in turned put there by some higher-level management program that read them from sources such as durable storage or buffers that may be written to by hardware that receives messages from external sources such as network interfaces, capacitative touch devices, or keyboards.
Not all instructions accept operands and thus not all programs require operands. Trivially, the null program executes a sequence of NOPs.
So does every program need inputs? Well, every program is a state machine. A state machine has an initial state and an end state and these usually get referred to as inputs and outputs when discussing state machines. Even the null program is a state machine. It remains in the same state at each cycle no matter the current state, such that the final state is always the same as the initial state. The null program is also a function. It even has a special name: the identity function. Like all functions, the identity function has an input and an output and these are always the same. Another trivial program is the constant function, which produces the same output no matter the input. Consider a program to factory reset or wipe a device. The initial state of the device is still an input, but the final state at program completion will not depend upon this input.
What every program does not need is inputs provided at startup in the argv and envp arrays or provided interactively at runtime by other programs or human users.
The mixup here seems to be readers limiting themselves to considering input only in the sense of hardware devices that get labeled as IO devices when discussing the basic taxonomy of computer organization and design, but these are one of those "the categories are made for man" things. The execution unit on a processor just receives bits from the buses connecting the processor to a memory module. It doesn't know or care where they came from and whether they were already there or not before a particular program started.