Programming is an ongoing dialogue between programmer and programming environment. Programming activities are questions. The answers are the feedback provided by the programming environment.
The questions come in two flavours.
This “interactive” construal of programming is poorly supported by traditional programming environments. For example when debugging, we often want see the impact of a fix on our current view of the execution of the program. That carefully constructed view isolates a problem, and we want to know if the fix makes the problem go away. Using the terminology we just introduced, we want to ask a “what if” question, and have the answer take the form of a change to the answer to the “how” question we are currently exploring. But to ask a “what if” question, we must usually exit the program, apply the change, and then run the program again from scratch, losing our all-important debugging context.
I'm working on a new kind of tool design which supports these
interwoven, interactive Q&A sessions more directly. Instead of
restarting the program each time, we update its execution
incrementally, allowing our working context to be maintained as we
program, rather than forcing us to reconstruct it from scratch each
time. I have a prototype implementation
called
LambdaCalc is an incremental spreadsheet language, but with familiar functional programming features like recursion, higher-order functions and data types. Cells contain nested spreadsheets, so that all intermediate computations can be explored. A LambdaCalc computation is “spreadsheets all the way down”. Jonathan Edwards explored a similar nested-spreadsheet concept in the programming language Subtext, but without considering many of the features I'm investigating.
LambdaCalc is a proof-of-concept, not a production tool. It is partly self-hosted and so runs very slowly and does not have a GUI performant enough to accept user input. Instead, it provides a zipper-like interface to the program and its execution and a set of browsing and editing combinators which allow interactions of the kind described here to be scripted up in Haskell and executed. It also able to generate the UI state associated with any configuration, which can then be displayed in a window or rendered as a PDF or Postscript file.