Interactive Programming
I used to restart a program after every change I did to it. Now I'm no longer doing that. Instead I insert a server which lets me evaluate scripts inside the program.
I have uploaded such netcat gate and vim plugin into a github repository. There there's demo for pygame program. You can start on that by evaluating the vimgate -script and replacing the paint() -function with your own.
I did this because it's a big advantage over the software:
- It lets me see the effects of modification immediately.
- It discourages from jesus programming. You've got less desire to code up something you won't immediately need or notice on your screen.
- It encourages writing up micro-editors for things you need to tune or adjust inside the program.
- It makes it easier to work on large, complicated interactive programs. Open the parts you need to modify, use the scripts to reload only the things you need to reload.
- The interactively developed code ends up into a text file. From there you can easily move it into the project once you're done.
It's not all roses though. The technique has it's problems:
- I have to implement and secure a gate to evaluator. For releases it feels responsible to close that gate using a flag.
- Module systems usually run a cache, which conflicts with the technique. Without modules I'd be soon looking into a horde of global variables.
- Occassionally the program state from old scripts end up haunting, requiring a restart of the process.
- The newer scripts collect dependencies over older scripts implicitly. The effects are difficult to track.
- Subsequent scripts occassionally require hooks into the old scripts. If the scripts are given in wrong order, the blank hooks override the filled hooks.
Having access to evaluator in an interactive program isn't a new idea. It's common practice for smalltalk and lisp programmers. The result is something akin to emacs. The program becomes a small operating system for your scripts. Some of the problems I have are severe. Some are avoidable. The benefits are great enough to have bit of thought towards the technique.
It might be that there's an approach that would make it easier to produce interactive software. I haven't figured what that might be. But I've had few observations. They might direct someone to the right trails.
First-class hooks
The blank hooks can override filled hooks because both of them are functions. If I made setting up a hook and binding it distinct operations, the wrong ordering of scripts would lead to an error.
Potentially if one knew beforehand which scripts bind to which hooks, scripts could be evaluated from a directory, based on which hooks they fill up.
Module reloading on import
Modules aren't implicitly in conflict with plugins. The problem is that caches aren't invalidated when a script is reloaded.
Process image
The programming model forces the program to be evaluated before it has effect on anything. We can assume a single part of a program to be part of a specific source listing.