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.
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.
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.
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.
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
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.
Beware the IDEs of March
I eat only the real part of complex carbohydrates.