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....
Comments
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....