5 ms·

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some conc

by ben509 7y ago

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some concerns (e.g. file I/O and word splitting). It's odd he makes these complaints, because the comment he's responding has this caveat: > unless they are talking about writing a clone of The Sims or something In the context of a game or simulation, such classes can absolutely do all these things. And those seem entirely reasonable ways to teach someone about programming, while being more accessible and engaging than "let's talk about how to write an IO stack." * > Penguins don’t implement the “fly” method that can be found in birds. That's an important issue, though, which an OO tutorial needs to deal with. It points at two major problems: 1. The circle-ellipse problem[1]. 2. That nominative types have all the inherent problems that taxonomy has. And since one solution is "duck typing"[2] it's worth noting that it's entirely clear what it means, despite being named after ducks. [1]: https://en.wikipedia.org/wiki/Circle-ellipse_problem https://en.wikipedia.org/wiki/Circle-ellipse_problem [2]: https://en.wikipedia.org/wiki/Duck_typing https://en.wikipedia.org/wiki/Duck_typing * IO stacks are good to learn, but to do them in OO you have to understand IO first, and though it's very satisfying when you get tricky IO code right, it's not really something you can show to your friends.

overgard 7y ago
Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You would see similar things in something like Unreal, or even in-house engines. The implementation is likely also to be way more interested in acting on aggregate data streams rather than enforcing strict encapsulation and object boundaries and such. It's still very OOP, but not in the sense of representing real-world taxonomies. I know there's an argument that this real-world metaphor is good for beginners, but at least in my personal experience I don't think that's the case. I remember when I was a kid, my dad tried to teach me coding with a lot of object oriented examples with like Cats and Dogs and stuff. He was really well meaning, but it never really made sense to me. I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global. Awful code, but 10 year old me was able to reason about that a lot easier than polymorphism/encapsulation/scoping/etc.
- eckza 7y ago
  > I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global. An aside: It's okay to learn that way, when you're 10. A lot of my own big programming revelations have come from ignoring best practices and accidentally trying to implement or construct them from first principles once my problem becomes unmanageable. "Doing it wrong" is an even better teacher than "doing it right all of the time", because the mistakes you make can lead you to a deeper understanding of why things are done a certain way.
  - overgard 7y ago
    Totally agree. I think we make a mistake trying to harp on doing things "right" too much for new programmers, because they end up with analysis paralysis.
    - TeMPOraL 7y ago
      That's my current approach to teaching people programming concepts. I try to provide an example of not using that concept, point out the quickly growing complexity of the code, and then show how that complexity can be reduced with the new concept I'm introducing. (And yes, as a kid, I was hurt by all those "Cat : public Animal" examples too. It took me many years before I figured out why they didn't work in practice for me.)
    - abricot 7y ago
      I think this is why you often see people reinvent GOTO. Everyone who started with BASIC (and moved on) knows why you won't do that any more. But someone today starting with python might not understand. [replace GOTO with any bad example]
- ben509 7y ago
  TBH, I haven't written any real games, and the simulation work I do is in finance, so if we have an account, it's really just an account. But securities and accounts and such are all well-defined abstractions that lend themselves very well to direct representation in code, so my experience is not representative. Maybe it's possible to be less misleading, but I still think it's a mistake to try to write a tutorial that tries to present basic concepts in the fashion that production code is written. There's just so much stuff you do in prod that is not relevant to the concepts you're trying to convey. > I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place... I learned on a C64 when I was a kid, too. I'd absolutely recommend learning structured imperative programming before OOP.
ben509 7y ago
I think my broader criticism of this complaint is that they aren't considering the pre-requisite mastery problem. > Here’s an example that I think would be better to use instead: the `Visible` hierarchy in [Pygmusic][], which is a kind of software drum machine. A `Timer` is a horizontal strip on the screen with a stripe racing across it. A `NumericHalo` is a spreading ripple on the screen that fades. That's how someone experienced in OOP is going to do it. The problem is that this depends on experience and knowledge of how such a system works. I don't think this would be significantly better than the Vehicle-Car examples, because your target audience is seeing this odd layout and you aren't likely able to give them reasons why it should be that way. To fully explain yourself would require information you can't reasonably impart in a tutorial. You know why it's done that way, but the underlying rules are obvious and intuitive to you because you worked on them long enough. These rules manifest in a trained developer as an intuition that is developed by the feedback of doing things and failing or succeeding. Maybe they could be expressed mathematically, but it'd probably be very specialized math like advanced linguistics. > In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication Maybe we should really stop talking about "objects" and "classes" entirely? Non-OOP structured programming doesn't have this problem; it's hard to grasp exactly when two subroutines are overly coupled, but it's easy to explain that sharing state and having action at a distance is a bad idea. And, generally, it's just not claiming any subroutine represents a real life "object". The only hierarchy imposed is the hierarchy of control flow.
- jameshart 7y ago
  The thing OO tutorials steeped in real world hierarchies are missing, though, is that understanding the concept of a hierarchy is not the hard part. Understanding what hierarchies are interesting in factoring a problem into code is the hard part that the student needs to understand.
  - TeMPOraL 7y ago
    And the key part of the problem is understanding that hierarchies and categories are completely arbitrary, and their value is determined by how useful they are. There's no one holy taxonomy. Real-world examples can be used to point that out. Whales are mammals to biologists, but they're essentially fish to the economy. A bat is a mammal and an airplane is a vehicle, but both of them go into the same bag as birds if your main concern is "things that can fly" vs. "things that can't". Square is a special form of rectangle to mathematicians, but it's the other way around if your main concern is how much information you need to draw it. "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad." Etc. Once you crack the student's belief in there being one proper taxonomy for everything (a belief that strangely seems common even in adults in general population), you can then effectively show them that one of the main tasks of a programmer is finding the most useful way of categorizing things they're dealing with - and once that's done, the programming languages tend to have tools that let the programmer exploit such categorizations to minimize complexity.
fenomas 7y ago
> In the context of a game or simulation, such classes can absolutely do all these things Sure, but the point of TFA is that even then it still doesn't (necessarily) make sense to give them an OO hierarchy similar to their real-world taxonomy. It might make sense of course, but it might not - you can't tell without looking at the code. The point here is that duck/bird analogies imply that the real-world relationship between ducks and birds tells you something about whether your Duck class should inherit from a Bird class, when in fact it doesn't.
kragen 7y ago
> It's odd he makes these complaints, because the comment he's responding has this caveat: > > unless they are talking about writing a clone of The Sims or something Although I formatted it as a quote, I wasn't quoting or responding to somebody else in that part. That part about the Sims was part of the somewhat flippant principle I was proposing. The litany about ducks was just to explain the reasons for it. It wasn't a rebuttal. We regret the inconvenience.
- ben509 7y ago
  Even though I disagree with it, I think it was still a valuable point. And everyone should deliver a litany about ducks at some point in their life.
  - kragen 7y ago
    I'm glad I've passed that point now.
- DonHopkins 7y ago
  The Sims actually uses "subject oriented programming", and it even personalizes objects and objectifies people! ;) It's actually implemented in C++ of course, but it has a virtual machine that executes a noodly visual programming language called "SimAntics". And by noodly, I mean optimized for spaghetti code, containing intertwined loops, floppy, and droopy... https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74da3#d23a https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74d... Subject Oriented Programming This is described by some people as object — not Object Oriented Programming, but Subject Oriented Programming. Objectifying People People are objects, so when you click on another person, the items that you get in the menu depend on your mood, and your relationship with that person. (From the transcript of this demo video:) https://www.youtube.com/watch?v=-exdu4ETscs https://www.youtube.com/watch?v=-exdu4ETscs The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that I developed for The Sims with Will Wright at Maxis and Electronic Arts. http://radar.oreilly.com/2009/03/interview-will-wright-sims-a.html http://radar.oreilly.com/2009/03/interview-will-wright-sims-... Will Wright: Well, one of the first challenges was could we develop a really robust model of human behavior test so that we could put these little characters in the elements in any situation they would behave reasonably. A Sims user is kind of controlling the environment. They can put the Sims in a wide variety of potential environments and then the Sims have to act reasonable. So we kind of had to develop a very — well, on the surface, it looks like an object-oriented programming model, but in fact, it’s what’s technically called a subject-oriented programming model. But I won’t get into that detail. So developing this robust kind of behavior system — in fact, it was environmentally distributed intelligence is the way we solved it. But on the design side, there was a lot of thought about how much autonomy do these characters have versus how much reliance do they have on the player directing their actions. And there was also a whole dimension of thought around how much are we going to let the player read in to the simulation. In other words, how much of the simulation are we going to offer them to play of imagination versus make very clear and overt? https://www.gamedev.net/forums/topic/697362-need-some-advice-on-interactable-entites-in-ecs/?tab=comments#comment-5382061 https://www.gamedev.net/forums/topic/697362-need-some-advice... All8Up Moderator Posted June 15, 2018 From the way the embedded code is shown, I would say the first thing to do is reverse the logic. What I mean is that what you posted suggests that the code is along the lines of "I'm trying to interact with you" and "I need to figure out what you are and what I can do to you". Conceptually of course is the most sensible solution, unfortunately in practice it is also the solution which fails the most often. Rather than this, I've always used subject oriented programming for interactions. This reverses the logic such that rather than the 'doer' figuring things out the subject of the interaction performs the work. Basically this means that the input system would simply set a flag on the input component saying "this entity wishes to interact". The interaction system can then do pre-cull for subject entities which are in range, which ones can be used from the doer's position, etc. Finally, you end up with a door that runs the rule checks: "You are in range, you have my key, it is Monday after noon, you are wearing a purple shirt... Ok, guess I will open now." As to how you implement these things in the ECS itself, I suspect everyone does it differently. Personally I use a handle based approach where the interaction component simply contains a handle which refers to usually a script which checks the interaction rules. The script gets the doer and subject ID's so it can check states and make the decision. Then, likely in another script, an action is performed. Overall this probably sounds ass backwards but it is a well proven solution to removing massive 'if/else' checks. It is also great for expansion packs and such since all the new logic is contained in the subject and you don't have to patch the doer code to understand the new interaction. Just as an example, The Sims used(still uses I assume) this subject oriented approach which allows DLC to be dropped in and mostly just work. Hope this makes sense. http://ivizlab.sfu.ca/arya/Papers/SW/SOP.pdf http://ivizlab.sfu.ca/arya/Papers/SW/SOP.pdf Subject-Oriented Programming (A Critique of Pure Objects). William Harrison and Harold Ossher. Abstract Object-Oriented technology is often described in terms of an interwoven troika of themes: encapsulation, polymorphism, and inheritance. But these themes are firmly tied with the concept of identity. If object-oriented technology is to be successfully scaled from the development of independent applications to development of integrated suites of applications, it must relax its emphasis on the object. The technology must recognize more directly that a multiplicity of subjective views delocalizes the concept of object, and must emphasize more the binding concept of identity to tie them together. This paper explores this shift to a style of object oriented technology that emphasizes the subjective views: Subject-Oriented Programming. https://en.wikipedia.org/wiki/Subject-oriented_programming https://en.wikipedia.org/wiki/Subject-oriented_programming In computing, subject-oriented programming is an object-oriented software paradigm in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions (“subjects”) of the objects. The term and concepts were first published in September 1993 in a conference paper[1] which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996. As illustrated in that paper, an analogy is made with the contrast between the philosophical views of Plato and Kant with respect to the characteristics of “real” objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird’s nor the tax-assessor’s additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant’s analysis, the same may be true even of characteristics we think of as intrinsic.

by ben509 7y ago

overgard 7y ago

Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You would see similar things in something like Unreal, or even in-house engines. The implementation is likely also to be way more interested in acting on aggregate data streams rather than enforcing strict encapsulation and object boundaries and such. It's still very OOP, but not in the sense of representing real-world taxonomies. I know there's an argument that this real-world metaphor is good for beginners, but at least in my personal experience I don't think that's the case. I remember when I was a kid, my dad tried to teach me coding with a lot of object oriented examples with like Cats and Dogs and stuff. He was really well meaning, but it never really made sense to me. I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global. Awful code, but 10 year old me was able to reason about that a lot easier than polymorphism/encapsulation/scoping/etc.

eckza 7y ago
> I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global. An aside: It's okay to learn that way, when you're 10. A lot of my own big programming revelations have come from ignoring best practices and accidentally trying to implement or construct them from first principles once my problem becomes unmanageable. "Doing it wrong" is an even better teacher than "doing it right all of the time", because the mistakes you make can lead you to a deeper understanding of why things are done a certain way.
- overgard 7y ago
  Totally agree. I think we make a mistake trying to harp on doing things "right" too much for new programmers, because they end up with analysis paralysis.
  - TeMPOraL 7y ago
    That's my current approach to teaching people programming concepts. I try to provide an example of not using that concept, point out the quickly growing complexity of the code, and then show how that complexity can be reduced with the new concept I'm introducing. (And yes, as a kid, I was hurt by all those "Cat : public Animal" examples too. It took me many years before I figured out why they didn't work in practice for me.)
  - abricot 7y ago
    I think this is why you often see people reinvent GOTO. Everyone who started with BASIC (and moved on) knows why you won't do that any more. But someone today starting with python might not understand. [replace GOTO with any bad example]
ben509 7y ago
TBH, I haven't written any real games, and the simulation work I do is in finance, so if we have an account, it's really just an account. But securities and accounts and such are all well-defined abstractions that lend themselves very well to direct representation in code, so my experience is not representative. Maybe it's possible to be less misleading, but I still think it's a mistake to try to write a tutorial that tries to present basic concepts in the fashion that production code is written. There's just so much stuff you do in prod that is not relevant to the concepts you're trying to convey. > I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place... I learned on a C64 when I was a kid, too. I'd absolutely recommend learning structured imperative programming before OOP.

ben509 7y ago

I think my broader criticism of this complaint is that they aren't considering the pre-requisite mastery problem. > Here’s an example that I think would be better to use instead: the `Visible` hierarchy in [Pygmusic][], which is a kind of software drum machine. A `Timer` is a horizontal strip on the screen with a stripe racing across it. A `NumericHalo` is a spreading ripple on the screen that fades. That's how someone experienced in OOP is going to do it. The problem is that this depends on experience and knowledge of how such a system works. I don't think this would be significantly better than the Vehicle-Car examples, because your target audience is seeing this odd layout and you aren't likely able to give them reasons why it should be that way. To fully explain yourself would require information you can't reasonably impart in a tutorial. You know why it's done that way, but the underlying rules are obvious and intuitive to you because you worked on them long enough. These rules manifest in a trained developer as an intuition that is developed by the feedback of doing things and failing or succeeding. Maybe they could be expressed mathematically, but it'd probably be very specialized math like advanced linguistics. > In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication Maybe we should really stop talking about "objects" and "classes" entirely? Non-OOP structured programming doesn't have this problem; it's hard to grasp exactly when two subroutines are overly coupled, but it's easy to explain that sharing state and having action at a distance is a bad idea. And, generally, it's just not claiming any subroutine represents a real life "object". The only hierarchy imposed is the hierarchy of control flow.

jameshart 7y ago
The thing OO tutorials steeped in real world hierarchies are missing, though, is that understanding the concept of a hierarchy is not the hard part. Understanding what hierarchies are interesting in factoring a problem into code is the hard part that the student needs to understand.
- TeMPOraL 7y ago
  And the key part of the problem is understanding that hierarchies and categories are completely arbitrary, and their value is determined by how useful they are. There's no one holy taxonomy. Real-world examples can be used to point that out. Whales are mammals to biologists, but they're essentially fish to the economy. A bat is a mammal and an airplane is a vehicle, but both of them go into the same bag as birds if your main concern is "things that can fly" vs. "things that can't". Square is a special form of rectangle to mathematicians, but it's the other way around if your main concern is how much information you need to draw it. "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad." Etc. Once you crack the student's belief in there being one proper taxonomy for everything (a belief that strangely seems common even in adults in general population), you can then effectively show them that one of the main tasks of a programmer is finding the most useful way of categorizing things they're dealing with - and once that's done, the programming languages tend to have tools that let the programmer exploit such categorizations to minimize complexity.

fenomas 7y ago

> In the context of a game or simulation, such classes can absolutely do all these things Sure, but the point of TFA is that even then it still doesn't (necessarily) make sense to give them an OO hierarchy similar to their real-world taxonomy. It might make sense of course, but it might not - you can't tell without looking at the code. The point here is that duck/bird analogies imply that the real-world relationship between ducks and birds tells you something about whether your Duck class should inherit from a Bird class, when in fact it doesn't.

kragen 7y ago

> It's odd he makes these complaints, because the comment he's responding has this caveat: > > unless they are talking about writing a clone of The Sims or something Although I formatted it as a quote, I wasn't quoting or responding to somebody else in that part. That part about the Sims was part of the somewhat flippant principle I was proposing. The litany about ducks was just to explain the reasons for it. It wasn't a rebuttal. We regret the inconvenience.

ben509 7y ago
Even though I disagree with it, I think it was still a valuable point. And everyone should deliver a litany about ducks at some point in their life.
- kragen 7y ago
  I'm glad I've passed that point now.
DonHopkins 7y ago
The Sims actually uses "subject oriented programming", and it even personalizes objects and objectifies people! ;) It's actually implemented in C++ of course, but it has a virtual machine that executes a noodly visual programming language called "SimAntics". And by noodly, I mean optimized for spaghetti code, containing intertwined loops, floppy, and droopy... https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74da3#d23a https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74d... Subject Oriented Programming This is described by some people as object — not Object Oriented Programming, but Subject Oriented Programming. Objectifying People People are objects, so when you click on another person, the items that you get in the menu depend on your mood, and your relationship with that person. (From the transcript of this demo video:) https://www.youtube.com/watch?v=-exdu4ETscs https://www.youtube.com/watch?v=-exdu4ETscs The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that I developed for The Sims with Will Wright at Maxis and Electronic Arts. http://radar.oreilly.com/2009/03/interview-will-wright-sims-a.html http://radar.oreilly.com/2009/03/interview-will-wright-sims-... Will Wright: Well, one of the first challenges was could we develop a really robust model of human behavior test so that we could put these little characters in the elements in any situation they would behave reasonably. A Sims user is kind of controlling the environment. They can put the Sims in a wide variety of potential environments and then the Sims have to act reasonable. So we kind of had to develop a very — well, on the surface, it looks like an object-oriented programming model, but in fact, it’s what’s technically called a subject-oriented programming model. But I won’t get into that detail. So developing this robust kind of behavior system — in fact, it was environmentally distributed intelligence is the way we solved it. But on the design side, there was a lot of thought about how much autonomy do these characters have versus how much reliance do they have on the player directing their actions. And there was also a whole dimension of thought around how much are we going to let the player read in to the simulation. In other words, how much of the simulation are we going to offer them to play of imagination versus make very clear and overt? https://www.gamedev.net/forums/topic/697362-need-some-advice-on-interactable-entites-in-ecs/?tab=comments#comment-5382061 https://www.gamedev.net/forums/topic/697362-need-some-advice... All8Up Moderator Posted June 15, 2018 From the way the embedded code is shown, I would say the first thing to do is reverse the logic. What I mean is that what you posted suggests that the code is along the lines of "I'm trying to interact with you" and "I need to figure out what you are and what I can do to you". Conceptually of course is the most sensible solution, unfortunately in practice it is also the solution which fails the most often. Rather than this, I've always used subject oriented programming for interactions. This reverses the logic such that rather than the 'doer' figuring things out the subject of the interaction performs the work. Basically this means that the input system would simply set a flag on the input component saying "this entity wishes to interact". The interaction system can then do pre-cull for subject entities which are in range, which ones can be used from the doer's position, etc. Finally, you end up with a door that runs the rule checks: "You are in range, you have my key, it is Monday after noon, you are wearing a purple shirt... Ok, guess I will open now." As to how you implement these things in the ECS itself, I suspect everyone does it differently. Personally I use a handle based approach where the interaction component simply contains a handle which refers to usually a script which checks the interaction rules. The script gets the doer and subject ID's so it can check states and make the decision. Then, likely in another script, an action is performed. Overall this probably sounds ass backwards but it is a well proven solution to removing massive 'if/else' checks. It is also great for expansion packs and such since all the new logic is contained in the subject and you don't have to patch the doer code to understand the new interaction. Just as an example, The Sims used(still uses I assume) this subject oriented approach which allows DLC to be dropped in and mostly just work. Hope this makes sense. http://ivizlab.sfu.ca/arya/Papers/SW/SOP.pdf http://ivizlab.sfu.ca/arya/Papers/SW/SOP.pdf Subject-Oriented Programming (A Critique of Pure Objects). William Harrison and Harold Ossher. Abstract Object-Oriented technology is often described in terms of an interwoven troika of themes: encapsulation, polymorphism, and inheritance. But these themes are firmly tied with the concept of identity. If object-oriented technology is to be successfully scaled from the development of independent applications to development of integrated suites of applications, it must relax its emphasis on the object. The technology must recognize more directly that a multiplicity of subjective views delocalizes the concept of object, and must emphasize more the binding concept of identity to tie them together. This paper explores this shift to a style of object oriented technology that emphasizes the subjective views: Subject-Oriented Programming. https://en.wikipedia.org/wiki/Subject-oriented_programming https://en.wikipedia.org/wiki/Subject-oriented_programming In computing, subject-oriented programming is an object-oriented software paradigm in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions (“subjects”) of the objects. The term and concepts were first published in September 1993 in a conference paper[1] which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996. As illustrated in that paper, an analogy is made with the contrast between the philosophical views of Plato and Kant with respect to the characteristics of “real” objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird’s nor the tax-assessor’s additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant’s analysis, the same may be true even of characteristics we think of as intrinsic.