Why we write code and don't just draw diagrams 8
Advocates of graphical notations have long hoped we would reach the point were we only draw diagrams and don’t write textual code. There have even been a few visual programming environments that have come and gone over the years.
If a picture is worth a thousand words, then why hasn’t this happened?
What that phrase really means is that we get the “gist” or the “gestalt” of a situation when we look at a picture, but nothing expresses the intricate details like text, the 1000 words. Since computers are literal-minded and don’t “do gist”, they require those details spelled out explicitly.
Well, couldn’t we still do that with a sufficiently expressive graphical notation? Certainly, but then we run into the pragmatic issue that typing textual details will always be faster than drawing them.
I came to this realization a few years ago when I worked for a Well Known Company developing UML-based tools for Java developers. The tool’s UI could have been more efficient, but there was no way to beat the speed of typing text.
It’s also true that some languages are rather verbose. This is one of the ways in which Domain-Specific Languages (DSL’s) are going to be increasingly important. A well-designed DSL will let you express those high-level concepts succinctly.
I’m not claiming that there is no place for graphical representations. UML is great for those quick design sessions, when you’re strategizing at a high level. Also, the easiest way to find component dependency cycles is to see them graphically.
I’m also not discounting those scenarios where a diagram-driven approach actually works. I’ve heard of some success developing control systems that are predominantly well-defined, complex state machines.
Still, for the general case, code written in succinct languages with well-designed API’s and DSL’s will trump a diagram-driven approach.
Trackbacks
Use the following link to trackback from your own site:
http://blog.objectmentor.com/articles/trackback/8804
I think you are 100% correct. I wrote a post expressing similar ideas about a week ago
@Arnon, Thanks for the link to your post. Good examples there. I also thought that Neal’s talk on DSL’s was right on the money.
Dammit!
When I saw that title (especially by you, Dean; you’re usually no-nonsense objectivist), I was hoping for:
i) An answer (I think your answer is, “Computers are literal-minded;” but computers aren’t literal-minded, they work on bits, and bits are as far removed from text as they are from diagrams (or as close; when you’re down to two digits, both can be considered text or diagrams (though very small diagrams))).
ii) A fair comparison between text and diagrams.
iii) A deep analysis of the differences between text and diagrams (along the lines of, “Text generally consists of a finite set of characters (and again, a character is a much a piece of text as it is a diagram) from a well-defined alphabet combined using the rules of a well-defined syntax …” and perhaps reaching, ”... But UML (for example) is a not a well-defined syntax because of (insert insightful wizzardry here) ...”
iv) A historical perspective on the success of text and the failure of diagrams (it would have been lovely make some connection between the cost of early computing machines and input devices and thus a commercial imperative for text rather than diagrams; it would have been really, really lovely to highlight that man, as a species, developed diagrams long before text, to trace the historical rise of text to prominence and to illuminate the various contributing factors).
v) A word on Xerox PARC (not only because everyone should reference Xerox PARC, but I seem to remember that one of the first Smalltalk applications was some sort of drawing programming language that allowed kids to write programs in pictures. Or maybe my memory’s misfiring and I’m completely wrong (though this doesn’t detract from the advice of always referencing Xerox PARC for something or other)).
vi) (Stretching a bit here) A comparison of the parts of the brain dedicated to text and diagrams (ok, “Pictures”), a description of the relative powers of both parts, a declaration of a winner and a natural imperative towards either information-form.
vii) (Oh!) A discussion on information entropy, a comparison of the entropies of text versus diagrams and a declaration of a theoretical imperative towards either information-form.
viii) A discussion on the longevity of information itself outside a human context (why not?).
ix) A solid conclusion.
x) A wry introspection (a pithy introspection would also have sufficed).
xi) A witty anecdote.
Alas.
I was going to do that and more, but I hate to show off %^P
Actually, this is a great list of the topics that need to be considered for an exhaustive analysis. I’m sure that others have tackled many of them. Each point would be interesting to study. Oh, for more free time! ;)
I’d love to write the definitive analysis on the subject that analyzes all of them (and more), but I’m not the expert, so a lot of research would be required. In fact, I hope that people will continue working on this vision and maybe some day the tide will turn…
So, I cut to the chase. My arguments were very pragmatic in nature. They reflect my own experience and my impression of the landscape today, as well.
I’ll try to do better next time!! ;)
Very interesting comment Edmund. While I really like your 11 outlined points (what you had hoped to see in the blog post) I think that you have created a better outline for a book of substantial size. Of course, we could always break each point out into a separate (and lenghtly) blog entry of its own.
It would be great to start a conversation around many of the points you’ve mentioned.
We write code and don’t just draw diagrams for exactly the same reason that poets and novelists don’t just draw pictures. Simply, written language is one of the great human inventions. Writing is more exact, and often more expressive than pictures. The real question is why the computer industry continues to have so may “advocates of graphical notations” who feel that banging rocks / clicking mice on pictoglyphs / icons is somehow superior to that “old fashioned language thing.”
While there are a lot of cases where I will use a diagram to convey an overall concept, I’ve yet to see anything that comes remotely close to what can be expressed in code.
picture is not very suitable for the mental activity involved in daily development. But I think in some kind of development, it would be superb. For example, when we write automation test for a GUI, it is more natural to write test by marking on the GUI screen shot instead of writing redundant code about how the GUI will be driven.
Dean, I have been working on an Eclipse-based tool for UML modeling based on a textual notation:
http://abstratt.com/textuml/
I would be more than happy to get your feedback on the approach/product.
Please feel free to delete this post if you take it as blatant self-promotion.
Cheers,
Rafael