It seems like the author forgets that the medium of code IS text. Not graphics, or sound, or a 3D model... but code is text, and for now text is the most concise representation of code.
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.
It seems like the author forgets that the medium of code IS text.
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.
> 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.
Syntax highlighting is pretty much it. Adding much more would blow out our ability to handle complexity and just be too busy on the screen for anything to make sense.
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.
Yes, I love lisp - I'm a huge Clojure buff. And that's exactly what makes me think a graphical programming interface could be done well. As languages get more lisp-like, it seems as if they would become more conducive to a graphical programming environment.
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.
That's just an imperative program using "blocks" instead of "lines."
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.
Look at XML (its simpler than programming languages so easy to discuss). If your sole editing tool is a text editor it will suck - things like unclosed tags are possible.
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.
Even though code is text, you would think someone would have tried to build a different view given the popularity of MVC.
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.
Indeed, MS are trying to encourage this with the new WPF-based editor in VS2010. The developer's examples are all about graphical overlays replacing certain types of code. It will be interesting to see if ISVs take this forward.
Let's say you had an eclipse plugin that let you write in lisp, but it actually converted the code to java underneath. You could click a button to switch between views. Are you saying that would be a bad thing? If a tool allows you to be more productive, I use it. Note: I don't use lambda4jdt at all, I just like the idea of creating problem specific views for code and I don't think that belongs at the language level.
You're right, my comment was directed at your example really; the code before and after use the same representation, text. In that case it seems the original was simply a poor textual representation of the logic. I'm actually a firm believer in being able to visualise code. After all coding really gets done in my head and when it's in there it's in 3D images/videos. I long for the day when I can work in an immersive environment where I can walk around the design suspended in the air. That day seems a long way off at the moment though :)
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.