4 ms·

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

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.

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.