The experience I have had on large, REPL-driven development is that continued development is assumed to also work under REPL-driven environments, so debugging or supporting them begins with "try typing X into your REPL." Many of the distributables I have seen also maintains REPL interactivity as part of the live deployment solution, with similar debugging solutions. While this may not be unilateral, "ship the deployment environment" seems to be a running theme.
I'm interested in your experience in avoiding this, and the process you used.
I think this gets to the issue that there are two different ideas of "REPL driven".
In one, you're using the REPL frequently in production. In the other you're using it during development. Those are two different scenarios and result in different perspectives.
Just like many (most?) organizations have gone to (varying degrees of) infrastructure as code versus tweaking each server manually, REPL-in-production is similarly problematic. As you noted, you end up in a position where you aren't actually sure of the system state (both what it is and how it got there). This is a use of the REPL that should be minimized (if you're using it to actually change the system state versus trying to understand the system state, especially).
However, when working on a new system you may tweak a single or small cluster of servers manually and build out your automation scripts based on that experience. Similarly, the REPL during development is a way to quickly prototype, experiment, and test code but needs to end up committed to actual source files for deployment.
i'm starting to feel that REPL driven development can be bad for maintenance, when you have a REPL, you can write ridiculously compact and abstract code that is hard to understand just by reading it.
I'm a bit curious about your comment. Do you mean during development you run your code on a REPL and change portions of it , or do you mean you run code in Production in a REPL and change portions of it as it's running?
I'm interested to know your setup in either of those cases. The one inconvenience I have about REPL based development is that I need to copy over an expression from my editor into the REPL and if I make any changes in the REPL, like fix a typo, I need to make sure to copy it back to my editor.I guess this may be because I don't use Emacs and have an editor and REPL in one.
> Even worse, this basically hamstrings it as a standalone application. The workflow to _use_ the application becomes "start the REPL under emacs and launch it"
This seems like an incidental property (symptom of poor engineering discipline, which manifests itself in other ways in other development paradigms e.g. lack of documentation from "agile" teams) of the particular applications you've worked with and not an essential property of the (architecture decisions resulting from the) REPL-driven development style. What makes you think that this is actually due to REPL-driven development?
I develop several tools from the REPL and was able to easily convert each one to a standalone tool (when I attempted to do so).
I find REPL driven development to be really helpful here. You play around with toys til you get your bearings, then you sit down for real to do the task. The instant feedback from the REPL causes me to not get sidetracked nearly as easily. YMMV, of course.
REPL Driven development as it's called is really yes having your whole system running at your thingertips (even production for the adventurous). You can execute arbitrary code and get results or see what state has changed. You can also redefine anything (in Clojure at least) that is referred to, such as functions and variables (I use these terms loosely here).
Normally you have your IDE configured so that anything executed is executed in the context of the running REPL session. So there should be no need to copy/paste.
When done properly with tests running on every change you really can't, as a developer, get any quicker feedback. It's brilliant and empowering!
Your issue could be emacs but, for Clojure at least, there is the Cursive Intellij plugin which is now definitely usable. Also there are the brand new IDEs like LightTable.
LightTable.com started out with some very different ideas with regards to code organisation and there is still a lot of potential work there. But lighttable instead became open source and a core for plugins. The plugins now range from rainbow parentheses to 'pick your language' evaluation.
If you want to discuss any of these ideas or others please do or PM me. I'm always willing to discuss as my girlfriend is hopeless. But then for everything not programming she keeps me sane.
I concur. Use REPL driven development to arrive at a solution, but use unit tests (or similar) to make sure there are no regressions in the future and that it continues actually being a solution.
That's really missing the best part of drop-in debugging, which is taking advantage of the REPL. You see what's wrong, and then can fiddle with code to see the exact lines of code to put in place to resolve the issue. REPL-driven development is pushed hard in e.g. Clojure land, but it's an insanely productive workflow in a ton of different languages
Of course that's possible, but the evidence suggests that most people become more productive when using the REPL to experiment while developing large projects.
One issue with trying to adopt the habit midway through a project is having a design that makes it easy to load small portions of the project with test data into the REPL. It's not quite the same as having code that's easy to test.
Do you use an interactive debugger? It's the same principle, but earlier in the lifecycle of development.
Good catch. But strictly speaking that wasn't doing development in the repl, but repairing data. The live server is the only place you can repair data on the live server.
A peculiar workflow of REPL-driven programming environments is that the running program is eventually "saved" by writing the state of the virtual machine to disk. There may be no source code to rebuild from, if the program was built interactively. It has its appeal, but it's kind of a nightmare from a maintainability standpoint.
That's pretty much exactly how I develop. I rarely type anything directly into the REPL, instead typing into the source file in emacs and then C-c C-c it over to the REPL for me. The advantage is that I get a canonical copy of the entire source code, whilst still having the ability to inspect and hotfix things through the REPL. If I then need to reboot the image or deploy to a new server, the entire source base should be completely stable and consistent.
I often connect to production servers using Slime and fix little things like typos this way - then check the source into Github and have it permanently saved. It removes a lot of the stress of doing a full deployment each time you need to patch something!
I'm interested in your experience in avoiding this, and the process you used.
reply