THE SCRIPTOR'S MAID
The Perspective of the Experienced Computer User


Bloat War - Part 1

Scripted and compiled code has a habit of bloating.  Everyone assumes that this is the result of the complexity of the task undertaken, but a little reflection will show that bloat only occurs after the most complex aspect of a task has been written.

Ironically bloat begins not with what is most difficult to do, but with those things which pose only mechanical obstacles and require little invention or imagination to complete.  It is the practical implementation of the core program, not the core program itself where good clean code begins to corrupt.

The reason for this is simple.  The core task is usually the first thing started - at least it is the one which is first fully conceptualized.  By the time this core task is working, the clarity of its original purpose imposes a similar clarity on the code.  At this early stage, the code often becomes smaller and more robust as it is refined without any undue concern for the problems of practical implementation.

However well behaved the core task is while in a controlled environment, it must eventually be married to a working environment.  The working environment can never be easily contained the way a core task can be - regardless of the complexity of that task.  The working environment is not so much complex as it is chaotic, at least from a programming standpoint.  The code must cope with what will get thrown at it where no two things need exhibit the slightest similarity or rational relationship.

All aspects of practically adapting the core task (i.e. exception handling, the user interface, and other necessary features), contribute to bloating simply because they are not amenable to coherent logic.  Bloat festers where clarity disappears.  Marrying self-enclosed core task(s) to work environments which cannot be neatly enclosed engenders the confusion, the inconsistencies and the expansion that are bloat.

Naturally, as software develops, the range of practical variation and the demand for extra features increases. Bloat is not content with simple increase, but swells exponentially as the program accumulates "work-arounds" and the inevitable inconsistencies that will, with equal inevitability, engender even more of the same.

Breaking bloated software into modules may seem like a good idea, but it does not help.  Most schemes for modulating software are arbitrary and artificial - making software modules fosters greater bloat than perhaps any other method.  It seems that every new thing done increases the problem, even if this is an attempt to simplify and better organise the code.  Bloat seems to have a life of its own as well as a very spiteful personality along with it.

The solution to bloat has been around for years, although the potential has been ignored; it is the Graphical User Interface (GUI).  The GUI was invented to encourage a better marriage between the work environment and computer code, and we know it works but we have only understood this to flow in one direction; from the user to the code.  We have neglected the possibility that the GUI might also serve the programmer to form the code.

The GUI qualifies as a programming language in its own right, but this has been overlooked because it does not resemble code.  GUIs have a syntax (graphic controls) which support generalised commands (events).  If this were not so we could scarcely run a previously unseen program and deduce its actions from clicking around its GUI - we do this automatically, the GUI being so familiar and intuitive that it is nearly impossible to see it as syntax and commands, i.e. a language.  Nevertheless that is what it is.

But a GUI is only an unrealised potential unless we can program with it.  However, the way GUIs are implanted into code dissipates any such potential.  We put GUIs into code when in fact we should be putting code into GUIs!

When GUI controls are placed within the body of the code, they contribute mightily to software bloat while evaporating any programming potential of the GUI.

The programming potential of the GUI lies in its organisation; what controls are placed where, what names are given to controls (i.e."Cancel"), what events are associated with the controls (i.e. click-events, change-events, activate-events, etc.), and finally whether the use of one control effects the behavior of another control (i.e. disable, hide, show, send-event, etc.,).

In terms of software implementation the GUI gives structure to what would otherwise be chaotic exceptions and conditions sandwiched inside the code. Normally if a process needs to check a number of conditions before proceeding, we may or may not use a GUI.  If we do we would include calls for it within the main code.  In either case we have effectively bloated the code with logically extraneous matter.

On the other hand, if the GUI is allowed to organise the underlying code, then a simple check-box combined perhaps with a list-box selection may contain within them the conditional code necessary for the process to proceed - the conditional code is not only logically isolated from the rest of the code, it is also informatively labeled and, because it is placed within the message-event of the controls used, message handling routines are simply eliminated.

Given:

  • A drag-and-drop visual editor for creating a GUI dialog,
  • That each element used is already associated with appropriate events,
  • A GUI interpreter which runs in the background,
  • And an editing environment where code is written directly into event modules,

we would have a powerful and natural module builder without mammoth confusion and monstrous overheads - i.e. Object Orientated Programming (OOPs is shorthand for bloatware).

In Conclusion

Bloat has never been the result of attempting complex tasks; some of the most elegant software deals in extremely complex tasks.

The contention that bloat becomes a problem at the level of implementation has been argued, but the actual proof lies in experience.

If the contention is correct then it must be acknowledged that the proper resolution of the problem should be a GUI programming language - the only difficulty is appreciating the GUI as a language.

Ironically this device (the GUI), a child of programming, does not look like any other programming language - but then why should it!

Of course such a GUI programming environment exits - it is "Modular and Integrated Design" (MAID), and the mission of this is column to properly introduce this new form of language to our community.

Greg Schofield <schofield@taunet.net.au>,
the Darwin correspondent for the RexxLA Newsletter