I’m always a little confused when people are blown away by the “the program IS data” revelation. What did they think the program was? Why is this seen as transcendental LISP enlightenment when it’s the main feature of a von Neumann architecture?
That's not usually what people mean though.
They usually mean that the tools you have within your user-level application for working on useful data structures directly apply to creating new functions and modifying that application. That's non-obvious, especially if your mental model is something that looks like C.
Edited to add: also worth knowing is that historically the Von Neumann architecture itself was invented only 6 years before Lisp was. The "Maxwell's Equations" would have been written in a context where separating instruction memory and data memory would have been a commonplace assumption.
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.
I'd never really used a Lisp-based language before, but I decided to give Clojure a try, and it was the first time I grokked the value of "the program is the data is the program".
In PHP I had different "things" - operators, functions, scalar variables, class variables - and I needed to think about what was assigned and when. But in Clojure, everything was "data" that I could use to construct bigger pieces of data. Maybe that's obvious to better programmers than me, but my mind was blown.
A little deeper, you can think “an obj file are bytes, even called TEXT section, so the same, a program is data”
But in Lisp the parallel comes at a much higher abstraction level. In the sense that you learn “algorithms AND data structures” like 2 different things, and when they conflate, that is the aha moment.
It is interesting when you start to understand that data can affect flow control exactly as code, that you can generate code on the fly as needed, just as data (which is bot really possible in C- in an easy way, at least) and you even can generate code, which generates code, which gene… that runs at the end.
Let me add another thing: probably you have heard “self modifying code is dark, dangerous, not recommended”. Now, if you really embrace the idea that data is code, code is data, then you start to be very cautious with variables. Any change in a variable, is changing code… I think that is the reason why people in functional languages value so much immutable data.
It means that the source code of the program is a data structure, whose processing can be customized in the programming language.
In machine language, you do not have access to customize the assembly language. For that, you work in a different language: the macro language of the assembler.