New IDE: code bubbles
cs.brown.edu
cs.brown.edu
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.
I'd happily accept syntactically- and semantically-aware line wrap, if someone could do it and get it right. Combine that with elastic tabs that actually work, add a standard set of layout rules that gives good results, and provide bullets to shoot anyone who thinks coding standards should be about whether the space goes before or after that `*` when declaring a pointer, and I'm sold. :-)
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.)
It's a pretty neat literate programming tool.
I would probably use it more if I wrote some scripts to autogen the outlines for entire codebases.
http://tibleiz.net/code-browser/
More powerful overall. It implements elastic tabstops too! Little unknown gem. good for outlining a book/paper also.
Vim (or Emacs) along with ctags == awesome. Go to any definition, open file if it was not yet open. Buffer stacks, split windows.
I also like using tabs, so I found the following mapping to make tag lookups open in a new tab instead of a new buffer:
map \gt :tab split<CR>:exec("tag ".expand("<cword>"))<CR>
It has a few kinks, but it works well and I think it complements my \tt, \tn, \tp commands. (Tabnew, tabnext, tabprev.)Yes, that was something bugged me for a long time so I wrote an Emacs package to fix it. http://breadcrumbemacs.sourceforge.net/
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".
This is a really promising start. Very cool.
Any IDE worth its salt will do all the things in that video, except for the little draggable bubbles.
Yeah, because we have to type M-. to navigate to the related code.
(Also, insert rant about how "UNIX is my IDE".)
I can see grandma not using it, but anyone on this site ought to be able to figure out the basics in short order.
Of course, no one ever truly masters it - I'm always learning cool new things. But that's part of what makes it so great.
Can Emacs give me a hyper-linked list of all usages of a given symbol and do it properly(lexical scope, etc.), not just doing a simple symbol search?
Can I edit my code in emacs, have a background compiler compile the file on the fly, and also provide error feedback, hilighting the problem lines with a tagged failure reason and also providing a hyper-linked list in another window as well? Last I checked, the best I could do would be to kick off a compile manually and navigate the errors as a linked list.
How's emacs' refactoring support? Judging by the following stackoverflow post, it's pretty poor: http://stackoverflow.com/questions/673554/how-can-i-refactor....
How's Emacs' keyword completion? Last I checked, it was just a hacky dictionary look-up, whereas an IDE can semantically analyze the source to provide intelligent suggestions.
Even if you can get Vim or Emacs to do some of the above, it usually isn't as easy to use or as useful as an IDE. For instance, I know you can get call graph support in Vim using cctree.vim, but it relies on cscope, which requires refreshing the database manually, is slow to load, and tends to generate incomplete tag sets.
IDE's are, well, better integrated, and so can do many things a lot better than looser environments like Emacs and Vim. Their UI's tend to be a lot more powerful because they are not designed to be run on windowless environments. Personally, for small projects I use Vim and for large projects I use an IDE with a Vim emulation plugin like Netbean's JVI plugin.
It's just not a mouse-based IDE. Mouse clicking makes my hands hurt much faster than using the keyboard. I also find it annoying to switch from mouse<->keyboard, so I don't want a UI that relies on constant mousing.
Um no. But if so, then someone better start busting a lisp to get emacs to make cute little bubbles. I'd love to see that.
Saying "Emacs can do whatever you want" is like saying "your computer can do anything you want." Sure it can, so long as you're willing to write the code to make it go. But my time is finite; I cannot be bothered to re-build environments that have already been implemented elsewhere.
Yes, I've used ctags and I've used etags. They tend to be interesting approximations but are never 100% reliable. They don't do a deep sematic analysis of my program. (For example, they don't understand C macros.) They don't update as I type.
The closest I've ever seen has been the "Semantic Bovinator" thingy. I have never managed to get it to run, nor has anybody I've seen try. You experience may be different, of course. (I realize that by posting this I'm inviting a raft of people to post and say "It works for me!" :) )
That said, I use vim for C, but I still use Eclipse for Java and C++/Qt.
Perhaps vim and emacs don't do everything you want. But also, perhaps you don't know their capabilities as well as you think you do?
SLIME has this in Emacs for Common Lisp and perhaps other languages that work with SLIME.
I'm on a non-multitasking phone now so you'll have to do the googling yourself.
We might use different technologies. I mostly write Objective-C, Ruby, Python, C, JavaScript, and recently some Objective-J and Erlang. Now and then I write Lisp (CL, Emacs), Scheme, Haskell, x86 assembly, and PHP. The only one of those I don't write in Emacs is Obj-C.
Other editors or IDEs may be better at certain tasks, just as Emacs has unparalleled Lisp support with SLIME. When there is clearly a best tool in one field then people tend to use that tool, if the payoff is worth it. Except for pg and a few others, people generally write Lisp in Emacs. I write Cocoa and Cocoa Touch apps in Xcode and IB. I'm pragmatic about it. But when I tried to use Eclipse for Mojo (webOS) because Palm recommended Eclipse + Mojo plugin, it ended up being more productive for me to extend an existing Mojo mode for Emacs[1] to have even more features[2] than the Eclipse plugin (or any of the others, Komodo, etc). Similarly if I were doing Java I would at least look into IntelliJ IDEA or Eclipse.
[1] http://www.emacswiki.org/emacs/MojoSdk and http://github.com/samsonjs/mojo.el
[2] http://www.webos-internals.org/wiki/Comparison_of_Editors (temporarily down)
It's true that some things are lacking, so it's too bad that whoever wrote the code that does your high-level syntactic analysis didn't make it independent enough that it could be used in other places than whatever IDE you were referring to.
Good keyboard navigation in an editor is valuable, and many IDEs have poor support for it. On this we can probably all agree.
But as I read it, the grandparent post was about functionality. Modern IDEs have a level of semantic awareness that generic editors like Emacs don't, at least not without a prohibitive amount of effort to implement it. As a text editor, Emacs is very powerful. As a code editor, it lacks support for even basic semantic analysis, which means such tricks as it does have are naive operations based on text matching. In a world where even entry-level IDEs have support for basic refactoring, auto-completion and code navigation, Emacs is the dinosaur that hasn't seen the asteroid yet: awesome raw power but completely unaware of the bigger picture.
Emacs may have a shallower understanding of languages than an IDE, but the breadth of languages it understands is pretty amazing.
Still, I think this raises an interesting question: is it more beneficial to choose exactly the right language for each project in isolation, or to adopt a "good enough" general purpose language that can be learned in more depth by the development team, and used together with comprehensive library support and a strong and familiar IDE?
Eclipse is a step in the right direction in terms of openness and universality. But the editing experience still sucks. And it's harder to extend and customize than it should be.
There may come a day when there's an IDE that a) has a great editing experience b) is fast, flexible, and universal, and c) offer not just crutches and marginal improvements, but radical, order-of-magnitude improvements to the way we interact with software. It's not today. But the linked research project actually has some promise.
Are you sure? I would expect that the process of physically typing in the changes you want to make takes only a fairly small amount of time, certainly much less than understanding the code that will be changed or designing the new part.
However, the typing is just mechanical grunt-work that tends to distract from other areas. If it can be automated with good refactoring tools and the like and so minimize the distraction to the developer's thought process then so much the better.
I would really like to see Yi step up at some point and solve the problem here. It's already got proper incremental parsing with a proper syntax tree. When people add advanced language-specific modes to it, it might be the first "proper" refactoring vim/emacs like text-only IDE.
Not strictly speaking true: http://cedet.sourceforge.net/semantic.shtml
Yes. You're looking for Cedet. Can your IDE read my mail?
> Can Emacs give me a hyper-linked list of all usages of a given symbol and do it properly(lexical scope, etc.), not just doing a simple symbol search?
Yes. You're looking for Cedet. Can your IDE integrate with your calendar?
> Can I edit my code in emacs, have a background compiler compile the file on the fly, and also provide error feedback, hilighting the problem lines
Yes. You're looking for `flymake-mode`. Can your IDE email who created the error using version control information?
> How's emacs' refactoring support? Judging by the following stackoverflow post
Stackoverflow gives retarded answers sometimes. The next best suggestion on that page is correct. Cedet is great.
> How's Emacs' keyword completion?
It's fine. You can complete symbols sensitively, and complete filenames or email addresses from anywhere. Having multiple completion systems is very useful. How's your IDE's ability to complete those things?
> Even if you can get Vim or Emacs to do some of the above, it usually isn't as easy to use or as useful as an IDE.
You don't need to be so hostile. Emacs does these things just fine, and has for a long time. Emacs also does my time tracking, outlining, and email. Your IDE won't do any of those things, and you don't expect it to because you think those tasks are best left to other parts of your operating system.
The thing you're missing is that for Emacs users, Emacs is the operating system. I dual boot into Firefox sometimes.
I would be interested in seeing similar environments for C#/Java as well as for dynamic languages like ruby/python/php, which IDEs have also been handling very well lately. I've also noticed in general that it's difficult to make an IDE for c/c++ that works better than editors. They compile slowly, The macro system severely complicates quick parsing, C++'s grammar in particular is very difficult to parse and analyze, the languages do not make run-time loading of code easy, and they don't provide much in the way of RTTI. In short, they are not very IDE-friendly languages. Java and C# are the perfect IDE languages, and dynamic languages suffer from not providing enough static information.
This isn't helpful.
First of all, Emacs is an excellent IDE for Lisp and has a built-in debugger, sensitive completion and automatic documentation, while Visual Studio can't do any of those things you thought were important until you install Visual C/C++.
Is Visual Studio "just" a editor with a plugin system?
Why are you so interested in giving emacs such a negative label?
> I would be interested in seeing similar environments for C#/Java as well as for dynamic languages like ruby/python/php, which IDEs have also been handling very well lately.
For python, there's Ropemacs: http://rope.sourceforge.net/ropemacs.html
For perl, there's Sepia: http://cpansearch.perl.org/src/SEANO/Sepia-0.97/Sepia.html
I don't program in C# or Java or Ruby or PHP regularly so I don't know about them off the top of my head.
> Can your IDE integrate with your calendar? Yes. > Can your IDE email who created the error using version control information? I don't know. But I'll give it a qualified yes bes cause this is generally handled by the build script, which is IDE-agnostic. > How's emacs' refactoring support? Judging by the following stackoverflow post Stackoverflow gives retarded answers sometimes. The next best suggestion on that page is correct. Cedet is great. > How's Emacs' keyword completion? It's fine. You can complete symbols sensitively, and complete filenames or email addresses from anywhere. Having multiple completion systems is very useful. How's your IDE's ability to complete those things? I don't see anything, so perhaps they don't exist.
But this is silly. We're developers. Using IDEs designed to be extensible. There is very little we couldn't do if we wanted to. Emacs has been around forever, and it has tons of stuff available for it. It also favors a different working style than something more GUI-based, which some prefer and some don't.
There are tons of great tools out there. It's a great time to be a developer. > Even if you can get Vim or Emacs to do some of the above, it usually isn't as easy to use or as useful as an IDE. You don't need to be so hostile. Emacs does these things just fine, and has for a long time. Emacs also does my time tracking, outlining, and email. Your IDE won't do any of those things, and you don't expect it to because you think those tasks are best left to other parts of your operating system. The thing you're missing is that for Emacs users, Emacs is the operating system. I dual boot into Firefox sometimes.
- I think that different languages (and programmers) suit themselves to different balances of the IDE/Editor combination. I agree with your post, inasmuch as I find writing Java outside of an IDE like Eclipse limits you greatly. It sounds like you write Java a lot.
- OTOH, I find writing C/C++ in Emacs with cscope/etags/make support and some custom keystrokes, and functions for common Unix calls, is about as good as any IDE can get you for those languages (although I admit that I've only had limited C++ IDE experience, using Visual Studio.)
Yes, you have to do custom configuring to get Emacs working well. So, it's a small amount of extra upfront work over Eclipse. The upside is that you get to customize it however you want. In Eclipse I'm still using most of the default configuration, for the simple reason that it works "well enough"
I find writing Erlang in Emacs erlang-mode is fine as well, mostly because the language doesn't encourage me to create the kind of horrible architectural behemoths that you _need_ an IDE to manage.
The difference between Language-oriented and IDE-oriented approaches to programming was laid out really well in a recent blog post that made it to HN, but I can't find it with a quick google - sorry.
Thanks for the tip.
Hyperlinked call graphs: nope. Never needed it, don't know how to generate them for any language I use. Emacs can't do it, but neither can anything else. Write the code to do the work, and Emacs will support it in about 30 seconds.
All use of a given symbol: same problem. The static analysis for this is Really Hard, and it would provide me with near-zero value.
Background compilation: yup. Supported by pretty much every mode.
Refactoring: I've used Eclipse, but I've never had good luck with its refactoring tools. The automated refactorings are almost what I want, but since exactly what I want is so simple, I just do it manually. If you are renaming your classes everyday and you have to change the name in 1000 files, you have two problems that can't be solved by an IDE.
Keyword completion: excellent. I was using Eclipse today, and there is a noticeable delay between when I press M-/ and when the keyword was completed. I eventually learned to not use that feature, because I can type faster than the auto-completion can "intelligently select" the right keyword.
Emacs is instantaneous, and right as often as anything else. And I can expand things other than symbols, like long words in the documentation, or filenames in string literals, etc.
As for integration, I find Emacs to be quite well integrated for the work I do. A few weeks ago, I was writing a Haskell app for use on Windows. I was really not looking forward to it, until I realized that all the Haskell functionality works perfectly on Windows. I never needed to leave Emacs; I could test my code (interactively or automatically) from the GHCi REPL and I could build binaries and docs with M-x compile. Of course, it's just one keystroke to move to compilation errors (in both cases). If I needed to poke around in a shell, I just used Eshell, which works the same on every platform. Everything you need to do is tightly integrated and very fast.
Working with Perl is just as nice; one keystroke runs the test suite in a nearby eshell, another just runs the tests that pertain to the current file. Anything I want to do is usually one or two keys away, and a shell to do something complicated is just as easy to get to. (For me, C-x C-x switches between the shell and the most-recently-used buffer. Fast!)
Their UI's tend to be a lot more powerful because they are not designed to be run on windowless environments.
Not true. But one thing that's nice about Emacs is that you can run Emacs in the background and connect to it multiple times. If your X session dies, no information is lost. If you are poking around in a shell, you just "emacsclient -t file" (which I alias to "ec file") and you are instantly working with that file in your normal Emacs session.
for large projects I use an IDE with a Vim emulation plugin
That means you are probably unaware of about 90% of Vim's features. I've watched many experienced Vim users try to use various vi emulation plugins for Eclipse, and there is always a lot of cursing involved. They eventually just invoke Eclipse functions from vim instead.
The underlying theme here is that IDEs make tasks that you perform once or twice a week really simple. The "traditional editors" don't do much about that; instead they make the things you do 10,000 times a day really really simple.
(One other thing I notice is that IDE users tend to ignore features that Vim and Emacs have and dismiss them as unnecessary, while Emacs/Vim users steal the good features from IDEs as often as possible.)
In conclusion, you don't know much about Emacs.
You're right that I don't know a lot about Emacs. In this thread in particular I've learned about CEDET and flymake-mode, which seem to apply to C/C++ and maybe Java and C# to some extent and add a lot of useful IDE-like features.
Unrelated but interesting out of 130 space flights 2 resulted in the destruction of the vehicle.
Nice troll though, I will give you that.
Since the IDE remembers all your parameter sequences and types there is also less incentive for developers of APIs to think ahead of time and plan their interface so it is consistent and easy to remember.
foo.bar().baz().qux()
...Grrrrr! if (foo != null) if (bar.bar() != null) if (foo.bar().baz() != null) {
...
worked = true;
}
if (false == worked ) {/*to do*/}
But, staying on the happy path until you can demo something is often useful. I think the problem is how you transition from demo to production worthy code.Could become:
Bar bar = foo.bar();
if(bar == null) handleBarNull();
else {
Baz baz = bar.baz();
if(baz == null) handleBazNull();
else {
//(assuming qux is a value)
return baz.qux() * 2;
}
}a = foo.bar() will always evaluate to true as the assignment shouldn't ever fail. Of course, in compiled languages I'm sure there will need to be a declaration of 'a' but if there is a possibility to reuse temp variables then could work.
However, if you are coding in C/C++ (and to a similar extent Java, there really is no way around it.
This could be an example of why hybrid functional, imperative, and object oriented languages are becoming popular because the programmer can pick the paradigm that most suits the problem.
foo >>= bar >>= baz >>= quux
and there would never be a NullPointerException, because the >>= function could react appropriately when null was encountered!foo?.bar()?.baz?.quux
What other languages have this kind of shortcut?
$ irb
>> def nil.method_missing *args
>> nil
>> end
=> nil
>> a = nil
=> nil
>> a.b.c.d
=> nil
>>Code like that is really common, and, unfortunately, so are blank 'catch' sections.
Clever? Insane? Horribly un-portable and prone to breakage depending on compiler, libc, and OS versions? All of the above!
(And yes, I have seen this coding style used in multiple projects at a major corporation. It was a favorite of a coder-turned manager, which means it tended to sneak in on any project he supervised.)
Yeah, you already said it was C++.
Say you have
public int doubleFooBarBazQux(Foo foo) {
return foo.bar().baz().qux() * 2;
}
That might throw a NPE, but what's the alternative? public int doubleFooBarBazQux(Foo foo) throws NullPointerException {
try {
return foo.bar().baz().qux() * 2;
}
catch(NullPointerException e){
throw new NullPointerException(e.getMessage());
}
}
If only there was a right-click option for "improve quality"...The cool things there, in my opinion, were the code navigation pieces. Those are the things I actually think work better with tabbed files.
In other news, yikes! I seem to have started an IDE vs. Text Editor flamewar. Sorry about that.
They have some great grouping features - snapping, colouring, pushing, connections with lines, naming groups.
This stuff is awesome. First time I've been this impressed by an IDE outside of Smalltalk, Self, or Symbolics, Lisp.
Besides, it's not like it's a primitive environment ... when I want some API discovery/learning or when I want to do some debugging (or both) ... I open up an interactive shell.
I have Textmate-like snippets setup in my Emacs, and for CRUD-stuff I bet I'm ten times more efficient than you (and adding new snippets is a piece of cake ... not to mention that we share them company wide because they are text-files in our SVN).
When wanting "rename" refactoring, commands with grep/find/sed are already hardwired in my brain.
And nothing beats editors like Vim/Emacs on pure text-editing efficiency. Also, good luck using your favorite IDE when trying out a new language ;)
So you can cringe all you want, some of us are quite happy with just text-editors.
To some extent you'll need mouse-interaction, for dragging things and clearly visual stuff like that (nobody likes to position things with the keyboard, or at least they shouldn't), but they should really do their best to add keyboard hooks to almost everything that they can, definitely.
I have, however, come to realize that navigation through a large project with keys alone is suboptimal. One typo in a nav command and you have to press at least four or five more keys. With the mouse, you're less likely to make such mistakes and your retry time would also be low. It'd be like trying to browse the web using the keyboard alone... even I, a hardcore vim user, found firefox/vimperator underwhelming to say the least.
What would be awesome is if they made some sort of hybrid superintelligent keyboard where the whole keyboard surface could also act as sort of a multi-touchpad. As a compromise, I've found that the thinkpad-style pointing stick in the middle of the keyboard does a fair job.
Practically, this means that whatever file you think of, you can type any part of its name at any time to get to it. Once I got used to working this way, I stopped using the project tree-view: it's just much slower.
Highly recommended, they both have a smart open file that lets you start typing a filename, and smart goto, which lets you start typing a class or method name. Makes navigation so much faster!
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.
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!)
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"?
What I meant is that in Vim I go to a name in ctags. That's what happens - whether I'm in the same file, or different, or I looked at that tag before. Type in tag name -> go - that's all that happens.
With code bubbles, I could have the bubble already open, but just off the screen. Or maybe it's open in another dependency. Or maybe it's not open at all. I have to look at the screen, localise the bubble, make a decision and then do the action (either click existing bubble, or open a new one). Of course it's too early to criticise it, without testing beforehand. But it definitely got my attention, as something I tried to avoid. Having one good way to access stuff == less thinking.
Let's say that Vim is stateless, but bubbles are stateful :)
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 recommend setting up cscope for hacking the kernel. I haven't done any kernel hacking for a while, but when I did I found cscope (and vim+cscope) very helpful. Since it's database-driven and designed to run on systems from the 80s, it's still extremely fast.
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.
Not that this is a bad thing, though. People seem really afraid of having the code they just wrote be executed, but I think this is an unfounded fear. And, as SLIME shows, you get great information from running the code; much better than mere static analysis.
Personally, I have all the pieces together for doing this with Perl, but I have not put it together into anything coherent because it's largely useless. An occasionally-updated tags table is really all I need, so I can't get motivated to make "Eclipse for Perl".
Maybe someone else that sees the value in these tools will do it. Let me know what information you're interested in, and I will show you how to implement it.
It seems like what would be hard is dot-oriented method invocation ala python and ruby. There's been some work at figuring that out using static code analysis, but it's a lot less ready.
I've tried 3 screens (in: square, wide, square configuration) for a while. I wouldn't say no, if anyone gave me that again, but I didn't notice any significant improvement over 2 screens.
The difference is that I use Linux/xmonad on my eeepc, and Windows XP at work. A good window manager will make your computing experience 1000x more enjoyable than a new monitor will.
(As I mentioned above, I have a 24" monitor at home and use xmonad with that. Needless to say, that is the best environment of the three.)
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.
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.
A website where programmers can contribute 'widgets' which can be mashed together to create applications. Widgets would be written in python, and would have access to a bunch of underlying services and to other widgets.
You'd use an interface like what you have here as the 'ide' to create the bits and pieces of code that go in to making a component, and then a similar interface to combine components in to working websites.
The end result would be hosted on the same service, either using your own URL or using a subdomain of the service.
It sounds like a large amount of work though, to get that up and running, especially the security angle is a complicated one.
Such things strike me as generalizable beyond just IDEs.
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.
- 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.
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.
It would be most interesting to see this idea extended in this manner, and possibly alter it so coding can be done differently. One possible way might be to have a collection of functions available, then link them together to create new functions. In most cases, this could be done using relatively few commands, so could be done on a touch-only screen.
Program is interconnected mutating tree. Why the hell we are looking at its latest snapshot through set of flat files showing encoded parts of these trees grouped chaotically?
On the other hand, why anyone who tries to actually show trees forces me to enter 2+(2*5) as five nodes without using my keyboard?
What was striking for me was the "capture my workspace and send in email" feature. Couple this with the Omniscient Debugger (http://www.lambdacs.com/debugger/), and you've got me sold. Oh, but I'm a Ruby programmer.
You've ended up adding more things for me to read / look into. I love programming... there's no way I can keep up with it all, so there's always something interesting.
In Eclipse I am editing a twisted project (usually 3 different files at once but only 2 methods from each) and a Django project (probably about 10 files to juggle there).
In Visual studio, I tend to have another 10 files open (the firmware builds to Win32 too).
God it would be awesome to have all that on one monitor in little bubbles.
* saves for later
And on that note, how come all academic screencasts are so monotonous?
edit: ohh the top bar acts like that. Kinda cool. Very biased against vertical scrolling, which might be bad for certain kinds of files.
Pity it doesn't interoperate with all eclipse-compatible languages (just yet). I'd love to use it to work with Python.
First split the screen horizontally, then split the current panel vertically.
Not the same thing, at all.
It's not nearly as slick as code bubbles, but it does work for many of the use cases suggested above.
Though, if we had a desktop that is infinitely expandable, then emacs, and any other windowed application for that matter, could be put to the same use. Really, bubbles is best as a general workflow paradigm, of which programming is a sub problem.