Slashdot Mirror
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."
Welcome to the 1970s. Squeak is one of the better implementations these days.
I'm going to need a bigger screen.
More UI elements to click-n-drag
As if having a couple dozen windows open and trying to organize them wasn't fun enough.
No sig for you!!
Perhaps we could call such a pieces of code "functions" instead.
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.
I've recently been using Mylyn to give me a focussed view on the code I'm working on. I love the way it automatically adds things to the context as I click around.
Then of course there's the rather gorgeous "Run unit tests in context" to give me feedback on the things I've been tinkering with.
Might just be more handy as a display mode than an entire paradigm but I can see how it would be nice if you could display functions together from different files.
If you are working on one function that is in file3.c that has to interact with functions in file7.c and file3.c, why not be able to display them all as if they are in the same file (when they will eventually get compiled together anyways). The code already exists in most IDEs to collapse functions, so why not extend that to being able to mash up all the collapsed functions from every file. Then you can display the ones you want to see as if they were all in the same file.
Keeping stuff in separate files and including them is a good organization technique and helps with multiple people working on a project (and you can substitute different files for different platforms, etc.) but I can see where this would be useful if instead of flipping between 5 open files, the IDE could display just the portions you need. Bonus points if the IDE can do this automatically in a semi intelligent manner--like show the collapsed version of functions that might be relevant based on some criteria and then allow you to expand them if you like.
Bottles.
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.
meep
isolated, self-contained, easily testable pieces of code
And I'd add small and short to that list. There's no way this bubble concept would be useable with code fragments longer than a few lines, and even those need to be short since wrapping would destroy the usability of the whole thing. Also, in the sample video, when they had to scroll the screen because of the many bubbles, well, there it became a lost cause for me. Realistically, from code dealing with more than helloworlds that I've seen and written, this thing would be a real dealbreaker. I can't think how so much fragmentation can help you in the long run. Having self-contained small pieces of code that do one thing - that is useful -, I'd say those are hard to find. Managing tens of thousands of lines of code this way, I'd go crazy very quickly.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
M-C-x fuck-up-my-screen
It must have been something you assimilated. . . .
See the Smalltalk browser:
http://onsmalltalk.com/on-the-smalltalk-browser
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/
"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...
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
But, does it have a good text editor?
I figured out just recently that the first goal of any true Java developer is to write an abstraction layer/framework to abstract previous abstraction layers/frameworks written before them.
Now, this week, I learn the 2nd goal. Write a way cool looking but really very complex development environment to help you muddle one's way through the myriad of abstraction layers already written.
All of this just to help overcome the basics such as overloading operators.
In all seriousness, this seems to show too little information with too much space in between. My screen real estate is vary valuable. Not to be wasted with pretty colored borders and arrows and such.
-joe
-- Many men would appreciate a woman's mind more if they could fondle it
Speak for yourself. Some of us like the mouse and window for code editing.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Wanted:
Java developer with 40 years experience in Code Bubbling concepts.
5 years experience with the Code Bubble IDE.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
I think this kind of IDE would be very usefull during code-maintenance, especially when the code you maintain is written by you (which is often the case).
When developing new code, the bubble-concept could be too confusing, because it seems to hide the overall structure of the code.
But during maintenance, when hunting bugs, I often don't want to see the whole picture (and hence the whole complexity), but am much more interested in smaller sections of a program, and the relations between them. The bubble concept would really help.
this sig has intentionally been left blank
What a closed-minded and overly general statement!
I certainly agree that often a keyboard-only approach and minimal screen "wastage" is great - I am an emacs fan after all. However, there are always exceptions and if we don't explore new ideas we won't find better ways of doing things. How can you call it an automatic giant failure when you haven't even tried it yet.
Your complaint about not using all available screen space for what you want to see doesn't even make sense in this context! Why would you want a single bubble/code fragment to take up the entire screen? That's contrary to the point! The idea here is to be able to quickly trace a complex program by seeing only the code that represents the function being called at any point, rather than the whole irrelevant file. And while there should surely be a keyboard method to navigate the bubbles (arrow keys would work marvelously here), a mouse is an excellent way to navigate a large 2D surface.
I just checked on Wikipedia and I couldn't find a picture of a function, could you draw me one please so I can see how to fill my bath tub with them?
And hey... If you watched the whole video, you'd discover: They do have ways of navigating the space via keyboard.
I'm more a .NET guy these days, but I'd love to try this. Even if the whole thing isn't a slam-dunk, I think there are valuable and useful concepts here that can be useful elsewhere.
~D
This sig has been enciphered with a one-time pad. It could say almost anything.
Beware the IDEs of March
I eat only the real part of complex carbohydrates.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.