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's not all roses though. The technique has it's problems:

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.

Similar posts