Processing for Android
wiki.processing.org
wiki.processing.org
Of course someone would have to come up with a more programmer-oriented virtual keyboard. I've already messed around with using bash and python without a physical keyboard and you really want easier access to all your punctuation and braces.
Imagine the program as a tree of nested boxes: a leaf node / box for each single-line statement, an inner node (= outer box) for compound statements. Introduce some modalities: insertion between nodes, selection of node subtrees. Edit and create nodes using aggressive code completion. Complete initial keywords, consider using 'let' and 'call' or equivalents for assignment and invocation expressions (avoids starting statements with an identifier). Complete identifiers aggressively, starting with params, locals and most-recently-used, being able to browse up into an outer scope, possibly converting long lists of potential identifiers into Patricia trie navigation to avoid laborious scrolling.
A typed language would probably be better, though with inference wherever possible, because completion has much higher quality there.
Back in the day, 320x200 - 40 columns x 25 rows - Commodore 64 seemed OK, until I saw the hires mode on an Amstrad CPC 64 - with 640x200, giving 80 columns. All these were huge luxuries compared to the 20x1 LCD character screen I mention in another comment here, of course.
But the point is, the problems you'd tackle are smaller too. Just ad-hoc things: probably simple mashups using maps, GPS and connectivity; algorithm implementation to satisfy curiosity, or to learn in idle time, or even to brute force a puzzler in a newspaper column. There was an iPhone game, Fling, which I spent 20 minutes writing up a solver for, on my laptop. I'd have liked to do it on the phone instead.
Why would one want to code on an Android device? Not everyone uses laptops all the time. Laptops need to be lugged around (even though mine's a Toshiba Portege, and is lighter than most at ~1.2kg, I seldom bring it anywhere), opened up, resumed (takes a second or two), balanced on a knee (so you need to be sitting), etc. Hard to do when you're e.g. waiting in a queue, walking in the countryside, lying in bed (without rearranging pillows, sitting up, lighting up the room from the screen, fans and light disturbing your significant other, etc.)
And then there's the idea that you're writing programs for your device without the need for a deployment stage. You're running them right there on the device. No need to faff about with cables, or build / deploy steps.
As to lines of code, in a structure-oriented editor, I think that would not be relevant. I would imagine program navigation to be spatial with drill-down, up and out; all identifiers are hotlinks to their definitions; MRU lists and the same Patricia trie technique, or incremental search, for more random access, etc.
I've ordered one to try this out - but can't confirm whether it's true just yet.