One of the hardest things to grasp in programming is simply what happens when. The simplest case is usually what we’d call a Read-Eval-Print-Loop (REPL): the user types instructions one by one, and they happen in that order. It’s very similar to the ‘command line’ in that the basic flow is, simply, down.
But most code doesn’t run this way. Applications in all their forms are composed of documents of code that are composed and then executed at some point in the future. The tools we use to write them, like vim or Sublime Text are more similar to word processors than REPLs.
This is well-trod territory: LISP-family languages have long enabled a smooth connection between interactive evaluation of code and document editing, the latest step being Light Table, an impressive full-fledged IDE.
RPL is the next step. Line-by-line evaluation could never escape the problem that most code isn’t evaluated top-to-bottom. And to be truly useful, the thing needs to edit files on your computer, so that you can switch into it as a first-class debugging and prototyping environment, and save your changes directly into your project.
It’ll support widgets for viewing data inline, like maps, charts, and tables.
I use mistakes.io to write regular expressions, do math, and test chunks of code. Even in its primordial state, RPL has already been useful for debugging code in-place and writing node.js-based “data transformation” code without needing to tab through windows to test hypotheses.
I plan to write more about the internal workings of RPL and once it is stable, promote it as a downloadable and web-runnable tool. In the meantime, RPL is an open source project on GitHub and I welcome contributions and ideas.