4 ms·

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 transc

by taneq 2y ago

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?

blowski 2y ago
The closest I've come to being "blown away" by it was a project where I needed to clone the results of an Excel workbook onto the server, without installing Excel. I started with PHP as my normal language, but it ran into the ground when I had to deal with order of operations, new operators, and cell references. 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.
f1shy 2y ago
On a shallow level, is trivial; as in “a program is a file with ascii codes, like any other file, is data” 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.
aap_ 2y ago
I think that's a really interesting point. I don't think there are many high level languages where code and data are fundamentally the same kind of thing. I'm aware of only lisp and tcl (funnily there's a thread about tcl on the front page right now). Also people probably don't think about machine code all that much and even if they do they probably don't consider self-modifying code. The only exception to this may be JIT compilation? Anyway, it seems to be a concept that's rare in high level languages so I understand the surprise.
regularfry 2y ago
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. 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.
- trealira 2y ago
  > 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.
- regularfry 2y ago
  Turns out I'm wrong about dates in my historical edit: it's 16 years, not 6. No idea how quickly von Neumann took over from Harvard in that period, so it's conceivable that assuming a merged memory was already the standard.
kazinator 2y ago
"Code is data" doesn't refer to self-modifying code. 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.

by taneq 2y ago

blowski 2y ago

The closest I've come to being "blown away" by it was a project where I needed to clone the results of an Excel workbook onto the server, without installing Excel. I started with PHP as my normal language, but it ran into the ground when I had to deal with order of operations, new operators, and cell references. 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.

f1shy 2y ago

On a shallow level, is trivial; as in “a program is a file with ascii codes, like any other file, is data” 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.

aap_ 2y ago

I think that's a really interesting point. I don't think there are many high level languages where code and data are fundamentally the same kind of thing. I'm aware of only lisp and tcl (funnily there's a thread about tcl on the front page right now). Also people probably don't think about machine code all that much and even if they do they probably don't consider self-modifying code. The only exception to this may be JIT compilation? Anyway, it seems to be a concept that's rare in high level languages so I understand the surprise.

regularfry 2y ago

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. 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.

trealira 2y ago
> 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.
regularfry 2y ago
Turns out I'm wrong about dates in my historical edit: it's 16 years, not 6. No idea how quickly von Neumann took over from Harvard in that period, so it's conceivable that assuming a merged memory was already the standard.

kazinator 2y ago

"Code is data" doesn't refer to self-modifying code. 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.