4 ms·
one way to do it is to load the entire system into the image and actually just straight up deploy the image as an executable.
by pnathan 14y ago
one way to do it is to load the entire system into the image and actually just straight up deploy the image as an executable.
- kemiller 14y agoI 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?"
- pnathan 14y agoI'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.
- tomjen3 14y agoIn 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.
- gphil 14y agoI 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.
- pnathan 14y ago> 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.
- juan_juarez 14y agoThat's great if you only have a single developer. Larger teams working together are going to have issue with this. I think that may have been part of why the Lisp Machines died - not only were they obscenely expensive, but they were extremely expensive single user machines. This is fine if your entire development team is one MIT supergenius but becomes problematic when you merely have a handful of rockstars.
- pnathan 14y agoI'm talking about deployment, not working together. Typical lisp development today usually involves using git and loading files into the image using SLIME. And, yes, LispMs were very expensive and cpu-performed less well than a risc box.
- lispm 14y agoLisp Machines were single-user, but networked and using servers.