Touch based WP7 programing environment and language by Microsoft Research(research.microsoft.com)
research.microsoft.com
Touch based WP7 programing environment and language by Microsoft Research
http://research.microsoft.com/en-us/projects/touchstudio/
15 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.
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.
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...
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
- 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.
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....
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 :)
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 :)
Might someone with a WP7 phone be kind enough to make a video of this? I'm super curious.
It has some nice UI ideas - I particularly like the idea of calculator-like editor.
Environments with limited text input ability get significant advantage from staticaly (or at least strong) typed languages - code autocomplete is really killer weapon when editing text.
As a sidenote something similar can be achieved on Android phones using Touchqode [1] and Scripting Layer For Android [2]. It does not have specific language but you can use any of its supported languages - Python, Ruby, BeanShell (Java), Rhino (JavaScript)
Disclaimer: I work on touchqode
[1] http://www.touchqode.com [2] http://code.google.com/p/android-scripting/
Environments with limited text input ability get significant advantage from staticaly (or at least strong) typed languages - code autocomplete is really killer weapon when editing text.
As a sidenote something similar can be achieved on Android phones using Touchqode [1] and Scripting Layer For Android [2]. It does not have specific language but you can use any of its supported languages - Python, Ruby, BeanShell (Java), Rhino (JavaScript)
Disclaimer: I work on touchqode
[1] http://www.touchqode.com [2] http://code.google.com/p/android-scripting/
Duck Duck Go gets a bit of love in the sample applications. There is a sample app that talks to their API.
Interesting to see how they've shoehorned an editor into the touch screen interface. As an end user its nice to have a little more control over my device.
Interesting to see how they've shoehorned an editor into the touch screen interface. As an end user its nice to have a little more control over my device.
The editing UI with the keywords as a calculator-style interface in the bottom half of the screen is an interesting '80s flashback. It reminds me of LucasArts-style adventure games with a grid of action verbs below the game view.
Also, those home computer keyboards where each key had both an alphabet and a BASIC keyword printed on it:
http://ewyse.files.wordpress.com/2011/03/acornelectron_top.j...
That was a pretty clever way to make the programming language quick reference available at a glance.
Also, those home computer keyboards where each key had both an alphabet and a BASIC keyword printed on it:
http://ewyse.files.wordpress.com/2011/03/acornelectron_top.j...
That was a pretty clever way to make the programming language quick reference available at a glance.
This probably dates me and marks me as unhip but..
When I first read the headline, I thought "Why would anyone add a touch interface to WordPerfect 7?"
When I first read the headline, I thought "Why would anyone add a touch interface to WordPerfect 7?"
First thought: Wow, the syntax looks like AppleScript.
Looks quite compelling though - hopefully they'll tie in the PIM and GPS features - imagine being able to ask you phone how long you spent physically at work during the week, or who are the top 5 people you emailed in the last month.
Looks quite compelling though - hopefully they'll tie in the PIM and GPS features - imagine being able to ask you phone how long you spent physically at work during the week, or who are the top 5 people you emailed in the last month.
it's probably not there yet: http://www.ycombinator.com/rfs5.html
Could there be an entirely different approach to programming, built around the touch-screen from the ground up? Using its strengths (e.g. analog 2D input) and skipping its weaknesses (e.g. no digital symbols from keystrokes) - instead of trying to cram the old ideas into the new? Let it grow in its own way, I say.
A starting point might be visual form creation; lines for bindings, for transitions, for calls; multiple fingers for looping. Or, perhaps even better, to be like the diagrams we sketch to represent coding ideas! Instead of adapting our most natural and intuitive expression (diagrams) to coding in text, why not work directly with diagrams, now that we finally have the appropriate tools?
Diagrams aren't suitable for all coding tasks, but I recommend fitting a technology to the tasks where it naturally excels.
disclaimer I haven't played with the tech (no WP7), just going by the webpage. Lest I offend with my ridiculously idealistic demands (who of us has created a fundamentally new approach to coding? Not I), this really shows that MS is pro-developer (while apple is pro-consumer) - and just starting to use multi-touch as a programming fundamental is the most important step in this quest.