What is the exact (philosophical?) distinction between data and code? When you extract the host name from email to be able to send a email, you are interpreting a string. We could call this process executing a program that outputs the host name.
def echo():
user_input = input('enter some text: ')
print('your text: {}'.format(user_input))
def echo():
user_input = input('enter some text: ')
command = "print('your text: {}')".format(user_input)
exec(command)
enter some text: '); print(10**2000) #
your text:
1000000000000000000000...
That would print however many zeroes the user specified, and use a whole lot of memory. With some creativity it's possible to cause lots of havoc.
You don't seem to understand the distinction between running algorithms on data and taking programs as input, which is what the GP talked about.
Any sufficiently complex program can be viewed as an interpreter for its inputs. Input into a calculator program is code which programs an equation. Input into a word processor is code which programs a document. Input into a video game is code which programs a real time simulation. Input into a compiler is code which programs an executable. These are all different types of executable code sequences.
However, the fact that modern computers can be exploited due to architectural and engineering decisions (eg memory unsafety) does not mean a separation between code and data is not possible.
In fact, it is precisely a hot topic how to cheaply bend current practices back to that model given the rampant amount of vulnerabilities in the wild.
If you never treat data as code, you can only do uninteresting things. My example was the email address. The instance you look into the "black box" of the string, you are starting to treat the string as an executable structure. An email address' raison d'etre is provide that; an address to send an email to. You can not do that without looking into it.
Now, from here we can discuss safe and unsafe ways of doing that. You could use string splits or what not, or you could use a parser combinator library. Doing the latter will make it easy to see that parsing and executing a program is not that different from parsing an email into an AST, (user, hostname), and then treating that as a higher order program (ie. we need to specialize with a message before we can execute it as a "send email" program).
In another context, though, the function 'f(x) = x + x' might itself be data. Within a given context, however, the answer is generally unambiguous: data is what is acted upon by code.
(The breaking of this distinction is one of the reasons self modifying code is Bad.)
No, the fact that current archs encode data and code in the same memory space and there are vulnerabilities does not mean the separation is not possible.