MetaCard Corporation

Part 1: Overview of interactive GUI development environments

Once upon a time (1984), professional software engineers were the only people capable of developing graphical applications. The toolkits available at that time - the Macintosh toolbox, Digital Research's GEM, the interminably-in-beta-test Microsoft Windows 1.0, or the fledgling VAX-based X window system - were primitive and required mastery of a very complex GUI API. Worse still, applications usually had to be written in C, a language infamous for being difficult to learn and very unforgiving of programmer mistakes.

A few years later, some bright engineers at Apple Corporation decided that what "the computer for the rest of us" needed was a GUI development environment "for the rest of us". The result of this project was HyperCard, the first full-featured development environment designed for non-programmers (first released in 1989). Since then, many other end user programming tools have been developed including such HyperCard-like tools as SuperCard and ToolBook, and independently evolved tools such as Visual Basic (VB) and Visual Basic for Applications (VBA).

Though tools like these were a long time coming for the Unix/X11 market, they're finally here. Products such as Tcl/Tk, the COSE Desktop KornShell (dtksh) and MetaCard make it possible for non-programmers to develop GUI applications without requiring the massive effort required to master C/C++ and the Xt/Motif toolkit.

But end users are not the only ones to benefit from the development of these tools. By offering a higher-level language for GUI development, these tools are much more productive development tools for *all* developers. In fact these tools are so much more productive than conventional tools, they will eventually replace conventional GUI development environments for nearly all application development.

Just as C compilers replaced assemblers as the standard software development tools in the early 80s, and languages like Perl and the shell languages have replaced C programming for most system administration tasks, it won't be long before developing an application in C or C++ with a low-level GUI API like Xt/Motif will be about as popular as programming in assembly language is today. This transition is already largely complete on the Microsoft Windows platform where the vast majority of applications are developed with tools like VB, PowerBuilder, Borland's Delphi and a wide variety of 4GLs and other high-level languages.

Why an interactive GUI development environment?

The primary advantage of a VHLL (also commonly called a scripting language) over a third generation language like C or C++ is that fewer lines of code must be written to complete a given task. Fewer statements take less time to write, and can be understood and modified more easily. The bottom line is increased developer productivity and better quality, higher functionality applications.

A second benefit arises from the fact that VHLLs are usually interpreted, which means you don't have to wait for compile-link-run cycles. This also greatly improves developer productivity since more time is spent developing and less time waiting. The productive time gained is actually much more than just the compile-link-run cycle time, since the developer doesn't repeatedly have to refocus attention on the task at hand, a process that can take as long as the compile-link-run delay itself.

While one might guess that choosing a high-level language might require sacrificing performance, benchmarking shows that in many cases screen update performance of applications developed with these tools is even *faster* than comparable applications developed in C with Xt/Motif due to the greater overhead of that toolkit (details to follow in the last article in this series). Furthermore, most VHLLs can be extended by adding commands written in C to improve performance where needed or to take advantage of libraries that are only available for C or C++. Certainly performance concerns aren't a reason to choose a third-generation environment over one based on a VHLL.

Scripting Language Overview

Though there is no universally accepted definition of a what a scripting language is, there are certain features that they usually have:
  • Interpreted execution, so compile-link cycle is required. Execution errors cause the environment to point out the error to the developer allowing them to fix it and continue.
  • A simple syntax. For example, statements are usually terminated by returns (new lines) rather than by semicolons or other punctuation. In most cases statements have a common "verb-arguments" format rather than the mixed order used in third generation languages.
  • Untyped variables which act as strings or numbers depending on what operation is being performed on them.
  • Variables are created when referenced, rather than through explicit declarations.
  • High-level string manipulation features such as concatenation, substring operations and searching/sorting primitives are built in to the language.
  • No pointers or memory allocation. "Garbage collection" of unused memory is done automatically, freeing the developer from having to deal with the most time-consuming and bug-prone aspect of programming in C.

Note that many of these features are also common to the fourth-generation languages (4GLs) used with many database front-end toolkits. The various shell languages and UNIX pattern-matching languages like awk and perl also have many of these characteristics. Even some older languages like Lisp could be classified as scripting languages based on this criteria, though perhaps the simple syntax requirement can't be met. New-generation 3GLs like Java have some of these characteristics, but the complex syntax, requirement to compile as a separate step, and the need to type all variables means that Java should not be grouped with true scripting languages. See also Java is taking us in the wrong direction

Another useful distinction is that scripting languages are not the same as macro languages. Macro languages typically lack the control flow (repeat, if-then-else) and the procedure building capabilities that are required in a general purpose programming language.

On to Origins and general description of the environments

Up to Table of Contents