Bloat War - Part 3


The opposite to bloatware is software which, as it generally improves and accrues functions, becomes relatively smaller over time.  Despite common experience, shrinkage should be the common attribute of software which has had the benefit of frequent revisions.  If this is rarely the case in practice, it is mainly because of the compounding confusion created by forcing all aspects of a solution through the eye of a single language.

The underlying reason why three different levels of languages (compiled, interpreted and visual) work so well together is that they reflect the different demands of software creation and implementation.

The most generalized code is that which should be compiled.  Whereas that which sets-in-motion this compiled code is naturally more specific, more open to change, and thus better served by being interpreted.  The final layer is where the real world deploys the code, thus customization and integration with that real world environment is mandatory - obviously a visual language best fits such an agenda.

Modularity in such an environment requires no real pre-planning, rather the languages together suggest workable modules.  This form of modularity reduces scripts to a handful of lines, easily comprehensible, simple to edit and inviting reduction.  The critical point being that the visual interface knits-together the disparate parts of the program, each scripting module insulated from its neighbors, communicating via events and changes to "global" variables, each script fragment automatically exiting, discharging its local variables and disappearing.

Because the program is only really held together at the front-end, each script fragment can be changed with a cavalier disregard to the style and variable conventions of any other fragment.  The need to add comments is greatly reduced, for not only is each fragment shorter and relatively independent, but the control that is associated with it already conveys much about its purpose and how it works.

Consider a simple entryfield which by itself conveys very little about itself.  But that same entryfield procures eloquent testimony in the context of the dialog in which it appears.

Consider that this same entryfield is also its own "global" variable and, lacking any appreciable imagination, we call it "A".  Add a sister entryfield named "B" and another sibling called "ANSWER" whose style is set to "read only".  Now add a button.  To this button we add the script fragment <ANSWER = A * B>.  Here we have not only a self-explaining script but also an exemplar of concise programming.

Add to this script fragment <A = ""> and the entryfield self-cleans. Apply a label, "Amount", next to entryfield "A", and "Exchange rate" next to "B".  Make the style of "B" "read only" as well and add to the dialog's initiation event a few lines that will retrieve the exchange rate from a given HTML file and place the recovered figure in "B".

Now we have an exchange rate calculator for the price of less than twenty lines of script and the use of a generalized DLL.  Extra features are not hard to imagine, but none would need to be explained beyond adding labels and none of the scripts need be particularly mindful of how they make their features available.

The natural modularity of the above example flows from the way the script and compiled code are orchestrated by the visual elements and their associated styles and events.  The fact that each visual element is also a "global" variable simplifies matters even further.

In this context scripts get shorter because it is easy to see what everything is doing and in what sequence, hence improvement is not just adding to, but also, editing down fragments.  The whole thing is easier to understand because it all comes together at the same level that it is put into use.  Thus what confronts the user is not a GUI added to the program as an extra, but a GUI which is the final expression of that program.

Clarity is what dispels bloatware.  Combining languages is not enough unless this combination is given final shape by the visual expression of its practical implementation.  Clarity can only become real if each element visually present can be separately opened and examined.  Only if the content of each element directly corresponds to its purpose, only then can the program be self-explaining and clarity effortlessly promoted.

The GUI has been terribly underestimated by the programming fraternity, passed-off as a sop for the ignorant user, as needless prettification. And bludgeoned into a coding framework ill-fitted to the task, the GUI has come to simply represent so much unrewarding toil.

The independent power of the GUI as a programming language (albeit of an unusual and visual kind) has not been widely realized.  In the present column this power has been linked to script shrinkage.  Yet the reader could well be of the opinion that such a link has not been sufficiently well drawn to be persuasive.

One of the problems in providing anything resembling a convincing example is that every example of verbose scripting was so obviously in need of editing, that it seemed the height of pointlessness to present it as an example.

It is altogether better to suggest that the reader simply imagine the worst piece of scripting they have ever written buried amongst hundreds of lines, and all the problems that may arise in identifying and changing it, compared to the very same fragment being more or less isolated and insulated from the rest of the script.

In the latter case the fragment simply begs to be rewritten.  While in the former case it may take a little self-convincing to seriously remodel the offending piece and to do so without awakening too many bugs.

What is meant by referring to the visual language as "the final expression of a program"?

While it is true that the last thing to be twigged into shape is often the GUI itself, this is a trivial point.  More seriously, it is obvious that the GUI can be seen as the outer appearance of a program and in this sense it is a candidate for being seen as "the final expression".

It is universally the case, when working with such language combinations, that the very first thing created is a primitive version of the GUI front-end.  It is this front-end from which the code grows, it is to this front-end that debugging devices are added and then removed, it is the elements on this front-end that explain the underlying code and set them into motion.  It is the front-end that practically defines the program both in its design and usage - the GUI is no mere add-on.

Greg Schofield, the Darwin correspondent for the RexxLA Newsletter, Schofield@TAUnet.net.au

RexxIO.dll (FREE) and MAID ($US50) are available from http://www.lestec.com.au/