Hacker News Reader

Comment by kemiller | Hacker News Reader

I guess I don't understand where the line between code and data lies, then. Is there a store for variable data that is separate from the image?

EDIT: To clarify, I know that Lisp and Smalltalk have a fuzzy-to-nonexistent line between code and data. What I want to know is how you'd manage that in practice. If I'm changing an existing piece of software, I don't want to expose production users to its incomplete state, so I can't change the running production site directly. (Right?) But if I'm developing locally, or even in a staging version, I don't want to transfer my test/sample data.

Maybe a better question is, "What is a typical workflow like for modifying production software?"

View on HN

> Maybe a better question is, "What is a typical workflow like for modifying production software?"

In a modern Common Lisp web server set up, you'll likely have a SWANK connection available for debugging and patching. You will have to write live-patching code to correctly lock, drop/unbind old definitions, rebind new definitions, and unlock. It will likely remind you of a DB migration script.

For a non-live upgrade, you'll have a process that starts up the new server image, gets it ready to receive connections, then switch the routing & drop the old server. It's not too different from other systems, IMO.

I'm not sure there's a line between the two.

To quote an old lisp saying, code is data is code.

If I want to do an image deploy, what I'll do is load the libraries into the image as part of the build, set up a 'main' function that the executable will trigger, then main will read any config files and go. This image will be an actual executable for the OS. The receiver will execute the executable and not know the difference.

edit: In terms of version control, each deploy to production would generate a tag.

In languages like Smalltalk and Lisp, there often is no difference between code and data. The famous Lisp parenthesis exist exactly because your source code is both code and data (specifically, nested lists).

Though if you were making a program that should be deployed at the end user you would properly make it read and write files or communicate with a server over the internet and obviously that kind of data cannot be put into the image.

I think the idea is that the code and data are dealt with and versioned in the same way (a common saying about Lisp code is that the "code is data.") I haven't actually used any of the environments mentioned in the article, but I believe that the code, as well as the entire state of the running program, can be snapshotted and versioned in these environments.

Reply on news.ycombinator.com