Why Does GHS Use Commands?

Commands are your building blocks. You design and build a procedure 
(embodied in a "run file") which in turn produces a report for the purpose 
you have in mind. The procedure is your product. The report is the product
of GHS operating on your commands.

When you use a CAD program, your commands (pointing and clicking) are 
consumed immediately by the program. Your product is the drawing/model. 
Your commands are directly reflected in the product: the coupling between 
command and result is so close that we say the drawing is your product.

When you use a word processor, you likewise create a document from your
ideas. The commands are keystrokes, and the document is the summation of 
them. The document is your product. The exact sequence of commands that
went into creating it is irrelevant.

The distance between your input and the computer's output is very great
with GHS. However, if the run goes quickly enough, you can make use of 
frequent feedback from trial runs to help create and correct your procedure. 
But still your product is the procedure. The report production requires none 
of your effort after you have written the procedure.

When you are finished with a GHS project, you have a run file that can be 
used again with some modification to make another report that may look 
quite different. When you finish your CAD drawing or text document, you
also have a file that perhaps can be modified for another project, but you
must focus on the output in order to make the changes because the output 
is your product. With GHS you focus on the input.

GHS can be used interactively through menus, without typing commands 
and without a run file. In that case it is like the interactive CAD experience
in that you get a response from each input in real time and your product is 
the report, which you build step by step. The drawback is that you cannot
edit your product like you can edit a CAD drawing or a text document: 
you have to start over if you want to make a change. So except for very
short reports, it is not practical. The QMENU formerly supplied with GHS
did this.  

The menu approach could be made more practical by formalizing the steps
and preserving them so that they may be edited and the report regenerated
without manually repeating the inputs. There is some merit in that, but it 
cannot approach the elegance and power of the macro command language.

There is a method by which you make use of a run file without having to 
write the procedure or know the commands involved. We call this a wizard. 
Essentially a wizard is a ready-made run file that has options built into it so 
you can adjust it to your particular need. In that case the set of options is 
your product, which is saved as an input file to the wizard. GHS provides 
wizards for certain tasks when the effort it would take to write the run file
would be a major undertaking. DAMSTAB2.WIZCO and RIG.WIZTA 
are prime examples. 

A wizard is limited to a particular task. If one exists that does exactly what 
you want, then the wizard may save you time.

It would be impossible to make a universal wizard that does everything
anyone would want to do. If we attempted to make one, it would have 
to be enormous. It would be awful. 

The only feasible way to do something like that is to break it into two levels 
with a wizard-making wizard. GLM_MAKER.WIZ is like that. It's a wizard
that generates a run file tailored to be a command-free version of GHS for
onboard use (GLM). Even for this limited application the options it offers 
are innumerable. You can make a basic GLM very quickly and easily with it, 
but if the ship has special needs, you will find layer upon layer of options. 
If you are good with run files, you may wonder whether you could have 
finished it sooner and gotten closer to what you wanted by building your 
own run file. Some users do just that, making a command-free version of 
GHS for a particular application.

That is one reason why GHS uses commands.

When you write a run file, you have become a programmer. You have opened
the door and stepped outside the confines of the application into the land of 
power users. Only a small fraction of computer users know what a computer 
is: all they know is the operation of certain software applications. When you 
write a program you tap into the power of your computer, and you discover the
potential that most applications conceal from you. Regardless of what language 
you use or how many layers of software insulate you from the hardware, you 
have gotten control of your machine (or virtual machine), and you can harness 
it to do your work. You have escaped out of the user loop: you can stand apart and 
make it do things automatically if you learn the control structures of your
language. GHS macros, templates, and variables give you a simple and easy
way to write a program to do almost anything. 

In our experience, users love programming with GHS once they get into it. 
Basically it's fun. That's another reason GHS uses commands.
   
The difference between direct input and input via programming is illustrated
by comparing a CAD program to Part Maker. Typically the CAD user is in a 
tight interactive loop with the computer as the model is developed. As creative 
as the work might be, it involves a lot of repetition because the commands are
down at the ground level of production. Basically CAD is a better pencil.

With Part Maker the loop is large and very loose. Repetition in your work 
as you develop your run file can approach zero if you make good use of the 
programming facilities. As brilliant as a CAD program might be in manipulating 
shapes, you have to instruct its every move in real time. If there is any program, 
or implied procedure in this, you are it. You build the model of your ship with 
your own hands. It is a draftsman's tool.

When using Part Maker you enter a different time domain. You are not the 
program; you are the designer of the program that makes the model of your 
ship and your hands need never touch it.

This is not to say that Part Maker is better than CAD. They both have their place. 
CAD programs offer programming environments for power users too, and some
synergy between the two approaches may be achieved. Part Maker is at the other 
end, primarily a programming language with some direct drawing capability via 
Section Editor. Perhaps synergy is possible there too. Watch for a new Part Maker 
interface.