Another nice summary of Bell Lab work was found in Daemon News 1999/03 - A History of UNIX before Berkeley- UNIX ...
3.2 roff
Having a good text editor is only half the text processing battle. Having entered your text, you still must format it neatly for presentation. That's the function of a text-formatting program. The earliest UNIX formatter known to man is roff, a line-command formatter. Like ed, roff is part of a large and diverse family, one that includes the runoff package found on Digital Equipment computers (the latest release is called DSR, for DEC Standard Runoff). The earliest Runoff program is attributed by Kernighan and Plauger to J. Saltzer, who wrote it for CTSS. Runoff also is an ancestor of the Script programs available on IBM mainframe systems; that descent would be equally interesting for IBMers to trace (no doubt we'll get letters from those with information to SHARE with us).
Roff was written by M. D. McIlroy, at Research. Like ed, roff was well in place by the First Edition of UNIX. It was considered static by the time of the Sixth Edition, regarded as obsolescent by the time of the Seventh, and dropped altogether by the time of System III.
3.3 nroff and troff - The assembler of text
Computerists are never satisfied. So after roff came ``New Roff'', or nroff, written by the late Joseph Ossanna, who throughout his career was concerned with improving the way text was handled. Ossanna's nroff, as Kernighan and Pike relate,
``was much more ambitious [than roff]. Rather than trying to provide every style of document that users might ever want, Ossanna made nroff programmable, so that many formatting tasks were handled by programming in the nroff language.
``When a small typesetter was acquired in 1973, nroff was extended to handle the multiple sizes and fonts and the richer character set that the typesetter provided. The new program was called troff (which by analogy to ``en-roff'' is pronounced ``tee-roff''). nroff and troff are basically the same program...'' with divergent processing appropriate to the differences in output device. [UNIX Programming Environment, page 289]
They point out that troff is tremendously flexible, and indeed many computer books have been typeset using it. But it can be complex to use. As a result, most everyone uses one or another ``macro package'' - a series of pre-programmed commands - and optionally one of the preprocessors (such as eqn, tbl, refer, and more recently pic, grap and ideal). Troff was originally written in assembler, but was redone in C in 1975. Joseph Ossanna wrote both versions and maintained it until his death in 1977.
3.4 Macro Packages
The earliest macro package to come into wide use was ``ms'', for ``manuscript''[Lesk1977a]. Written by Mike Lesk, the ms macros provide a powerful but easy-to-learn (by comparison with bare nroff) approach to document formatting. The ms macros were distributed with the Sixth and Seventh Edition UNIX and most subsequent releases. The package was picked up and extended at Berkeley.
The USG versions of UNIX include a macro package called `mm', for ``memorandum macros''[Dolo1978a]. These do most of the same things as ms, in slightly different ways, with the addition of numbered lists and a few other bells and whistles, but are about half again as big as ms. The startup time is such with mm that USG in 1979 had to resort to a compacted form of the macro packages; this made it into System III.
There are two versions of the `man' macro package used to format the manual pages in Volume 1 of the UNIX Manual Set. One was used on V6, and the other from V7 on. If you see a manual page beginning with `.th' instead of `.TH', it's from V6. System III has an (undocumented) command mancvt, and 4.1BSD had trman, to convert files from the old to the new format.
There is also the `mv' macros for producing viewgraph or slide presentations. This is a USG product, and versions of the USG manuals from PWB 1 up to just before System III carried the now-famous line:
The PWB/UNIX document entitled: PWB/UNIX View Graph and Slide Macros is not yet available.
System III manuals appeared with scarcely a mention of mv, and (finally) it was documented with the System V manuals.
3.5 tbl, eqn, refer
One view of troff is as an assembler language for text processing. If this be true, then eqn, tbl, refer and later preprocessors are the high-level compilers that go with it.
Mathematics has always been an inconvenience to traditional typesetting. This observation led Brian Kernighan and Lorinda Cherry to develop eqn for UNIX, and would later lead Donald Knuth to write his TeX typesetting package with math capabilities built in.
The eqn program reads an entire nroff/troff input file and passes it unchanged except for ``equation specifications'' delimited by .EQ and .EN requests (or pairs of delimiter characters for in-line equations). Material inside these requests is used to construct equations of considerable complexity from simple input. English words such as `sum', `x sub i', and 'infinity' produce the expected results (a large Sigma, x with a subscript i, and the infinity symbol respectively). In most cases no typesetter wizardry is required. A list of some forty extra character definitions lives in the file /usr/pub/eqnchar; these can be copied, extended, or altered by the knowledgeable user.
Eqn was written by Brian Kernighan and Lorinda Cherry. The ``new graphic symbols'' in /usr/pub/eqnchar are the work of Carmela L'Hommedieu (formerly Scrocca) at Bell Labs. The first public write-up of eqn appears to be a paper by Kernighan and Cherry in the CACM, March 1975[Kern1975a]. The software was included in the Sixth Edition UNIX.
Like eqn, tbl is a preprocessor that passes over a formatter input file looking for special requests (here .TS and .TE)[Lesk1976a]. The material between these requests is expected to be a series of special commands to tbl and some tabular data. To greatly over-simplify how this program works, tbl replaces tab characters with explicit horizontal and vertical moves to make the rows and columns in the table align exactly under control of the table specification. It is invaluable for putting tabular material of any kind into documents.
Mike Lesk wrote tbl at Research; the idea for it came from an earlier table formatting program by J. F. Gimpel. Tbl first appeared outside the Labs with the V6 release of UNIX. It appeared in its present form on the ``Phototypesetter Version 7'' (interim V7) and PWB tapes, in Seventh Edition UNIX distributions, and in all systems since then.
Lesk also wrote refer[Lesk1978a], a bibliographic citation and reference package, which first appeared in V7. Regrettably, not all UNIX distributions picked it up (like Lesk's tbl, refer contained many bugs, some of which manifested as core dumps on various architectures; that probably didn't help, though there have also been strong rumors that AT&T didn't want to distribute any form of software incorporating indices, notably the V7 dbm library, in order to leave a market for third-party data base companies). It incorporates knowledge of how to format citations and can produce from an approximate citation a footnote (or reference) mark and a formal citation as a footnote or reference at the end. Once you build up (or copy) a large collection of references, this is very handy. If your system doesn't come with refer, grefer can be found in the groff distribution.
3.6 Typesetter Independent troff
New! Improved! Yet again! That's right. troff is infinitely perfectible. In 1979, Brian Kernighan at Research set out to re-write troff. Rather than rewrite it completely and be incompatible with the tens or hundreds of thousands of documents in existence, he chose to ``clean up'' troff. It turned out to be rather more akin to cleaning the Augean Stables than he had imagined, but resolve did not desert Kernighan. Finally he emerged with a tape for the Typesetter-Independent (later dubbed ``Device-Independent'', to avoid a sexually-charged acronym) troff[Kern1982a], along with revised tbl/eqn/refer and two new preprocessors, pic and Chris Van Wyk's ideal[Kern1981a]. The new ditroff produced output that is readable ASCII containing a low-level description of the commands needed to drive a typesetter; this `intermediate language' is fed to a particular post-processor to generate the particular commands needed to drive a typesetter. Pic (as the name implies) does pictures. It is useful for drawing ``flow-chart''-like drawings, but there is much more to it than that. Ideal also draws pictures, but is somewhat more mathematical in usage than is pic.
This set of products formed the basis of the commercialized ``Documentor's Workbench'' package from AT&T. And work continues, of course. Kernighan has been working on cleaning up the appearance of eqn output. Recently, Kernighan and John Bentley have written grap, a graph plotting preprocessor for pic. The program was released with Release 2 of Documentor's WorkBench, released in early 1986. A report on grap is also available from Bell Laboratories as a CSTR[Bent1984a].
3.7 Troff in the outside world
Several Universities have further developed troff. Since these are changing all the time, it is not feasible to mention them all here. A future issue of the USENIX journal ;login: will contain a summary of this work.
Many companies picked up the commercial (binary sublicense) release of Documentor's WorkBench. As a result one can now purchase this product in binary-only form for most any UNIX computer. Most of these ``troff houses'' have added post-processors for specific output devices; few have made substantial change to the main program. One of the authors (Darwin) was employed at SoftQuad in the mid-1980's, then believed to be the only company doing serious development on troff internals (AT&T had no developers assigned to the product). SoftQuad had drastically changed the intermediate language devised by Kernighan. It is now more readable and more amenable to additional processing with the UNIX software tools than is the standard ditroff. Most troff houses support the common output devices (in 1986 this means the Apple LaserWriter® and other PostScript® printers, Imagen imPRESS® printers, the Hewlett-Packard LaserJet®, and other devices; by the mid 1990's it means PostScript and HP).
A few attempts have been made to port Documentor's WorkBench to non-UNIX environments. Both SoftQuad and Elan Systems have an MS-DOS port of complete DWB. Other companies (including Image Network) have ported the product to Digital Equipment's VMS system. But the main usage of troff continues to be on UNIX.
3.8 Of Mice and Blits
Tired of typing at a dull, boring 24×80 screen, Rob Pike and Bart Locanthi had a better idea. Integrating the ideas of the Alto project and related work at Xerox PARC (Palo Alto Research Center) with the UNIX approach to things, they built a special terminal called the Blit[Pike1985a, Pike1984a, Carg1984a] (not an acronym) with a Motorola 68000 processor, high-resolution screen, good keyboard, a fabulous mouse, and software split between the host and the terminal. Their particular combination of these ingredients makes possible a form of interaction with the computer that was years ahead of its time. Pike, in addition to being a radical advocate of the UNIX approach to software development, is quite visionary. Some of his work was described at recent (1980's) USENIX conferences. Sadly, large parts of the audience didn't seem to grasp the essentials of what he was saying. Some of the same ideas are of course found in other bit-mapped screen environments, such as the SUN workstation and The X Window System, in somewhat different forms.
Blits were available only inside AT&T, mostly in Bell Labs, although a few have been released to selected Universities. The Blit has been commercialized by AT&T/Teletype, and was sold (with a different microprocessor) as the AT&T DMD 5620 terminal.
(More recently, much of this work has been consolidated into an operating system called Plan 9 From Bell Laboratories.)[Pike1990a, Pike1995a]
3.9 Style, Diction, Writer's Workbench
One of the authors (Darwin) has long been interested in the computerized processing of text, a term I take to mean more than is commonly included as ``word processing.'' So I was quite interested to read a paper by L. E. McMahon, Lorinda L. Cherry and R. Morris entitled ``Statistical Text Processing'' in the 1978 special BSTJ issue on UNIX[McMa1978a]. I would later use several of the techniques mentioned in the paper.
At the end of the paper, Ms. Cherry describes a program parts for finding parts of speech in English text. This was written to be the first pass of a system to add inflection to the speak program written by Doug McIlroy, but the person doing the stress part left the company. Ms. Cherry wasn't interested in the stress assignment, so she documented the work done so far and went on to other things.
In the spring of 1979, W. Vesterman of Rutgers approached Doug McIlroy at Research about computerizing one of the techniques Vesterman used in teaching writing. The students had to count surface features in their text and in a sample of text written by a professional writer. That summer, Ms. Cherry expanded parts considerably, and added the code that turned it into style, a program to analyse the readability and other characteristics of a textual document. She also developed diction to check for awkward word uses, over-used words, and other problems facing everyone who composes text for others to read. She also modified deroff to find the real text in a document. Vesterman consulted on this work.
And when the 4.1BSD release of the system came out, I was pleasantly surprised to see that style and diction were present[Cher1981a]. Bell Labs has a policy of sometimes releasing software to educational institutions; this probably explains the release at Berkeley.
While this was going on, the Human Factors group at Piscataway (now at Summit) was getting interested in automating document review, and Nina Macdonald of that group called Ms. Cherry about using parts. She had worked at Murray Hill in a Linguistics group and was familiar with the program. Ms. Macdonald took style and diction, and WWB evolved from there. Writer's Workbench (WWB) consists of style, diction and a dozen or so related programs for finding problems in written work. The ``chattiness'' level of the programs is set for the beginning user, but can easily be adjusted by the advanced user. The ideas for this work came from the Piscataway group, the Murray Hill group, and from Colorado State University, where extensive use of the Writer's Workbench (described at USENIX, Toronto, July 1983) currently puts several thousand undergraduates on WWB each year. The use of WWB is perceived to improve significantly the students' writing skills.
Many writers will be thankful to all who contributed, because these programs have proven themselves useful many times over. If buying a 4.1 or 4.2BSD system, insist on style and diction. If you get a System V UNIX, consider getting the WWB add-on if you'll be doing any document preparation. Writer's Workbench is one product that should survive and prosper as UNIX continues to evolve. The next major release of WWB (3.0) was scheduled for the spring of 1985.
About two-thirds of this book concerns Knuth's experiences writing a book entitled "3:16." Knuth decided to study the Bible through a sort of stratified random sample: taking Chapter 3, verse 16 from each book of the Bible and studying it in depth. These discussions do have their interest, but I do not feel that "Things A Computer Science Rarely Talks About" really stands on its own.
A better title for this book would have been something like "3:16: The Story Behind The Book." See
TechNetCast - MIT God and Computers Lecture Series Donald Knuth
Consider chapter 4. This is mostly a series of stories about how Knuth and Herrmann Zapf asked many of the world's leading calligraphers to illuminate the verses he used. He talks about the suble colors used to print them, the delicacy of the originals (not fully picked up by a 600 dpi scanner and requiring pixel-level editing to prepare them for reproduction). It therefore can only be described as irritating to be presented with these pictures, about fifty of them, in the form of little 2x3" halftone reproductions.
I do not feel the book delivers much on the promise that Knuth will reveal "the many insights that [he] gained" from the work. He talks a good deal about the reasoning and the process behind the project and it is quite interesting, perhaps even inspiring in the sense of making one wish to do likewise. But his presentation of his own beliefs is rather muted and low-key. I perceive this as modesty, not evasion. Still, it is not what I expected. Consider chapter 4, again: we learn a great deal about how he feels about the esthetics of the calligraphy, how he edited them, how he dealt with issues like calligraphers who inadvertently made mistakes in the text. But are there really any religious insights here? Well, subtle ones, perhaps.
I think he is sincere when he says, referring to "3:16," "I am not here today to sell copies of the book." In a discussion, someone asks "What would you recommend for computer science students who have never read the Bible?" and I believe Knuth is joking when he says "The number one recommendation is that they should certainly read my book. You know, it makes a wonderful Christmas gift. More seriously..."
Chapters 5 ("Glimpses of God") and 6 ("God And Computer Science") are fascinating, and come close to delivering on the promise of the book. I would gladly read a book-length expansion of this material in these two chapters.
Still, on finishing this book, I am aware of two feelings: a) an interest in reading "3:16," and b) an irritation with myself for
having purchased this one.
A
unique and intimate portrait of the Bible., January 13, 2002
Reviewer: A reader from New York, New York
From his idiosyncratic perspective as a computer scientist, Knuth presents an aesthetically pleasing and intellectually inviting commentary
of the 3:16's.
In this day and age of technological sophistication, it is so courageous that a scientist and scholar of Knuth's stature can say "it's tragic that scientific advances have caused many people to imagine that they know it all, and that God is irrelevant or nonexistent. The fact is that everything we learn reveals more things that we do not understand... Reverence for God comes naturally if we are honest about how little we know." [1]
Knuth is candid about what he knows as well as what he doesn't know and he presents his views in a non-judgemental, introspective manner. For example, Knuth is surely including himself when he states "God sees the rottenness, deceit, and hypocrisy in every one of us..." [2] Furthermore, there are rare glimpses into Knuth the man as he unabashedly says what he feels. To illustrate, Knuth describes his thoughts about his own mortality and how he felt when his father died. [3]
Ultimately, this book is Knuth's solemn and joyous celebration of his relationship with God. But don't let the elegance of the artwork or the relative brevity of the commentary fool you into thinking this book is merely easy on the eyes. The Christian will find this an uplifting and spiritually challenging study, while the unbeliever will discover the richness of the 3:16's and why Knuth finds the Bible is relevant to everyday life.
Knuth is a consummate craftsman and this is a towering work of biblical scholarship, an enduring exegetical legacy for the ages.
Quotes and references from book:
[1] Proverbs 3:16 study
[2] Romans 3:16 study
[3] Job 3:16 study
Was this review helpful to you? 
7 of 10 people found the following review helpful:
We
Are Not Worthy!, August 17, 2000
Reviewer: A reader from Sim City, CA (Somewhere in the South Bay)
In the well-rounded, whimsical, yet diligent style that is so characteristic for all of his work, Knuth has given us a small stochastico-theologico-typographical
masterpiece.
This work shows Knuth's authorship to an extent that even medieval monks could only dream of: He not only wrote the exegeses, but he translated each of the 59 verses of the bible he picked from the original Hebrew or Greek; he picked 59 illustrators to illuminate the verses; he wrote the software that controls the placement of each character on the pages of the book, and he wrote the software that controls the bits for each character of the book.
This book is by no means Knuth's most important contribution to humankind, but if it were the only one of his works to reach posterity, it would still suffice to show him as the compassionate and inspired genius that he is.
closest
thing to a miracle in our times, December 20, 1997
Reviewer: A reader from Pasadena, California
Zapf + Knuth. Two of the best in their fields came together and made a book about the best of books. Knuth really dedicated himself
in writing this book, and the result is clearly superb: I was compelled to say Amen at the turning of every few pages. He also presented
the material in a jargon-free way, keeping it relevant to the modern world. If you miss the days when scientists and artists unabashedly
manifest their great faith in the Lord, this is the book to get.
In the well-rounded, whimsical, yet diligent style that is so characteristic for all of his work, Knuth has given us a small stochastico-theologico-typographical masterpiece.
This work shows Knuth's authorship to an extent that even medieval monks could only dream of: He not only wrote the exegeses, but he translated each of the 59 verses of the bible he picked from the original Hebrew or Greek; he picked 59 illustrators to illuminate the verses; he wrote the software that controls the placement of each character on the pages of the book, and he wrote the software that controls the bits for each character of the book.
This book is by no means Knuth's most important contribution to humankind, but if it were the only one of his works to reach posterity, it would still suffice to show him as the compassionate and inspired genius that he is.
The book 3:16, Bible Texts Illuminated combines Don Knuth's life-long interest in Bible study, typography, and art. For each of the 59 books of the Bible with at least 16 verses starting at Chapter 3, verse 1, that book is selected for a chapter. Each lesson has four pages. The first page summarizes the book and its historical context. The second page contains an illustration of the sampled verse, The third page gives the text of that verse and discusses it on that page and the fourth, relating it to other Bible references, other translations, and the original languages from which translations have been made. In some cases his original translations are used.
Each of the illustrations is done by a different one of the world's leading calligraphers.
The book, and also a poster containing those illustrations, is available from A-R Editions, Inc.
The book 3:16, Bible Texts Illuminated is a marriage of profound Biblical insights, exquisite calligraphy, and balanced page typography - "a treat for the mind, the eyes, and the spirit."
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Oct 13, 2019 | www.quora.com
Eugene Miya , A friend/colleague. Sometimes driver. Other shared experiences. Updated Mar 22 2017 · Author has 11.2k answers and 7.9m answer views
He mostly writes in C today.
I can assure you he at least knows about Python. Guido's office at Dropbox is 1 -- 2 blocks by a backdoor gate from Don's house.
I would tend to doubt that he would use R (I've used S before as one of my stat packages). Don would probably write something for himself.
Don is not big on functional languages, so I would doubt either Haskell (sorry Paul) or LISP (but McCarthy lived just around the corner from Don; I used to drive him to meetings; actually, I've driven all 3 of us to meetings, and he got his wife an electric version of my car based on riding in my car (score one for friend's choices)). He does use emacs and he does write MLISP macros, but he believes in being closer to the hardware which is why he sticks with MMIX (and MIX) in his books.
Don't discount him learning the machine language of a given architecture.
I'm having dinner with Don and Jill and a dozen other mutual friends in 3 weeks or so (our quarterly dinner). I can ask him then, if I remember (either a calendar entry or at job). I try not to bother him with things like this. Don is well connected to the hacker community
Don's name was brought up at an undergrad architecture seminar today, but Don was not in the audience (an amazing audience; I took a photo for the collection of architects and other computer scientists in the audience (Hennessey and Patterson were talking)). I came close to biking by his house on my way back home.
We do have a mutual friend (actually, I introduced Don to my biology friend at Don's request) who arrives next week, and Don is my wine drinking proxy. So there is a chance I may see him sooner.
Steven de Rooij , Theoretical computer scientist Answered Mar 9, 2017 · Author has 4.6k answers and 7.7m answer views
Nice question :-)
Don Knuth would want to use something that’s low level, because details matter . So no Haskell; LISP is borderline. Perhaps if the Lisp machine ever had become a thing.
He’d want something with well-defined and simple semantics, so definitely no R. Python also contains quite a few strange ad hoc rules, especially in its OO and lambda features. Yes Python is easy to learn and it looks pretty, but Don doesn’t care about superficialities like that. He’d want a language whose version number is converging to a mathematical constant, which is also not in favor of R or Python.
What remains is C. Out of the five languages listed, my guess is Don would pick that one. But actually, his own old choice of Pascal suits him even better. I don’t think any languages have been invented since was written that score higher on the Knuthometer than Knuth’s own original pick.
And yes, I feel that this is actually a conclusion that bears some thinking about. 24.1k views ·
Dan Allen , I've been programming for 34 years now. Still not finished. Answered Mar 9, 2017 · Author has 4.5k answers and 1.8m answer views
In The Art of Computer Programming I think he'd do exactly what he did. He'd invent his own architecture and implement programs in an assembly language targeting that theoretical machine.
He did that for a reason because he wanted to reveal the detail of algorithms at the lowest level of detail which is machine level.
He didn't use any available languages at the time and I don't see why that would suit his purpose now. All the languages above are too high-level for his purposes.
|
|
|
Sep 07, 2019 | archive.computerhistory.org
Knuth: Yeah. That's absolutely true. I've got to get another thought out of my mind though. That is, early on in the TeX project I also had to do programming of a completely different type. I told you last week that this was my first real exercise in structured programming, which was one of Dijkstra's huge... That's one of the few breakthroughs in the history of computer science, in a way. He was actually responsible for maybe two of the ten that I know.
So I'm doing structured programming as I'm writing TeX. I'm trying to do it right, the way I should've been writing programs in the 60s. Then I also got this typesetting machine, which had, inside of it, a tiny 8080 chip or something. I'm not sure exactly. It was a Zilog, or some very early Intel chip. Way before the 386s. A little computer with 8-bit registers and a small number of things it could do. I had to write my own assembly language for this, because the existing software for writing programs for this little micro thing were so bad. I had to write actually thousands of lines of code for this, in order to control the typesetting. Inside the machine I had to control a stepper motor, and I had to accelerate it.
Every so often I had to give another [command] saying, "Okay, now take a step," and then continue downloading a font from the mainframe.
I had six levels of interrupts in this program. I remember talking to you at this time, saying, "Ed, I'm programming in assembly language for an 8-bit computer," and you said "Yeah, you've been doing the same thing and it's fun again."
You know, you'll remember. We'll undoubtedly talk more about that when I have my turn interviewing you in a week or so. This is another aspect of programming: that you also feel that you're in control and that there's not a black box separating you. It's not only the power, but it's the knowledge of what's going on; that nobody's hiding something. It's also this aspect of jumping levels of abstraction. In my opinion, the thing that computer scientists are best at is seeing things at many levels of detail: high level, intermediate levels, and lowest levels. I know if I'm adding 1 to a certain number, that this is getting me towards some big goal at the top. People enjoy most the things that they're good at. Here's a case where if you're working on a machine that has only this 8-bit capability, but in order to do this you have to go through levels, of not only that machine, but also to the next level up of the assembler, and then you have a simulator in which you can help debug your programs, and you have higher level languages that go through, and then you have the typesetting at the top. There are these six or seven levels all present at the same time. A computer scientist is in heaven in a situation like this.
Feigenbaum: Don, to get back, I want to ask you about that as part of the next question. You went back into programming in a really serious way. It took you, as I said before, ten years, not one year, and you didn't quit. As soon as you mastered one part of it, you went into Metafont, which is another big deal. To what extent were you doing that because you needed to, what I might call expose yourself to, or upgrade your skills in, the art that had emerged over the decade-and-a-half since you had done RUNCIBLE? And to what extent did you do it just because you were driven to be a programmer? You loved programming.
Knuth: Yeah. I think your hypothesis is good. It didn't occur to me at the time that I just had to program in order to be a happy man. Certainly I didn't find my other roles distasteful, except for fundraising. I enjoyed every aspect of being a professor except dealing with proposals, which I did my share of, but that was a necessary evil sort of in my own thinking, I guess. But the fact that now I'm still compelled to I wake up in the morning with an idea, and it makes my day to think of adding a couple of lines to my program. Gives me a real high. It must be the way poets feel, or musicians and so on, and other people, painters, whatever. Programming does that for me. It's certainly true. But the fact that I had to put so much time in it was not totally that, I'm sure, because it became a responsibility. It wasn't just for Phyllis and me, as it turned out. I started working on it at the AI lab, and people were looking at the output coming out of the machine and they would say, "Hey, Don, how did you do that?" Guy Steele was visiting from MIT that summer and he said, "Don, I want to port this to take it to MIT." I didn't have two users.
First I had 10, and then I had 100, and then I had 1000. Every time it went to another order of magnitude I had to change the system, because it would almost match their needs but then they would have very good suggestions as to something it wasn't covering. Then when it went to 10,000 and when it went to 100,000, the last stage was 10 years later when I made it friendly for the other alphabets of the world, where people have accented letters and Russian letters. <p>I had started out with only 7-bit codes. I had so many international users by that time, I saw that was a fundamental error. I started out with the idea that nobody would ever want to use a keyboard that could generate more than about 90 characters. It was going to be too complicated. But I was wrong. So it [TeX] was a burden as well, in the sense that I wanted to do a responsible job.
I had actually consciously planned an end-game that would take me four years to finish, and [then] not continue maintaining it and adding on, so that I could have something where I could say, "And now it's done and it's never going to change." I believe this is one aspect of software that, not for every system, but for TeX, it was vital that it became something that wouldn't be a moving target after while.
Feigenbaum: The books on TeX were a period. That is, you put a period down and you said, "This is it."
|
|
|
Sep 06, 2019 | archive.computerhistory.org
...I showed the second version of this design to two of my graduate students, and I said, "Okay, implement this, please, this summer. That's your summer job." I thought I had specified a language. I had to go away. I spent several weeks in China during the summer of 1977, and I had various other obligations. I assumed that when I got back from my summer trips, I would be able to play around with TeX and refine it a little bit. To my amazement, the students, who were outstanding students, had not competed [it]. They had a system that was able to do about three lines of TeX. I thought, "My goodness, what's going on? I thought these were good students." Well afterwards I changed my attitude to saying, "Boy, they accomplished a miracle."
Because going from my specification, which I thought was complete, they really had an impossible task, and they had succeeded wonderfully with it. These students, by the way, [were] Michael Plass, who has gone on to be the brains behind almost all of Xerox's Docutech software and all kind of things that are inside of typesetting devices now, and Frank Liang, one of the key people for Microsoft Word.
He did important mathematical things as well as his hyphenation methods which are quite used in all languages now. These guys were actually doing great work, but I was amazed that they couldn't do what I thought was just sort of a routine task. Then I became a programmer in earnest, where I had to do it. The reason is when you're doing programming, you have to explain something to a computer, which is dumb.
When you're writing a document for a human being to understand, the human being will look at it and nod his head and say, "Yeah, this makes sense." But then there's all kinds of ambiguities and vagueness that you don't realize until you try to put it into a computer. Then all of a sudden, almost every five minutes as you're writing the code, a question comes up that wasn't addressed in the specification. "What if this combination occurs?"
It just didn't occur to the person writing the design specification. When you're faced with implementation, a person who has been delegated this job of working from a design would have to say, "Well hmm, I don't know what the designer meant by this."
If I hadn't been in China they would've scheduled an appointment with me and stopped their programming for a day. Then they would come in at the designated hour and we would talk. They would take 15 minutes to present to me what the problem was, and then I would think about it for a while, and then I'd say, "Oh yeah, do this. " Then they would go home and they would write code for another five minutes and they'd have to schedule another appointment.
I'm probably exaggerating, but this is why I think Bob Floyd's Chiron compiler never got going. Bob worked many years on a beautiful idea for a programming language, where he designed a language called Chiron, but he never touched the programming himself. I think this was actually the reason that he had trouble with that project, because it's so hard to do the design unless you're faced with the low-level aspects of it, explaining it to a machine instead of to another person.
Forsythe, I think it was, who said, "People have said traditionally that you don't understand something until you've taught it in a class. The truth is you don't really understand something until you've taught it to a computer, until you've been able to program it." At this level, programming was absolutely important
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: February 19, 2020
