8

From - Object (computer science) - Wikipedia:

A language is usually considered object-based if it includes the basic capabilities for an object: identity, properties, and attributes. A language is considered object-oriented if it is object-based and also has the capability of polymorphism, inheritance, encapsulation, and, possibly, composition.

From Object (philosophy) - Wikipedia:

A related notion is objecthood. Objecthood is the state of being an object. One approach to defining it is in terms of objects' properties and relations. Descriptions of all bodies, minds, and persons must be in terms of their properties and relations. The philosophical question of the nature of objecthood concerns how objects are related to their properties and relations. For example, it seems that the only way to describe an apple is by describing its properties and how it is related to other things. Its properties may include its redness, its size, and its composition, while its relations may include "on the table", "in the room" and "being bigger than other apples".

I also find these relevant articles:

However skimming them I fail to see any explicit statement about the philosophical theory behind object-oriented programming in computer science. So far I have a notion that any philosophical theory can be a foundation for that. Is that correct? Or is it that I shouldn't analyze computer science objects via any philosophical theory about object because I should acknowledge that the word object as a polysemy? Similarly how the word bank is a polysemy, and I cannot use geological theories to analyze financial activities.

10
  • 12
    An object in programming is nothing but a set of related data packed along with the definition of the operations that can be done on this data (methods). There is not much philosophical consideration to it, more practical consideration based on early programmers experience.
    – armand
    Jun 2 at 5:53
  • 2
    The word 'bank' came from the word for bench, where people sat outside in Venice around 1600 to do trading and accounting. They made loans. It was not a geological term. Similarly, programming doesn't have much to do with mathematics. (I work as a programmer)
    – Scott Rowe
    Jun 2 at 13:01
  • 1
    You'd do yourself a favor by looking at what some computer science stalwarts say about OOP
    – Rushi
    Jun 2 at 15:21
  • Also CMU, ranked between 1 and 3 worlwide in CS departments has chosen to eject object oriented programming from its freshman courses. May be justified??
    – Rushi
    Jun 2 at 15:50
  • 1
    Rhizome of course could be connected in a deeper and forward-looking connection to improve OOP, but most objects in OOP are arborescent tree-like, not arbitrarily composable. You may link to his virtual and singular ideas... Jun 7 at 3:17

6 Answers 6

5

The Relationship between Philosophical and Computer Science Objects

There is a deep, fundamental connection between computer science and philosophy, and not just because the first computer scientists, such as Turing, von Neumann, Kleene, and others were mathematicians and familiar with mathematical logic (Turing's PhD is a about logic, for instance), but because conceptually, there is a correspondence between how logic works and what computer programs do. One relevant result is known as Curry-Howard correspondence.

In object oriented programming languages (OOPLs), objects are instantiations of classes which for the unfamiliar is the notion that machine instructions, which are notoriously terse and primitive, are built into constructs that are psychologically simpler to understand and use when programming computers. In lieu of strings of one's and zero's, modern programming languages offer syntaxes more compatible with natural language, and are often compiled just-in-time according to an execution model which can be understood as a relationship between the syntax and the semantic import of the language, that is, what the language actually does. Arguably, programming languages is largely the creation of syntactic sugar, and OOPLs and hybrid functional-OOPLs use the object as a unit of organization to make separation of concerns easier to manage and design patterns possible. An object arises as an idea because it allows us to group state and instruction in one structure, as an abstract data type, to help combat complexity, the scourge of computer systems everywhere. As such, CS objects are a practical way to modularize systems linguistically.

The notion of an object in computer science didn't come from deep philosophical study of abstract objects (SEP) or subject-object relationships. Computer science is a young discipline compared to logic since electro-mechanical computers which led to their construction in programming languages, and often novel developments like OOP arise from the practical application of challenges in academia and industry. For instance, in the history of OOP, Smalltalk, one of the ancestors of C++, C#, Java, and JavaScript originated at Xerox PARC with men like Alan Kay doing industry R&D. Computer science has often had contributions by individuals who are engineers and engaged in industry such as John Backus who was notoriously clever and was very remote from formal education and philosophy.

The CS object is a handy way to organize data AND instructions within the execution context of a run-time system. Back in the days when programs often required you to peek and poke memory addresses directly, programs were interpreted, and program flow might involve numbered lines, variables and procedures were much simpler and software was much smaller. Today, a modern build system might require a pipeline, devOPs personnel, web APIs, and extensive libraries and frameworks (built from extensive libraries and frameworks). Objects allow for simplifying software systems by thinking in human terms (such as object hierarchies and inheritances which focuses on WHAT is being modeled) rather than in terms of compiler primitives such as lexical scoping, execution contexts, references and data primitives, etc. (which is HOW the language is modeling).

Software as Models and the Intentionality of Symbolic Artifacts

Organizing state and instructions into logical abstractions that have instance variables and methods is a way to build sophisticated models of a problem domain. In philosophy, that raises the question of what exactly a model is, and how it is used in math and science (SEP), and unlike a physical model, say a toy plane, a computer model can be interpreted as a type of formal system; Tony Hoare built his career around the mathematical evaluation of computer software, for instance, and has a logic named after him. In that sense, objection orientation and functions are techniques for representing things internally inside a computer which can be thought of as a type of intentionality (SEP) which is a property traditionally applied to people, and not inanimate objects:

In philosophy, intentionality is the power of minds and mental states to be about, to represent, or to stand for, things, properties and states of affairs. To say of an individual’s mental states that they have intentionality is to say that they are mental representations or that they have contents. Furthermore, to the extent that a speaker utters words from some natural language or draws pictures or symbols from a formal language for the purpose of conveying to others the contents of her mental states, these artifacts used by a speaker too have contents or intentionality.

"[T]hese artifacts used... too have contents or intentionality" is particularly relevant to computer science, because unlike a notebook or an abacus, a computer automates and uses the symbols and languages people invent.

Ultimately, the entities, attributes, and relations of data modeling and instantiated in design language standards like UML has an uncanny similarity to the entities, properties, and relations of metaphysics of logic and mathematics. This is seemingly because natural language is itself used to describe and model the external world around us and are used for communication and reasoning about that world. CS objects reflect that reality as an aspect of developer experience (MS). People have uniquely evolved the capacity for symbolic communication in a way that even our Great Ape relatives simply don't have the capacity for, and it's no coincidence that computer languages and grammars are named after Noam Chomsky, a linguist who studies natural languages. Computer languages are artificial, but the best of them are modeled on the same resources evolution has provided the brain.

The object of an object-oriented language is simply an intuitive semantic primitive that takes advantage of the principle of compositionality (Frege's principle); this has fascinated philosophers since at least the time of Gottlob Frege who is considered the father of analytic philosophy. Objects, then are simply building blocks that make a language easy to use, whether they are expressed as nouns with definitions (a tree that grows in the shade), or as classes (public shadeTree { growInShade() }). The philosophy of computer science is new and is emerging (as noted by Raymond Turner in his Computational Artifacts: Towards a Philosophy of Computer Science (GB)), but central to its study is certainly the philosophy of language.

6
  • Misuse of Curry-Howard, FWIW. More crucially, you're wrong about the nature of Kay's object metaphor; Kay was inspired by biology and objects are like cells in multicellular organisms. Kay's 1997 OOPSLA keynote is a good starting point.
    – Corbin
    Jun 4 at 17:04
  • @Corbin Thanks. I don't recall making claims about Kay or his views directly, but I'm glad you introduce me to materials on the matter. Obviously my post lacks a degree of historical specificity, and I make no warrant as to my historical expertise in the motivations of the original engineers and practitioners of OOPL. I'm not old enough to remember it. As to the claim of misuse, I'm not sure what your accusation asserts. There are conceptually connections between the formalisms of logic and of computer science, and certainly an overlap in ideas. That humans and computers both use grammar...
    – J D
    Jun 4 at 18:46
  • , both use logic, both are capable of algorithmic processing, and both exhibit the behaviors of Turing Machines is a matter of fact. To adduce CH to show that there are generalizations to be made between people and the machines built to emulate them, or that the metalanguage of logic and software are similar hardly seems an abuse or merits the claim of bad philosophical intent. Of course, I'm open to a complaint that goes beyond vague finger wagging. The question is whether you want to make the effort to articulate a useful complaint, which I certainly encourage you to do.
    – J D
    Jun 4 at 18:51
  • 1
    @Corbin I have amended my language to "One relevant result" to distance CH from the claim that preceded it. It is certainly possible to have misread some form of logical consequence between the two statements.
    – J D
    Jun 4 at 18:58
  • I didn't think writing an unlikely-to-be-accepted answer to be worth it. In short, objects are not to be understood in terms of classes; Kay says this directly, and also says that e.g. C++ classes are not what they had in mind. Rather, objects are to be understood like actors or biological cells or chemical proteins. As several other answers correctly note, objects are primarily about encapsulation and message passing.
    – Corbin
    Jun 4 at 23:37
9

If you are asking whether ontology had an influence on what are called objects in computer science, then the answer is probably "no". I was reasonably familiar with the literature from the beginning of the object-oriented program movement, and don't recall any discussion of that; however, there was a sort of philosophy behind object oriented languages if you mean philosophy in the general sense such as a philosophy of education or a philosophy of success in business.

There is a philosophy of programming languages, a sub-field of computer science that discusses the effectiveness of programming languages for certain tasks, or how good certain language features are. Object oriented programming languages and the variations in how objects are handled are very much influenced by the philosophy of programming languages.

As evidence that contemporary ontology has no influence on what are considered objects in computer science, here is an example where ontology could have lent some real insight to an issue of object-oriented languages but I've never seen it mentioned.

In most programming languages there are two sorts of references to objects: mutable and immutable. The details vary from language to language, but typically this comes up in the context of parameter passing. If you pass an object x to a function f, can x be modified by f or can't it? The C family of languages distinguish between broad classes of object: arrays can be modified, integers and floats cannot. However the descriptions of these broad classes are generally ad hoc and a bit confusing to new programmers. That's because the real reason has to do with implementation details rather than with the language abstraction itself, but you don't generally want to discuss implementation with new programmers. To add confusion, these implementation details can to some extent be overridden by declarations.

Some languages try to simplify things by distinguishing explicitly between mutable and immutable objects (objects that can change over time and objects that cannot), but this notion is also a bit ad hoc. There is some equivocation as to whether immutability is a property of the object itself or a property of a reference to the object. But some objects are just plain immutable, regardless of reference.

This whole situation could be greatly clarified (I claim) by appealing to the modern ontological distinction between abstract objects and physical objects. An immutable object is an abstract object like a number or a mathematical set. Regardless of implementation, it is not created or destroyed, and there is no operation to change it because it makes no sense to change it. What would it mean to change the number 2 to 3, or to add something to a mathematical set? A mutable object would be a physical object, something that exists in time, having a beginning and an end, and with various states in between.

People intuitively understand the difference between a number and a physical object. Why not exploit that intuition to make programming easier to understand? I suspect the reason no one has done this is because the people who design programming languages don't know anything about ontology.

4
  • if ontology has no influence to objects in computer science, then would it safe to say that I can analyze computer science objects via any philosophical theory about object? Or is it that I shouldn't do that because I should acknowledge that the word object as a polysemy? Similarly how the word bank is a polysemy, and I cannot use geological theories to analyze financial activities.
    – Ooker
    Jun 2 at 7:38
  • Some programming languages, such as Scala, have more or less well developed "ontologies" or at least hierarchies of classes, with an "empty" type (class) and an "any" type at the bottom and top, so the concept of classifying classes is not unknown (see "inheritance").
    – Frank
    Jun 2 at 11:45
  • @Frank, yes, absolutely, but these structures are more mathematical than philosophical. Jun 2 at 11:49
  • Abstract or concrete is usually used for the distinction of objects that are actually build and those that are just blueprints for other objects. While there in terms of being immutable there are several options for why that is the case. It could be a primitive such as numbers, but it could also be a constant or it could be because you're not dealing with the same object but a copy that is equivalent but not identical and so on.
    – haxor789
    Jun 3 at 5:06
4

I'm not convinced that there is a philosophical theory behind object-oriented programming in computer science, and I have been using OO since 1987. My first object oriented programs used objects in Turbo Pascal 5.5 to represent objects in the real world; this sort of naive OO probably does correspond to some equally naive physical theory. During the 1990s I started to move away from the data an instructions points of view, first to the idea that objects were "lumps of behaviour", and then I discovered Design Patterns: Elements of Reusable Object-Oriented Software, by Gamma, Helm, Johnson, and Vlissides. My code now uses objects & classes to encapsulate design decisions; some classes may correspond to real world objects, but most are very abstract. If my approach to coding has a philosophy, it corresponds to Bob Martin's definition of good design.

A piece of software that fulfills its requirements and yet exhibits any or all of the following three traits has a bad design.

  1. It is hard to change because every change affects too many other parts of the system. (Rigidity)
  2. When you make a change, unexpected parts of the system break. (Fragility)
  3. It is hard to reuse in another application because it cannot be disentangled from the current application. (Immobility)

Moreover, it would be difficult to demonstrate that a piece of software that exhibits none of those traits, i.e. it is flexible, robust, and reusable, and that also fulfills all its requirements, has a bad design. Thus, we can use these three traits as a way to unambiguously decide if a design is “good” or “bad”.

IMHO objects are nothing more than a means towards an end. Having a philosophical theory of objects is analogous to having a philosophical theory of bricks; a philosophical theory of buildings would be more valuable. I'm interested in Stewart Brand's idea of shearing layers, a philosophical theory of buildings that also works well for software.

9
  • +1 Thanks for the link to Martin's paper!
    – J D
    Jun 3 at 18:12
  • "we can use these three traits as a way to unambiguously decide" - I think that's obviously codswallop from Martin. The traits themselves are not "unambiguously" measurable in specific instances but are a question of judgment, and just because something is easy to alter and reuse doesn't make it "an unambiguously good design". (1/2)
    – Steve
    Jun 10 at 12:21
  • Most of the techniques that make individual objects easier to reuse, actually make the system as a whole harder to grasp in the first place. Often because of the presence of too many small objects which do little (artificially so, in order that they seem "reusable" without ever further modifying their innards), and too many constraints or workings expressed tacitly in their collective arrangement and construction (which is a complicated and fragile thing), rather than stated explicitly in a procedure. (2/2)
    – Steve
    Jun 10 at 12:25
  • @Steve (1) I've found Robert Martin's work useful building production software (medical devices). IMHO, my practical experience is more relevant to me than your humble opinion. (2) My experience has been that the word "obviously" is used as a shorthand for "argument weak here, thump pulpit loudly". But thank you for your opinion, for what it is worth. Jun 10 at 19:20
  • @SimonCrase, did you find his work useful in that you now judge the quality of your medical software purely by whether the software objects are flexible, robust, and reusable, as Bob Martin says is the "unambiguous" standard for software design? So for example, patient safety, or medical effectiveness, does not feature in your reckoning of whether the software design is good or not?
    – Steve
    Jun 10 at 19:49
2

Sorta.

It's a high level (in the sense of being several levels of abstraction removed from pushing bits) view of computer science that is supposed to be an analogy to how we structure our environment and solve problems in the real world. So yeah it explicitly and implicitly follows similar ideas.

Like the computer science objects are under the hood just attempts to encapsulate data and functionality under one name and place, to make them more accessible. Thus they follow the idea that objects are distinct entities, with which we interact via their properties, attributes and relations to other objects.

Like originally they were probably just a lazy attempt to avoid remembering loads of individual names, values and relations and just group them together to a useful entity.

But ones you have those entities it kinda influences how you think about that, which makes your problems somewhat philosophical. Like what actually is the computer object? Is it the space in memory addressed by the name? Is it the values that are currently stored there? Is it a certain type of data?

Now while usually you'd need to prompt nature for that or conjecture, in CS you can define, so different programming languages might actually just answer these questions with yes or no or different programmers could interact with them in a way that answers these questions for them.

Now they don't technically have to, but it certainly helps in terms of staying comprehensive to oneself and others if this follows a consistent philosophy.

Not to mention that as you've mentioned object oriented languages have build upon the concept of objects. So you can create forms or classes from which you can create objects, like idk you can create a class called tree that has properties of trunksize, diameter, height, leave form, ... and then create objects that have these properties but represent concrete trees like pine, apple tree, ... You can create interfaces that are compatible with every instance of the type tree. You can pass objects by value or by reference (so is the object what it looks like or is it the thing itself. So is a picture of a pipe a pipe?).

And again if you want that to be useful you'd have to follow some consistency and thus end up with similar questions as you might encounter in philosophy so explicitly or implicitly there is probably a philosophical theory in them. Though it might depend on the language and the programmer how they answered the questions that were left open.

6
  • So can I analyze computer science objects via any philosophical theory about object? Is there a philosophy theory about object that is not suitable here?
    – Ooker
    Jun 7 at 3:00
  • Rather the other way around you can use many philosophical theories as inspiration for design patterns on how to create and use computer science objects. Like the original approach seems to follow the "bundle theory" of objects, not sure the substance theory is very applicable as they share the same physical substance which is also completely ignored in computer science and the properties aren't really emerging from that. Could you give an example of how you would want to analyze them? What question or approach you would take?
    – haxor789
    Jun 7 at 10:42
  • Mostly I'm interested in the act of modulating the world into separated objects, as well as the recursibility, that is you can have objects inside objects like fractals. The method and class aspect of it are also interesting
    – Ooker
    Jun 8 at 10:39
  • As said primarily objects follow the bundle theory so an object makes it easy to interrogate properties, you simply ask "[Name].[Property]" and receive the corresponding properties value from the named object. Also within a system you might not have to exchange all the data but only the "name" which acts both as an identifier and encodes where to find it the entity. So there are concepts of uniqueness, equivalence and identity in use. And for several similar objects you'd look at what they have in common and abstract that to a class/concept so that an object becomes and instance of that.
    – haxor789
    Jun 8 at 11:15
  • With respect to recursibility, it's a bit of cheating. You can make a property of an object be an object itself idk if a tree has a fruit then both tree and fruit are objects themselves and the fruit can both be created by a tree and be the origin of another tree. Though the computer is kinda cheating in that, while we might forget it for how fast it goes, time goes incrementally and actions occur sequentially so the whole fractal doesn't actually exist but is created a step at a time.
    – haxor789
    Jun 8 at 11:22
1

Aristotle and Object Oriented Programming

https://dl.acm.org/doi/pdf/10.1145/331795.331862

This short paper contains many associations with Aristotle and the philosophical descriptions of reason. I am at a loss to try to selectively quote the material to provide a terse answer to the question.

In the Abstract:

Classifying is a central activity in object-oriented programming and distinguishes it from procedural programming. Traditional logic, initiated by Aristotle, assigns classification to our first activity in reasoning, whereby we come to know what a thing is. Such a grasp of the thing's whatness is the foundation for all further reasoning about it.

This connection between Aristotle's way of classifying and object-oriented programming is sometimes acknowledged, but rarely explored in depth. We explore this relation more closely and more carefully, in the hope that a better understanding of classification and programming can be gained from a study of philosophy than from many current text books on object-oriented programming.

In the Conclusion:

Traditional logic is concerned with developing the student's ability to understand what each thing is; that is, with developing the student's ability to handle meaning. This is important to all students insofar as they are human, and therefore their reasoning is concerned with content. It is doubly important to all students of computer science, whose future success will depend upon their ability to express complex technical ideas clearly to both computers and their colleagues. It is triply important to all students of object-oriented programming, and the reasons are twofold: (1) the form of object oriented programs reflects the form of the syllogism; and (2) traditional logic is where the ideas underlying classification are considered as such, without resorting to metaphor.

Object Oriented Programming Principles

https://indico.ictp.it/event/a05231/session/11/contribution/8/material/0/0.pdf

This is another rich paper which develops the concept of Abstraction as the fundamental principle of OOP driving concepts of polymorphism, inheritance, and encapsulation. But it may lack discussion of conceptual association with philosophical descriptions of reason.

1

I think there is philosophical theory behind OO programming, yes, although not necessarily an explicit and fully worked-out philosophy, and not necessarily a single coherent philosophy held by all.

As far as computer science is concerned, object-oriented programming is a particular set of programming practices where data and algorithms are combined together into units called objects, and which form the main concept which the programmer creates and arranges the manipulation of as part of programming work.

A common analogy for objects is that they are akin to manufactured machines which we handle or use on a daily basis, like say a wristwatch, or a car engine.

What I mean by machines are things with settings and moving parts, and which have some kind of surface designed for two-way human interaction (which is often much simpler than the innards of the machine) - such as how a wristwatch has a face and hands to display the time, and a dial for adjusting the time setting.

That is the usual analogy, which references a kind of machinery, and uses a kind of vocabulary, that is familiar to all.

The exact nature of objects (without resorting to analogies) might be clear only to those with fair knowledge of computer science, but an analogy that is even closer to the truth (than the common analogy already given) is that objects are like paper forms (of the everyday kind used for various corporate and bureaucratic purposes) which contain not only fields (boxes or marked areas on the form where data can be recorded or official stamps applied), but also carry a set of instructions detailing exactly how the form is to be used or modified by the clerk (and it mustn't ever be used by the clerk otherwise than in accordance with a procedure defined and stated on the form).

In the real world, and not least for reasons of economy and clerical convenience, paper forms don't typically carry these kinds of explicit procedures along with the data they record. Most commonly, forms which record data, and materials which record procedures (like rulebooks), are not both part of the same document. The procedures may refer to the data they handle, but the forms containing the data do not refer to the procedures.

With computers however, putting data and instructions always together, as "objects", is at least a feasible way of working.

There's a subtle but important philosophical difference between the analogies, which is that in the first analogy, the machinery itself has moving parts, whereas in the second analogy, there is only static information recorded on paper, and it is the human clerk that provides the dynamism.

The second analogy is closer to the computational reality in that "objects" are in fact static things (each existing in memory like sheets of paper, and unlike wristwatches and car engines), but the information recorded by objects are capable of being interpreted and handled by the computer machinery.

And as well as being more honest to the reality of how the computer works, the second analogy is also closest to the reality of how clerical work is done by human workers. As an expert, my own preferred understanding accords more closely with the second analogy.

Object-oriented programming, however, has become more closely associated with the ontology implied by the first analogy.

OO languages that were designed to make the associated programming patterns as tacit as possible, and avoid cluttered code, have also succeeded in obscuring the existence and nature of those patterns to a generation of programmers who grew up with OO languages at their zenith.

OO also reached its zenith largely after the era when corporate administration was first computerised (so that most opportunities had already passed for young workers to observe or participate in the most systematic and large-scale forms of routine clerical work executed by human hand - what remains to be seen done by hand today are often awkward or unsystematic tasks that don't easily correspond to what a computer can do).

Part of the promise of OO to the business world - not to mention to academia - was to make things simpler, and to allow programmers to work effectively with lower skills and less computer science knowledge.

Changing from an honest computer science-style philosophical paradigm, to one in which the output of programming work (in the form of "objects") seemed to more closely resemble manufactured goods, was a gambit to try and solve the so-called "productivity problem" in software.

The productivity problem being that the labour and difficulty/risk involved in designing computerised clerical (i.e. data processing) systems for corporations, seemed only ever to go upwards.

Part of the solution was to try and find a simpler conceptualisation - programmers would be encouraged to think about the nature of objects in the "real world", and then (supposedly) program these.

Reusability was another part of the solution. Objects would allow expert library programmers to develop a component, to be reused by others who didn't need that expertise. In the same way we can use wristwatches without being expert watch-makers, or builders can use steel without having to be steelmakers.

This plan can largely be seen to have failed - most software is worse than ever, more software projects than ever fail, wheels are constantly reinvented - but it's legacy is an industrial workforce and business community with often very poor philosophical understandings of the work, and has even led to academia largely forgetting exactly what is going on with programming.

It also failed because, more often than not, programmers haven't in fact been equipped to understand how things work in the real world - not even their own computers, let alone other people's jobs.

When programmers try to model the "real world" with objects, they more often come up with models that are simpleton in that they omit crucial details or workings that actually characterise the real world, but also models that are overly complicated in that they encourage focus on irrelevant aspects of the real world instead of modelling the clerical work in the simplest way possible.

So for example, new OO programmers often end up trying to think about modelling objects representing patients and their behaviours at the hospital, rather than thinking about how to model clerical records representing data about patients (and which needs to be primarily tailored around thr clinician's idea of what is relevant to record, and the clerk's view about how to work effectively with the records, nothing to do with what is "real" or not about the patient).

A final thing to say is that OO programming attracted and appealed to certain ideological interests, who saw an analogy between the conceptualisation of objects and their interactions within a program, and the nature of market capitalism and relations between individuals in that market.

This last link is the most logically tenuous and least readily articulated, but it's worth mentioning in passing that the perceived ideological resonance of OO programming - especially in the 1990s - also goes toward explaining how it gained so wide attention and positive reception.

9
  • Please accept my +1 for the "It has failed..." In particular this answer would merit a bounty if the paragraph clerical records representing data about patients was further expanded. IOW the only answer that comes close to saying OOP is wrongheaded not merely at the tech or even scientific level but at the most fundamental philosophical level. As for the capitalist part...hmmm. Never saw it that way... seems like a 'conspiracy theory' except that it's likely true given Sun spent half a billion dollars on advertising and propagating Java
    – Rushi
    Jun 5 at 1:25
  • @Rusi, I daren't touch it now it's done - I galloped through so much already! On the "capitalist" part, I'm not suggesting a conspiracy - much of the capitalist agenda was completely overt, when it came to things like deskilling - but it's worth mentioning how the philosophy of objects dovetailed more subtly into the liberal philosophy of individuals, and how OO programming had an aesthetic appeal particularly to American corporate management.
    – Steve
    Jun 5 at 14:34
  • "new OO programmers often end up trying to think about modelling objects representing patients and their behaviours at the hospital, rather than thinking about how to model clerical records representing data about patients" — I don't get what you mean here. Isn't that the record should be on one person? I get that a patient can have different records, but then each record can be a sub-object of the person object? I think the reason new programmers fail to tailor to what the clinician and the clerk need are simply because they don't study medical science and health administration?
    – Ooker
    Jun 8 at 11:43
  • 1
    @Ooker, a patient doesn't have records. A hospital has records. You're right that an absence of training is a problem, but so is mis-training. The big idea was once that you model "the real world" with objects, and that you think about what "attributes" and "behaviours" those objects have. But records don't have behaviours - clerks possess all the "behaviours" of a manual record-keeping system - and records may be about a patient but are not thereby an attribute of the patient. (1/2)
    – Steve
    Jun 8 at 15:43
  • 1
    The reality is that what methods represent are not "behaviours" of records (and certainly not behaviours of patients), but defined operations upon the records. And often, those operations do not belong to one record or another, but transform many records at once without being focussed on any single one of them. (2/2)
    – Steve
    Jun 8 at 15:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .