https://futureofcoding.org/ logo
Join Slack
Powered by
I’m writing a paper on the notion of “digital obje...
# thinking-together
o
I’m writing a paper on the notion of “digital objects” and would seriously appreciate any papers/sources that explore this idea (the notion of digital “things” in general, not OOP-specific). The notion of an “object” is one of the most basic and fundamental ideas in philosophy and it has received surprisingly few treatments in the context of computing given its importance. I have many thoughts on the significance of the question, and have developed a tentative theory of digital objects that I think is well supported and useful. But at the moment I’m just trying to gather more literature and perspectives (as in, your perspectives!). A few related phrasings to the question that I’ve seen around: In what ways do digital things exist? What is the nature of digital “stuff”, What defines a computational entity?, etc. While “object” is really the proper term here, there are others that get used often like entity, item, thing, or unit. Some sources that explore this question: A theory of digital objects On the existence of digital objects Theorising the digital object and for reference here are wiki pages for objects (in computer science) and objects (in philosophy)
c
👀 1
r
It's difficult to pin down the meaning of 'object' in a digital sense because in many ways it is used as a term of art, and it doesn't seem like the philosophers are in agreement in any case. Objects can be best defined by differentiating them from data, where objects are behavioral while data must be altered by external procedures, as elaborated in On understanding data abstraction, revisited, The power of interoperability: why objects are inevitable, and "Object Thinking" by David West. OOP muddies the waters with notions like inheritance and classes, but is still centered around objects as the fundamental unit of computing. You can have objects like this in a language that isn't OOP (as many do, however clumsily), but the origins of OOP were centered around the philosophical notion of object as Dan Ingalls puts it in Design Principles Behind Smalltalk:
The mind observes a vast universe of experience, both immediate and recorded. One can derive a sense of oneness with the universe simply by letting this experience be, just as it is. However, if one wishes to participate, literally to take a part, in the universe, one must draw distinctions. In so doing one identifies an object in the universe, and simultaneously all the rest becomes not-that-object. Distinction by itself is a start, but the process of distinguishing does not get any easier. Every time you want to talk about "that chair over there", you must repeat the entire processes of distinguishing that chair. This is where the act of reference comes in: we can associate a unique identifier with an object, and, from that time on, only the mention of that identifier is necessary to refer to the original object.
So perhaps the goal of OOP is to facilitate the primordial meaningless goo of bits and bytes into well-behaved and understandable objects. Brad Cox writes in Planning the software industrial revolution:
What does any adjective mean in this murky swamp we call software? No one is confused when adjectives like `small' or `fast' mean entirely different things in nuclear physics, gardening, and geology. But in this murky domain of intangible abstractions, it is all too easy to lose your bearings, to misunderstand the context, to confuse the very small with the extremely large.[...]
Such confusion is not surprising. The denizens of the software domain, from the tiniest expression to the largest application, are as intangible as any ghost. And because we invent them all from first principles, everything we encounter there is unique and unfamiliar, composed of components that have never been seen before and will never be seen again, and that obey laws that don't generalize to future encounters. Software is a place where dreams are planted and nightmares harvested, an abstract, mystical swamp where terrible demons compete with magical panaceas, a world of werewolves and silver bullets. As long all we can know for certain is the code we ourselves wrote during the last week or so, mystical belief will reign over quantifiable reason. Terms like `computer science' and `software engineering' will remain oxymorons -- at best, content-free twaddle spawned of wishful thinking and, at worst, a cruel and selfish fraud on the consumers who pay our salaries.
In the broadest sense, object-oriented refers to an objective, not a technology for achieving it. It means wielding all the tools we can muster, from well-proven antiques like Cobol to missing ones like specification languages, to enable our consumers by letting them reason about our products via the common-sense skills we all use to understand tangible objects.
So, what is an object in a computer, a digital thing? It is philosophy come to life in a metaphysical tool, a structure of consciousness reproduced as a model, which can be understood as an object to other object-speaking agents through what it does.
👏 2
n
The notion of an “object” has received surprisingly few treatments in the context of computing
IMO the software industry's blindness to what it means to be an "object" (in our everyday lives) is a major contributor to the stagnation in PLs that we are experiencing. From my perspective, objects are immortal once they appear, i.e. they can never be destroyed. The rationale: we can still talk about Alan Turing, or the 2001 World Trade Center, even though neither of those things have a physical body anymore. Thus, they still exist as objects in our minds. The fact that they continue to have an influence in the world — associations continue to be made between them and other things — means that they are not really "gone". Whilst such objects can't be destroyed, they can be forgotten. Computers should be able to model this phenomenon. Object-oriented languages kind of do this, in that objects are garbage-collected only when all references to them are released, i.e. you can't destroy an object that somebody else is still "thinking about". But they conflate something important: objects are given "attributes", and those attributes cannot be forgotten (cleared from memory) until the object itself is forgotten. Crucially, attributes are the only thing that actually consumes memory! Thus, what OOP seems to really be garbage-collecting is attributes, not object themselves. But it's really weird to manage the lifetimes of attributes (i.e. the lifetimes of relationships between things) by bundling them into a "group" that we call an object. After all, they make no contribution to the object's identity — in an OO language, the identity of an object is given by its location in memory. In conclusion: I think "objects" should be considered immortal (once they appear), and not "contain" any relationships. Instead, relationships should be a separate construct, similar to how "relational languages" (SQL, Datalog...) do it. The open question is: what is the right way to model the lifetimes of relationships, such that relationships can become invalid and be "garbage-collected"? Neither SQL nor Datalog offer a compelling model.
amiga tick 1
l
The notion of an “object” is one of the most basic and fundamental ideas in philosophy and it has received surprisingly few treatments in the context of computing given its importance.
The philosophical notion of an object as applied to the context of computing casts quite a wide net. The notions of a “digital object” or similar terms as treated in the links you and Riley provided mostly seem considerably narrower. Do you think your tentative theory will start with a narrower category as a premise and then go from there? Or is the goal to apply the philosophical notion to the context of computing in order to discover the category? (Unfortunately I don’t think I have any more reference points to contribute.)
k
Gilbert Simondon's "_Du mode d'existence des objets techniques"_ is probably relevant, but I don't know if it has been translated. It's about "technical objects" and their role in modern societies, so it's a bit wider than "digital objects". Your second link mentions Simondon BTW.
➕ 2
o
@Konrad Hinsen Yeah that’s one of the main influences that Yuk Hui pulls from in his book. I found the idea of “technical objects” really useful in clarifying the relationship between digital objects and broader society, but still need to dig into some of Simondons original work. I just haven't found a good english copy of that work yet.
@Luke Persola the goal is to discover the category, though I would say I’m doing something more like synthesis than pure application of philosophy. And yes, it’s a very wide net, and I agree that some of those references are far too constrained (even if they are useful to some).
👍 1
@Riley Stewart thanks for the links! Some really great thoughts here! Love that Ingalls quote, and it maintains some clarity (which is often lost nowadays) that the object and the ways we refer to that object may be conceptually distinct. You can refer to the same object in a number of ways, and it isn’t guaranteed that you’ll be referring to the same object with the same reference. I’d like to push back on the distinction between objects and data though, as that would mean that things like files are not objects, and the computational distinction can be blurry when the data might be source code or something ‘computational’ in nature.
@Nick Smith interesting stuff! You raise a couple of important points: • A conception of objects as defined by relations, which as you point out can persist beyond the existence of the original object. This also points to the ontological status of digital objects, and wether an object can be ontologically independent (imho they probably can't be). It also raises the question of the kinds of relations relevant to objects, e.g. do objects have a meronomy (part-whole relation) where their attributes or properties are contained “within” the object. In my view, this question doesn't have a single answer and it comes down to context/perspective. A property may be “part of” an object from one view, and an external relation from another view. • The question of identity! This is actually what prompted me to write the paper, as I think this is a much harder question, and one that I think naturally follows from a conception of ‘digital object’. Identity is essentially the question of “sameness” over time/place/context/etc. In your OOP language example, I think it’s not exactly the location in memory that gives an object its identity, but is instead the interaction between the addressing system (often a location in memory) and the mutability system (which is conceptually related to identity). This is only true at the language level though, and doesn't entirely track to broader systems. In the paper I introduce and build on two related notions: “Objects as addressability” and “Identity as governance” which roughly correspond to the points you made (though I take a systems-theoretic view, not a language one). I think its only when viewing these together that we get a more complete picture. I think the mutability-as-default of our systems may have contributed to the conflation between these two notions. I’m also aware that “addresssability” and “governance” are undefined here, but I’ll leave that for the future for now.
❤️ 2
k
t
My first thought when reading "digital objects" was, how might NFTs, Metaverse, AR/VR fit into this conversation... I'm a big proponent of "merge reality" or the idea that smart glasses will merge our physical and digital worlds. All of those "digital objects" are going to come out of the proverbial pandoras' box and live next to our physical objects. How is an object classified once, in example, our toaster has an AR based menu?
k
@Orion Reed Another maybe interesting site is https://fairdo.org/, if only for the fact that it tries very hard to talk about digital objects without ever providing a definition. Put differently: the people behind that site need to read your paper 😉
🙏 1
4 Views
Open in Slack
PreviousNext
Powered by