BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person or online.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or online.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Is a picture always worth a thousand words?

Building field-level lineage for modern data systems (Live Webinar Apr 13, 2023) - Save Your Seat

Is a picture always worth a thousand words?

This item in japanese

Bookmarks

Nov 08, 2007 3 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more

Is a picture always worth a thousand words?

In his recent article, Why we write code and don’t just draw diagrams, Dean Wampler argues that in software development the opposite is more often true.

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?

There are not many graphical programming environments that are widely used, but there are exceptions. Labview is possibly the most well known one, but it is primarily used by testers (and kids with cool Lego) - not traditional developers.

Why is that? Likely because there are a lot of details to take care of in software development. This makes it hard to create visual languages that can represent such complexity without overwhelming the reader. If we represent programming constructs as pictures, we need to map these pictures to an (often) abstract concept to be able to understand what it means. The hard part is to not end up in a classic trap. And since we talk to other developers, we do need words for everything in any case.

Dean writes:

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.

However, this all depends on how powerful abstractions you have created in your code. Poorly done, you may need a thousand words to represent what could be said in one picture. And you or your colleagues need to decipher that each time you read the code.

The current Domain-Specific Languages movement explicitly focuses on this point:

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.

Dean refers to textual DSLs in this case, but companies like Metacase creates tools for designing visual modeling languages and Microsoft took a similar route when they developed tools for creating graphical DSLs to accompany their Software Factory vision.

Arnon Rotem-Gal-Oz describes the limitations of graphical DSLs like this:

Unlike small code based DSLs - the modeling based approaches of software factories, MDA etc. aim too high and thus provide much less value or suffer too much from the generation gap (the code generated is too generalized or far off from the actual need of the solution).

Arnon also has explicit comments on if a picture is really worth a thousand words:

This is true if you treat models as sketches you can raise the level of abstraction by as much as you want and convey ideas with less clutter. However when you need to make the model very specific so it would allow code generation - you get to a stage where it is more convenient to do it in code and rely on generated or pre-built DSL or framework

Ironically, pictures can be a good way to grasp a complex code base. InfoQ recently published an interview with Erik Doernenburg on Software Visualization, where Erik explains ways to visualize different aspects of for instance a system or a code base. Using visualizations, it is possible to quickly spot anomalies that would be hard to find otherwise, but that is still a different thing from creating software graphically.

Dean concludes by explaining that he doesn’t imply that there is no place for graphical representations, but:

Still, for the general case, code written in succinct languages with well-designed API’s and DSL’s will trump a diagram-driven approach.

On the other hand, Intentional Software will tell you that code or pictures are just different projections of the same underlying model.

Rate this Article

Adoption
Style

This content is in the Architecture topic

Related Topics:

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • A beethoven piano sonata worths 1000 pictures ....

    by Ke Jin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Without clearly defining what means "worth", what is the specific communication background (i.e. context) ... this kind of statements could only be taken at their face value. Human communication is evolved from pictures (prehistory) to words/languages, not the reverse ....

    Back to top
  • visual programming will come eventually

    by ding jack,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    im wondering why case tools like ROSE just do not provide procedure define function. otherwise we can generate entire code than only empty function definition.

    Back to top
  • Graphics for structural representations

    by Stefan Wenig,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Visual models have proven very useful in some cases. Take UML's static class diagrams, for instance, state diagrams, or even workflow as flow charts. In some cases, even roundtripping to code/DSLs/XML/whatever is painless (UML-like class diagrams within the target language's type system).
    Whatever visual representation you use, there has to be a textual representation that you can read and edit. For understanding, troubleshooting, generation, version control, you name it. But if roundtripping works, and if the visual model provides additional value, why not.
    Still, the designer-happy crowd that tried to make us think that you don't have to know programming in order to create non-trivial applications, is running into walls everywhere. It's about time the industry recognizes that this has been a wrong path from the beginning. In most cases, pictures are just a good way to get a good overview and navigate your code, but when you drill down into the details, it's still code.

    Just compare blogs about programming to blogs about using visual tools. The code blog will tell you, that in order to achieve this, here's these few lines of code.
    The visual guys will be busy for days creating lists of steps you have to perform and creating snapshots, testing if this really works, etc. Just to produce a blog entry that takes the better part of an hour to comprehend. If this is not a clear indicator, I don't know what is.

    Back to top
  • DSL and XML first, visual programming second

    by Raphaël Valyi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    sure, DSL should come first, visual tools come second. Visual tools may not allow enough expressibility but are great ways of communicating.

    Simple and most portable DSL are better done as XML dialects while scripting (say Ruby) DSL are way more expressive and powerful but are harder to implement in different ways and plug with different tools.
    XML DSL are also easier to plug with visual modeling tools.

    I think we should mix strict XML DSL's with more expressive scripting parts. I like the way for instance JBPM addresses it by supporting scripting inside its XML. Thus you get the Eclipse visual editor but don't loose the power where you need it.
    Google Mahup Editor is taking a similar way even if their is no visual tool yet.

    In any case, IMHO, the worst situation is when either
    * the DSL is so dependent to tools and languages that you are tied with a vendor lock in
    * the visual modeling tool has been done before thinking about a simple and published DSL allowing the portability.

    Raphaël Valyi

    Back to top
  • Re: Graphics for structural representations

    by Niclas Nilsson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I didn't include one idea that I was thinking about in the post, but maybe I should have.

    Image having an IDE that would allow you to navigate from the highest abstractions down to the tiniest details with speeds like Microsofts CDragon technology.

    Granted, CDragon does not change the type of representation when it drills down, but imagine a tool that could? At that speed...

    Kind regards
    Niclas Nilsson

    ---
    blog: niclasnilsson.se

    Back to top
  • Lineair text presentation versus spatial presentation

    by Jan Vegt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One of the problems not yet mentioned is that textual programming languages have a sequential, lineair order. Given the Western domination into programming languages exclusively or almost exclusively in a top-down, left to right fashion.

    A visual, spatial programming language has the challenge of not only coming up with an understandable and compact set of symbols, but also presenting these symbols in a uniform way. And with very little history or tradition - like there is with text writing - to make this a familiar experience to a larger audience.

    Marten, a ProGraph IDE by Andescotia software, is one of the few visual language environments still around and I think it's pretty coureagous effort given the fundamental challenges of visual programming. www.andescotia.com/
    [ I have no affiliation with these guys but think they deserve credit for the effort ]

    Cheers, Jan

    Back to top
  • Code is text

    by Magnus Christerson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Niclas - you are right. Code and pictures can be different projections of the same underlying code model. As long as we store programs as text in the syntax of the programming language we are screwed. That means we will never have the freedom you talk about. But if we separate the storage format from the syntax, we are golden. Then we can have both text in the syntax of the programming language AND pictures, both as editable projections from this same model.

    Back to top

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT