Data And Code Are Not The Same Thing

Code is always data, this is true, but data is not always code....

: "fa;sldjfsaldf" <-- Not code, just data, so they can't be the same thing, though they are sometimes the same thing.

Coincidentally, that's a Teco program that creates a new buffer, copies the old buffer and the time of day into it, searches and then selectively deletes. It's a program in several other languages, too.
I find it hard to believe it's something that sensible, but sure it's some Teco program. It is also a brainfuck program that does nothing, and a vi program to jump to the second "a" forwards and replace it with the string "ldjfsaldf".
I know, sorry about my sense of humor (it is a Teco program, but I'm too rusty to recall what it would do). Still, it's worth noting that it depends on context whether something is data, code, both, neither, etc. It's unreasonable to merely say they're the same thing simply because the subject is more complicated than that. Sometimes they're the same. Sometimes they're not. Sometimes it's not the point whether they are or not.
Extending this point, you can define data to mean something and code to mean something in a specific context, but the string above cannot be said to be "obviously" more one than the other.

Just because any string of characters 'can' be code in some language somewhere misses the point, it doesn't mean it's code in the language you're using. In most contexts, data is not always code, this page is rebutting the ignorance of DataAndCodeAreTheSameThing, which is constantly used to justify Topminds positions on just about everything. It's his cheap cop out whenever he loses an argument.

Top tries to use the fact that code is data and data can be code to say the distinction is meaningless and useless. That's the flaw in his argument. Even if code and data are the same thing, it's still useful to distinguish between the two.

Absolutely. I tried to say they were dual to each other, but kind of got nitpicked to death. I think it's the more useful way to look at it, though.
- Gee, I thought it was Perl :-)
How do you know? One cannot tell without knowing the context in which it is used. A program is just a big string of text unless you have the right interpreter/compiler. One can convert your name into ASCII bytes and feed it to the CPU as machine instruction bytes. Most likely it will won't do anything useful, and perhaps crash the system. But a super-buggy program is still a program. --UnknownDonor
Re: "Top tries to use the fact that code is data and data can be code to say the distinction is meaningless and useless." - This a misrepresentation of my usual positions (not knowing the specific instances). More likely it's a case where I say that ProgrammingIsInTheMind such that a classification is not subject to the usual objective analysis. This is NOT the same as "useless", except perhaps being useless as formal or consistent definition. Be careful about the distinction of being useless as a formal definition and useless as a tool to do work. --top

B may always be A, but that doesn't mean A is always B, so lose the logical fallacy that DataAndCodeAreTheSameThing, it isn't true.

See DataEqualsCodeDependsOnContext

Question: Is DNA data or code?

MuAnswer. DNA is a chemical. Data and code are imaginary abstractions.

True, but amounts to a nitpick over phrasing, because the question returns anew if one rephrases as "Does DNA function as data or code?"
By definition, aren't all abstractions imaginary?

Answer: Moot due to LaynesLaw.

  while(print((A,T,G,C)[rand 4])){}// how to make a human :-)

This debate hits LaynesLaw so fast it's silly.

Well, definition is indeed a part of it, but viewing code as data can change one's perspective on how software is or can be designed. If you focus on the data part, then you will see more opportunities for DeclarativeProgramming. To a compiler/interpreter a program is just data. The C/I converts programming code into internal data structures, usually a bunch of lists, sets, stacks, or maps with pointers to each other. Your code is essentially a data structure in the end. This may at first seem irrelevant, but it is not. Think of a code-centric GUI API/framework versus a declarative one. Under the declarative GUI system, an interpreter-like engine (AKA "browser", "windowing system") "runs" the declarations in a manner not that much different than an interpreter running programming code. The original declarative GUI layout may be specified as code, such as XML, or via an IDE that builds a hidden structure, similar to VB's approach.

Since ObjectsAreDictionaries (maps), or at least can be viewed as maps, an OOP program is essentially a little (non-relational) database. Whether it "is" a data structure or can be viewed as a data-structure, but also viewed as code is not that important. The important thing is that they are interchangeable viewpoints. Which form you "see" it as is a mental preference issue. In practice I would often rather use relational structures than a web of maps. Thus, the two somewhat orthogonal open questions are which view is preferred (code or data structures), and what type of data structuring discipline to use (relational or navigational). Maybe data and code are not "the same thing", but rather interchangeable. Although interchangeable can perhaps mean they are the same thing. But the important thing is that we agree they are interchangeable viewpoints for essentially the same information.

Our difference really seems to be that I prefer a data-centric view for a much higher percentage of a given project than you do, and I prefer a relational setting for the data-represented info over a navigational one. The debate is not really about what is or what is not, but what we prefer. Agreed? Once we agree on that, then we can go to the next step of fighting over which is better :-) -- top

I concede. Data and code are the same thing. In the interest of Once and only once, we should eliminate one or the other. I suggest we eliminate all data; it is the same as the code and therefore superfluous. Now that we are agreed, there is no point to further discussion of data; it is the same as code so we just don't need it.

Assuming you are serious, my point is that as humans sometimes we prefer a data-centric viewpoint and sometimes a code-centric viewpoint. There is no single viewpoint that makes every person happy for every situation. I suppose we could randomly select a "prototype" human and kill off everyone else with a different preference in order to satisfy OnceAndOnlyOnce, but Hitler Oriented Programming has fallen out of style.

What is there to prefer? We have declared them the same. We are comparing apples to apples, brand X to brand X. Code is data is data is code.

Then I do not understand "we should eliminate one or the other". You cannot eliminate one without killing the other if they are equivalent. Perhaps you meant eliminating the viewpoint of one or the other?

There are not two viewpoints to discuss. The terms are identical so there is no point reason to use both terms. If the term "data" is important, then let's eliminate the term code.

Just because somethings are identical does not mean they cannot have different names for different forms. If data is printed out in a columnar format, we call it "a report". If it is copied in it's native format onto another disk, we call it a "binary dump".

If code and data are identical, what reason is there to use different names? What is the basis to determine which name is to be used?

I think the biggest distinction is that how data is presented is mallable, while code is pretty static. One does not "re-sort" code expressions in a code viewer, for example. But filtering or sorting a dictionary array or table to look at it differently is common-place. Code is sort of "stuck in space" the way it was created.

One does not "re-sort" data expressions in a word processor, either. Filtering or sorting code in an IDE is common place. What characteristics identify data that is mallable versus data that is "pretty static"?

If your IDE is parsing code and shifting it around, then you are essentially converting code to data, processing it, and then converting it back to code. I suppose this introduces another possible distinction: You generally don't "parse" data, at least not as heavily. The more complex the parsing needed, the more code-centric it probably is.

However, we agreed code and data are identical, so what does it mean to convert "code" to "data" and vice-versa? How can one tell the difference between data mode and code mode?

There are conventions we tend to call "data" and conventions we tend to call "code". We could instead say, 'convert from format X to format Y because I want to see/use it in format Y for various reasons.' It's a communications shorthand that may not necessarily have rigor. A UsefulLie if you will.