Tools Aim To Ease Burden Of Do-It-Yourself Programming

Most people working with personal computers don’t have degrees in computer science and don’t write their own programs. But in the population of people who do program, scientists make up a large percentage. Off-the-shelf software often doesn’t provide just what laboratory scientists are looking for therefore, many of them tinker with altering these store-bought packages or develop their own. If you do a little programming on an IBM PC, you should know that some reasonably priced language tools that go beyond compilers and program editors can save time and headaches—products such as organizational language tools, screen editors, and on-line help programs’ all of which can help make programming less of a chore than it otherwise might be. Organizational language tools help a programmer develop the concept or logic for a program before actually writing any code. Flowchart editors and prototyping software are two such tools. Before investing lots of time writing a program it is useful to draw a flowchart—a diagram that outlines the step-by-step progression of a program. Writing code is much easier when the programmer has just such a road map to follow. Just as writing a scientific report is easier with a word processor, the best way to draw flowcharts is on a computer because the pieces of a chart, like the paragraphs in a doc ument, can be easily changed and rearranged. Of the flowchart editors on the market, I've found Interactive Easyflow to be among the best Its optional mouse control makes it a pleasure to use, and it supports laser printers as well as dot-matrix machines and plotters. Each milestone in programming can be represented on the flowchart by using one of more than 60 available shapes, which are large enough to house text describing the particular step. Lines connecting the shapes and labels for each can be added effortlessly. Any scientist who is used to drawing flowcharts with paper and pencil will find this a vast improvement over the manual method. Another organizational tool helps the programmer—before he or she begins to write code—to envision how screens will look in the resulting program. I’ve found that prototyping software—software that lets the programmer create models for screens—is helpful in getting the feel for the way the final software application will look when it is run up on a screen. Dan Bricklin’s Demo II program, developed by one of the inventors of the computer spread- sheet, is the prototyping tool par-excellence. With this software, scientists can quickly produce special screens called text slides or snapshots from a running program. Then Demo can arrange the slides or snapshots in the same order they will appear in the program. This lets the programmer, without ever writing a word of code, get a feel for how the screens will look to the person running the program. A second category of tools, screen editors, come into play when it is time to actually write the code for these screens—a process that can be tedious indeed, especially in designing color screens. Screen editors can make the job much easier. A screen editor allows a programmer to manipulate the basic screen design similar to the way a word processor manipulates the words in a document. However, instead of interfacing with a printer, it translates a screen design into source code. I’ve familiarized myself with three screen editors. Softcode, which links with templates for four different languages; SayWhat?!, which can be indirectly linked to several languages and directly linked to Turbo Pascal 4.0, a powerful programming language; and Turbo Plus, which is specific to Turbo Pascal. All three can draw graphics character boxes, paint parts of the screen with any color, and move or copy blocks of text and colors. In this respect, all three are functional, even pleasant to use as screen editors. However, concerning the language link—the function that translates a screen design into source code—there are more pronounced differences. Turbo Plus handles this best: It stores compressed memory maps (sets of machine language instructions) in the middle of the program, includes a number of routines to spruce up screens (by making certain words or phrases flash, for example), and allows input fields with data verification, which controls the type of data the person running the program can enter—numbers only, for example. Both Turbo Plus and Saywhat?! store compressed images of the screen program in a binary format that can be added to the overall program code using utilities that these tools provide. Softcode uses an interesting technique of combining the screen with its own screen templates to generate code. I admire the idea, but unfortunately the implementation is very slow: On a 386-based machine, the process on a single screen took five minutes. Given this and its comparatively high price (see table), I’d recommend one of the other programs. (I should add that, while Turbo Plus and Saywhat?! are equally good in terms of features, the documentation that comes with Turbo Plus is awful no index is provided and too much is not documented at all.) Regarding on-line help, let me begin by noting that some programmers feel that written manuals are only for sissies, although it is clear that compiler manuals need to be taken seriously. And if the proprammer doesn’t get the syntax precisely right, and the program therefore won’t compile, any programmer—sissy or not—is apt to end up with several manuals sprawled out on the desk. Thus, the virtue of having all manual information and syntax instructions available electronically; this explains why organized help systems for languages are making gains as a convenient new software genre. The programmer loads these products as either memory-resident programs or in a mode where the help program actually runs the editor. They allow programmers to access, on screen, all the same coding information they would normally look up in a manual. I’ve examined three such help systems. IN evaluating them, the “engine” that displays the help and the quality of the database are the critical features. All the programs I tested can be called up with a hotkey so that they search their database for the word at the cursor. So, to recall the proper coding syntax, the programmer simply types in the word and hits the hotkey. To my taste, the nicest engine is the one in Peabody. It will display the help window over the window the programmer is working in, and on request, the help window can be kept in a corner of the screen for easy reference. Techhelp’s linked database has a hypertext flavor (instead of information linked sequentially, it can be linked in a variety of ways) that is very pleasant. I found that I liked the engine on the Norton Guides the least: A weak aspect is the inability to search the entire database at once rather than only one submenu at a time. Techhelp’s superb programmer’s database is limited to BIOS and DOS calls and related issues. Peabody currently has C and Pascal databases with an assembly language database due out by the time this article appears. Norton Guides has two C databases, Pascal, Assembly, and OS/2. Ideally, I’d run with both Techhelp and Peabody resident, but they each take so much memory (55 K and 110 K respectively) that for the time being I must choose between them. Currently, I use Peabody most often for programming in Pascal. and Techhelp for any lower-level programming I do. Barry Simon is IBM Professor of Mathematics and Theoretical Physics at Caltech.

Tools Aim To Ease Burden Of Do-It-Yourself Programming

Interested in reading more?

Become a Member of