Help understanding this bit of philosophy in this paper

Question

I was reading about data structuring in computer science in this paper "Record Handling C.A.R. Hoare" when he outlined some philosophy about the properties of objects that I'm struggling to understand, please help.

In section 1.2. he writes the following:

Each of the objects represented in the computer by a record will possess one or more attributes which are relevant to the solution of the problem. Such attributes can generally be indicated by simple values some appropriate type. For example, the rate of interest on a bank loan can be indicated by a real number, the date of birth of a person can be indicated by an integer, the name of a variable by a string, etc. In order to represent in the computer a group of one or more attributes which are relevant for a given object, the record which represents that object will have allocated to it a group of one or more variables. Each variable will be capable of holding a simple value indicating the nature of some attribute of the object. A variable allocated to a record is known as a field of that record; it will often be given an identifier which is suggestive of the corresponding attribute, for example, "rate of interest", "date of birth", etc.

I understand attributes of the objects as things that are predicable (predicables) of them. But that definition doesn't seem to match with C.A.R. Hoare's examples of some attributes. For e.g. the "Date of birth" of a person, because the date of birth of a person isn't predicable of the person. Does anyone know where I am going wrong here? What does the "Date of birth" and "Rate of interest" actually mean if they are not properties/predicables.

Thank you

Answer 1

First of all I fear you're overthinking this way too hard. Like computer science often borrows terms from philosophy because both are dealing with the relation between abstract logical entities and formalized languages, so it's quite useful to borrow terminology that already exists and expresses ideas of these sort of concepts.

That being said, the use of these languages is usually not just pure theory but it's about describing concrete applications and ideas about applications. So you're probably doing yourself a disservice to assume a deeper meaning to the usage of terminology beyond the immediately obvious and stated meaning. In other words the terms are used as a reference to a philosophy not as a means to extend that philosophy.

So in 1.1. he's just arguing that in the real world we organize our environment by thinking of it as a fixed number of distinct entites; i.e. objects. That is, instead of 4 wooden or metal or plastic or ... pillars and a flat, rectangle, round, ... surface, we think of it as one entity, that we call that: a table. And the way we solve problems is by mapping out relations between these distinct entities (objects) and how their properties relate to each other.

So that's basically his "philosophy" that he draws from. And from there he argues that we can emulate this thinking on the computer. So when he comes to 1.2 his philosophical introduction is already finished and now he goes into how he would implement this concept on a computer.

So essentially "an object" is really just a "list of information". And that's already it.

Again the idea is that we encapsulate a bunch of related data in one place making it accessible by one name and call that "an object". Because that's how we deal with objects in the real world. Instead of listing a bunch of properties/attributes/features/relevant information about a thing/however you want to call that/..., we point to something sketch it's perimeter and give it a name.

And in this direction that works quite well. An object is a distinct entity with a set of features, so a (computer) object is a set of data (called features/attributes/properties/you name it).

However that comparison also has limits like in the real world the features would describe the object, while in this abstraction the features ARE the object. Like all that distinguishes the features form the object in the sense of a computer object is to draw a boundary and give it a name. Likewise the attributes of the (computer) object don't necessarily describe the (computer) object itself but the (real world) object that the (computer) object refers to.

So it's not the computer object that has an interest rate (it's just a bunch of data), it's the real bank loan that has the interest rate while the (computer) object is just a sheet that keeps track of that. That being said while the birth day of the person might still not work, we're now at a point where the "bank account"-computer object probably IS the REAL bank account... So the interest rate of the bank account object also effectively is what your concept of "your bank account's interest rate" will refer to.

Also these objects don't really distinguish between the different groups of predicables in this stage of definition. That changes with 1.3 where he introduces "classes" which are categories of objects. So for example:

Object(name=Richard, account_age=2 years) might be an instance of class Person(name, account_age). So all members of the same class share the same list of properties but not necessarily the same value of these properties.

So when speaking of objects that relate to a class we can speak of "properties" and "essence" if we allow for "inheritance" that is classes of classes we might even allow for "genus" if an instance of the class must have the properties of the class but is allow to have more (not in his definition of class apparently) we might even get accidental properties and the comparison with classes can also lead to properties being "differentia" and thus we could incorporate the whole 5 Aristotelian categories.

So this philosophical language is immensely useful to describe ideas of data structures and abstract computer objects but one should keep in mind that it's mostly used as a tool for a particular application and not really as a standalone universally applicable idea, that being said the more useful it is the more people might get interested in learning more about that and expanding upon it.

Answer 2

See you're still at it. Good for you.

Hoare is a biggy in mathematical correctness strategies in developing software in computer science; he has a logic named after him, and is in the Turing Award club. What you need to know, to do violence through simplicity, is that he's a big advocate for computer scientists to use specification languages to ensure that the software does what it is meant to do deductively. It's not really practical, and he admits it, so most correctness is done empirically through strategies like unit testing, user acceptance testing, regression testing, and so on. A big company like Bell/Nokia might automate as many as 4 or 5 million tests every night on their proprietary OS kernel.

He uses object as in abstract object (SEP). Both algorithms and software are abstractions, and so if one talks about static entities, one just uses the term object like any math philosopher would. It should be noted, and it's not the case in the passage you cite, that object can have a more technical meaning in computer science, as in object-oriented programing. In that sense, a run-time environment carves out some memory and tracks a process or thread for the data/methods that are instantiated from a class definition.

Given Hoare's place in the philosophy of computer science, he's using object and attribute like a computer scientist would. Objects/entities, attributes, and relations are high-level abstractions used in programing languages, modeling languages, and database models. UML is a very famous example of such a specification. Hoare is a computer scientist who has a foot in philosophy, so don't read him like a philosopher who is exploring computers. Mathematicians, logicians, linguists, computer scientists, and philosophers share a lot of ideas, but each tribe puts their own spin on concepts and terminology.