But actually, a textual representation means that you need to rely less on fancy GUI's to write code. There are also added benefits like ease of search. If you're using a nice editor like Emacs or Vim, the medium is very easy to manipulate.
In fact, it isn't. Code is better defined as a tree. The "impedance mismatch" of writting a tree using sequential text strings is what makes fragile the tools that IDEs feature.
That code is seen as text is just a historical accident. I believe most serious programmers have been beaten by some incomplete implementation of graphical interfaces and accepted to fall back to good old plain text.
But we are in 2010. This acceptance of this state of matters is very unfortunate. Specially sad is when the author says that IDEs are no more than text editors with some extended capabilities. They shouldn't! They should load the code in all its glorious shape... that by no means is a chunk of text.
Text is the best medium right now. No one's discovered a better method of representation.
Are you saying we should represent code in a more graphical tree-like way? Even in that case, you still need text to fill in the tree.
Or are you saying we should program in visio-style diagrams?
Yes. It should be possible to develop an interface that is actually faster and cleaner to program in than text. I'd love to see what touch interfaces can do in this regard.
It's never been done, granted. But it should be possible. I hope developers aren't dissuaded from attempting graphical programming interfaces just because everything that has existed up to now has sucked.
I am not sure I would like to use it for anything complex.
An innovative, usable visual programming language will introduce a new programming paradigm (probably based off of functional languages) that provides deep integration with the GUI and plays to its strengths, not just do a linear line->block transliteration into a graphical environment.
Although, Scratch is great for teaching kids about programming.
Go look at a language parser sometime; we've actually put a lot of work in any production-ready language into that "low tech" text interface. The tree approach is useful for macro writing, and if you don't know Lisp maybe you should go check one out, but I'm very unconvinced there's a better way to actually interact with the code even in theory. It may be visually unimpressive but it's actually incredibly, incredibly sophisticated under the hood. If it's good enough for human speech, it's more than good enough for programming.
I imagine looking at something that looks a lot like lisp - it shows the high-level structure of the code as a tree. But it could allows me to change the level of abstraction I'm viewing on the fly. Also, it could reveal (or hide, at my preference) lots of metadata about the code... is it pure, is it stateful, is it parallel, etc.
In essence, it allows you to look at your code as an n-dimensional entity instead of a 2 dimensional file.
Basically, I'd like to see what happens when you decouple the code from its presentation. Then, you can choose alternate presentations (including plain text!) depending on the task at hand.
If your editing consists of something like elementtree, that actually works at the higher level of the language, pushing and popping elements onto the ends of xpaths, you might actually not mind editing XML at all.
No one's discovered a better method of representation.
Hmmmm... that's only half true. The text layout in a real program is already a tree-like representation: using vertical and horizontal space (blank lines, indentation) and providing syntax highlightling, we "paint" text to resemble the real structure: the one the compiler understand.
But syntax highlighters, "intellisense" and the rest of IDE tricks are just that: a patch over the text handling.
A true IDE would read code directly into a in-memory tree structure, resolving external references, making a first processing of the code on the moment the code is loaded.
A true IDE would eliminate the burden of writing annoying control characters (curly braces, semicolons, quotes) to placate the compiler, escaping delimiters, correcting indentation, etc. The editor could use some quick key combinations to navigate the code.
This is not really related with a Visio-like interface. It would look more like add-ons such as Resharper that "understand" the code to a point and make it easier to write code. Visually it would present the code already indented and colorized. It could be "skinned".
Unlike add-ons, it would be fully aware of the code meaning, so it wouldn't need scanning the code to support editing. The code would be fully loaded and cross-references checked.
BTW, there have been some proof-of-concept of "syntax-driven editors" or something like that. I haven't even seen them, so not sure to what point it's what I have in mind.
Or a graph. But the most general and manipulable way to represent this graph really is as text.
Inline expansion would be nice. So would code paths. So would inline images & html rendering for documentation. So would the relevant rendered html for the issue relating to the code you are looking at. So would other annotations. And what about visually hiding code when working in a language like java?
I tried to get this going in eclipse once, and it really wasn't going to happen easily so I gave up. I've always hoped someone would build something similar as I feel it would really help productivity having everything relevant right there with the code.
Note: The project http://code.google.com/p/lambda4jdt/ is the closest thing I have found to what I am suggesting which I think shows the power. It just goes to show that it could work.