tags:

views:

323

answers:

5

Let me explain what I mean by "two-dimensional code editor": imagine of using Inkscape or Gimp in a big canvas (say infinite). The "T - add text" tool is used to write the code. Additionally, all function definitions will be framed and links will connect the called functions.

In other words: you have a very large sheet of (virtual) paper where you can write.

It would be really useful. I don't want to write code as a long list of lines, especially now that big monitors are cheaper.

Is such a code editor out there?

What's your opinion? Would you use a 2d code editor?

A: 

For me, the MVVM pattern means that there's no code behind the UI controls anyway. The logic is all in a class with properties.

The properties use WPF databinding to update the UI controls. For example, on the form or window, page, whatever, MySearchButton.IsEnabled is bound to ViewModel.MySearchButtonIsEnabled property. So the app logic runs in the ViewModel class and just sets its own properties and the UI updates automatically.

Although this is specific to MS WPF the pattern actually stems from SmallTalk and is found across the development field as MVP. Without WPF one would need to write the databinding or 'presenter' logic, which is common.

This means the UI can be torn off and a new one pasted-in really quickly and with little code knowledge from the UI guy - who, in an ideal world, is a crack creative guy that drives a 70s Citroen.

So my point is that, although it sounds like a neat innovation, a 2D editor like this would be assisting a coding style that is no longer considered optimal.

Luke Puplett
The OP is not asking about UI development at all.
Jay
Sorry, I thought he was explaining a system whereby the CodeBehind for the window/page/control is on the design surface floating around in boxes.
Luke Puplett
A: 

At one point, LabView had a programming mode like this. You connected program blocks together in a graphical way.

It's been so long since I've used LabView that I don't know if it is still the same.

Zan Lynx
A: 

This probably doesn't answer your question exactly, but anyway.

Have a look at the NodeBox beta . It is a visual programming environment mostly for creating generative graphics. You can program and edit the nodes with python code, connect and reuse them in multiple ways. (Windows and Mac OS)

Also worth mentioning (in terms of concept) is Field . It is for programming performances and arranges bits of code on a stage/timeline. Very interesting but also very confusing. (Mac OS only)

Third one is vvvv. It is used a lot by graphical artists to create realtime 3d visuals. Node based. (Windows only)

NodeBox and Field are open-source, so if you are looking to create something yourself you can see how it's done there.

allesblinkt
+1  A: 

I've written 3 or 4 visual editors and my second one worked like this, that was for java and c++ (never published, though I did use it for some published research work) I still don't like much to write my code 'as a long list of lines'. My point is, after trying a system like this, I tried a windowed system (class outlines in windows, right click to open code editors), then a tree based system...

in the long run (I wrote several apps using all of those), the tree based system with non overlapping windows felt at once most scalable (to different monitor sizes) and foremost, most productive, because dragging the text boxes and links and/or windows in the first version was necessary, without adding much to the programming experience, so it felt wasteful.

If you want to try some of this stuff out, you can google antegram for java (java only) antegram for web (javascript/php/actionscript) and ee-ide (on oogtech.org). I'm not sure if I could dig up the original c++/java textbox + links editor (which could collapse graphs as well, and had an infinite canvas, so pretty close to what you describe).

I'm not working on this as much as I used to as few programmers ever seemed to like it except me, but if you like working the tree way, or feel like adding stuff for your own purposes, ee-ide would be the way to go, as it's nicely modular and easy to extend compared to the rest.

On the commercial side, you can configure visual studio to work with UML-like diagrams. I have a feel it might be a little too heavy (although it's definitely more coding than UML oriented), but I'm not sure, I haven't really tried yet.

Thibaud de Souza
+1  A: 

Check this out. I came across it today and remembered this question.

Code Bubbles

alt text

Developers spend significant time reading and navigating code fragments spread across multiple locations. The file-based nature of contemporary IDEs makes it prohibitively difficult to create and maintain a simultaneous view of such fragments. We propose a novel user interface metaphor for code understanding and maintanence based on collections of lightweight, editable fragments called bubbles, which form concurrently visible working sets.

The essential goal of this project is to make it easier for developers to see many fragments of code (or other information) at once without having to navigate back and forth. Each of these fragments is shown in a bubble.

A bubble is a fully editable and interactive view of a fragment such as a method or collection of member variables. Bubbles, in contrast to windows, have minimal border decoration, avoid clipping their contents by using automatic code reflow and elision, and do not overlap but instead push each other out of the way. Bubbles exist in a large, pannable 2-D virtual space where a cluster of bubbles comprises a concurrently visible working set. Bubbles support a lightweight grouping mechanism, and further support connections between them.

A quantiative user study indicates that Code Bubbles increased performance significantly for two controlled code understanding tasks. A qualitative user study with 23 professional developers indicates substantial interest and enthusiasm for the approach, despite the radical departure from what developers are used to.

http://www.cs.brown.edu/people/acb/codebubbles_site.htm

frou