When I arrived at Lawrenceville School for my second year there in 1968 ("fourth form"), I was informed of a computer on campus. It was a model 33 Teletype which connected by phone to a line in Princeton that was linked to a GE 635 in Teaneck, NJ. At the time I figured: computers are the wave of the future. I should learn something about them. This simple observation was a key turning point in my life.
I have worked on a number of projects over the years. Here is a description of some of the ones that have stood out in my memory.
The GE system had BASIC, FORTRAN (2?), and ALGOL, and I learned BASIC. I disagree with ewd that BASIC was a fatal disease, but it did create habits I had to unlearn in subsequent years. Actually, I think we still need BASIC: it's a reasonable first programming language to teach some basics.
For Mr. Waugh's exceptional English class, I wrote a program I remember fondly.
It was simply a madlibs generator based on Jabberwocky: T'was
This was not great literature, but Mr. Waugh brought out the creative streak in
me, such as it was.
The poem was not well received. He spent a fair amount of class time
discussing the poem, and how the first and last stanzas were brackets to the
poem. My brackets didn't match.
I don't have any of these early programs. They were all saved on paper tape,
which didn't survive my college years.
We named the program Senator at Doug's suggestion: a combination of "setup" and
"editor". We wrote the program twice, the second version being distinctly cleaner
and better, and both were used by a number of CDC sites.
Here is Version 2.5, the last I knew of, and includes some
stand-alone programs like "breseq", Steve Lidie's program to resequence all of parts
of basic programs.
Breseq would correctly resequence a portion of the program, changing references throughout,
so you could group one set of routines starting at line 1000, and another set at 2000,
and not lose the separation of the parts during reseqencing. We also had a "flag" option
which took several line numbers. Breseq would print the old and new values of those numbers.
Senator itself was a numbered line-oriented editor. We quickly tired of entering line numbers
for extended text entry, so the INPUT command would let you enter text after a line, moving
subsequent numbers down as needed.
Since Senator knew the language you were entering, we had convenient shorthand for a number of
languages. For example, COMPASS assembler input, which we used all the time, might look like
this:
Would give properly formatted card images:
There were similarly convenient formatting rules for other languages like FORTRAN, COBOL,
and, God help us, WIZARD. The computer gave no responses while you were in INPUT mode.
";" escaped the mode, ";D" would delete the previous line, ";L" would list the previous
line, and there may have been a couple others.
Speaking of modes, SENATOR was very much a mode editor, based on the old GE Time sharing system.
Aside from entering particular line numbers and INPUT mode, you could go into EDIT mode
for a completely different syntax and a variety of fairly powerful features. My thought
at the time was that it was a good idea to keep all this power away from beginners.
What happened is that power users had to keep flipping back and forth, in and out of EDIT
mode. I have since taken the Unix lessons to heart: design to the power users and let the novices
learn their way. Someone (Steve Roseman? (still at Lehigh)) put in a PRC mode that somehow automated
the switch.
EDIT mode had a number of useful features. Probably the most notable was the concept of marking
lines. You could find lines with certain attributes and mark them, the find a subset and re-mark
them, and then edit only the marked lines. I hadn't seen this before, and don't recall seeing it since.
Strings could match ellipses, and the whole ellipsis replaced with a string, or just one part of the ellipsis.
Regular expressions are a bit more powerful, but I am not sure in retrospect about usability
comparisons.
You could also restrict editing by column or column ranges. The EDIT parameter was Z for zones.
I spent a fair amount of thought adjusting command and parameter names to try to make the letters
fit. Should it be S)earch, F)ind, or L)ocate? Well, I might be using S for something else. I spent a lot
of time at the blackboard juggling letters.
I am typing these notes on a modeless editor (jove). My later editing designs were all modeless.
Of course, there were RUN, COMpile, and EXEcute commands. These invoked a series of CDC
control cards with a number of options depending on many things. I created a little command
language to handle this out of the COMPASS macro and string manipulation features.
These generated table entries that were assembled into commands. They don't make much sense
alone, but they looked like this:
The CDC console let you peer into executing programs with a fascillity I've
never seen matched since. DBG doesn't hack it. The COMPASS assembler stored
the line it was assembling around address 140, as I recall, and you could watch it
zipping through the program. But when it came to these CSS statements, each one
would sit there for about a second as it ground through all my fancy macros and option
processing.
I was particularly proud of one typing simplification. If you wanted to compile
a FORTRAN program with optimization level three, you might enter:
I think you could set options so you wouldn't have to retype them. There was no command line
editing that is so common today.
For the lucky people who had access to the CDC consoles, there were some nice programs
for text entry and execution at the console itself. I remember programs called O26, O29, and
DIS. There was one that allowed command abbreviations, and it was wonderful.
On CDCs you were always entering control cards, and for a long time, they required a trailing
period or they would abort. For example, to copy your input deck to the printer,
you might have after the job card:
But the long names, and the required periods, were a pain, and one console program allowed
abbreviations. If I recall this correctly, the two cards above could be entered:
I loved this, and brought these abbreviations and other features to SCP (for SCOPE commands)
mode. I don't remember much about the rest of the processing, but you have the source code
if you wish to chase some of them down.
SENATOR was used at Lehigh and Temple, and a few other places, well into the 1980s, before
CDC machines went away. I ended up getting an A in a IS-390, a special projects Information
Science course, after writing up something like the above.
I toyed with more special purpose editors in the early 1980s, but didn't pursue them much. EDL
was a general line editor. EDP edited Pascal, doing automatic formatting based on the language.
EDT would have been an early shot at a WYSIWYG text editor similar to some I was seeing
on microcomputers at the time. All these were written in Pascal, which was easier and quicker
and better for writing this stuff. Senator was all assembler, and at its smallest, in SCP
mode, was 13K on the CDC. The CDC did not have shared program text, so this size was very
important.
1000 print "T'was "; fna(); ", and the "; fna(); fna(); fnn(); " did " …
Senator
The GE Time Sharing system was pretty much the Dartmouth system, I think, and I
was used to it. When I got to Lehigh I found a mainframe, the CDC 6400. It
ran the SCOPE operating system and a fairly crude timesharing system called
Intercom. The old program that offered GE-style editing was called "setup",
and was due to be replaced with the new program, "editor".
I didn't think either of them were nearly as good as the old GE system, and,
after learning the amazing CDC assembler COMPASS, set out to bring the joys of
GE to the CDC. Assisting me were Doug Price (later of the NSA and Sparta), and
Steve Lidie (who has served at Lehigh ever since.)
Some notable Senator features
Text entry
INPUT
ENTER TEXT
IDENT SAMPLE
ENTRY SAMPLE
SAMPLE: BSS 0
SB1 1;ALWAYS
;
READY.
IDENT SAMPLE
ENTRY SAMPLE
SAMPLE BSS 0
SB1 1 ALWAYS
EDIT mode
Execution
**** TPPT ENTRIES.
FORTRAN RUN (B,CFL,EFL,LIB,PR,PU,SHOW,MAP,U,L,LOAD,COPYL)
RUN (R,OPT,S,G)
RUN (DEBUG)
COM (B,CFL,PR,PU,SHOW,U,L,COPYL)
COM (R,OPT,S,G)
COM (DEBUG)
EXE (EFL,LIB,LOAD,MAP)
EXE (DEBUG)
BASIC RUN (CFL,EFL,U,LIB,LOAD,MAP)
COM (CFL,LIB,L,B,PR,PU,U)
COMPASS RUN (CFL,S,G,L,B,PR,PU,U,EFL,LIB,LOAD,MAP,COPYL)
COM (CFL,S,G,L,B,U,PR,PU,COPYL)
EXE (EFL,LIB,LOAD,MAP)
SYMPL RUN (U,CFL,EFL,B,L,LIB,LOAD,MAP,PR,PU,COPYL)
COM (U,CFL,B,L,PR,PU,COPYL)
EXE (EFL,LIB,LOAD,MAP)
These showed allowable parameters. The commands were generated from skeletons:
* IF I=INPUT,L=OUTPUT,LIB=LIB
*
* THE FOLLOWING CARDS WOULD BE PRODUCED
*
* REWIND,INPUT,OUTPUT.
* LDSET,LIB=LIB.
* PROG,I=INPUT,L=OUTPUT.
SPACE 4,10
** CONTROL STATEMENT SKELETONS.
CSSDEF (FORRUN,FORCOM) FTN 4
U CSSUSE RCEUP
CSS (REWIND,),I,(,),L,(,),CB,(.)
CFL CSS (RFL,),CFL,(.)
DEBUG CSS (FTN,A,I=),I,(,L=),L,(,B=),CB,(,OPT=),OPT,(,R=),R,(,S=)
,,S,(,G=),G,(,PMD.)
DEBUG CSS ("GOTODBG1")
CSS (FTN,A,I=),I,(,L=),L,(,B=),CB,(,OPT=),OPT,(,R=),R,(,S=)
,,S,(,G=),G,(.)
DEBUG CSS ("DBG1")
COPYL CSSUSE RCECOPYL
PR CSSUSE RCEPRINT
PU CSSUSE RCEPUNCH
RUN CSS ("GOTOEXE")
COM CSSUSE RCERST
CSS ("EXIT")
PR CSSUSE RCEPRINT
CSS (ERRFTN,),L,(,"OFILE".)
CSSUSE RCERST2
RUN OPT=3
But I hated that the equals sign was a shifted character, and allowed a minus for the
same thing:
RUN OPT-3
I really like this form: type typing was justy easier, especially on lines that had a number
of options.
SCP mode
REWIND,INPUT.
COPYSBF,INPUT,OUTPUT.
Old-time CDC users are still very quick at typing REWIND, COPYSBF, RETURN, UPDATE, MODIFY, and
some others.
R,II
SBF,I,OO
Retirement
STAR4 - my answer to the Trek program (June 1974)
CODACAS - multiuser trek
Micromark - hardware-based spelling checker
CDC CALCOMP plotter software rewrite
Primos-based DEC dump tape reader (LaSalle)
PC Lab print queue software (NJIT, c. 1985)