Is programming an emulation of the real world?

Question

Assume that we have a car in the real world, this car would be composed of atoms, and we can do operations on this car (for example: we can move the car or change its color, etc.).

And assume that we have a car object in the computer world (in RAM), this car object obviously is not a real car but rather a representation of a real car, but we can imagine that this car object is a real car, and we can also do operations on this car object (for example: we can move the car object or change its color, etc.).

Now if we want to for example change the color of the car in the real world, we have to manipulate some of the atoms that compose the car to accomplish that. And to change the color of the car object in the computer world (in RAM), we have to manipulate some of the bits that compose the car object to accomplish that.

However, one difference that I can think of between the real world and the computer world is that in the real world the car is visible to people, however in the computer world the car object is not visible to people (you have to paint the car object on the screen to make it visible to people).

So can we think of programming as an emulation of the real world? more specifically, can we think of the real world as "real world RAM" that can contain any object (these objects would be composed of atoms) in the same way that RAM can contain any object (these objects would be composed of bits)?

Answer 1

No.

Object oriented programming will at times model the real world, but as the old saying goes "all models are wrong, but some are useful". Even in the real world, changing the color of the car doesn't involve changing the state of the atoms in the car, but adding new ones that have the new color. The real world does not change its state so easily as a computer, and as we learn more about our physical world we're learning just how non-deterministic it is.

And unfortunately, many schools teach OOP via the "car" model of programming which is horrible. Modeling the real world one-to-one is very often a poor way to solve problems at hand. I'd recommend developing a better mental model for programming, one based more on coupling and reasons to change.

Answer 2

I would tend to think of programming as less about emulating the real world and more as a form of executable mathematical modeling. You can develop mathematical models for anything, even things with no real-world equivalent (which sometimes crosses over; the idea of non-Euclidean geometry was a sort of intellectual speculation until the Einsteinian revolution and boolean algebra would have seemed an odd curiosity before someone had the base tech to build a digital computer).

Mathematics demands rigor, not usefulness; programming is the same. I can certainly write simulations that closely approximate the real world, but there is nothing forcing this to be the case. Just like you can model systems that don't exist in nature, you can write programs that compute things with no analogue.

Answer 3

Thinking of a car as a collection of atoms isn't particularly useful, unless perhaps you're examining some quantum effect on the car, which is unlikely. A mechanic doesn't care about the atoms when he's turning a wrench on an engine bolt. He might care about the temperature of the engine, but that can be modeled by a simple measurement; you don't need the LHC to figure that out.

So what you're left with are everyday attributes, like the bolt's thread pitch, the size of the wrench that fits it, and the torque standard that must be applied to it when it is tightened. These are things that can be modelled inside a computer, and the computer can actually make predictions about what is likely to happen when you turn that wrench, based on those attributes.

Notice I haven't said anything about metallurgy, chemistry (the rusting of the bolt), or the physical fitness of the person turning the bolt. Neither you, nor the computer, need to be all-seeing in order to impart useful information from computing. Quite the opposite, in fact; we always rely on partial information when we are modelling anything, especially in a computer.

Does the computer always model real-world actions or consequences? No, of course not. Many abstractions in a computer are there for the sake of the computer itself. And many of those abstractions are, well, abstract. We have collections because many things can be modelled as a collection of entities (the "entity" being essentially a "noun"), including the controls on a User Interface. Those entities can be anything, including cars, but they can also be collections of numbers in a neural net, where you're actually taking some relationship in the real world, breaking it down into bits, and modelling the continuous relationship between input and output. That's pretty far afield from, say, a baseball that you're simply holding in your hand.

Remember, all the computer knows about that paint color you're about to paint your car with is the formula for mixing the pigments that produce that color. It doesn't actually know anything more about the paint, unless you tell it.

Answer 4

OO is not about the "real-world". Not in the sense a lot of people seem to think it is.

Objects are supposed to model your very special, and narrow view of something in the context of the problem you are supposed to solve.

If the context of traffic policing a car may have just one method ticket(). In the context of leasing, it may have lease(), repossess(), whatever. In the context of garbage disposal it may have destroy(): Tonnage, or whatever.

An objective "car" does not exist. Indeed no objects nor model exists without context. This is why any design / architecture that starts with "let's define what a car is" is wrong. This is also why comments like "but a car doesn't lease itself in the real-world" don't make any sense. We don't model the real-world.

Answer 5

What does "emulating the real world" even mean? Does it mean emulating all aspects of a car which took millions of man hours to conceive, refine, and manufacture?

Or does it mean taking some programmer, probably one with very little experience in mechanics or mechanical engineering, and modelling their naive conception of what the essence of a car is?

I agree with @Michael's answer that ultimately programming is more like an executable mathematical model. Certainly a program is far more similar to maths than to the "real world" if that means physical things.

But more pertinently, what is being modelled in the first place is not the real world at all, but some human conception of it.

In the "real world modelling" paradigm, the programmer is cast as somebody who simply measures or detects (in a routine or fairly routinised way) the features of some thing that already exists "in the real world", and translates that into object-oriented code. It's presumed to be obvious enough what features a car has and how the whole thing hangs together in order to be a useful machine.

In the actual real world, the thing to be modelled is often some new implementation of ideas or principles - or else anything that does "really" exist is to be further modified in some way as part of the translation to a computer program - so the programmer really ends up as the designer and midwife of some new conception. And that role of designer remains a professionally expert role, involving massive knowledge, judgment, creativity, and ingenuity.

And that is really where this paradigm fell down: it does not itself reflect the real world of software development.

Answer 6

In the general sense object-oriented programming is not an emulation of anything. At best it can be used to make analogies to real-world objects, more for convenience of programmers than anything implicit in programming or OO itself. In my experience these analogies are most often learning or comprehension aids and when you get down to the fine details the analogy falls down - unsurprisingly, since this is the nature of analogy.

Your car example is a little mixed. Yes, we can create a Car object that models aspects of a real-world concrete instance. We can make it as detailed as we like but the object in the computer is at best only a description of the real-world object and some subset of the real car's properties. We can perhaps use some physics simulations to affect the virtual car, but inside the computer you've got only analogs of the various physical properties.

however in the computer world the car object is not visible to people

In the real world we see things by intercepting photons that have bounced around and eventually impacted on our retinas. The photons that happened to bounce of the car will carry information about their interaction with the car's surface. There is no such thing in the computer, no "world" with photons bouncing around only memory, storage, I/O, etc.

So no, nothing can "see" anything inside the computer's memory. The best you can hope for is to build an emulation of sight, or analogise sight into something like "able to read an object's properties" or some such thing.

The problem is that we talk about these analogies as though they were much more than they are simply because it's the simplest way to get an idea across. We talk about pages, handles, windows, streams, pointers... all words that have concrete physical meanings that often are only vaguely related to the computer terms. We use the words because they are useful. I know that a handle is an index that is used to calculate an offset into a block of memory that contains the bytes which the operating system uses to record meta-data about a digital resource of some kind... but I only have to think "handle" because there's no reason to think about memory, metadata, etc. while I'm opening a file or working with a UI element, or... and so on.

So no, there is no equivalence between the real world and the internal state of your computer, no matter how many layers of abstraction you put in there.