4 ms·
This question has been of interest to me for a long time. I think it's fine to call it an Abstract Artifact but I think that's too ambiguous, and also we alread
by proc0 2y ago
This question has been of interest to me for a long time. I think it's fine to call it an Abstract Artifact but I think that's too ambiguous, and also we already have a term in computer science that describes what software really is: the runtime. Software is identical to its runtime execution... in other words it's information processing itself.
We can have an SSD with Windows on it, and we could refer to that as software colloquially, but it cannot be properly checked until you run it inside of existing software like a BIOS. So until you execute and run it it's really just information on a storage medium.
- MrMcCall 2y agoI consider them to be tools run upon/within other tool(s), their entire purpose being to manifest some kinds of data flow that produce a cascade of changes within a specific context. All the contexts are nested aggregates: software resides within the OS (itself having/providing many contexts), which is within the hardware's complex set of contexts, which is within the network of networks. So, I would say there's nothing really abstract about software systems, except for, perhaps, when we are conceptualizing them, but even then we are imagining something very real that does something very concrete to some real things. One could also look at the software itself, while latent, as potential dataflow; and then, when it runs in its appropriate context, it is an active agent of change, that may or may not be actually accomplishing its goals, depending on its and its contexts' circumstances at the time. There are many reasons developing software is the among the most difficult tasks in the history of human tool engineering. The evidence for that is that there is no industry that I know of in 2024 that is not wholly dependent upon software.