Live data from Hacker News

New IDE: code bubbles

cs.brown.edu

131–140 of 226 posts

Re: New IDE: code bubbles

#131
post #18

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. This is a really promising start. Very cool.

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.

Re: New IDE: code bubbles

#132
post #103

Earlier quoted context omitted.

Emacs can do whatever you want. If it doesn't, it can be added. In fact, Emacs is an IDE... 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.

Respectfully, I think you're avoiding the main point of the post to which you replied. 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 im…

I think it depends on what language you're using at the time. If I'm using a static language I'll give an IDE a try. Otherwise I use Emacs.

Re: New IDE: code bubbles

#133

Earlier quoted context omitted.

Emacs is a text editor in the same way the space shuttle is a vehicle.

It's also based on technology that's ancient compared to everything else around it. (Not that ancient is a bad thing, go unix!) Unrelated but interesting out of 130 space flights 2 resulted in the destruction of the vehicle.

Yeah, dynamic customization and extension is quite antiquated. Modern IDEs should only be customizable by writing 5000 different classes, recompiling, and restarting the IDE. Tools should only be built by dedicated tool-builders, not by your average programmer!

Nice troll though, I will give you that.

Re: New IDE: code bubbles

#134

It's odd that it's so rare in software to find window widgets that push each other out of the way instead of overlapping. 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.

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.

Re: New IDE: code bubbles

#135
post #103

Earlier quoted context omitted.

Emacs can do whatever you want. If it doesn't, it can be added. In fact, Emacs is an IDE... 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.

Respectfully, I think you're avoiding the main point of the post to which you replied. 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 im…

" As a code editor, it lacks support for even basic semantic analysis"

Not strictly speaking true: http://cedet.sourceforge.net/semantic.shtml

Re: New IDE: code bubbles

#136
post #118
post #99

Earlier quoted context omitted.

Can your emacs editor construct hyperlinked call graphs showing all callers and callees of a given function? Will this call graph generation remain up to date as I edit files? 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…

> Can your emacs editor construct hyperlinked call graphs showing all callers and callees of a given function? Will this call graph generation remain up to date as I edit files? 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. C…

I apologize if people thought I was hostile. I thought I was just making an argument by pointing out several examples of things text editors like Emacs don't normally do that IDE's do well. You've proven me wrong, at least for the case of C/C++. I would still argue that Emacs itself is not an IDE. It's just an editor with a turing-complete scripting engine. However, you could definitely convince me that Emacs+CEDET is an IDE, and I'm glad you pointed it out for me.

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.

Re: New IDE: code bubbles

#137
post #110
post #103

Earlier quoted context omitted.

Emacs can do whatever you want. If it doesn't, it can be added. In fact, Emacs is an IDE... 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.

"Emacs can do whatever you want." 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.

In the 30+ years Emacs has been around people have written a huge amount of Emacs Lisp that does pretty much everything you can think of. Almost every feature from other editors and IDEs has been implemented in Emacs. I like Lisp but rarely write very much Emacs Lisp, and when I do it's usually an extension of some code someone else started. There aren't a lot of new ideas and when an Emacs user sees one he implements it for Emacs.

Re: New IDE: code bubbles

#138
post #99

Earlier quoted context omitted.

Emacs is a text editor in the same way the space shuttle is a vehicle.

Can your emacs editor construct hyperlinked call graphs showing all callers and callees of a given function? Will this call graph generation remain up to date as I edit files? 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…

geocar's response is pretty good, but I am going to disagree on some points.

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.

Re: New IDE: code bubbles

#139

Earlier quoted context omitted.

Sure, but when you're working on a project that uses only a few languages, specialised tools are always going to be much more effective, and you just update the tools as you update your choice of language(s). Jack of all trades is master of none, as the saying goes.

In many ways I'd love the luxury of writing code in just a few languages. The reality is though, at justin.tv, I've needed to write code in (at least) 7 different languages over the past 2.5 years. I would not have liked to learn 7 different IDEs on top of learning new languages. (We don't tend to gratuitously start using new languages - it's just often a requirement as a project gets more ambitious and wants to do m…

I sympathise with you on the polylingual tendencies. I'm currently working on something for one client that uses several different programming languages plus the usual web-related stuff all on the same project (and with perfectly legitimate reasons, not just because of historical baggage).

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?

Re: New IDE: code bubbles

#140
post #130
post #61

Earlier quoted context omitted.

I'd like to have a dollar for every time I've seen a NullPointerException on some line that was constructed by someone who loves the list of methods that automagically pops up for the dot operator: foo.bar().baz().qux() ...Grrrrr!

That might be the correct way to write that code if the situation is not recoverable. Say you have public int doubleFooBarBazQux(Foo foo) { return foo.bar().baz().qux() * 2; } That might throw a NPE, but what's the alternative?

I typed this into Eclipse, and it's super-awesome-excellent auto-code-writer decided that it should be:

   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"...
Post reply on HN