Dont Eat The Menu

I saw reference to this on OTUG by someone. "The menu listing of the meal is NOT the meal".

Also, seems like someone referred to a current methodology book coming out now, that has a picture of a boat, and a picture of a cad drawing of a boat, and under each was the admonition: "This is not a boat".

Perhaps this is biting me as I try to learn OO. Some say that the "model the real world in code" is bunk. Some say TheSourceCodeIsTheDesign.

More Later. Any thoughts? JohnClonts

In the mid-1900s, Magritte did a series of paintings on this theme. He drew a picture of a pipe, and within the painting wrote the words, "Ceci n'est pas un pipe", "This is not a pipe". For some of us, this painting was a mystery - of course it's a pipe! But he was referring to the confusion between the pipe as what we smoke with vs his oils on canvas, which only remind us of a pipe.

''I don't think Magritte meant this. Remember, this was part of the surrealist movement (with connections to dadaism). While I like your interpretation and have observed it myself, Magritte was trying to show a treason of words. The treason was saying a pipe was not, in fact, a pipe. In fact, I think if possible, a real pipe would have been used. The true and real pipe would then have a caption declaring that "This is not a Pipe!" -- RobertDiFalco

And yet, the painting is titled 'La Trahison des images': the treachery or the betrayal of images. -- GrahamHughes

According to Robert Hughes the phrase became a condensed manifesto about language and the way meaning is conveyed, or blocked, by symbols. So, there is a sort of treachery of both words and images.

No, no....Magritte was playing with signification and meaning -- the illustration of a pipe only signifies the real pipe, but you cannot point to the signification and say "there is a pipe." That would be confusing TheMapWithTheTerritory?.

It becomes interesting when you are dealing with software and mind-body problems. Searle argues that just as a computer simulation of a thunderstorm doesn't get anyone wet, so a computer simulation of a human won't really be conscious. I think he's wrong; in this case you can eat the menu. -- DaveHarris

He is obviously wrong: a lot of people get wet in that computer simulation! -- PhilippeDetournay

I have two strong hypotheses (to me all of living is hypothesis exploration, so someone else might write "I have two strong beliefs"):

My job is not to build models of the world. It is to build software. So I disapprove of the notion, "Model the world, then cast it into code". There are many, many valid models of the world, many of which will not make good software design. However, there are also a number that will make good software design. How do you tell which your initial "model of the world" will turn out to be? Answer: only after you examine it close to, or in, the final code will you know. So choose one and check it, be prepared to change your mind.
The final code, when nicely done, will contain a meaningful model of the world. If it doesn't - and you're doing OO - then you can significantly improve the design, still.
In the end, the source code wins. The drawings, if they differ from the code, are the ones that are "wrong" (a weak version of "wrong", they may still be useful). I don't believe TheSourceCodeIsTheDesign in the sense that you can learn the design easily from reading it. It contains the design in the sense that all other documents are quite likely to be out of date.

Alistair Cockburn

This is interesting, Alistair. I think I see an assumption about the singularity of problem and solution, though. A solution in the form of a software program often embeds a model of the problem. This is especially true of control type software. I think you are pointing to instances where this embedded model will not be the case, which is fine. To me, the advice "model the world, then cast it into code" carries this assumption in the word it. The advice might be more applicable if it said "model the world, then cast your response to that model into code." I wouldn't dispense with the modeling, for fear of losing that needed depth of problem understanding. -- WaldenMathews

I belong to the "modeling the real world in code is bunk" school. Many of the things we create in software are new things, and consequently there is nothing in the real world beforehand to model them on. Even when there is, the resemblance between the real world entity and the computer program is superficial. For example, word processors are not computer models of either pencil and paper or typewriters. -- CurtisBartley

Sure they are -- they are just so fast that it seems substantively different. Think about it this way: any word processor operation models rewriting the whole document, but with only the one change you asked for, and only on a model of the paper that appears on the screen. It does this for every character you enter or delete, or for any formatting changes, etc. A lot of word processors also model an editor (the person, complaining about your spelling/grammar), typesetter, thesaurus, etc.

''I've always thought of word processors as programming tools designed specifically for programming printers. There is the intermediate language (PDF or PostScript), and it is the goal of any good word processor to create executable programs written in these intermediate languages. --KellyAnderson

By the way, I belong to the "fence-straddling" school here. Most (maybe all) of the real world could be modeled in code. Most (maybe all) code is a model of something in the real world -- even if the code models nothing more than a process some computer is capable of executing.

One corollary is the problem of iconic representations that don't age gracefully: "connect" as telephone, image modeled on the Western Electric bakelite desk set with rotary dial (which I remember from my childhood in the upper Cretaceous). This does NOT look like a telephone to my seventeen-year-old daughter. Come to think of it, if she hadn't been a Wizard of Oz fan, I would probably had to explain why "wait" was a sandglass - all our kitchen timers being digital. -- RickFrancis?

See also ItsOnlyaMetaphor

Yes. Don't model the world in software, use software to make a world.

This doesn't mean that you can't learn from the world. We can say ItsOnlyaMetaphor, but metaphors are concrete instances of proven designs. Leasing in JiniTechnology works because it uses proven concepts from the social arena: leasing and power of attorney. MartinFowler's accountability pattern is another case of a metaphor that points towards something elemental in the way that systems organize.

-- MichaelFeathers

I'd say: Be ready to both: sometimes model existing things/ideas and sometimes to create some new things/ideas. In either case, make sure that other people can understand what you've done, fix it, improve it, refactor it, even ``use it``.

-- DickBotting

I think we often confuse metaphor and symbolism with simply trying to copy something from the real world. Software is almost always symbolizing or representing something else. It's almost always metaphorical. However, that doesn't mean a Word Processor needs to look like a sheet of paper or an Audio Player like a Stereo Rack. In fact, these have no symbolism at all. The just copy something from the real world. -- RobertDiFalco

"It's like a finger pointing to the moon... 
Don't look at the finger or you will miss all the heavenly glory."
BruceLee

The menu may not be the meal, and my watch may not be the shadow that indicates the current position of the sun, but these things substitute cheaply for their more expensive counterparts when we have to make certain decisions. The purpose of having models (and analogies and metaphor) is to make decisions cheaply, is it not? When the decisions are made, that's when the menu ceases to be the meal. So much for deciding, let's eat. -- WaldenMathews

Oh, by the way, some restaurants feature a dessert cart as the dessert menu, with actual desserts on it. So you can have your menu, and eat it too.

And some dessert carts feature desserts that are merely simulacra. I wouldn't eat those, if I were you.

Building your software as clones of systems in the real world is bogus for the same reasons we no longer drive cars with horse's reins. A new interface is needed that represents what really is going on. This is why virtual reality is bunk. I went on to some length about this a few weeks ago on MeatballWiki: http://usemod.com/cgi-bin/mb.pl?VirtualReality. -- SunirShah

 TheMapIsNotTheTerritory, 
 TheWordIsNotTheConcept?
 TheRepresentationIsNotTheRealThing

the original line is from the author fritz pearl and reads "do you want to eat the menu? or eat the meal?" that is, the concept of X is never tantamount to or on the same level as the experience of X

I first saw it in one of RobertAntonWilson's books, perhaps the "Illuminatus!" or "Schroedinger's Cat" trilogies. I think I may have been the person who mentioned it on OTUG, under the pseudonym "Adolph Mendicant" or another I've forgotten. -- EricHodges

Oft quoted by ChuckMoore, "TheMapIsNotTheTerritory."