[Access to Wang masthead]

It's All in the Code

Comparing the VS with other development environments
From "VS & Beyond",  Access to Wang, November 1997
  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

Are you a Wang programmer interested in working with graphical applications, the World Wide Web, or other new development environments? If so, here are some of the differences you can expect to find in tools and development techniques. In this discussion, "new" development applications could include any of the following:

Monolithic applications versus scripts

When a Wang COBOL programmer sits down to create a new program, all elements of the program's universe must be defined, including values (properties), containers for these values (objects, variables), and behaviors (methods, logic). The compiler interprets these specifications, merging all elements into a single executable program that creates this universe and populates it for the duration of its execution. I refer to these as monolithic applications. Such programs usually stand alone, finding and using all of the data they need without need for procedural languages (scripts or Procedures) to tie them together. Most Wang applications are developed using this model. Other third-generation languages - such as C or C++ - share a similar approach except there is a larger reliance on a mass of common functions: their libraries. The programmer is freed from writing some common code, such as a similar Input-Output section for each program, allowing greater concentration on the actual application. Typically, many smaller programs and developed to handle common elements of an application (file access, screen validation, etc.) and assembled into a single program using make or a similar tool. This environment puts additional requirements on the programmer to be aware of the standard functions that are available. Like the Wang environment, the resulting application is assembled into a single whole, but these programs may require scripts to provide information about the system or tie modules together.

In most other development worlds, the programmer works within a universe of defined functions, purchased libraries, and other preexisting conditions. Small programs, scripts, and pre-built code modules "glue" all of these elements together to form applications. It is the responsibility of the programmer to understand these elements and to work within them.

To understand this, consider the role of Procedure language: in most Wang environments, Procedures provide a way of tying programs together but they are not strictly required. In new development environments, script languages tie together elements of program functionality to form the application itself. In some development environments, it may be common to use dozens or even hundreds of small code fragments - scripts - to create a single application.

Multiple syntax

Most program development activities assume there is a single syntax within an application unit (program, page, etc.). In the case of Web development, this is not necessarily true, as the normal formatting language (HTML) is supplemented with a variety of other tools and applications. For example, a single Web page might contain:

Of course, you would never find all of these languages within any normal Web page, but it is common to find two or three. Client- side scripting languages are often used on input forms to overcome the severe limitations of HTML forms, providing field- level checking for the type of input, length, etc. Server-side scripting can provide a common page appearance across many pages, link the application to databases, and adapt the page's appearance to the preferences of the reader or the capabilities of their computer system.

Since there are few development editors that can work with more than one language in the same program, individual modules usually must be constructed and tested independently. A test environment must be constructed to develop each module, which slows development considerably. Fortunately, most modules of this sort perform a single function and can be easily copied from a known source once developed and tested.

These modules must be merged later to form complete programs. This merging process can itself cause errors, since the various code modules must be "hidden" from each other until they are invoked. In Web applications, this hiding is usually done by bracketing code sections with comment markers, which are removed by the client or server as the application is run.

Writing to the user environment

One notable difference in developing for graphical user environments is the unpredictable nature of the user environment. Old-style applications could rely on the standard text terminal display dimensions (24 rows, 80 columns) and capabilities (ASCII text with display attributes). When developing applications that must work on graphical displays, there are more capabilities (color, fonts, different field types), and far more differences in the possible dimensions of the display at the reader's side.

Web applications present a special challenge. The primary development language for the Web - HTML - was designed to allow information to be displayed according to the preferences and capabilities of the client program, not to allow specific control of content presentation. HTML code suggests content presentation rather than enforces it, allowing text to wrap and pictures to move according to the current dimensions of the screen, fonts, and other elements. Thus, Web applications must be built with an understanding of the possible range of end-user capabilities - and, inevitably, with some compromises in format.

In addition to the technical differences in application development, new applications - particularly Web applications - are now expected to be usable within a wide range of user disabilities, including limits in sight, hearing, or mobility. The Web has opened up an enormous world of information to many disabled users who were previously unable to participate, and there will be increasing need to accommodate this audience. In many cases, this will require providing alternate versions of the content.

Conclusions

The differences between developing applications in Wang COBOL and working in one of the many new development tools go beyond program syntax and tools: the programmer must understand more of the audience's expectations and capabilities. It will also remain a struggle to keep up with the dizzying pace of new product introductions, program versions, and vendor bug fixes over the next few years, as vendors refine their products.

Recent product introductions show more similarity in program syntax than before, so it may be possible at last to apply knowledge gained from one language to other languages as they appear. Nevertheless, Web applications will continue to require two, three, or even more different types of syntax within a single page to work around the inherent limitations of the medium. At the same time, user expectations are rising for application presentation, design, and accessibility.

With so many differences, what remains the same?

These three abilities are not developed casually, so you may find your experience is more marketable than you think. Developing experience in a new syntax or development environment is not trivial, but easier than acquiring the judgment and experience to create great applications.

Figure 1: A Comparison of Program Development Environments

Item Wang VS New Development Tools
1. Development environment Full-featured text editor with integrated compiler and debugger support Varies tremendously: mostly simple text editors with syntax checking, no direct debugger support
2. Access to debuggers Integrated with editor

Several types of traps, view contents of variables, etc. 		Generally limited to syntax checking

Most debugging performed by running program and viewing results
3. Description of syntax Consistent, well-documented; derived from industry standards Poorly documented

Closely resembles other languages with minor syntax differences

Constantly changing as the industry evolves
4. User environment Standard display terminal of known capabilities

Very limited local processing capability 		A wide variety of terminal sizes and capabilities ranging from none (dumb terminal) to very extensive
5. Standard routines, libraries Limited use of subroutines and COPY libraries

Some subroutines provided by limited set of vendors (Wang, several others) 		Extensive use of vendor-supplied libraries, files, common code, etc.

Aftermarket tools and applications available from many vendors
6. Procedural languages; access to system data Wang Procedure language; not required by all applications

System data available to programs through calls to subroutines 		A large number of possible shell and script languages, depending on the environment

Typically required for large applications to tie programs together, extract system data, etc.

  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

Copyright © 1997 Dennis S. Barnes
Reprints of this article are permitted without notification if the source of the information is clearly identified