Dynamically changing running Lisp code #3
Wednesday, February 25, 2004
The "Use Perl" site has a post by "ziggy" in which he questions the value of being able to dynamically change running Lisp code. Here are some excerpts (with some of my comments thrown in):
"First, it's nice to work with a long running system, know you've got everything working and leave it alone when it works. Everything is in one place, including the test scripts. That development model works for some people, but it never worked for me. I'm a dyed-in-the-wool C programmer, and I'm used to lots of small programs running, with the odd server performing some task specific function. I don't expect every program I write to have a full development environment, along with multiuser connectivity so that approximately anyone can log into the system and make modifications. But that's just me."First of all, it's important to make a distinction between a language feature/capability and good security practices. Just because Lisp provides you with the ability to dynamically change running code, does not mean that you should enable that capability in every application that you deliver. Nor should your security be set up to provide access to the system so that "approximately anyone can log into the system and make modifications". Hey, but that's just me ;-)
"Second, these Lisp-based systems tend to be written by very small teams of very talented programmers. They like the fact that Lisp environments give them all the tools they need to operate at light speed. At the same time, this kind of solution feels fundementally unscalable. This is not the kind of project I'd want to use with dozens of programmers, or programmers with widely varying levels of expertise. Allowing anyone (on the development team) unfettered access to the entire running project feels like an invitation to crash the system in horrible, almost irrecoverable ways. And always at the worst possible moment, of course."Many Lisp-based systems are written by very small teams of very talented programmers. But this does not mean that Lisp is not suitable for larger development teams. However, allowing "anyone (on the development team) unfettered access to the entire running project" is not something that would be allowed on any well-managed development project (regardless of the programming language used or the size of the development team).
"And I think that's why I'm most uncomfortable working with system images. Not only is your source locked in, but enabling runtime patches to a live system just feels dangerous."I can think of a lot of scenarios where having that capability would be considered an asset:
- Think high-availability, mission critical systems - the ability to dynamically fix bugs without bringing down the system is a tremendous asset.
- Think customer support - the ability to immediately respond to customer issues can dramatically improve the support process.
- Think quick reaction to market demands - the ability to immediately make available new functionality without re-deploying can mean market responsiveness and flexibility in providing new functionality.
- More examples are left as an exercise for the reader... :-)
