Code Verbs Data Nouns

I don't expect this page to endure for long, but I didn't want to try to insert the idea into either of the other (currently hot) pages on the topic.

On the pages describing the relationships between data and code (being the DataAndCodeAreNotTheSameThing and DataAndCodeAreTheSameThing pages) there is an effort to clarify when data can be code.

Without trying to be too shallow, it seems that "sentences" in the world of programming have verbs, nouns/pronouns, and adverbs/adjectives and a grammar that binds them.

Different grammars change the way predicates are constructed and parsed.

Modifying clauses clearly change what a verb is doing, how, and to what.

In x86 AssemblyLanguage the instruction MOV AX,[BX] has a verb with modifiers and implied data (with ellipsis). No one questions that MOV is code, and most of us allow that AX,[BX] is also code, while the data @[BX] is just data -- the assembler makes no assumptions about it (except that BX is offset from the elliptical DS).

In VonNeumannArchitecture(s), the separation of code and data is arbitrary, while in HarvardArchitecture machines the separation of code and data is explicit.

Data that is never executed and that is only ever manipulated by code (my mailing list, for example) can be said to be data-but-not-code, while the data that tells my JMP INIT instruction where to resume execution is clearly inseparable from the code it modifies, and should be considered at least adverbial code.

One can generalize and say that "code is just data being interpreted by a CPU" but this is only interesting at the theoretical level.

At run time it is useful -- even necessary -- to differentiate between code (which does stuff) and data (to which stuff is done).

A sentence is only meaningful if it has a predicate. However, the subject and object are differentiated. It is, altogether, a sentence, and the entire sentence can arguably be called "code" but if the sentence is

  "Go to the kitchen and clean whatever you find there."

the dishes that may be in the sink are clearly just data and not part of the code.

So, while in theory it may be fun to say that "code is data and data is code" it is not a useful model in real world stories.

Within your context (whatever that is) you will have code and data and some other data that modifies one or describes the other.

Don't get too hung up in the "all encompassing Zen" of it.

-- GarryHamilton

"if the sentence is

  "Go to the kitchen and clean whatever you find there."

the dishes that may be in the sink are clearly just data and not part of the code"

Speaking more as a linguist than as a programmer, that's because "whatever" functions as a parameter, which is a defining characteristic of pronouns. English also has the "pro-verb" do, so you could equally say "Go to the kitchen and do something to the dishes", or "Go to the kitchen and do something to something", or "Go somewhere and do something to something"... or "find something somewhere to do something to and do it". The point is, by your argument (or by the extension thereof), it is whatever you parameterize that is "data", whereas "code" forms the framework within which the parameters are resolved. In natural language, for example, words are the "data", or parameters, whereas grammar or sentence structure (e.g. NP + VP [noun phrase followed by verb phrase]) is the "code", or framework. So... CodeSentenceStructureDataWords, anyone?

Suppose we have a wish-list for a party:

food quantity ---------- -------- cookies 12 biscuits 8 hamburgers 9

Suppose we also had scripts in files that could control a robot to cook these items.

  qr = query("select * from partyWishList");
  while (row = getNextRecord(qr)) {
    commandLine = "myinterpreter " . row['food'] . ".prg " . row['items'];
    if (!execute(commandLine)) die "Cannot run command: $commandLine";
  }

The commands in this case would be:

 OS> myinterpreter cookies.prg 12 
 OS> myinterpreter biscuits.prg 8 
 OS> myinterpreter hamburgers.prg 9

Here the name of a food is also the name of a script. So, is the list of foods code or data? Was it data UNTIL the scripts and/or the script running program was created? To misquote Einstein, that would be "Spooky definition action at a distance".

For this specific example, it was data and still is data. "Cookies" doesn't have an inherent executable meaning. It's only a useful token to find the section of code named "cookies.prg".

How does that differ from a list of functions or operations that may eventually be executed? For example, assembly language is a lot like that: just a big list of instructions. And, what is an "inherent executable meaning"? Who assigns and defines this meaning? Is it in the machine or in your head? If your head, then remember that YouAreNotEveryone.

I think it's just the example chosen. Language specs and compilers assign meaning, and I don't know any languages where "Cookies" is an operation. Am I splitting hairs? Probably. If the example read for(i=1;i>10;i++) then it's a different ballgame. The data could be directly executed in the same context that created them.

We could prepend "make_" to the script names, but that is merely a cosmetic change:

    commandLine = "myinterpreter make_" . row['food'] ...

{"Meaning" is relative to the observer. Different observers may find different meaning depending on their goal and circumstances. There is no objective central "meaning". I'm waving an EverythingIsRelative flag again here, which probably wouldn't surprise anybody. --top}

Well, if we're trying to fabricate an example where the boundary between code and data is as blurred as possible, there's always ForthLanguage. And then we could point out that, to a compiler, all the stuff it parses and converts is just data.

Happily, I'm not confused by the "recipe is just data until you open the book and start doing it" thing.

You seem to be implying that "most of the time the distinction is clear".

That is so. While I can invent scenarios where the distinction is muddy, and while I can play semantic games about whether a falling tree, unwitnessed, actually makes a sound, I don't think that the majority of us wonder which is code and which is data.

Any attempt to convolute the definition(s) to achieve some mystical "see, it's really all just waves" epipahny degenerates directly to LaynesLaw, do not pass go.

My computer language classes nearly always began with my assertion of the lower-level abstraction that "ItsAllJustSwitches" (which see). Higher level abstractions (ItsAllJustData?) are for the ComputerPhilosophers? among us.