Live data from Hacker News

New IDE: code bubbles

cs.brown.edu

121–130 of 226 posts

Re: New IDE: code bubbles

#121
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…

Wow what what a rant.

- 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.

Re: New IDE: code bubbles

#122

Earlier quoted context omitted.

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…

The flip side of this is: Emacs was invented around the time I was born, and could be used to edit the languages that were available at the time. It can still be used to edit those languages, as well as the hundreds (thousands?) of languages that exist today. I won't be surprised if it's around in 10 or 20 years more, and still able to edit every language under the sun at that point. Emacs may have a shallower unders…

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.

Re: New IDE: code bubbles

#123
post #64

Earlier quoted context omitted.

Because not declaring the type of variables makes code not work with bubbles?

I think that because not having typing information makes it more difficult for the IDE to help you out.

Slime makes a lot of this navigation possible; I don't think dynamicness has anything to do with 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.

Re: New IDE: code bubbles

#124
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…

That is my biggest problem with vim/emacs - they can edit the code well, but they have no real notion of syntax. You can do refactoring based on their lexers and a lot of regex, but it's just not what you really want.

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.

Re: New IDE: code bubbles

#125

Earlier quoted context omitted.

The flip side of this is: Emacs was invented around the time I was born, and could be used to edit the languages that were available at the time. It can still be used to edit those languages, as well as the hundreds (thousands?) of languages that exist today. I won't be surprised if it's around in 10 or 20 years more, and still able to edit every language under the sun at that point. Emacs may have a shallower unders…

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 more things and reach more targets).

Re: New IDE: code bubbles

#126
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.

Re: New IDE: code bubbles

#127
post #114

Earlier quoted context omitted.

If only there was some combinator for sequencing computations... then you could write: foo >>= bar >>= baz >>= quux and there would never be a NullPointerException, because the >>= function could react appropriately when null was encountered!

Since I don't know haskell, I'll throw out that groovy does this too. foo?.bar()?.baz?.quux What other languages have this kind of shortcut?

CoffeeScript: http://jashkenas.github.com/coffee-script/#existence

Re: New IDE: code bubbles

#128
post #68
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!

Try catching a block that does that is actually less code than a long set of conditionals. Granted it's basically saying: 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.

That's not the same since you are executing the bar method multiple times.

Re: New IDE: code bubbles

#129
post #102

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.

I never even thought of that. Any examples of software that does this?

Any tiling window manager will have a mode, usually the default, where no windows will be occluded. Instead, all screen space is divided among them according to some algorithm.

Re: New IDE: code bubbles

#130
post #61

Earlier quoted context omitted.

IDE's can be neat, but plenty of people seem to use them as crutches to keep on walking through minefields of APIs. 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.

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