| I remember that a lot of people at the MIT AI lab used to use
an extended version of DDT as their primary command interface.
DDT is the PDP-10 and -20's debugging language, similar to VAX DEBUG.
In other words, the usual purpose for it was to look at memory
contents and interactively step through programs.
Andy V
|
| One obvious thing to mention is UN*X -- the shell is a block structured
interpreted language. It is better suited than most languages, there is
easy access to lots of filters which are designed to mung words and text,
just the sort of thing you want to deal with at that level.
In a lunch time conversation a while ago someone mentioned a system which
had some form of ALGOL or something similar as the command language.
The two main differences that we came up with between a normal language
and what you want from a command language are: 1) ways to process text
(like the UN*X filters) and 2) the context -- to start a program you often
have to do lots of initialization, you need many things setup for a
command language (like having your user name, login directory, etc.
available in variables).
This same person also advocated having two command languages, one for
command files with the full features of a language and another for
interactive use. I didn't approve of this -- when using UN*X I frequently
type in while loops from the keyboard.
------
A separate topic is the use of an editor as the top level of a job.
This is the sort of environment that I used at Yale, in two flavors.
The first flavor was on TOPS-20, using an editor developed at Yale
as a top level process over a highly modified EXEC. The EXEC modifications
had nothing to do with the using the editor, they just made it nice to
use by making some things more consistent and adding many features
including various useful UN*X filters. You typed commands directly
through the editor to the exec, but the editor kept a history file
of all input and output and was used to edit and re-submit commands.
This meant that all editing you did on the system used the same commands.
One keystroke would take you back to the buffer of the file you were
last editing (with all context saved since you never left the editor).
[The editor kept many files you have edited mapped in virtual memory
and remembered the last editing location for the last hundred or so
files. This is a helpful feature -- you often want to go back to the
same place if you edit a file you have edited within the last week.
And if not, getting to the top is simple.]
The mail program let you edit messages, it sent the file up to be edited
rather than down as in most environments. It was real easy to send
histories to show how a program bombed -- just switch buffers to grab
a piece of the transcript.
There were other nice features of this environment, but they were mostly
concerned with forking and making up for the fact that 24 by 80 is too
small to have many windows at once.
The other environment with the editor at the top was on Apollo workstations.
These have multi-windowed bit-mapped displays. The display manager (DM)
has many commands for moving around and inserting and munging text.
These are bound to key actions so that keys will have an effect when
they are pressed. [These primitives are much simpler than what TPU has.]
Theses same definitions were used in edit windows (were you were actually
editing the file and could move over the whole window) and command windows
(where the window was mostly a transcript of what had occurred -- you could
move over the entire window but could only change the unprocessed commands).
B.J.
|
| Re .3:
I read the article about the Yale work done above Twenex. Did they have a
good bootleg copy of the multiforking EXEC to compare their progress against
before they started? I can't imagine someone going through the contortions
they did to end up with so much duplicated effort. (I also think they should
have sprung for a Bliss-36 license, or wangled one out of DEC; using Bliss-10
for so much new code is a real waste of effort).
The article was interesting, but was littered with "we wrote X ourselves,
because Tops-20 doesn't supply it" where I often use the specific X'es daily,
along with lots of customer sites.
/AHM/SIGH
|
| Re .6:
For the record, I'd like to respond to Martin's message of three
years ago:
I read the article about the Yale work done above Twenex. Did they
have a good bootleg copy of the multiforking EXEC to compare their
progress against before they started? I can't imagine someone
going through the contortions they did to end up with so much
duplicated effort.
...
The article was interesting, but was littered with "we wrote X
ourselves, because Tops-20 doesn't supply it" where I often use the
specific X'es daily, along with lots of customer sites.
We started our work in 1978, when the set of tools commonly available
for TOPS-20 was indeed quite inadequate. The work trailed off after
1982 (publication delays for SP&E were quite long).
Bootlegged copies of the multiforking EXEC weren't available until well
after we had done most of the related work. We did use the
multiforking EXEC, but continued to use our own multiforking tool as
well, since it was better integrated with the rest of the tools and was
more keystroke efficient.
A good TOPS-20 port of Emacs was available, but it was not suitable for
a number of reasons. Our text editor was much less piggy than Emacs,
which was quite important on our heavily loaded -20s. Unlike Emacs,
our text editor gave immediate, interactive response on a loaded
machine. The editor was also the first to provide a general-purpose
typescript facility on a timeshared machine, something that TOPS-20
Emacs never had and that appeared in Gosling Emacs only much later.
As time went on, we did import a number of smaller TOPS-20 tools, but
as we explained in the article, we found many of them were unsuitable
for an "integrated" environment. For example, the spelling corrector
"ispell", since it was written in assembly language, couldn't be easily
integrated into our text editor, so we wrote our own. As another
example, one commonly available file-searching tool used the
sub-command parsing of TOPS-20 instead of taking its arguments on the
command line, and most users found that sub-command mode clunky at
best; it also didn't accept the regular expression syntax that our
other tools used.
(I also think they should have sprung for a Bliss-36 license, or
wangled one out of DEC; using Bliss-10 for so much new code is a
real waste of effort).
We had no grant money. The Yale computer science department wouldn't
buy a license, and at that time DEC was, to put it kindly, niggardly in
its support of university research. BLISS-10 was adequate for our
purposes -- it produced acceptable code, and we didn't spend much time
on compiler bugs. For the most part our code was quite clean, so it
wouldn't have been a big deal to port to BLISS-36.
-- John R. Ellis
|