I like the concepts of the bubbles and the fact that it show call execution so well instead of one file at a time. That's really cool, but what I find so amazing is that since they built on top of Eclipse they got much further towards a usable system like having an integrated debugger was a nice surprise to me. 10-20 years ago the gap between an academic project and a finished product would have been much wider. Not to mention they got to explore more ground with the concept. Just shows how open source software enables innovation better.
I feel like the response has been fairly lukewarm, but to me this is some really nice (dare I say game-changing) stuff. Mindmap + IDE = great. Why? I have written in a variety of languages, and my number one complaint, whether it be with eclipse, textmate, vim, emacs, whatever, is the clumsiness of going from one file to another and then back to the original. Further, outside of actual development, when debugging, I really like to have all the different pieces open at once. This is a nice way for this to happen and is pretty slick with the different gui movement options. I, like other posters, would be really psyched if you could have some kind of MVC opener which would automagically open all the code files using a certain view. That would save a lot of time shuffling, and then save a lot of time by having them all displayed simultaneously. Anyway, I'm probably over reacting, but after years of having to go back to the mouse everytime i need to look at a new file or struggling to figure out in which square i put which file, this is definitely, in my opinion, a step in right direction.
my number one complaint, whether it be with eclipse, textmate, vim, emacs, whatever, is the clumsiness of going from one file to another and then back to the original
Emacs has a stack for this. Jump to related definition with M-., jump back to where you were before with M-∗. One keystroke is not exactly "clumsy", IMHO.
I, like other posters, would be really psyched if you could have some kind of MVC opener which would automagically open all the code files using a certain view.
I just open all files in the project with `eproject-open-all-project-files`. Then I can iswitchb between them. (Of course, there are lots of extensions that don't require you to have the files open to easily navigate to them; eproject, anything, ido, etc.)
Without downplaying the possible effect of the presented technology, you really should not need to poke through to find stuff or use the mouse to move around...
Vim (or Emacs) along with ctags == awesome. Go to any definition, open file if it was not yet open. Buffer stacks, split windows.
I think there's some really interesting stuff here that should be leveraged. What I like best is that it really focuses your mind on the task at hand. You don't spend a lot of time looking through large amounts of code just to find a few things.
I wouldn't like the UI directly as presented, but there's certainly a starting point there.
Really though, don't know what kind of programmer would accept line wrap on code. Urf.
> my number one complaint, whether it be with eclipse, textmate, vim, emacs, whatever, is the clumsiness of going from one file to another and then back to the original.
I'm curious about what exactly didn't you like about moving between files in vim?
CTRL-^ just toggles back and forth, with ctags you get one-keystroke movement up and down the function call stack, and you can jump to various buffers with ":b partial_filename", or ":b<number>" if you remember the specific number, or ":blast".
That is a very interesting approach - instead of just presenting files, this IDE is already abstracting out some of the semantic structure for you and presenting code based on its relationships. It's meeting you halfway. And it keeps track of things the way you work - by explicitly acknowledging the task structure of the work, it's again meeting you halfway.
One extremely annoying bit watching the video is that for an IDE manipulating text files it requires that your hand never leave the mouse. Every single operation it looks like requires that you right click, click to activate, click to drop down, click to open. Even the 'insta-search' box requires a click. Someone should buy a one button mouse and install it on their computer or just take the mouse away completely. A mouse has a place, but it shouldn't be the primary means of interacting with something that is text.
Programming hasn't been about files for a long time now. That's the reason that we have IDEs in the first place, and why I cringe when people talk about writing code in a text editor.
Any IDE worth its salt will do all the things in that video, except for the little draggable bubbles.
That's why I prefer Wmii, Ion2 and similar window managers. They really manage my windows, ensuring that they don't overlap and use the screen effectively.
In contrast, most other window managers just enable you to fiddle with the windows yourself, and that's all they do for you. You keep moving and resizing them, one by one, steadily. That's very annoying.
(In fact, I don't even have a desktop image, because most of the time, the desktop isn't visible anyway. I don't want to look at my desktop, I want to use that space for the application I'm working with!)
Visual Studio sort of does this. When you drag one pane over another, the default is to have the panes be tiled or tabbed (depending on where you drag it). It's all very intuitive too, with the arrows to guide you through what you're doing. Visual Studio's window management is totally awesome and one of my favorite features.
Indeed. Remember that overlapping windows was a tech demo to show how powerful the graphics processing was. It was never intended to actually be a production feature.
Pallets have been able to snap together to the side of the screen since at least CS3, though I only had issues with < CS1 just after changing main monitor resolution...
I see how useful it could be, but I wonder if it would be good for me. So far I've tried to run in exactly the opposite direction:
1. not using mouse at all
2. concentrating on what needs to be done to what object... not where
I'm a heavy Vim user, so I'm relying on ctags / incremental searching / positions stack for a lot of work. This goes exactly the other way - click your way through to the point you want to get to.
On the other hand, I'd probably prefer to fix bugs in this environment instead of in Vim, because it gives a lot more context and freedom. It looks good for... let's say "exploratory programming".
Maybe it's time to think 2 different IDEs - for "writing code" and for "modifying code"?
I would agree. This seems to be exactly what this IDE is for. I wouldn't dare do any serious code-creating in an environment where I have to do that many key-clicks, but if I'm tracing through code and trying to find exactly where a bug is, I could either open about a zillion split panes in emacs/Netbeans, or I could have all the relevant code open at once, and only the relevant code open. That is where this IDE overlay(?) (it's part of Eclipse, right?) shines.
The thing that makes Vim Vim is just that its modal and has keyboard access for everything. You can get as fast on this as Vim if the right model is applied to the keyboard. Just look at Vimperator.
Guys, we need a better way for exploring big open source projects (like Android, for example), preferably online. Google Code Search is pretty good, but I think there is so much more that can be done.
The most striking thing is how few people here have addressed this point. Everyone seems to be living in a fantasy land where "learning APIs" is as hairy as it gets. I've messed with portions of the Linux Kernel, Chromium, Mozilla, and Coda Filesystem codebases. In each occasion, tools like code-search (provided by lxr.linux.no, mxr.mozilla.org, Google COde, and even `find . | xargs grep`) have been invaluable in getting anything done.
Chromium, Mozilla, and the Linux Kernel were unpleasant, but manageable with the existing tools, because of the incredibly strict guidelines imposed upon contributors as far as code style and other things. On the flip side, the Coda Filesystem, which has grown as the result of many relatively disjoint Ph.D. research projects) requires a whole lot of help and handholding from the guys who have put a decade into it already. I can only imagine private code bases being a LOT worse.
An IDE that makes semantic relationships more obvious to the new guys would do a lot to ramp new people up faster and would really be a huge benefit from a community standpoint as well as just being generally helpful to existing developers.
That said, this is a good first step, and not necessarily perfect. It kind of looks like a toy now, so managing screen real-estate better would be the next big step, I think.
I'm kind of a weird mixed-bread developer. I'm now a heavy Vim user, but was once a heavy IntelliJ IDEA user. I'm also currently a heavy Resharper user at work. I understand the importance of really solid, visual tools, but I also understand the importance of simplicity and flexibility. There is a middle ground, I know it.
As an aside, I think that the GUI toolkit confusion is one of the biggest blockers to this sort of innovation. Terminal emulation is just the lowest common denominator. HTML/JS/CSS is the closest thing we have towards a portable, successful GUI toolkit. And it's simply still not quite ready to fight the advanced desktop graphics battle necessary for this sort of new bread of tools.
1. /Way/ too much mouse-action for coding in my opinion
2. I saw no mention of the best killer feature I can see for this, which is allowing refactoring and restructuring of code by extract bubbles, moving them around, popping bubbles... I've been wanting to perform refactorings in a visible fashion for quite some time now.
The main benefit of this IDE, compared to terminal stalwarts vim and emacs, is the effective use of a large, high-resolution screen. The color-coding and context grouping is really slick; IMO vim gets a bit visually confusing if you split windows more than twice.
My main gripe about this system would be the normal one of moving back and forth between the keyboard and mouse. Also I wonder how sluggish it gets if you have multiple workspaces and debugger sessions open.
The alt+drag static call graph was another cool feature.
Ultimately, the best tool is the one you know best. Any IDE will have a very tough time competing with 30-odd years of developers perfecting all the small stuff in vim and emacs.
I have an unfinished project where I was attempting something similar - I am going to throw it up on google code now and I guess put up a demo in case anyone is interested in the code. It's all just simple javascript/jquery proof of concept. You can see it here http://www.churchofturing.com/dragedit/dragedit.html and google code is http://dragedit.googlecode.com
This is the IDE I didn't know I was missing. Navigating around the code is undoubtedly the highest overhead task I do. This IDE seems like it fixes that problem.
The smart tiling and interaction of "bubbles", beyond just IDE-centric actions, most intrigued me. I'm reminded, of all things, of playing with the Acme editor. The overarching task bar with nameable, savable, and shareable sessions was nice, too.
Such things strike me as generalizable beyond just IDEs.
Regardless of anyone's opinions of this particular IDE / workflow it's been clear for a while that the future of developer tools will almost certainly include:
- IDEs that take advantage of greater knowledge of code than just a simple organization of text files (e.g. reflection, call stacks, static and dynamic analysis, etc.)
- Tying bug-tracking, automated testing, and source control together in a coherent way.
- Generally merging the developer workflow into a seamless experience instead of a disjoint series of steps across N sets of distinct tools.
Already we're seeing plenty of movement in this direction, with things like visual studio's intellisense, more in-IDE unit test tools, and the plethora of refactoring tools out there.
The days of IDEs that do little more than compile and keep track of collections of files for you are numbered.
I thought this was a really interesting idea. In uni (college) I became pretty dependent on Mind Maps (using FreeMind) for planning essays. Laying all the relevant concepts and relationships out visually worked really well for me.
From that angle, I think anything that helps programmers visualize the structure of their software is a good thing. I think any half-decent programmer is good at maintaining these kind of relationship graphs in their head, anyhow. But that's no reason why tooling can't make that even better. There's potential for a programmer to visualise the structure of their program, beyond what they can hold in their head.
I also like that this idea encourages good overall design, short logically arranged methods, and neatly compartmentalises "workspaces" in a visual way.
I have a few criticisms, though:
- Nowhere near enough keyboard-driving for my liking. :).
- It'd be great if zooming out could transform the representation a bit, so instead of ant-size pieces of code the user could work with only the higher-level abstractions between the bubbles they've laid out. I see this happening from the "groups" and "workspaces", but not being inferred from the code itself.
- Is there some other way to show bubbles that were opened independently, but are actually related in the code? Apart from drawing a specific line and seeing the call graph (which is neat, btw.)
- I'm concerned about what happens when a single workspace gets bigger than a single window.
- What happens when design (as it often needs to) breaks through neatly defined abstractions, and lines start needing to be drawn all over the place. Can Code Bubbles represent this without driving the programmer insane, and (also) can it represent this in a way which encourages the programmer to see better ways to refactor?
- Arbitrary areas and names, in a flat namespace on a flat 2D plane, with no relationships between them, is nice and simple. However, it seems like it would limit you when working with big projects and lots of different, but related, spaces.
[+] [-] chubbard|16 years ago|reply
[+] [-] d4ft|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
Emacs has a stack for this. Jump to related definition with M-., jump back to where you were before with M-∗. One keystroke is not exactly "clumsy", IMHO.
I, like other posters, would be really psyched if you could have some kind of MVC opener which would automagically open all the code files using a certain view.
I just open all files in the project with `eproject-open-all-project-files`. Then I can iswitchb between them. (Of course, there are lots of extensions that don't require you to have the files open to easily navigate to them; eproject, anything, ido, etc.)
[+] [-] rue|16 years ago|reply
Vim (or Emacs) along with ctags == awesome. Go to any definition, open file if it was not yet open. Buffer stacks, split windows.
[+] [-] mrcharles|16 years ago|reply
I wouldn't like the UI directly as presented, but there's certainly a starting point there.
Really though, don't know what kind of programmer would accept line wrap on code. Urf.
[+] [-] ww520|16 years ago|reply
Yes, that was something bugged me for a long time so I wrote an Emacs package to fix it. http://breadcrumbemacs.sourceforge.net/
[+] [-] LiveTheDream|16 years ago|reply
CTRL-^ just toggles back and forth, with ctags you get one-keystroke movement up and down the function call stack, and you can jump to various buffers with ":b partial_filename", or ":b<number>" if you remember the specific number, or ":blast".
[+] [-] unknown|16 years ago|reply
[deleted]
[+] [-] Hexstream|16 years ago|reply
[+] [-] Vivtek|16 years ago|reply
This is a really promising start. Very cool.
[+] [-] icefox|16 years ago|reply
[+] [-] jasonkester|16 years ago|reply
Any IDE worth its salt will do all the things in that video, except for the little draggable bubbles.
[+] [-] thetable|16 years ago|reply
I'm thinking of the gazillion pallettes in Adobe CS that always occlude each other. You'd think they'd have figured that out by now.
[+] [-] vog|16 years ago|reply
In contrast, most other window managers just enable you to fiddle with the windows yourself, and that's all they do for you. You keep moving and resizing them, one by one, steadily. That's very annoying.
(In fact, I don't even have a desktop image, because most of the time, the desktop isn't visible anyway. I don't want to look at my desktop, I want to use that space for the application I'm working with!)
[+] [-] altano|16 years ago|reply
[+] [-] breck|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
[+] [-] devin|16 years ago|reply
[+] [-] DougBTX|16 years ago|reply
[+] [-] viraptor|16 years ago|reply
1. not using mouse at all
2. concentrating on what needs to be done to what object... not where
I'm a heavy Vim user, so I'm relying on ctags / incremental searching / positions stack for a lot of work. This goes exactly the other way - click your way through to the point you want to get to.
On the other hand, I'd probably prefer to fix bugs in this environment instead of in Vim, because it gives a lot more context and freedom. It looks good for... let's say "exploratory programming".
Maybe it's time to think 2 different IDEs - for "writing code" and for "modifying code"?
[+] [-] Vivtek|16 years ago|reply
[+] [-] sukuriant|16 years ago|reply
[+] [-] gfodor|16 years ago|reply
[+] [-] sofal|16 years ago|reply
[+] [-] alexgartrell|16 years ago|reply
Chromium, Mozilla, and the Linux Kernel were unpleasant, but manageable with the existing tools, because of the incredibly strict guidelines imposed upon contributors as far as code style and other things. On the flip side, the Coda Filesystem, which has grown as the result of many relatively disjoint Ph.D. research projects) requires a whole lot of help and handholding from the guys who have put a decade into it already. I can only imagine private code bases being a LOT worse.
An IDE that makes semantic relationships more obvious to the new guys would do a lot to ramp new people up faster and would really be a huge benefit from a community standpoint as well as just being generally helpful to existing developers.
That said, this is a good first step, and not necessarily perfect. It kind of looks like a toy now, so managing screen real-estate better would be the next big step, I think.
[+] [-] snprbob86|16 years ago|reply
I'm kind of a weird mixed-bread developer. I'm now a heavy Vim user, but was once a heavy IntelliJ IDEA user. I'm also currently a heavy Resharper user at work. I understand the importance of really solid, visual tools, but I also understand the importance of simplicity and flexibility. There is a middle ground, I know it.
As an aside, I think that the GUI toolkit confusion is one of the biggest blockers to this sort of innovation. Terminal emulation is just the lowest common denominator. HTML/JS/CSS is the closest thing we have towards a portable, successful GUI toolkit. And it's simply still not quite ready to fight the advanced desktop graphics battle necessary for this sort of new bread of tools.
[+] [-] abyx|16 years ago|reply
1. /Way/ too much mouse-action for coding in my opinion
2. I saw no mention of the best killer feature I can see for this, which is allowing refactoring and restructuring of code by extract bubbles, moving them around, popping bubbles... I've been wanting to perform refactorings in a visible fashion for quite some time now.
[+] [-] matrixownsyou|16 years ago|reply
[+] [-] utku_karatas2|16 years ago|reply
[+] [-] guelo|16 years ago|reply
[+] [-] Quiark|16 years ago|reply
[+] [-] jcromartie|16 years ago|reply
[+] [-] t_crayford|16 years ago|reply
[+] [-] unknown|16 years ago|reply
[deleted]
[+] [-] keltex|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
[+] [-] jamesrcole|16 years ago|reply
This approach might be conducive to RFS 5: Development on Handhelds (http://ycombinator.com/rfs5.html).
Bubbles - smaller chunks of information more suitable for a small display
Arranged in a spatial layout - fits with the spatial, panning style of the iPhone UI.
[+] [-] LiveTheDream|16 years ago|reply
My main gripe about this system would be the normal one of moving back and forth between the keyboard and mouse. Also I wonder how sluggish it gets if you have multiple workspaces and debugger sessions open.
The alt+drag static call graph was another cool feature.
Ultimately, the best tool is the one you know best. Any IDE will have a very tough time competing with 30-odd years of developers perfecting all the small stuff in vim and emacs.
[+] [-] chaosmachine|16 years ago|reply
[+] [-] shaunxcode|16 years ago|reply
[+] [-] jacquesm|16 years ago|reply
[+] [-] houseabsolute|16 years ago|reply
[+] [-] Semiapies|16 years ago|reply
Such things strike me as generalizable beyond just IDEs.
[+] [-] ximeng|16 years ago|reply
Edit: Also interesting - storing an old debug session with state and being able to visually compare that with a debug session made after code changes.
[+] [-] InclinedPlane|16 years ago|reply
- IDEs that take advantage of greater knowledge of code than just a simple organization of text files (e.g. reflection, call stacks, static and dynamic analysis, etc.)
- Tying bug-tracking, automated testing, and source control together in a coherent way.
- Generally merging the developer workflow into a seamless experience instead of a disjoint series of steps across N sets of distinct tools.
Already we're seeing plenty of movement in this direction, with things like visual studio's intellisense, more in-IDE unit test tools, and the plethora of refactoring tools out there.
The days of IDEs that do little more than compile and keep track of collections of files for you are numbered.
[+] [-] angusgr|16 years ago|reply
From that angle, I think anything that helps programmers visualize the structure of their software is a good thing. I think any half-decent programmer is good at maintaining these kind of relationship graphs in their head, anyhow. But that's no reason why tooling can't make that even better. There's potential for a programmer to visualise the structure of their program, beyond what they can hold in their head.
I also like that this idea encourages good overall design, short logically arranged methods, and neatly compartmentalises "workspaces" in a visual way.
I have a few criticisms, though:
- Nowhere near enough keyboard-driving for my liking. :).
- It'd be great if zooming out could transform the representation a bit, so instead of ant-size pieces of code the user could work with only the higher-level abstractions between the bubbles they've laid out. I see this happening from the "groups" and "workspaces", but not being inferred from the code itself.
- Is there some other way to show bubbles that were opened independently, but are actually related in the code? Apart from drawing a specific line and seeing the call graph (which is neat, btw.)
- I'm concerned about what happens when a single workspace gets bigger than a single window.
- What happens when design (as it often needs to) breaks through neatly defined abstractions, and lines start needing to be drawn all over the place. Can Code Bubbles represent this without driving the programmer insane, and (also) can it represent this in a way which encourages the programmer to see better ways to refactor?
- Arbitrary areas and names, in a flat namespace on a flat 2D plane, with no relationships between them, is nice and simple. However, it seems like it would limit you when working with big projects and lots of different, but related, spaces.