Licklider on April 25th, 1963: an intergalatic network of computers

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:, or follow me on Twitter.

An observation and a question:

1.) It’s impressive that his focus is on software-as-a-service rather than the sending of documents. In that sense, the arrival of the Internet in the 1970s was a step backwards. TCP/IP focuses too much on documents.

2.) Why was it so difficult for people to grasp the notion of sending data over the network, instead of code? If you include the endless efforts in the 1980s and 1990s and early 00s to send objects over the network, the notion that we should only send data didn’t fully arrive till 2005. Why is that?

It is amazing to see the tentative outlines of the Internet as they first begin to appear:

Dictating the foregoing paragraph led me to see more
clearly than I had seen it before that the problem of
achieving homogeneity within a set of correlated languages
is made difficult by the fact that there will be, at a
given time, only one time-sharing system in operation on a
given computer, whereas more than one programming language
with its associated debugging language may be
simultaneously in use. The time-sharing control language
can be highly correlated only with one programming and
debugging language pair. Insofar as syntax is concerned,
therefore, it seems that it may be necessary to have a
“preferred” language for each computer facility or system,
and to have the time-sharing control language be consistent
with the preferred. Insofar as semantics is concerned–or,
at least, insofar as the association of particular symbols
with particular control functions is concerned–I see that
it would be possible, thought perhaps inconvenient, to
provide for the use, by several different operators, of
several different specific vocabularies. Anyway, there
seems to me to be a problem, or a set of problems, in this
There is an analogous problem, and probably a more
difficult one, in the matter of language for the control of
a network of computers. Consider the situation in which
several different centers are netted together, each center
being highly individualistic and having its own special
language and its own special way of doing things. Is it not
desirable, or even necessary for all the centers to agree
upon some language or, at least, upon some conventions for
asking such questions as “What language do you speak?” At
this extreme, the problem is essentially the one discussed
by science fiction writers: “how do you get communications
started among totally uncorrelated “sapient” beings?” But,
I should not like to make an extreme assumption about the
uncorrelatedness. (I am willing to make an extreme
assumption about the sapience.) The more practical set of
questions is: Is the network control language the same
thing as the time-sharing control language? (If so, the
implication is that there is a common time-sharing control
language.) Is the network control language different from
the time-sharing control language, and is the networkcontrol language common to the several netted facilities?
Is there no such thing as a network-control language? (Does
one, for example, simply control his own computer in such a
way as to connect it into whatever part of the alreadyoperating net he likes, and then shift over to an
appropriate mode?)
In the foregoing paragraphs, I seem to have leapt into the
middle of complexity. Let me approach from a different
starting point. Evidently, one or another member of this
enterprise will be preparing a compiler, or compilers, for
modifying existing programs that compile FORTAN [sic.],
JOVIAL, ALGOL, LISP and IPL-V (or V-l, or V-ll). If there
is more than one of any one of the foregoing, or of any one
of others that I do not foresee, then it seems worthwhile
to examine the projected efforts for compatibility.
Moreover, to me, at least, it seems desirable to examine
the projected efforts to see what their particular features
are, and to see whether there is any point in defining a
collection of desirable features and trying to get them all
into one language and one system of compilers. I am
impressed by the argument that list-structure features are
important as potential elements of ALGOL or JOVIAL, that we
should think in terms of incorporating list-structure
features into existing languages quite as much as in terms
of constructing languages around list-structures.
It will possibly turn out, I realize, that only on rare
occasions do most or all of the computers in the overall
system operate together in an integrated network. It seems
to me to be interesting and important, nevertheless, to
develop a capability for integrated network operation. If
such a network as I envisage nebulously could be brought
into operation, we would have at least four large
computers, perhaps six or eight small computers, and a
great assortment of disc files and magnetic tape units–not
to mention the remote consoles and teletype stations–all
churning away. It seems easiest to approach this matter
from the individual user’s point of view–to see what he
would like to have, what he might like to do, and then to
try to figure out how to make a system within which his equirements can be met. Among the things I see that a user
might want to have, or to do, are the following:
(Let me suppose that I am sitting at a console that
includes a cathode-ray-tube display, light-pen, and a
typewriter.) I want to retrieve a set of experimental data
that is on a tape called Listening Test. The data are
called “experiment 3.” These data are basically percent-
ages for various signal-to-noise ratios. There are many
such empirical functions. The experiment had a matrix
design, with several listeners, several modes of
presentation, several signal frequencies, and several
durations. I want, first, to fit some “theoretical” curves
to the measured data. I want to do this in a preliminary
way to find out what basic function I want to choose for
the theoretical relation between precentage [sic.] and
signal-to-noise ratio. On another tape, called “Curve
Fitting,” I have some routines that fit straight lines,
power functions, and cumulative normal curves. But, I want
to try some others, also. Let me try, at the beginning, the
functions for which I have programs. The trouble is, I do
not have a good grid-plotting program. I want to borrow
one. Simple, rectangular coordinates will do, but I would
like to specify how many divisions of each scale there
should be and what the labels should be. I want to put that
information in through my typewriter . Is there a suitable
grid-plotting program anywhere in the system? Using
prevailing network doctrine, I interrogate first the local
facility, and then other centers. Let us suppose that I am
working at SDC, and that I find a program that looks
suitable on a disc file in Berkeley. My programs were
written in JOVIAL.
The programs I have located through the system were written
in FORTRAN. I would like to bring them in as relocatable
binary programs and, using them as subroutines, from my
curve-fitting programs, either at “bring-in time” or at
Supposing that I am able to accomplish the steps just
described, let us proceed. I find that straight lines,
cubics, quintics, etc., do not provide good fits to the
data. The best fits look bad when I view them on the
oscilloscope.he fits of the measured data to the cumulative normal
curve are not prohibitively bad. I am more interested in
finding a basic function that I can control appropriately
with a few perimeters than I am in making contact with any
particular theory about the detection process, so I want to
find out merely whether anyone in the system has any curve-
fitting programs that will accept functions supplied by the
user or that happen to have built-in functions roughly like
the cumulative normal curve, but assymmetrical. Let us
suppose that I interrogate the various files, or perhaps
interrogate a master-integrated, network file, and find out
that no such programs exist. I decide, therefore, to go
along with the normal curve.

Post external references

  1. 1