A while back, I was looking at a forum where someone asked if you'd use a tablet to do computer programming. Most of the responses were centered around "typing is slow/awkward on a tablet."
I agree. Typing is awkward. But, who says programming has to equal lots of typing? Yes, it does, currently. But does it have to?
I took a compilers course a few years ago. One of the things which I learned in that course was that a compiler does multiple steps, largely in series, where each one feeds into the next, with the object code being the final result.
The first step: going through the code, recognizing various kinds of constants, keywords and potential identifiers (variable names, class names, function/method names). Once it has a sequence of these, the next thing is to create something known as an Abstract Syntax Tree. For example:
a = b + c * d
Would be turned into a tree of nodes, containing operations, variable or constants. At the top, is an equals sign (assignment). "a" is on the left and "+" is on the right. The "+" also has nodes extending below it, "b" on the left and "*" on the right. The "*" also has nodes extending below it, "c" on the left and "d" on the right.
The next thing which usually happens is to "decorate" the tree. If "a" is a double and "b", "c" and "d" are all integers, we need to mark the "*" and the "+" as integer math, but we need to do some kind of implicit casting before the assignment. Usually, you "decorate" the various variables according to what type they are, then deal with the operations, then figure out where one type needs to be cast to another.
An interpreter or a compiler will start at the lowest point on the tree and work its way up. So, the aformentioned code becomes integer:c * integer:d, with the result being added to integer:b, with the result being cast to a double the assigned to double:a.
Most programs have more than one expression. Quite frequently, if you calculate "a" in one expression, then use "a" in the next expression, you could rewrite the two expressions as one. Shorter expressions, though, tend to be easier for a human to read, which is why only sadists and functional programmers (like me) tend to bother with creating really long expressions.
So, if the code you're writing is going to be turned into a tree, why can't you just create a tree? Such things tend to be awkward when you're using an interface dependent on a mouse and a keyboard, but they're much more natural in a touch-screen environment (tablet).
Something else I learned from that compilers course. Do you know what you get if you create a serialized version of the Abstract Syntax Tree, using prefix notation (such as "+ a b") instead of infix notation (such as "a + b") and put each simple expression inside a set of parentheses?
Indeed, the reason Lisp has such power over certain groups of programmers is that you're almost explicitly creating an Abstract Syntax Tree, in text. And it provides the means, not only for the programmer to create an AST, but also to programmatically create and manipulate ASTs. In other words, you can write code whch writes/modifies code. And you aren't doing anything as clumsy as putting together a string and running
You're starting one or two levels down the chain from there, with the initial parsing steps already done.
As such, the first step toward creating a touch-screen code development environment would be to create something which lets you drag various Lisp commands from a palette of commands, drop them onto the tree, and then execute the whole thing. From there, the next question becomes: do you want output in Lisp, or can we run some kind of code generator on this tree to create output in some other, more commonly used language?
Note: anything which can be done from XML or XSL can be done from Lisp. If we can drag-and-drop components into a Lisp program, we can also drag-and-drop components into XML and any of its derived forms (such as HTML, XHTML, HTML5, etc.).
So, would you use a tablet for writing code?