In the real world this is mainly used in development and like many features its only worth drooling over in the right context.
- personal programmer enlightenment bliss*
- true continuous deployment.
- zero planned downtime Service Level Agreements.
- debug production servers.
*not a guarantee.
for me, and i suspect some others here the real benefit of this
REPL driven development is that it can be
indescribably fun. addictive even. It can sometimes really give a sense of crafting-code. give it a try... come on man try it out, first REPL's always free :)
one big draw these days is
continual deployment.
currently the idea for continual deployment is that you change one thing, build everything (or package it rather) then deploy. with the lisp model its actually possible to edit a deployed (usually a box that is recieving a mirror of real customer sessions) box while it is in deployment.
just a pedantic note. you dont actually edit running classes. you compile a new copy of the class and leave it in a known location (a var) then the next time it is used the new copy is found and used. its not really editing while running and more like new code takes effect immediately this reduces the scope of the devlopment process from programs to expressions (typically functions).
another drooling point is the idea of getting the bennefit of
security fixes with out having to declare any downtime. you can do an upgrade with out it costing your SLA any of you precious "scheduled downtime". If you have to schedule planned downtime six months in advance, and you only get two hours of it then (for these poor souls) it could really make them drool.
If you have repl access to your running application as it is deployed (potentially (with permission) at a customer site) you can connect to the app while it is running and run tests on the existing code
in the existing context with out having to stop and connect a debugger. you also wont get any speed loss from a debugger. It's possible to do this with out a REPL, though when you get the repl in there you can then create new code easily (some will say that injecting dynamic class loaders through the debugger is easy) and then fix things. So you could connect to a running server. discover that a function failed to re-connect to a database after a short outage and then reconnect it right then and there.
as with all programming constructs there
never will be a silver bullet and this continual deployment/development has an interesting downside: you program can be correct in memory and wrong on the disk. if you compile a function then break it and save then the only working copy of the code is the one running. I't useful to be aware of this and re-eval files just after you save them.
This may sound fanciful so go checkout how to Embed a Clojure REPL in your production application