What Is Software Anyways? Where Does It Exist?

Basically nothing here is specific to software. You can talk about a piece of writing exactly the same way. Even the part about patching; lots of books have revisions.

I don't really see the point of focusing on software in particular before answering the general question. It's not being used to bring any special insight, and to my eye it's a false narrowing that makes it harder to answer.

> What this means of course is that programs are eternal unchanging things. We don't create programs as much as discover them.

This is a hell of a claim to pull out of nowhere.

I disagree that sentence 1 implies sentence 2.

And calling it a "fact" in the next sentence is bold!

  >Basically nothing here is specific to software. You can talk about a piece of writing exactly the same way. Even the part about patching; lots of books have revisions.

  >I don't really see the point of focusing on software in particular before answering the general question. It's not being used to bring any special insight, and to my eye it's a false narrowing that makes it harder to answer.

Computers are - ignoring emulation and things like that - physical machines that interact with the environment by reading inputs and writing outputs - reading whether the space bar is pressed and making a pixel on the screen light up red. While their function is fixed at the lowest level - how they process individual instructions due to their physical circuits - they are highly configurable machines, they have billions of capacitors or magnetic domains that you can charge and discharge or align one way or another in order to control what exactly the machine does, how it translates inputs to outputs.

Software - in the broadest sense - then is a description of how to configure a computer to achieve a certain input output behavior. It exists as a continuum of abstractness, from the idea in ones head, over the specification in a Word document, to the source code on GitHub, and the compilation result for a specific architecture on a flash drive. It is substrate independent, you can have the source code in your mind, store it on disk, or you can print it out. It is quite malleable, you can change it quite a bit without substantially altering it, at least at the more abstract end of the spectrum.

Where you draw the boundary between Windows 7 and not Windows 7 seems pretty arbitrary, that is just a label. Is the concept in your head already Windows 7? Maybe. How many changes are you willing to do before you decide to call it Windows 8? Arbitrary decision. Does an added comment in the source make a new revision? If you want to. There will always be some tension between the abstract description of what Windows 7 is supposed to do and the concrete implementation of that ideas - including details like the formatting of the source code - and I do not see that we have to gain much be trying to precisely define where the borders are. That seems like trying to nail down where blue turns into green.

> Irmak believes we should start with our everyday notions. When we talk about software, these are the kinds of things we generally believe about it. The way we talk about software, we being the everyday folk, should inform our theory as to what kind of thing software is

While this view is often intuitively persuasive and reasonable, I think we should be careful with it. While you could argue that social constructs are by definition constructed by the beliefs of everyday folk, sometimes our everyday beliefs really do turn out to be fundamentally incoherent. In other words I believe that ontological error theories can be correct and/or persuasive.

In any case, people interested in this might enjoy reading the SEP page on computer science, which includes a section on the software/hardware distinction and the ontology of software more generally: https://plato.stanford.edu/entries/computer-science/

Philip Armour has written on the topic in Five-orders-of-ignorance ~2000 [0], included in Laws of Software Process book [1]:

-- Software is 5th form of ~life-invented knowledge-storing/representing-medium - the previous ones being DNA, brain, hardware, books.

Which IMO, is exactly what it is. Whether its gigabytes of code or algorithm/structure written on napkin.. all the same.

[0] https://cacm.acm.org/opinion/the-five-orders-of-ignorance/

[1] http://www.amazon.com/Laws-Software-Process-Production-Manag...

The idea of software being eternal is rubbish, not least because software isn't its code but its "identity" which comes down entirely to the actual use of language (including all the branding and marketing, all the live demos and discussions over drinks after conferences).

The words "Napoleon Bonaparte" have a referent in the real world, just not in the present - does Napoleon Bonaparte exist? Usually we instead say he "existed".

Incidentally, this is why I agree with the author that criteria 1 and 4 aren't actually necessary for non-existence of a piece of software. Even if lots of people, authors or otherwise, remember a piece of software, the software is gone once it can no longer be said to be used anywhere. In that case we would say that the software "existed".

I think this is just a special case of the “problem of universals” which mediaeval philosophers endlessly debated, and which goes back to Plato and Aristotle in ancient Greece. However you choose to answer that more fundamental question is largely going to dictate how you answer this one.

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.

I think the answer is simple: Software is instructions we give to the computer.

But doesn't software exist in time and space too? I won't agree software has no physical-world representation, as it takes charges on my SSD, and if I did not copy it even once, then destroying that SSD or messing up the charges on that SSD will destroy my software. So software is essentially a piece of information in the first place, an ordered chaos of 1s and 0s which makes sense to the RISC assembly. If I do copy it, then my SSD will contain the Original information and it will be it's Source, all the rest would only be forks and copies and versions of that Original information. I wouldn't agree as well that software is an Abstract Artifact, I'm always envisioning it as a big Abstract Factory, with conveyor belts hauling, machines processing and trains moving and unloading at the speed of light the Information, or by it's other name Data, our abstract butter and our abstract bread. So my answer to the original question – software is a very specific kind Information. Information for another Information to synthesise... Information. Software is an Informational Artifact.

Software is an Artifact as much as common pressed plastic chair is an Artifact. There are millions of copies of that chair, and there are millions of copies of that software. If you can point to every copy of the chair, then why can't you point to every SSD/HDD/RAM containing a copy of software? This doesn't make sense to me. Abstract Artifact is too broad of a category to define software, as software's primary function — executing tasks or facilitating processes — extends beyond mere physical existence.

Question. What do you say to a manager who thinks that since software is non physical, it's easy to make changes to it?

Also relevant and interesting reading is SEP’s article on the philosophy of computer science, specifically the program section: https://plato.stanford.edu/entries/computer-science/#Prog

Those “bytes” are necessarily reliant on magnetic dipole moments in physical space, and when operated upon instantaneously to convert into electricity to sustain a self-certain predestined architecture of electrical instructions sequenced through super-sophisticated wires etched. The completion of the circuit is what software code executes in a logically cohesive patterning of the voltage operations of the embedded transistors at nanscopic levels of switches of 0s,1s, and -1s in relation to human measurements of electric charge loads, capable of being transmitted through physical space to coordinate the next electrical movement in said wires.

It’s taken me a lot of years to get that figured out. Heh.

[The article is concerned with a kind of philosophy of software existence. As a pragmatist (programmer), I'm more interested in addressing the first question concretely, as it pertains to what HackerNews is mostly focused on.]

After decades of loving the craft of crafting ever larger software systems, I've settled down to this description of what we devs actually produce:

Our fundamental spacial unit is "Information Representation". Yeah, that means data with its explicit semantics supplied by a type system. Whether amorphous (Python) or mostly concrete (C/C++) or whatever else, those are the bricks we use to construct our systems, because that is what our microprocessors are actually manipulating, by hook or crook.

What our software does temporally is to "Integrate" that data. Sometimes, it's character values coming in as input, with command-line functionality as output -- e.g. OS command-line commands. Sometimes, it's web-service requests coming in, and db accesses going out, with a lot of semi-permanent state being held in session data somewhere and a mostly-permanent database data somewhere. Regardless, the {input, state, output} is the spacial dimension being integrated in our logic. And note that "in and out" are the same as "call and response" in this description; the real idea is "How does the data flow, and what is the source, and where are the destinations?"

Of course, there are different temporal dimensions to our dev work: design-time, test-time, build-time, deploy-time, run-time. Each project has its own needs, so, just like advanced maths, we combine our integrations hierarchically to build up the entire system.

The coup de grace is the overarching notion, the "Engine".

Before real-world engines are used, they are designed, tested/verified, and planned for being assembled in production.

Once constructed, engines are prepared, tested, delivered, started, run while being manipulated/tweaked, and then they finish either by choice for maintenance or because their task is finished or because they failed. That's the cycle of use.

It doesn't look like our industry is very mature in how it approaches software systems as engines, especially with respect to maintenance. It would help if we understood that the fundamental unit of time is change, which is all that ever matters in the entire universe, but most especially in our software systems.

Software was telling computers what to do, to get those things done that we wanted done. This still remains software.

With AI, the new evolution in software is to skip the "telling what to do" part and directly specifying the goal - "telling what to get done" and let the system figure it out.

1. Instructions for the computer to execute 2. Wherever you put it

I had a prof who would say "there's no such thing as software; it's all just hardware in different states" and I think about that a lot.

This is a much deeper question that just software, but any thing given a label and treated singularly.