Real World Model

There seems to be a divide in opinion about whether our software should model the real world, and how closely it should. OO was born in physical modeling (Simula-67). Some say OO software development should stick to its roots. Others reject the notion. Famous quote:

"If airplanes were modeled after the real world, they would have wings that flap instead of propellers."

Note that being internally modeled after the real world and externally (UI) resembling the real world are not necessarily the same thing.

The real world is often limiting. Rolodexes cannot easily have multiple indexes, so just because a user uses a Rolodex does not mean we should carry over a single index or ordering into a replacement. The goal of Simula was usually to predict and optimize physical movement rather than make overall processes more efficient. A physical modeler might try to find the best place to put or move a tugboat, while an information analyst might look for ways to get rid of tugboats altogether by making smarter ships perhaps.

I can't help but believe OO would be dreadful for physical optimization problems relative to LogicProgramming languages. For one-way simulations OO works well enough, but OO needs considerable enhancements to support backtracking and following variations in paths forward.

Is the thought of an imaginary creature a real thought?

My invisible friend thinks so.

Consider two simulations:

a dinosaur stalks around on a map of terrain
a ping-pong ball bounces around a floor covered with spring-loaded ping-pong ball paddles

Are you going to model the first one different from the second, just because a dinosaur has a brain slightly larger than a ping-pong ball? --PhlIp

Of course! The ping pong ball would never "eat" anything. There are a multitude of differences, depending upon the relevant abstractions.--PeterOlcott?

My requirements did not include the dinosaur eating anything.

If you try to say "but dinosaurs are 'more likely' to eat things", then what about less "likely" requests, such as sniffing flowers or rolling in grass?

Further, eating things decouples from movement around a terrain. So there's no overwhelming need for a single object with both abilities, even though a dinosaur is (was) a real object in the "real world" with both abilities.

Movement and eating are not decoupled (in water may be different), from an evolutionary point of view: do plants move? However this doesn't influence the discussion. I think I agree with PhlIp--FedericoSpinazzi?

Even if we had some dinosaurs to work with, reductionism over brains has not yet achieved models of the fidelity required to simulate brains on the physical level. For dinosaurs, thus, any simulation of movement will likely require a simulation of motivation and the various influences upon it (including instinct, knowledge, and prediction... with 'instinct' including desires to eat, rest, survive). The degree to which our simulation will plod about like a real dinosaur would depend on the degree to which our simulation of motivations is accurate (not that we could falsify any but the most extremely erroneous models, but we could use other old animals (turtles, crocs, etc.) to gain some confidence). So I'll agree with Peter: the fact that a dinosaur might 'eat' something, and the various motivations surrounding such a behavior, are very significant. I believe I can say with some confidence that ping-pong balls can be accurately modeled without concerns for motivation.

DoubleEntryBookkeeping is an example where processing for the physical world are no longer needed for a virtual world. We don't need double entries if we do it on computer. They are a violation of OnceAndOnlyOnce.

Actually, DoubleEntryBookkeeping is not inherently a violation of OnceAndOnlyOnce. DoubleEntryBookkeeping systems represent a model of financial accounting that is expected by banks, auditors, accountants, tax officers and so on, but it does not have to be -- and usually isn't -- implemented in computer systems in a manner that violates OnceAndOnlyOnce. When done properly, the only thing "double entry" about it is the fact that each transaction references at least two distinct accounts.

It's not clear where the first paragraph and second paragraph contradict each other. I'm not sure what it is correcting. Perhaps you meant that "double entry" doesn't refer to amount duplication, but merely two accounts being involved. This differs from how I remember it taught, but without an "official" definition authority to reference, I will let it be. (Related: AccountingModeling.)

The first paragraph seems to be a misunderstanding of what DoubleEntryBookkeeping is, perhaps under the assumption that "double entry" forces duplication in violation of OnceAndOnlyOnce. It doesn't, except in certain situations where manual data entry is required. In such cases, a set of "double entries" are still distinguished by distinct timestamps and account references; their common elements (amount, date/time of "real world" transaction, and possibly a reference number and description) serve as a form of data-entry validation on distinct entries (that refer to the same real-world data, which needs to be recorded in the bookkeeping system) made at differing times. As a broader suggestion to those who recommend eliminating DoubleEntryBookkeeping: Understand it before you decide to eliminate it.

What would be a better name for the technique that requires the same amount be placed into two different "slots"? This is what the author was referring to I believe.

No new name is required. It should be noted that DoubleEntryBookkeeping defines both a model of financial accounting, and a means to validate manual data entry. The former can exist in the absence of the latter without any duplication of any kind -- but this is only appropriate for totally automated systems or environments with a relatively small number of manually-entered transactions. Requiring users to record the same entry twice, under differing contexts, is a common method of validating entry and facilitating error detection without violating OnceAndOnlyOnce in its usual code sense. It is a violation of OnceAndOnlyOnce in that the same "real world" datum is recorded twice, but this meets the requirements for data-entry validation and error detection.

Duplication, full or partial (such as parity bits), is a common form of error detection. OnceAndOnlyOnce is frowned upon in the "logical" world but is successfully used by the physical world for error detection/prevention/recovery.

Well said.

ThingsThatAreDifferentAreNotTheSame -- BobTrower