Pleasant@Rutgers (08/06/82)
HUMAN-NETS Digest Friday, 6 Aug 1982 Volume 5 : Issue 76
Today's Topics:
Call Waiting (4 msgs)
Working at home (2 msgs)
Command languages, bandwidth, abbreviations and encodings. (2 msgs)
Comment on NSF Report
Educational Gap
Call for Papers
----------------------------------------------------------------------
Date: 2 Aug 1982 1252-EDT
From: Larry Seiler <SEILER at MIT-XX>
Subject: Call Waiting
Call waiting already has the property of switching you to voice if a
call comes in while you are on the computer. I spent a while
wondering why I would mysteriously lose carrier, then have the phone
ring the instant I hung it up, before I discovered that the phone
company had given me call waiting on a trial basis. Unfortunately, I
have to do some of my work on VAX/VMS, which doesn't allow me to
continue an interrupted program. So call waiting with an
un-enlightened operating system is a big loss, but if I worked only
under TOPS-20 (for example), I'd love to have it.
Larry Seiler
------------------------------
Date: Tue Aug 3 19:38:06 1982
From: decvax!utzoo!henry at Berkeley
Subject: call waiting for voice breakin
There are two problems with trying to use call waiting to let a voice
call come through despite data traffic. The first is that one may not
want to leave one's data activity in the middle just to take a call;
the one-use-at-a-time-channel problem remains unsolved. The second,
and more serious, is that it is not in the phone company's interest to
encourage data traffic on residential lines and they cannot be
expected to cooperate (e.g. by choosing suitable frequencies for the
call- waiting signal). Phone company plant is designed around
statistical estimates of traffic per line; data traffic is already a
serious problem because it ties up lines for much longer periods than
normal voice communications. Charging even local calls by the minute
*might* make their attitude more reasonable.
Henry Spencer
decvax!utzoo!henry
------------------------------
Date: 3 Aug 82 11:38:17-EDT (Tue)
From: Vonglahn.EE at UDel-Relay
Subject: Videotext and telephony
I've been reading the discussion lately about tying up one's only
telephone for videotext.
My field is not telephony, but I remember reading that many are
predicting that the future will bring all-digital telephony. That is,
instead of an analog line to your analog phone, you would either have
a digital line (with digitization in the now digital phone) or a
digital line to a spot near your home, with analog the rest of the way
to your old analog phone.
If the first scenario comes to pass, it seems to me that enough
digital bandwidth would be available between your home and the phone
company to piggyback a digital bit stream on the encoded voice signal
(as several digital/voice PBX manufacturers do now). The piggybacked
videotext signal could then be split out at the phone company (and at
your home) and fed into the videotext system.
If one believes the second scenario, on the other hand, I think that
the a short hop analog line (from your home to the digitization point)
has enough bandwidth so that you could use a special modem with
frequency division muxing to put a secondary bit stream on top of the
voice signal. At the digitization point, the secondary signal would
be stripped off and fed into the videotext system. This would cost a
bit more than the first design, but it also wouldn't tie up the voice
part of the phone.
In summary, then, I think that ways could be found to get videotext
into the home over one phone line without sacrificing voice
communications while using videotext. Of course, they would require
the active cooperation of Ma Bell, which raises a whole host of other
issues.
Comments??
Pete von Glahn
------------------------------
Date: 4 August 1982 20:06 edt
From: Richard Lamson at MIT-MULTICS
Subject: Call Waiting
Before we had two phone lines in the house, we used call-waiting to
use the phone line for both data and conversations. We have a VA3451
in the house, and Vadic triple-protocol modems of some sort at the
other end.
The tone you receive when you receive a second call is sufficient to
cause the modems to hang up at at least one end (when talking to
another system with different modems, sometimes the line merely
glitched, rather than hanging up). If your host system has automatic
process saving when the line hangs up, you generally don't lose too
badly. However, I can tell you from experience that the pain involved
was sometimes sufficient to make me wish we could turn off
call-waiting for the duration of certain data calls.
This, of course, is why we now have a second line. I have a friend
who lives in a three-person (actually, the germane information is that
three programmers live there) house, and they have FOUR phone lines
into the house, one for voice, and three for data.
-- Richard Lamson
------------------------------
Date: 4 Aug 82 12:54:18-EST (Wed)
From: Ben Goldfarb <goldfarb.ucf-cs@UDel-Relay>
Subject: Working at home
Another good reference for people interested in "tele-commuting" and
general speculation on our future with networks is "The Network
Nation", by Turoff and Hiltz.
Chris Kent, Purdue CS
------------------------------
Date: 5 Aug 1982 0937-PDT
From: LAWS at SRI-AI
Subject: Working at Home
I thoroughly enjoy telecommuting, but then I enjoy my work at the
office also. I find that I do my best reading at home and my best
writing at the office. Programming I do best wherever there are the
fewest distractions -- it cannot be interrupted every half-hour the
way that reading and writing can.
(My experience may be colored by having much lower baud rates at home.
While word-processing is a wonderful way to write, the editing process
can be very painful over a slow line.)
As to personal contacts, I find that communication via messages is
much more time-effective than are bull sessions. Typed arguments tend
to be much better thought out and to stay focussed on the original
problems. I just wish there were a good method to communicate
drawings and pictures.
-- Ken Laws
------------------------------
Date: Sun Aug 1 20:34:08 1982
From: decvax!watmath!idallen at Berkeley
Subject: Command languages, bandwidth, abbreviations and encodings.
[ This article was originally submitted to the WORKS newsgroup. ]
[ It was pointed out that the topic was more suitable for HUMAN-NETS ]
We argue here over ways to make it *easier* and *faster* to do *more*
with *less* typing, less reference to manuals, less guesswork.
Bandwidth -- that's the central issue in command language design.
People argue over schemes that will remain friendly and mnemonic and
also provide high bandwidth (usually, less typing).
To maximize bandwidth without regard for memorability, simply assign
the first 26 most heavily used commands each to a single letter of the
alphabet. Minimum typing, but hell to learn and remember!
I have seen no discussions about how to maximize memorability without
regard for bandwidth. How do we write a command language that is
really *easy* to learn and remember?
Not everyone wants to learn a command language that is optimized for
speed and brevity. To want to learn such a language, the investment
of time spent learning it must produce a day-to-day saving that is
worth it. It's not worth it to me to Huffman-encode my command
vocabulary to reduce the number of keystrokes to the absolute minimum!
Let us be careful to distinguish how command language is used
1) when you know how to do something, and
2) when you don't know how to do something.
When you know how to do something, you may be willing to learn an
encoding scheme (such as abbreviation, command-completion, adoption of
terse aliases) to make entering the known sequence of commands faster.
If you are willing to spend time memorizing an encoding scheme, it
doesn't much matter which one you choose. I think the type of scheme
used will depend on personal taste.
When you don't know exactly how to express your needs in terms of the
names of commands that will do the job for you, then you aren't at all
interested in fancy encodings. Your first objective is to get the
task done. Speeding it up can be learned later.
We all start life using command language in the second category. We
all find ourselves in the second category at some time, wondering just
what the name of that command was that did such-and-such. We know
*what* we want to do, but don't quite know *how*.
The few command languages I've seen (UNIX, Honeywell TSS, VM/CMS,
IBM/TSO, CP/M) seem to echo the sentiments of many people on this News
Network -- they are already semi-encoded for speed. They allow
abbreviations, and all kinds of neat stuff. But nobody has told me
what the design of the underling command language is. How am I to
remember even the unabbreviated command names?
I must insist that a language be designed to be easy to learn and
remember. I should be able to guess how to do things once I
understand the model. I see a lot of emphasis on abbreviations and
encodings that allow command language to be typed conveniently.
But, what is the underlying design of the language that everybody is
trying so very hard to abbreviate?
-IAN! U of Waterloo (decvax!watmath!idallen)
------------------------------
Date: 4 Aug 82 9:03:36-PDT (Wed)
From: decvax!ucbvax!G.wing at Ucb-C70
Subject: Re: Bandwidth, encodings, abbreviations and command language.
To make a rebuttal to the last news item posted on this subject from
ARPAVAX:CSVAX:mhtsa!eagle!harpo!decvax!utzoo!watmath!idallen :
The command language for VAX/VMS IS memorable, at least to a point.
Some things are a little weird, i.e. using a command file, deleting
something from a queue, but are for the most part memorable. The help
system on here is somewhat cryptic, but it is pretty good and has fast
response, unlike "man." One main reason for the site I am at (not
Populi, but RIX) chose VAX/VMS is that it DOES have a more human
oriented command language that one can understand. Another reason was
that some of the possibily better system available when this system
was booted up for the first time were not available for VAX-11/780's.
And, by the way, I didn't miss your point, you missed mine... Live
Long And Prosper, and May The Force Be With You.
The One And Only,
Philip L. Wing
U.C. at Berkeley
ETA Region IX/DOL
P.S. If you know how to send stuff by mail to the Lawerence Berkeley
Laboratory Vax/Unix, you could probably bounce something to RIX. My
account name there is the same as here...
------------------------------
Date: 2 Aug 1982 1035-EDT
Subject: Comment on NSF Report
From: PHORWITZ at BBNG
Why do forecasters have such unquestioning faith in the tenet
that communication is going to replace transportation, e.g. with
respect to work habits? If there is any group of professionals who
are NOT required to travel to a central location in order to get their
work done, surely it is the programmers. Their work habits are
perforce quite solitary, many have (or could have) access to home
terminals, and as a group they are presumably less intimidated than
most by the technology. Yet in my experience very few programmers
actually take advantage of this golden opportunity to stay away from
their place of work for weeks or months at a time. Evidently, the
higher bandwidth links associated with face-to-face communications
(which make possible the process known to ordinary humans as
"socialization") have a perceived value greater than the costs of
commuting to work.
Paul
------------------------------
Date: 3 Aug 1982 2100-MDT
From: Walt <Haas at UTAH-20>
Subject: Educational Gap
Someone recently suggested in H-N that our society was forming a
division between those who understood computers and those who didn't.
The point is apparently well taken. The August 1982 @i[Scientific
American] contains an article (in the @i[Science and the Citizen]
section, p. 64) which reads in part:
"The education in science and mathematics that American students get
in elementary school, junior high school and high school has declined
in both quality and quantity in the past decade. The decline may have
become severe enough to affect the capacity of American society to
produce a competent labor force... the future of scientific education
may be bleaker than its present. Between 1971 and 1980 the number of
candidates training to become mathematics teachers decreased by 77
percent; the number training to become science teachers decreased by
65 percent... the decline in science education, although widespread,
has not been uniform. It is the education of lower-middle-class and
working-class children that appears to suffer the most. Indeed, the
education received by an elite of middle-class students seems to have
improved in the past decade. [Paul D.] Hurd [of Stanford University]
noted that test scores of children of couples who live in the suburbs
and have had at least some college education showed little decline in
the past decade. Furthermore, the number of students taking
advanced-placement examinations in science and mathematics increased
from 24,000 to 50,000 between 1969 and 1979, and the average scores
increased in each of those years..."
------------------------------
Date: 19 Jul 1982 08:05:51-PDT
From: allegra!rba at Berkeley
Subject: Call for Papers
CALL FOR PAPERS
The Association for Computing Machinery announces a new quarterly
acm Transactions on Office Information Systems
(TOOIS)
John Limb, Editor-in-Chief
SCOPE:
Significant and original work on analysis, design, specifications,
implementation, and experience concerning all aspects of office
information systems, including:
communication systems
data management
distributed processing
office organization
user interfaces.
SECTIONS:
TOOIS will contain the following sections:
Research Contributions
Practice and Experience
Technical Correspondence
FREQUENCY:
Quarterly. First issue dated early 1983. Projected content:
400 pages annually.
Send four copies of all papers to:
John Limb
MH 3D-479
Bell Laboratories
600 Mountain Avenue
Murray Hill, NJ 07974
------------------------------
End of HUMAN-NETS Digest
************************