Is revision control fundamentally at odds with live coding?

Question

Both live coding, and revision control, are very valuable tools when programming. But they seem to have inherently conflicting characteristics. Is it possible to fully benefit from both at the same time, or are they fundamentally incompatible?

EDIT: To those who don't bother reading the whole length of my question: please at least read the section "Both together?... Existing pseudo-solutions" so that you won't try to sell me on non-solutions that I've already listed.

What I mean by "revision control"

By revision control (a.k.a. version control) I mean mainly (quite obviously in our times) the likes of Git, Mercurial, SVN, CVS, darcs... etc., etc. But I like to think, that this category can be extended somewhat, to include conceptually simpler ideas, like: the now ubiquitous (however volatile) undo/redo; and probably also the notion of primitive "file name versioning" (like in: main.c, main-old1.c, main-old2.c), from which CVS presumably originated.

Anyway, the main premise of revision control is, that a programmer can store multiple versions of a program's source code ("snapshots" from different points in time), and quickly switch between them — "jump backwards and forwards in time". This way, one does never™ lose what he wrote.

What I mean by "live coding"

On the other hand, live coding may sound simpler as a name, but I believe it is a label which covers a much more diverse world of concepts and solutions. Probably the most well-known of them now is the read-eval-print loop, or REPL. It's present as "interactive console" in Python, Ruby, JavaScript, obviously Lisp, to name only a few. But as much as they are useful for "quick testing", in Python and the likes they are merely funny toys, when compared with systems, where REPLs were/are first-class citizens (or even the sole ones), such as IIUC: Smalltalk systems with their "images", to some extent Erlang, some Lisp systems. But then, there are other variations: e.g. Erlang has "hot swapping of modules". Or, there are attempts at editors like Light Table, experimenting with various approaches to instant feedback.

It's a bit harder for me to summarize what live coding is about, but I have to try: it's programming with instant feedback, when changes to a program are executed immediately, while performing the program's main function without serious interruptions; the programming is done in incremental way, often with much experimenting, in tight feedback loop, and in practice usually in volatile memory (RAM).

Both together?... Existing pseudo-solutions

Now, both main ideas described above are very awesome, but I've never seen them successfully combined together. I've encountered several attempts aimed at gaining from both worlds, but they were at best half baked, and often just doubling user's work, instead of reducing it. In no particular order:

1. Matlab's command log:
   • each command entered in REPL is auto-saved to a "log"/history window, from which it can be easily recalled and saved into a script file.
   • live coding: ☺ (REPL)
   • revision control: ☹ (some help via history, but then laborous manual editing and external VCS tools)
2. "Experiment in REPL, then copy successful snippets to editor"
   • live coding: ☺ (REPL)
   • revision control: ☹☹☹ (no help from computer; "what did I type to do this?"; at best rudimentary history with up/down arrows; generally "Left as an exercise for the reader")
3. "Compile and run on save"
   • live coding: ☹☹☹ (slow feedback, whole program is restarted and all state is lost, any inputs leading to particular state must be manually repeated on each restart)
   • revision control: ☺ (you have the code firmly on disk in some organized files, so you can easily put it in revision control; the current state of files is consistent and contains full and exact code of the program)
4. Erlang's hot-swapping of modules
   • also sometimes available (and working) in some RAD IDEs (for Java, C++)
   • live coding: ☹ (at least don't have to reset whole program and lose whole state; but much slower feedback than in REPL, very much not a tight feedback loop; also, usually supported only for changes not crossing boundaries of some small module; also, often requires the original program to be specially prepared in anticipation for hot-swapping of a particular module)
   • revision control: ☺ (all the benefits of normal program)

Did you ever see a solution combining advantages of both worlds, i.e. one for which I'd be able to put a smiling face in both categories? Or, do you maybe have some strong arguments why it is logically impossible?

(Also, in comments, I'd happily learn of other compromise solutions. I'd be also happy to learn if there is/was some method of recording history for Smalltalk systems, or at least objects in those systems?)

Answer 1

I've never had any trouble using those two together. I just don't use those two simultaneously.

For example, I use Brackets for developing HTML/CSS templates - it does the same as REPL, but in a browser (page is getting re-rendered when user updates the code). I do it live until I'm done with some particular feature, and then do git add/git commit one or more times to fix the changes, when go back to live coding. When I'm lazy, I can just commit once after I'm done experimenting. I don't rollback my commit history while live coding - that just doesn't make any sense to me.

So, my answer is: don't use a hammer and a saw both at the same time. You can only hurt yourself that way.

Answer 2

Version control works very well with what you describe as Live coding. Most coding I have done is more or less what you describe as Live coding, and I would call coding.

The workflow I usually use is:

• update (only needed if you are sharing code)
• commit any uncommitted changes
• code and test (you can use step-wise refinement to add full functionality)
• commit changes (try to avoid committing broken code, although committing working but incomplete changes is desirable)

Version control provides a lot of benefits. A few of the key benefits:

• You can really delete code when you don't need it now. (You can retrieve the changes from revision control.)
• Git allows you to stash work in progress if you need to deal with a different issue. Other tools allow you similar but more public functionality.
• You can review changes to determine where a bug was introduced.
• The risk of experimenting is significantly reduced. You can always revert back to the code before you started the experiment.
• It is easier to maintain production and development versions of code.

For a number of reasons, you need to be able to save the code you are working on. I have picked up the pieces from people who code and save snippets. The problem is they kind of work, but you need to re-edit them before you can use them. If you aren't interested in replicating your results, version control and artifacts you can version control don't matter. Coding from a recall buffer isn't readily reusable. Getting the code into a script that can be version controlled is key.

One thing I learned early is that there is little code that can be done as a one-off. Live coding as you describe it seems like one-off coding.