Code Bubbles — Rethinking the IDE's User Interface

kang327 writes "As Java developers we are used to the familiar file-based user interface that is used by all of the major IDEs. A team at Brown University has developed an IDE for Java called Code Bubbles that makes a fairly radical departure from current IDEs — it is based on fragments instead of files. The idea is that you can see many different pieces of code at once. Fragments can form groups, have automatic layout assistance, wrap long lines based on syntax, and exist in a virtual workspace that you can pan. A video shows reading and editing code, opening different kinds of info such as Javadocs, bug reports and notes, annotating and sharing workspaces, and debugging with bubbles. They report on several user studies that show the system increases performance for the tasks studied, and also that professional developers were enthusiastic about using it. There is also a Beta that you can sign up for."

Screen Size

[pavon]

The demo made this look pretty nice for tracing functionality through multiple classes/method calls. It annoys me that most IDEs make it harder to view code side by side than Emacs did 15 years ago. That said, it appears that you either need a really huge monitor, or be comfortable reading really small text, for this system to work they way they demonstrate.

Debugging and documentation

[beakerMeep]

This looks nice as a way of exploring, debugging, and documenting code especially. I like how you can save layouts by date. But I feel like I would want to step back into eclipse to do the writing. I would be nice if they made a way to integrate with other IDEs.

Looks promising...

[johnlcallaway]

I do mostly maintenance programming (by choice .. I'm good at fixing code I know nothing about, I like it, it keeps from from being pigeonholed, and there is a lot less competition). So I spend a lot of time hopping around code I know nothing about. I also spend a lot of time 'going backwards' through programs, since sometimes all I have is an error message and it's easier than trying to start at Main. This type of interface would be very beneficial in my type of work.

Even writing code from scratch, I rarely program 'top down', but group methods in the file based on some vague grouping concept, like all setters/getters together, methods that are called somewhere around methods that are calling them. It's really not necessary for me to 'know' where in the file they are, as long as I can get to them, open, do whatever, then close them.

I think that as long as I can open a 'bubble' and have complete access to all my code via scrolling, this would work fine. I would only need to open bubbles as I need to then.

Besides .. what would happen to those bubbles if some braces got out of alignment. You would have to have pure code scrolling to be able to fix something like that.

Step by step, Java reinvents Smalltalk...

[Paul Fernhout]

See the Smalltalk browser:
    http://onsmalltalk.com/on-the-smalltalk-browser [onsmalltalk.com]

Now if only Java had Smalltalk's blocks.

And Smalltalk's more descriptive message passing syntax of "Foo x: 10 y: 20". instead of "new Foo(10, 20);"

And Smalltalk's extendable control syntax...

And Smalltalk's "doesNotUnderstand" concept for proxying.

And Smalltalk's become: method.

And Smalltalk's ability to rethrow exceptions...

And Smalltalk's multi-generational garbage collector...

And so on...

One step at a time...

If only the ParcPlace suits had not been so greedy when Sun wanted to use Smalltalk in set top devices, and instead Sun turned to a Frankenstein "Plan B".
    http://fargoagile.com/joomla/content/view/15/26/ [fargoagile.com]
        "When I became V.P. of Development at ParcPlace-Digitalk in 1996, Bill Lyons (then CEO) told me the same story about Sun and VW. According to Bill, at some point in the early '90's when Adele was still CEO, Sun approached ParcPlace for a license to use VW (probably ObjectWorks at the time) in some set top box project they were working on. Sun wanted to use a commercially viable OO language with a proven track record. At the time ParcPlace was licensing Smalltalk for >$100 a copy. Given the volume that Sun was quoting, PP gave Sun a firm quote on the order of $100/copy. Sun was willing to pay at most $9-10/copy for the Smalltalk licenses. Sun was not willing to go higher and PP was unwilling to go lower, so nothing ever happened and Sun went its own way with its own internally developed language (Oak...Java). The initial development of Oak might well have predated the discussions between Sun and PP, but it was PP's unwillingness to go lower on the price of Smalltalk that gave Oak its green light within Sun (according to Bill anyway). Bill went on to lament that had PP played its cards right, Smalltalk would have been the language used by Sun and the language that would have ruled the Internet. Obviously, you can take that with a grain of salt. I don't know if Bill's story to me was true (he certainly seemed to think it was), but it might be confirmable by Adele. If it is true, it is merely another sad story of what might have been and how close Smalltalk might have come to universal acceptance."

How much people forget...

Of course, fifteen years later, Java is not that bad... Most of the bugs are out. There are some good libraries. There is a better garbage collector... And so on...

But, does it have...

[narooze]

But, does it have a good text editor [vim.org]?

But at least now we can use those wide screens

[Anonymous Brave Guy]

Actually, as I watched the video, the one thing I kept thinking was how nice it would be to use my current (1920x1200) screen efficiently for programming.

The typical Microsoft/Eclipse/whatever GUI today is horribly wasteful: vast areas are wasted on window dressing, toolbars, menus, scrollbars, title bars, line number margins, breakpoint margins, bookmark margins... I'm lucky if more than 1/2 of the pixels on my screen are actually showing me code at any given time, and the moment you mention compiling or debugging anything you're lucky if it's over 1/3 of the pixels.

Moreover, as others have noted, typical code formatting conventions today are wasteful as well. Any arbitrary limit on line width belongs in another century, and IME just results in developers who have a good reason to write a relatively long line messing around with awkward formatting hacks or truncating identifiers in order to obey the letter of the law. Equally, there is no point having lines that average perhaps half that length filling all 1920 pixels of my widescreen monitor's width.

There were plenty of ideas in the presentation that I thought had potential, though many of them have been tried by others before as well. Of all of those ideas, the one thing I wish every IDE would do tomorrow is let me open lots of smaller windows as I navigate my code, organise the windows automatically, and hide all the other clutter unless I actually want it. The Code Bubbles IDE seems to do a decent job of that.