I am visual programming skeptic (or better said pragmatic). I've seen quite a few visual environments where at the end of the day (once you've learned the language) it was faster to switch to text mode. Visual programming was great for learning the language though.
The main problem visual programming encounters is the sheer number of options you have when you are entering code in text form.
Just consider that on almost any new line in code you can type in control structure, variable declaration, assignment, function/method call etc. And it is almost always faster to type "if" or "for" than to click through some decision tree to get to your required command.
In touchqode we try to overcome this limitation using prefix tree when showing code suggestions - e.g. when you have methods showTime(), showDate() and showLocation() you can type "s", press "tab" and you see longest common prefixes of methods starting "s" - so you would see "show". Then you can click it and see the actual method names.
Needless to say - templates for structured commands (e.g. "if") are probably necessary for programming on mobile devices.
I have few experimental features for touch programming in my mind, so I hope I'll get to implementing them sooner than later. If anyone has interesting ideas I'll be glad to discuss them.
> The main problem visual programming encounters is the sheer number of options you have when you are entering code in text form.
Agreed. So maybe the solution is to adopt a completely different approach to "visual" programming. One that doesn't involve entering code, and has a bigger dependence on gestures. I have no idea how it would look like though, but something that would allow you to develop on a touch-screen device is quite intriguing.
I agree; yet I do think that there likely are a subset of coding tasks that are suitable for a visual approach (esp if a multi-touch screen gives other benefits, specific to that task). The only thing missing is knowing what those tasks are...
1) a way to address the choice explosion is (highly) domain specific languages, with limited choices. I guess this would be closer to scripting/macros than true programming, but still useful.
2) could the number of options be constrained in some other way? Or, perhaps chosen in a way that's more intuitive to touch - such as pointing to a graphical representation (of something that naturally has a graphical representation). OTOH, while good for nouns, less good for verbs. What about gestures for verbs (like sign language)? Maybe not for the specific choice, but to narrow it down to a family of choices?
3) and the bizarre idea of using the strength of multi-touch to make choices - like a chording keyboard (eg).
Is a keyboard really intrinsically better for coding than pen and paper? (maybe - there's linguistic power in symbols lacking in pictures).
BTW: A prefix tree is useful, but not specialized to multi-touch...
- have your methods and variables put into "categories". Then you could quickly choose category and you would be presented with limited choice in the category
- code snippets - templated pieces of code (control structures, database access...) where you would just choose variables/methods to fill in the template
Good ideas. Basically, you want to make the language as high-level as possible.
Everything that can be generated or inferred from a high level description should be, for example using templates or snippets. Maybe the whole text based idea of programming needs to be side-tracked.
For example, represent the program as kind of (multilevel) graph. After all, graphs are easier to manipulate with a touch interface than text...
Hey! I already mentioned narrowing it down to a family of choices. ;-)
Both these tricks are used by IDE's (and e.g. vim). But this is still thinking in terms of a touch front-end to a conventional language. I'm suggesting an intrinsically touch language - so well-fitted to touch, that a text front-end would be awkward (and difficult to even imagine).
I like your point about choices. It seems that however it was done, it would always boil down to making choices (in some way) among alternatives (of some kind). I also seems we'd need "methods" (or, to be more general, "verbs": for something to be done).
A way to specify what a method does (instead of using instructions) is to actually do it - as macros are implemented in vim and office. Like the writer's admonishment: show, don't tell. But to invoke a method, you still need to choose it in some way - so there's the choice problem you mention again. Maybe the subset of choices available could be constrained by a strict hierarchy of macros... or maybe we could just admit that this doesn't work well with touch, and instead restrict it to a Domain Specific (toy) Language, for very specific and common tasks (rather like the macros of vim and office are arguably DSLs). You don't have to have recursion or turing completeness for a tool to be delightfully useful for the job (e.g. hammers and cars aren't turing complete).
But I just have a nagging feeling that there is a way to do a touch-based general programming language... start by going back to basics and thinking about how we reason and communicate in practice (e.g. in the physical real world) - instead of being trapped by the elaborate programming languages that we happen to be familiar with. Solving the actual problem, not forcing a preconceived solution.
What about speech for choice of verbs? touch + "this one goes here".
Seems pretty intuitive and workable actually....
I'm pretty sceptical as well. These kinds of things have been tried before, and never really caught on. But that might be because pure touch-based interfaces were never really popular before and with the mouse it's entirely impractical.
I think the idea is very promising, to be able to 'code' with touch gestures instead of a keyboard. This is only the first iteration so I guess things will be improved eventually if this catches on.
Comments
I am visual programming skeptic (or better said pragmatic). I've seen quite a few visual environments where at the end of the day (once you've learned the language) it was faster to switch to text mode. Visual programming was great for learning the language though.
The main problem visual programming encounters is the sheer number of options you have when you are entering code in text form.
Just consider that on almost any new line in code you can type in control structure, variable declaration, assignment, function/method call etc. And it is almost always faster to type "if" or "for" than to click through some decision tree to get to your required command.
In touchqode we try to overcome this limitation using prefix tree when showing code suggestions - e.g. when you have methods showTime(), showDate() and showLocation() you can type "s", press "tab" and you see longest common prefixes of methods starting "s" - so you would see "show". Then you can click it and see the actual method names.
Needless to say - templates for structured commands (e.g. "if") are probably necessary for programming on mobile devices.
I have few experimental features for touch programming in my mind, so I hope I'll get to implementing them sooner than later. If anyone has interesting ideas I'll be glad to discuss them.
> The main problem visual programming encounters is the sheer number of options you have when you are entering code in text form.
Agreed. So maybe the solution is to adopt a completely different approach to "visual" programming. One that doesn't involve entering code, and has a bigger dependence on gestures. I have no idea how it would look like though, but something that would allow you to develop on a touch-screen device is quite intriguing.
I agree; yet I do think that there likely are a subset of coding tasks that are suitable for a visual approach (esp if a multi-touch screen gives other benefits, specific to that task). The only thing missing is knowing what those tasks are...
1) a way to address the choice explosion is (highly) domain specific languages, with limited choices. I guess this would be closer to scripting/macros than true programming, but still useful.
2) could the number of options be constrained in some other way? Or, perhaps chosen in a way that's more intuitive to touch - such as pointing to a graphical representation (of something that naturally has a graphical representation). OTOH, while good for nouns, less good for verbs. What about gestures for verbs (like sign language)? Maybe not for the specific choice, but to narrow it down to a family of choices?
3) and the bizarre idea of using the strength of multi-touch to make choices - like a chording keyboard (eg).
Is a keyboard really intrinsically better for coding than pen and paper? (maybe - there's linguistic power in symbols lacking in pictures).
BTW: A prefix tree is useful, but not specialized to multi-touch...
Just two ideas off the cuff:
- have your methods and variables put into "categories". Then you could quickly choose category and you would be presented with limited choice in the category
- code snippets - templated pieces of code (control structures, database access...) where you would just choose variables/methods to fill in the template
Good ideas. Basically, you want to make the language as high-level as possible.
Everything that can be generated or inferred from a high level description should be, for example using templates or snippets. Maybe the whole text based idea of programming needs to be side-tracked.
For example, represent the program as kind of (multilevel) graph. After all, graphs are easier to manipulate with a touch interface than text...
Interesting stuff.
Hey! I already mentioned narrowing it down to a family of choices. ;-)
Both these tricks are used by IDE's (and e.g. vim). But this is still thinking in terms of a touch front-end to a conventional language. I'm suggesting an intrinsically touch language - so well-fitted to touch, that a text front-end would be awkward (and difficult to even imagine).
I like your point about choices. It seems that however it was done, it would always boil down to making choices (in some way) among alternatives (of some kind). I also seems we'd need "methods" (or, to be more general, "verbs": for something to be done).
A way to specify what a method does (instead of using instructions) is to actually do it - as macros are implemented in vim and office. Like the writer's admonishment: show, don't tell. But to invoke a method, you still need to choose it in some way - so there's the choice problem you mention again. Maybe the subset of choices available could be constrained by a strict hierarchy of macros... or maybe we could just admit that this doesn't work well with touch, and instead restrict it to a Domain Specific (toy) Language, for very specific and common tasks (rather like the macros of vim and office are arguably DSLs). You don't have to have recursion or turing completeness for a tool to be delightfully useful for the job (e.g. hammers and cars aren't turing complete).
But I just have a nagging feeling that there is a way to do a touch-based general programming language... start by going back to basics and thinking about how we reason and communicate in practice (e.g. in the physical real world) - instead of being trapped by the elaborate programming languages that we happen to be familiar with. Solving the actual problem, not forcing a preconceived solution.
What about speech for choice of verbs? touch + "this one goes here". Seems pretty intuitive and workable actually....
I'm pretty sceptical as well. These kinds of things have been tried before, and never really caught on. But that might be because pure touch-based interfaces were never really popular before and with the mouse it's entirely impractical.
I think the idea is very promising, to be able to 'code' with touch gestures instead of a keyboard. This is only the first iteration so I guess things will be improved eventually if this catches on.
At least people are thinking about it :)