Visual vs. Textual Application Development Programming Software

Can visual application development programming software, similar to the now ubiquitous GUI-builder, ease concurrent programming? What are the fundamental reasons for selecting a visual or textual tool? The relentless drive to build ever more powerful computers is fueling equally dramatic rises in software complexity. Long gone are the days when a single type of description (i.e. text) was adequate to describe a complete application.

GUI builders are now well established and exploit a natural orthogonality between behaviour and appearance to allow the latter to be represented using a specialized, intuitive form blueprint. By raising the level of abstraction at which GUI appearance is described we can much more easily manage their escalating complexity.

Sea change in software development

Until recently synchronization, communication and arbitration logic (known collectively as infrastructure logic) has been fairly straightforward for the vast majority of applications. Traditionally single-process and single-threaded applications have been the norm and no such logic has been required.

The world has changed. The advent of multi-core processors dramatically changes the landscape, potentially for everybody involved in software development. In the words of Herb Sutter, Senior architect at Microsoft:

Writing software that exploits the latest multi-core processors is driving rapid increases in the complexity of infrastructure logic within applications across the whole spectrum of computing. Developers urgently need application development programming software and methodologies to deal with this new challenge. Without addressing multi-core scalability applications will not continue to run faster on successive processor generations and even worse, they are likely to run slower as individual cores are simplified in the interest of power efficiency.

The case for specialized blueprint representations

The specialized description for GUI appearance - the form blueprint - revolutionized GUI implementation by providing a much higher level of abstraction than textual code. This description provided two key benefits to the GUI implementor:

Localization of concerns

The form blueprint is only concerned with describing the appearance of the GUI. This means that browsing the form blueprint does not involve searching through content related to other aspects - the description of appearance is localized and contiguous.

Resemblance between design, blueprint and implementation

Designing GUI appearance typically involves drawing a sketch of how the final implementation should appear. Before the form blueprint, the only prescriptive blueprint of the appearance was textual code. This meant that the design would be translated into equivalent textual code, which when executed produced an implementation that resembled the original design.

A form blueprint captured using GUI-specific application development programming software (i.e. a GUI builder) now replaces the textual code (which had a poor resemblance to the design/implementation). This means that the design, blueprint and implementation all strongly resemble each other providing two important benefits:

• The process of producing the blueprint becomes much more intuitive because the mapping between the description in front of the developer and his mental models is greatly simplified
• The feedback cycle is considerably shorter, dramatically improving the ease and speed with which errors in the blueprint are identified.

Developing specialized blueprints requires specialized application development programming software. These tools are dedicated to providing optimal editing capabilities for a single application aspect.

The code that is concerned with the behavioral aspect of the GUI is still described using textual code (captured with textual application development programming software) as this happens to be the most convenient representation for this aspect.

A specialized infrastructure blueprint representation

There exists a natural orthogonality between infrastructure and other application aspects and therefore it is possible to cleanly separate infrastructure logic into a localized, contiguous description. This provides the same benefits previously identified with the GUI description - browsing does not involve searching for dispersed infrastructure logic through countless files.

Having separated this logic into a distinct blueprint, we now have to ask the question: what is the best way to represent infrastructure logic? We could provide a specialized textual language or we may wish to follow the same path as the GUI builder and work with a visual description and visual application development programming software.

Visual or Textual?

There are certain application aspects that are clearly best represented visually and GUI appearance is a prime example. However, some aspects are best represented textually such as processing algorithms. Visual programming has received some bad press in the past due to application development programming software initiatives that have sought to visualize those application aspects best represented textually.

So what is it about an aspect that makes it ideal for a visual representation? There are a couple of reasons why a visual application development programming software may be most appropriate:

• The aspect being described is itself inherently visual
• The mental models used to reason about the aspect are best represented visually

The GUI appearance is an obvious example of the first case. Infrastructure logic is an excellent example of the second.

Infrastructure logic can be thought of as describing the behavior of a community of interacting entities. This is directly analogous to interacting objects in the real world and we as humans are substantially better equipped to deal with understanding such behavior through our eyes than through language.

Consider a blind and a sighted man at a football match where the sighted man is describing the events to the blind man using spoken language. Who has the greater understanding? Why do we choose to watch sport on the television in preference to listening to commentary on the radio? we are capable of absorbing a great deal more information visually than through understanding language.

So infrastructure logic is conveniently expressed using visual application development programming software because the model that we use to reason about concurrency has an obvious visual analogy.

This is certainly not the case for all application aspects and processing algorithms are a clear example of this. Processing algorithms describe a sequence of steps from point A to point B and when we reason about how to achieve a desired effect from a given starting position, we naturally use language.

A possible explanation for this choice is that the ability to efficiently convey acquired strategies to subsequent generations is a powerful survival mechanism and therefore language has evolved to be a very efficient way to pass on this kind of information. Communicating strategies pictorially is much less efficient than using modern language. We can think of an algorithm as a 'strategy for implementing a transfer function'.

Follow this link for a more general discussion of the blueprinting approach to specialized application development programming software