> If your preferred method of changing program behaviour is directly editing bytes of machine code in unstructured RAM while the program is running, then yes, t

> If your preferred method of changing program behaviour is directly editing bytes of machine code in unstructured RAM while the program is running, then yes, the fact that it's a Von Neumann architecture does give you that "the program is data" duality. On some platforms, e.g. the Commodore 64, it wasn't uncommon to write self-modifying code, which is exactly what you describe. The fact that code can be data also seems somewhat clearer if you've ever had a use for structures of function pointers in C, or if you've manually written jump tables or directly-threaded interpreters in assembly. But, IMO, those aren't as interesting as the "code as data" model in Lisp, because in Lisp, it's the high-level code that's reified into its own untyped data structure, which makes it a lot more flexible and powerful than the literal bytes of machine code that Commodore 64 programmers modified at runtime.