This post begins a hopefully-weekly blog post about research that I have recently read or found out about. Posts may be written sporadically, but hopefully can be posted on a regular schedule.
Over in software engineering-land, a new paper at ICSE 2010 (May 2-8, Capetown, S. Africa) unveils the idea of Code Bubbles.
If you go to the site, there is a 1080p YouTube demo of the idea. Code Bubbles is an IDE where related bits of context can all be viewed together spatially, regardless of source file or class. These independent code snippets are graphically in separate "bubbles", and can be grouped together according to task. Additionally, things like emails, notes, Javadocs, and other assorted content can be loaded into a "bubble" and grouped with related content. The whole system seems to take the concept of "working sets" to its logical conclusion.
One common task in Java IDE's such as Eclipse is to read some code, recursively look up some declarations of types or methods, and then write some new code that incorporates all of these different types and methods. A similar process happens when a developer tries to find and fix a bug: starting from a stack trace or error message, one must trace through the execution of the program, possibly through many disparate classes, methods, and so on. In Eclipse and similar IDE's, this task involves opening many files as tabs in the same workspace; after trying one particular program trace, the windows must be closed individually, and if one finds a good combination of views that expose the bug, there is no way to serialize it so that others can also use the view.
Code Bubbles could potentially make the above situation much nicer: it has debugger support, which can automatically open relevant code snippets from the call stack at any point during execution. One of the best features in my mind is the ability to import and export working sets (groups of bubbles) by email. Coupled with some design explanations, a bunch of pre-determined snippets of code could go a long way towards documenting the architecture and important parts of a complex program. Other cool features I noticed include
- Traditional class/method browser- from which, any method can be pulled out into its own bubble.
- User queries- I didn't get a good idea of how this worked, but it seemed to be a fulltext search on method, variable, class, type names (similar to the Awesome Bar in Firefox).
- Labeling of bubble groups and workspace areas
- Zoom in/out for rearranging groups
Just looking from the video, i'm quite impressed by the amount of polish present (for a research work). Their framework is built on top of Eclipse, and uses its backends for the dirty work (parsing/syntax highlighting, static analysis, editor UI). I'm interested in the details as well- they will post a PDF after the conference is over in May.
• • •
I think there are plenty of exciting directions to go from this work. For one, it would be useful to find out through practical experience when this sort of interface is useful and when it is not. My guess is that this will be great for discovering a new codebase or hunting for bugs, but not as useful for writing new code. It also seems to require a 24"+ monitor to really shine (which is fine, because there is no other practical use for such large desktop monitors).
One idea that struck me is that since the workspace is so large, what would happen if multiple people could simultaneously share the workspace and see each other's changes in real-time? I don't know if such a scheme would work as well in an Eclipse-based application (cf. web-based collaborative editing such as CodeCollab and collabedit, or systems like SubEthaEdit built from the ground-up to support distributed/collaborative editing). It would also pose interesting (read: nontrivial) questions about the integration of version control into such a system, especially if there is no notion of who "owns" a certain version of a file.
The last point I want to address is the interesting yet puzzling response to the project on the rest of the Internet. On a Slashdot story about the project, the overall responses were neutral to negative. On a similar LTU story, almost all the responses were positive. This is surprising to me, because it is usually the reverse: LTU'ers complain about IDE's reinventing Smalltalk, while Slashdotters coo over pretty graphics. I guess the one thing that helps to explain the discrepancy is the use of Eclipse and Java, which (somehow) has a better reception at a programming languages research blog.