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!
I feel like this is a rehash of the very old conversation "what is math? is it invented or discovered". Note to the author: repeating trivial questions isn't the same as asking deeper questions.
In physics research, things are discovered. In engineering, things are (mostly) invented. Mathematics can be thought of as a combination of those. There are “physical” parts (think of facts of Euclidean geometry) and “engineering” parts (e.g. proofs).
>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.
I agree with the substance of this remark (the OP is indeed a general information-theoretic observation), except for the part where it's framed as a negative value judgement against the initial work.
It seems like this feedback could be trivially recopywritten in a way that elevates, rather than denigrates.
--
One thing that would seem to bear mentioning is that software seems to be highly compressible. Indeed, good software seems better represented by the path, rather than the current state. An analogy here would be chess, where a state can be represented by the sequence of moves or the current board state. The analogy isn't perfect, eg since in chess the board state tends to reduce information over time. I would expect, for software, when the (dead-end pruned) sequence representation exceeds the information content of the current 'board' state, that's when you know it's time for a refactor.
>How do you turn "you are coming at this from the wrong angle and that's causing problems" into praise?
By eliminating those judgement words "wrong" and "problem," of course. ;-)
A more positive-focused process might be, "that's an interesting perspective, and here's a generalization that might unlock new avenues for thinking further."
Anyway, see my edit above where I offer an elaboration on your (IMO excellent) observation.
“That’s an interesting perspective” is not the same feedback as saying something is wrong. Don’t mince words, not everyone needs a participation trophy.
Again, "wrong" is a judgement, not a fact. Whether something is "wrong" depends largely on how negative vs positive the reviewer wants to spin it. There's no objective reality to it, only a chosen emotional state at the time of writing.
>participation trophy
Sadly this is one of those (pre-) loaded phrases that tends to shut down thought, rather than stimulate it.
I don't see how "you are coming at this from an angle, end of comment" elevates anything.
You could cut off my original comment after the first paragraph and it would still be a reasonably useful comment, but I don't think you can remove the criticism in the rest of the comment without cutting that out entirely and losing the meaning.
Your "better" approach still throws out two thirds of my original comment. I'm not convinced.
Also I don't think the article covers the groundwork well enough to make the perspective interesting. Interesting is where it could get with further work, not where it is now.
I gave you an example, but you're right that I didn't do all the copyediting work for you. It's up to you to generalize the example to the rest of your post.
Good luck! Any questions please don't hesitate to ask. Good thread, thanks and cheers
Perhaps a softer but less-brittle version of this might be:
1. It is possible to define "programs" as an immutable abstraction, much like how "123+456" exists even if I decide not to do the calculation. In this view, we don't mutate our programs so much as we pick a different one to execute instead.
2. We create formal programs in code in response to discovering informal "programs" implemented in people.
Number 1 is just a library of babel argument. Every sentence that could ever exist can be enumerated in a giant list. That doesn't mean that creation ceases to exist and everything is actually discovery.
Number 2 seems overly dismissive of the work of crafting the informal version.
> overly dismissive of the work of crafting the informal version
I disagree, if anything it's the opposite and "we made new program X in-response-to existing process Y" is downright meek.
It never suggests that anyone is capable of fully replicating or even understanding Y, nor does it say X is even good enough to partially replace it... it's simply why they started a project.
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/
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 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.
What about the product of the instructions? Or as another commenter said, the runtime execution? Which of those is more “software” than the other and what does it make the other?
Seems reasonable to believe the thing happening due to the instructions is on another level of “abstract artifact” corroborating the point despite semantic nuances.
Product of instructions is just product. Sometimes it may be software, sometimes it may be graphics, sometimes it may be both (graphical programming languages, they exist).
> Seems reasonable to believe the thing happening due to the instructions is on another level of “abstract artifact”
Well, yes. Thing happening due to execution of instructions is typically[1] not those instructions.
> Or as another commenter said, the runtime execution?
Software is a list of instructions. Runtime execution is a process (of executing those instructions). What do you mean by your comment?
I hear you that the end result is the software product, but what I'm saying is there are a lot of middle steps and grey area that could also be argued to be "software."
In other words, I think I was trying to say I simply disagree with, or don't understand the point of the article due to the massive nuances.
Also, yes, I love quines. And they're a great example of a nuance I'm conveying here.
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.
Probably a more-diplomatic version of: "Our corporate charter isn't physical either, you can change that in a couple days too, right?"
Depending on their background and the kind of company, other things could be substituted, like "the long-term contracts with our suppliers", or "our rules for billing and customer retention" or "do a complete re-org of who-reports-to-who."
Basically, find something which that manager would never consider trivial to change because it requires running around somehow changing the expectations, opinions, and habits of lots of people, as well as getting all those intangible soft-things into a new harmony.
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.
>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.
Not exactly. Writing software has always been "telling computers what to do". Using AI to do this doesn't change much. In the very early days (after CPUs were invented), you told the computer what you wanted to do with CPU instructions directly, so you had to figure out how to manage memory and all other tedious things needed to get your program to work. Later, higher-level languages were developed to abstract the complexity of the hardware away, so you could tell the computer what you wanted in higher-level terms without so many low-level details. An AI tool just takes this to another level.
OK - how many practical declarative goal-based languages have been successful in the past 50 years? Only option I can think of till now is SQL. Maybe there were some Operational Research optimization stuff as well. All of these were quite limited in terms of the kinds of goals we could specify, and the range of impacts they could have on the world.
The possibility of pure goal-oriented systems are at an inception now. So it's a totally different game, different mechanisms, and so on.
"Short cuts make long delays." --somewhere in LOTR
Thinking the user of AI can just spec a goal and then the AI automagically produces perfect results is just the pipe dream of the lazy who won't ever have a clue about how to verify the resulting system, much less the system that produced it. Good luck with that!
Software is about 100% correctness, which is damn-near impossible. And when it fails, it will fail at the worst time and in the worst way possible. It's just a matter of when, not if. We can't even remotely do that (for nontrivial systems), but we're gonna make a machine that can do it?!
Don't have the time to make a long rebuttal, but my points are:
- For the past 50+ years, really intelligent people, including Turing award winners have believed in this dreams
- In fact, getting computer to solve problem on their own is the more intense path IMHO. The lazy path is sitting content with the way things are.
Do you mean written down code? I think that deciding whether that's software is debatable. Other than that I can't think of anything that doesn't run on a computer that can be called software. Unless you want to be pedantic and say 'this program doesn't run on a computer, it gets compiled down into machine code. The machine code runs on a computer.'
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!