From shoppa@altair.krl.caltech.edu Thu Oct 26 20:43:43 CDT 1995 Article: 120642 of alt.folklore.computers Xref: uchinews alt.folklore.computers:120642 comp.os.cpm:10932 Path: uchinews!ncar!elroy.jpl.nasa.gov!usc!math.ohio-state.edu!uwm.edu!fnnews.fnal.gov!nntp-server.caltech.edu!altair.krl.caltech.edu!shoppa From: shoppa@altair.krl.caltech.edu (Tim Shoppa) Newsgroups: comp.os.cpm,alt.folklore.computers Subject: Re: CP/M 3 source Date: 26 Oct 1995 03:26:07 GMT Organization: Kellogg Radiation Lab, Caltech Lines: 25 Message-ID: <46mv4f$29g@gap.cco.caltech.edu> References: <46mi7u$pri@mirv.unsw.edu.au> NNTP-Posting-Host: altair.krl.caltech.edu Keywords: CP/M 3 Status: RO In article <46mi7u$pri@mirv.unsw.edu.au>, Dr Henry Brancik wrote: > >In <461v2b$2eg@ixnews2.ix.netcom.com> dontar@ix.netcom.com (Donald E. Tarbell) >writes: >| >|I have a printed copy of the CP/M vs 3.0 source code. It was > ^^^^^^^^^^^^^^^^^^^^^^^ >|written in PL/M and assembly. >| >|Don Tarbell > >Just wondering, how and where did you get it? > > - Henry Brancik, My newsfeed's been spotty lately, so I must've missed Don Tarbell's post, but I must say that I am delighted to see that he's still around - that is, assuming he's the Don Tarbell who designed the cassette tape controller and disk controllers in my IMSAI's :-). And if it is the same Don Tarbell, then it wouldn't surprise me at all if he had the source code! Tim. (shoppa@altair.krl.caltech.edu) Kellogg Radiation Lab, Caltech. From dontar@ix.netcom.com Sat Nov 4 10:20:27 CST 1995 Article: 121675 of alt.folklore.computers Xref: uchinews alt.folklore.computers:121675 comp.os.cpm:11006 Path: uchinews!vixen.cso.uiuc.edu!uwm.edu!chi-news.cic.net!simtel!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!hodes.com!netcomsv!uu4news.netcom.com!netcomsv!uu3news.netcom.com!ix.netcom.com!netnews From: dontar@ix.netcom.com (Donald E. Tarbell ) Newsgroups: comp.os.cpm,alt.folklore.computers Subject: Re: CP/M 3 source Date: 3 Nov 1995 06:19:05 GMT Organization: Netcom Lines: 36 Message-ID: <47cc8p$c9@ixnews3.ix.netcom.com> References: <46mi7u$pri@mirv.unsw.edu.au> <46mv4f$29g@gap.cco.caltech.edu> NNTP-Posting-Host: ix-la25-25.ix.netcom.com X-NETCOM-Date: Thu Nov 02 10:19:05 PM PST 1995 Status: RO In <46mv4f$29g@gap.cco.caltech.edu> shoppa@altair.krl.caltech.edu (Tim Shoppa) writes: > >In article <46mi7u$pri@mirv.unsw.edu.au>, >Dr Henry Brancik wrote: >> >>In <461v2b$2eg@ixnews2.ix.netcom.com> dontar@ix.netcom.com (Donald E. Tarbell) >>writes: >>| >>|I have a printed copy of the CP/M vs 3.0 source code. It was >> ^^^^^^^^^^^^^^^^^^^^^^^ >>|written in PL/M and assembly. >>| >>|Don Tarbell >> >>Just wondering, how and where did you get it? >> >> - Henry Brancik, > >My newsfeed's been spotty lately, so I must've missed Don Tarbell's >post, but I must say that I am delighted to see that he's still around >- that is, assuming he's the Don Tarbell who designed the cassette >tape controller and disk controllers in my IMSAI's :-). And if >it is the same Don Tarbell, then it wouldn't surprise me at all >if he had the source code! > >Tim. (shoppa@altair.krl.caltech.edu) >Kellogg Radiation Lab, Caltech. Yeah, that's me. I got the CP/M 3 source when I bought the license to distribute CP/M 3 several years ago from Digital Research. Don From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!gumby!yale!yale!yale.edu!noc.near.net!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!postman+ Sat Jun 11 10:26:19 CDT 1994 Article: 69442 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!gumby!yale!yale!yale.edu!noc.near.net!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!postman+ From: Bill_von_Hagen@transarc.com Newsgroups: alt.folklore.computers Subject: New Light on the Legend of Mel Date: Sat, 11 Jun 1994 00:04:07 -0400 Organization: Carnegie Mellon, Pittsburgh, PA Lines: 185 Message-ID: NNTP-Posting-Host: po5.andrew.cmu.edu Status: RO The legend of Mel, meister programmer, is an occasional topic in this group and others. (I've appended it for clarification - if you're not familiar with the legend, you might want to read it first.) In the legend, Mel worked for Royal McBee, an early computer company. In the recent Boston Computer Museum Email Auction, I bought a set of manuals and a Read Flip Flop (5" square PCB, 4 tubes, etc.) for an Royal McBee LGP-30. The docs are dated 1959, and have some *great* illustrations of how drums work (all 4096 words of storage, on this particular system), what users will look like, etc... One of our local systems wizards recently posted the legend on one of our internal bboards to warm our hearts, which got me interested in reading the LGP-30 manuals I'd acquired (I'm funny that way.) In the manual for the LGP-30 ACT 1 (Algebraic Compiler and Translator) Compiler, the preface contains the following attribution from Clay S. Boswell, Jr. (apparently ACT 1's designer): >> I wish to acknowledge my appreciation to the many people who >> offered suggestions and criticisms of the ACT 1 System. In >> particular... Mel Kaye of Royal McBee who did the bulk of the >> programming. Perhaps Mel Kaye is the one true Mel? Interesting data to ponder, Regardless. I thought I should post this here, since the legend comes up every so often and the docs for these systems can't be all that common. This also provides a fine excuse to repost the legend itself. Has anyone run across a Royal McBee system in the last few years? Now there's a bit of cool ancient hardware I wouldn't mind for my computer collection. At least I have the docs... Bill von Hagen wvh@transarc.com ---------------------------------------------------------------------- A recent article devoted to the *macho* side of programming made the bald and unvarnished statement: Real Programmers write in Fortran. Maybe they do now, in this decadent era of Lite beer, hand calculators and "user-friendly" software but back in the Good Old Days, when the term "software" sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code. Not Fortran. Not RATFOR. Not, even, assembly language. Machine Code.Raw, unadorned, inscrutable hexadecimal numbers. Directly. Lest a whole new generation of programmers grow up in ignorance of this glorious past, I feel duty-bound to describe, as best I can through the generation gap, how a Real Programmer wrote code. I'll call him Mel, because that was his name. I first met Mel when I went to work for Royal McBee Computer Corp., a now-defunct subsidiary of the typewriter company. The firm manufactured the LGP-30, a small, cheap (by the standards of the day) drum-memory computer, and had just started to manufacture the RPC-4000, a much-improved, bigger, better, faster -- drum-memory computer. Cores cost too much, and weren't here to stay, anyway. (That's why you haven't heard of the company, or the computer.) I had been hired to write a Fortran compiler for this new marvel and Mel was my guide to its wonders. Mel didn't approve of compilers. "If a program can't rewrite its own code," he asked, "what good is it?" Mel had written, in hexadecimal, the most popular computer program the company owned. It ran on the LGP-30 and played blackjack with potential customers at computer shows. Its effect was always dramatic. The LGP-30 booth was packed at every show, and the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed. Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located. In modern parlance, every single instruction was followed by a GO TO! Put *that* in Pascal's pipe and smoke it. Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the "read head" and available for immediate execution. There was a program to do that job, an "optimizing assembler", but Mel refused to use it. "You never know where its going to put things", he explained, "so you'd have to use separate constants". It was a long time before I understood that remark. Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify. I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the "top-down" method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way. Mel never wrote time-delay loops, either, even when the balky Flexowriter required a delay between output characters to work right. He just located instructions on the drum so each successive one was just *past* the read head when it was needed; the drum had to execute another complete revolution to find the next instruction. He coined an unforgettable term for this procedure. Although "optimum" is an absolute term, like "unique", it became common verbal practice to make it relative: "not quite optimum" or "less optimum" or "not very optimum". Mel called the maximum time-delay locations the "most pessimum". After he finished the blackjack program and got it to run, ("Even the initializer is optimized", he said proudly) he got a Change Request from the sales department. The program used an elegant (optimized) random number generator to shuffle the "cards" and deal from the "deck", and some of the salesmen felt it was too fair, since sometimes the customers lost. They wanted Mel to modify the program so, at the setting of a sense switch on the console, they could change the odds and let the customer win. Mel balked. He felt this was patently dishonest, which it was, and that it impinged on his personal integrity as a programmer, which it did, so he refused to do it. The Head Salesman talked to Mel, as did the Big Boss and, at the boss's urging, a few Fellow Programmers. Mel finally gave in and wrote the code, but he got the test backwards, and, when the sense switch was turned on, the program would cheat, winning every time. Mel was delighted with this, claiming his subconscious was uncontrollably ethical, and adamantly refused to fix it. After Mel had left the company for greener pa$ture$, the Big Boss asked me to look at the code and see if I could find the test and reverse it. Somewhat reluctantly, I agreed to look. Tracking Mel's code was a real adventure. I have often felt that programming is an art form, whose real value can only be appreciated by another versed in the same arcane art; there are lovely gems and brilliant coups hidden from human view and admiration, sometimes forever, by the very nature of the process. You can learn a lot about an individual just by reading through his code, even in hexadecimal. Mel was, I think, an unsung genius. Perhaps my greatest shock came when I found an innocent loop that had no test in it. No test. *None*. Common sense said it had to be a closed loop, where the program would circle, forever, endlessly. Program control passed right through it, however, and safely out the other side. It took me two weeks to figure it out. The RPC-4000 computer had a really modern facility called an index register. It allowed the programmer to write a program loop that used an indexed instruction inside; each time through, the number in the index register was added to the address of that instruction, so it would refer to the next datum in a series. He had only to increment the index register each time through. Mel never used it. Instead, he would pull the instruction into a machine register, add one to its address, and store it back. He would then execute the modified instruction right from the register. The loop was written so this additional execution time was taken into account -- just as this instruction finished, the next one was right under the drum's read head, ready to go. But the loop had no test in it. The vital clue came when I noticed the index register bit, the bit that lay between the address and the operation code in the instruction word, was turned on-- yet Mel never used the index register, leaving it zero all the time. When the light went on it nearly blinded me. He had located the data he was working on near the top of memory -- the largest locations the instructions could address -- so, after the last datum was handled, incrementing the instruction address would make it overflow. The carry would add one to the operation code, changing it to the next one in the instruction set: a jump instruction. Sure enough, the next program instruction was in address location zero, and the program went happily on its way. I haven't kept in touch with Mel, so I don't know if he ever gave in to the flood of change that has washed over programming techniques since those long-gone days. I like to think he didn't. In any event, I was impressed enough that I quit looking for the offending test, telling the Big Boss I couldn't find it. He didn't seem surprised. When I left the company, the blackjack program would still cheat if you turned on the right sense switch, and I think that's how it should be. I didn't feel comfortable hacking up the code of a Real Programmer." -- Source: usenet: utastro!nather, May 21, 1983. From uchinews!att-out!gw1!news.bu.edu!olivea!charnel.ecst.csuchico.edu!nic-nac.CSU.net!usc!cs.utexas.edu!howland.reston.ans.net!newsserver.jvnc.net!igor.rutgers.edu!dziuxsolim.rutgers.edu!pion.rutgers.edu!bweiner Tue Jun 28 01:24:53 CDT 1994 Article: 70430 of alt.folklore.computers Path: uchinews!att-out!gw1!news.bu.edu!olivea!charnel.ecst.csuchico.edu!nic-nac.CSU.net!usc!cs.utexas.edu!howland.reston.ans.net!newsserver.jvnc.net!igor.rutgers.edu!dziuxsolim.rutgers.edu!pion.rutgers.edu!bweiner From: bweiner@pion.rutgers.edu (Ben Weiner) Newsgroups: alt.folklore.computers Subject: Re: New Light on the Legend of Mel Message-ID: Date: 28 Jun 94 02:31:13 GMT References: Organization: Rutgers Univ., New Brunswick, N.J. Lines: 92 Status: RO This is rather old news, but what the heck. It's an amusing story. Bill_von_Hagen@transarc.com writes: >The legend of Mel, meister programmer, is an occasional topic in this >group and others. (I've appended it for clarification - if you're not >familiar with the legend, you might want to read it first.) A long, long time ago - actually in 1985 - I had my first programming job, a summer job at the Westinghouse R & D Center just outside Pittsburgh. Westinghouse is a very large, somewhat dinosaurial technology corporation, and the R & D center operates in such an atmosphere, a strange mixture of creeping corporatism and rampant bureaucracy combined with a lot of high-quality engineering ability, often under- or mis-used, and the accreted apocrypha of forty years of engineering hacks. The kind of place where giant chip etching devices and gleaming things that some big shot wanted to buy coexist with back halls full of mysterious circuit boards and aluminum boxes with only half the knobs labeled. (Not to suggest that Westinghouse is any worse or better than any other such company.) At a place like that there is a lot of engineering history, arcana, and simple voodoo floating around, mostly in people's heads and communicated orally. You run into real old-school techies who do things in a pretty obscure way. For example this is where I first (and last) saw someone debug a program solely by reading the hex core dump. There was one particular engineer in my group who had begun programming at Carnegie Mellon a Long Long Time Ago. (This man's specialty when I met him was writing large codes in APL. He didn't have a computer or terminal in his office - his desk had a bunch of paper and a pile of IEEE Spectrum magazines about three feet high, on top of which a coffee cup always sat. He wrote these codes in APL, on paper, and sent them off to to another wizard in some other building who specialized in translating (!!) APL into FORTRAN, after which they could actually _run_ the code.) Once this guy described his first computer programming experience to me. When he was an undergrad at CMU, one of the departments acquired a computer (he thought it was the first at CMU). It took up residence somewhere in one of CMU's many basements. Nearly everyone ignored it, but there were a few professors and students who were interested and started playing around with it (mostly late at night, of course). This was a rotating drum memory computer, and it used the exact one-plus-one addressing scheme described in the Legend of Mel, where each instruction was followed by the address of the next. Indeed, he said, if you were a real sharp programmer, you knew how long each instruction took to execute, and you could locate the instructions on the drum so that the next instruction would be right under the head when its time came. Otherwise your program might have to wait an entire revolution to get its next order ... I've always loved this story (as an example of the bare-metal approach I'm too young to have experienced myself, though I do remember when the CMU computer science department owned two (2) DEC-10s - cough, cough, wheeze, nearly one foot in the grave!) So I was very pleased to see it as an integral feature of the Legend of Mel. -Ben Weiner astro dept rutgers university exit 9 nj turnpike -----[a few relevant parts of the legend appended] >Lest a whole new generation of programmers grow up in ignorance of this >glorious past, I feel duty-bound to describe, as best I can through the >generation gap, how a Real Programmer wrote code. I'll call him Mel, because >that was his name. >I first met Mel when I went to work for Royal McBee Computer Corp., a >now-defunct subsidiary of the typewriter company. The firm manufactured the >LGP-30, a small, cheap (by the standards of the day) drum-memory computer, and >had just started to manufacture the RPC-4000, a much-improved, bigger, better, >faster -- drum-memory computer. Cores cost too much, and weren't here to stay, >anyway. (That's why you haven't heard of the company, or the computer.) >Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What >does that mean?) The new computer had a one-plus-one addressing scheme, in >which each machine instruction, in addition to the operation code and the >address of the needed operand, had a second address that indicated where, on >the revolving drum, the next instruction was located. In modern parlance, >every single instruction was followed by a GO TO! Put *that* in Pascal's pipe >and smoke it. >Mel loved the RPC-4000 because he could optimize his code: that is, locate >instructions on the drum so that just as one finished its job, the next would >be just arriving at the "read head" and available for immediate execution. >There was a program to do that job, an "optimizing assembler", but Mel refused >to use it. > ... From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!gatech!udel!MathWorks.Com!yeshua.marcam.com!zip.eecs.umich.edu!montego!not-for-mail Thu Jul 28 14:01:18 CDT 1994 Article: 72655 of alt.folklore.computers Xref: uchinews alt.amateur-comp:2954 sci.edu:5420 comp.edu:6884 comp.unix.misc:14869 alt.folklore.computers:72655 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!gatech!udel!MathWorks.Com!yeshua.marcam.com!zip.eecs.umich.edu!montego!not-for-mail From: jrh@umcc.umcc.umich.edu (Jay Hauben) Newsgroups: alt.amateur-comp,sci.edu,comp.edu,comp.unix.misc,alt.folklore.computers Subject: Repost article from ACN 6-1:Interview with John Lions Date: 27 Jul 1994 10:28:33 -0400 Organization: UMCC, Ann Arbor, MI Lines: 278 Message-ID: <315quh$p6n@umcc.umcc.umich.edu> NNTP-Posting-Host: umcc.umcc.umich.edu X-Newsreader: TIN [version 1.2 PL2] Status: RO Spreading UNIX Around the World: An Interview with John Lions [Editor's Note: Looking through some magazines in a local university library, I came upon back issues of UNIX Review from the mid 1980's. In these issues were articles by or interviews with several of the pioneers who developed UNIX. As part of my research for a paper about the history and development of the early days of UNIX, I felt it would be helpful to be able to ask some of these pioneers additional questions based on the events and developments described in the UNIX Review Interviews. Following is an interview conducted via E-mail with John Lions, who wrote A Commentary on the UNIX Operating System describing Version 6 UNIX to accompany the "UNIX Operating System Source Code Level 6" for the students in his operating systems class at the University of New South Wales in Australia. Lions' important book provided some of the earliest printed commentary and documentation of the UNIX kernel. John Lions is a Professor of Computer Science in the School of Computer Science and Engineering, at the University of New South Wales.] Q: John, I have been reading with joy the interview with you that was published in UNIX Review in October, 1985. I found it inspiring because it showed the hard fight you and your colleagues and students took up to be able to adopt UNIX at your University and to help to spread it in Australia and around the world. In the UNIX Review article you describe the arrival of UNIX saying "UNIX was a revolutionary force on our campus." You tell how the University of New South Wales decided to purchase a Cyber 72 computer in 1974. But, since the Cyber could only recognize User200 terminals which were by that time obsolete, the University bought some PDP-11/40's to emulate User200s. You describe how you wrote for information about UNIX after reading an article by Ritchie and Thompson published in the "Communica- tions of the ACM," and explained how a copy of Edition 5 tape and manuals arrived in late December, 1974. A little later in the Interview you relate how Ian Johnstone with assistance from others wrote a new User200 emulator "that ran under UNIX. That," you point out, "became the first application of UNIX to be written in Australia .... This exercise proved to be extremely important. With a PDP-11," you explain, " completely to our- selves, we most likely would have run vanilla UNIX on it and been happy. But because we had to provide the User200 emulator, we had to learn a lot about the system and pay a lot of attention to performance issues. We needed help, but we couldn't get any from outside sources. So we ended up generating our own expertise." Lions: Undoubtedly true .... Q: What was it about UNIX that led you to do the hard work that you did? Were you aware of the power that it promised? Was that some of the consideration or was it more practical -- that you had certain things you wanted to be able to do and could hack to get the UNIX system to do it? Lions: UNIX was wonderfully plastic. We changed things to adapt them to our situation ... because it was a challenge, and we were having fun! Q: You then say that through your work on UNIX you started to make a few friends elsewhere on campus. Were they from any other particular department? How did you begin to build a user group? Did you start having formal meetings? Lions: Other people at the other batch stations were interested in solving the same problems as we were, so we found a common cause. This included the Library which in those days had passwords for the ordinary user accounts, but not for the super- user ... very convenient! Q: Can you say what kinds of similar problems people in other universities were encountering at the time that led you to be able to work together? Lions: In a word ... isolation. Q: Do you have any idea why UNIX was so widely adopted at other Australian Universities? Lions: We spread the news evangelically ... We were very anxious to share our accumulated knowledge and to experiment ... and we wanted to share it with others. We were having fun! Q: You say that UNIX has possibly made a deeper penetration in Australia than in any other country. Lions: That comment has to be understood in its proper context. I would not make it today. UNIX penetration is now 100% by university, though not by department within universities. The Internet is heavily UNIX-dependent, so I believe. Q: In the UNIX Review interview, you describe how in 1975, Ian Johnstone who was acting as a tutor for the operating systems course you taught, asked, "Why don't we run off a few of the source code files for the kernel and ask the students to take a look at them? Then we can ask them some questions; maybe it will be interesting." What kind of questions did you folks intend to ask? Lions: The same kind that the Commentary answers .... Q: After you took his suggestion and you both selected what seemed like a reasonable subset of the kernel and handed it out to students, you report that you asked them questions, but that they didn't have enough information to answer them so "they came back to us with questions of their own many of which we couldn't answer." Can you say any more about how the students suggested that you offer the complete kernel for study? Lions: They suggested that it should be all or nothing. The selection of code I finally printed (on a DECwriter) is only complete in a limited sense. Section Five that deals with device drivers could have been much longer. Q: Was there any special reason that you took their suggestions? What led to the preparation in 1976 of the booklet containing the source files for a version of Edition 6 UNIX that could run on a PDP-11/40 system? Lions: Seemed reasonable at the time ... what other options reasonably existed? Q: You say "Writing these was a real learning exercise for me. By slowly and methodically surveying the whole kernel, I came to understand things that others had overlooked." Can you give any examples of what you came to understand that others had over- looked? Lions: No. I guess what I meant to say was that I obtained an integrated view that allowed me to see more connections in the code than others did. I used to test the students' knowledge and understanding by weekly tests. Most years there would be two tests on each of the first four sections of the code. Students could sit for both tests in each section, but they were discouraged from submitting more than one answer for marking. If they chose to submit two answers, their mark was the better of the two, less 10%. This allowed students to recover from a bad first result, while discouraging them from trying again if their first attempt was reasonable. Marking was always a problem as overnight turnaround was needed. The sophistication of the questions increased over the years and towards the end, some new questions were quite devious. (Don't ask me for examples!) Q: In the Commentary you say: "A decision had to be made quite early regarding the order of presentation of the source code. The intention was to provide a reasonably logical sequence for the student who wanted to learn the whole system. With the benefit of hindsight, a great many improvements in detail are still possible, and it is intended that these changes will be made in some future edition." Did you ever write the future edition making the changes? Lions: No. There had been a three year gap between [UNIX -ed] Editions Six and Seven. This created a window of opportunity for us that never really occurred again. Q: In your Commentary you say "You will find that most of the code in UNIX is of a very high standard. Many sections which initially seem complex and obscure, appear in the light of further investigation and reflection, to be perfectly obvious and 'the only way to fly.' For this reason, the occasional comments in the notes on programming style, almost invariably refer to apparent lapses from the usual standard of near perfection .... But on the whole you will find that the authors of UNIX, Ken Thompson and Dennis Ritchie, have created a program of great strength, integrity and effectiveness, which you should admire and seek to emulate." Lions: That is what I believed then ... and still do. Q: Can you say any more about the conclusion you drew of the high standard of code in the UNIX kernel? Do you feel that students and others who studied your book and the code did emulate it? Did that help improve the level of code of those who had access to your book and the source code? Lions: In a general sense, I believe the answer is 'yes': students did learn better coding practices. Q: In the UNIX Review article, you relate that in 1977 at the University of New South Wales you were developing your own PDP version of UNIX to handle heavy student loads and that Ian Johnstone, Peter Ivanov and Greg Rose developed a "sanitized extended version of UNIX." And you made some changes to the kernel. Can you say what the most important ones were? Lions: We fixed bugs that we found ... or had introduced ourselves. I cannot recall what they were ... and of course the Seventh Edition changed everything anyway. We only did it once: that was enough. Q: Was your examination of the kernel for the Commentary helpful in determining what changes to the kernel were needed. For example, in the Commentary on pg. 82 under "Some Comments" you say " 'namei' is a key procedure which would seem to have been written very early, to have been thoroughly debugged and then to have been left essentially unchanged. The interface between 'namei' and the rest of the system is rather complex, and for that reason alone, it would not win the prize for 'Procedure of the Year.' Earlier in the Commentary in chapter 19 (pg. 82) you say "Copy the eight words of the directory entry into the array 'u.u_dent'." Then you comment, "The reason for copying before comparing is obscure! Can this actually be more efficient? (The reason for copying the whole directory at all is rather perplexing to the author of these notes.);" Were these problems clarified upon further examination or if not, did you make any effort to solve them when you folks made changes to the kernel? Lions: No comment now. My understanding changed over the years, and some questions that may been obscure once were no longer so. Q: In the UNIX Review Interview you explain that you were the first person from the UNIX community in Australia to spend a sabbatical at Bell Labs. Who invited you to the Labs? When? Why? What did you do once there? Lions: After I started distributing copies of my notes on UNIX (Source Code and Commentary), I sent more than two hundred copies to BTL [Bell Telephone Laboratories -ed]. One night (sometime in 1978?), I had a phone call from Doug McIlroy saying BTL would like to assume responsibility for distributing those documents, and would I agree? I did. It saved me much work. At the beginning of 1978, when I was starting to wonder what to do for my first sabbatical leave, I had another late night call, this time from Berkley Tague enquiring whether I might be willing to visit BTL, another easy decision. In the middle of 1978, my family (us and two daughters) set off for the USA, Madison, NJ in particular, where Berkley had arranged for us to rent the house of an academic from Drew University. (They were going to the south of France for his sabbatical!) I can still remember arriving at 26 Morris Place, tired but pleased to be there (I think we must have rented a car from Newark airport). Shortly afterwards Berk arrived and introduced himself. We have been firm friends since then, with both him and his wife, Anne-Marie. He is undoubtedly one of nature's gentlemen. Madison, N.J. is only a few miles (less than 10 -- I forget!) from BTL. Incidentally, Berkley used to collect me each morning and drive me from Madison to the Labs, so my wife could have our car! Q: You say in the UNIX Review interview that you worked in the UNIX Support Group while at Bell Labs during that first sabbatical and were able to introduce a number of utilities, including pack, etc. Can you say more about what your work was during that first sabbatical? Lions: There were no expectations and I was given a free hand to follow my own interests. Fortunately for BTL I had lots of ideas, so there was never a problem. Q: Do you know how your book was used as part of the work that USG [UNIX Support Group -ed] was doing? Do you know how it was used both elsewhere in Bell Labs and outside? Lions: I had sent them the original copies of my notes. They reproduced them and provided one copy to each new licensee (so I believe). Each new licensee was allowed to make additional copies under specified conditions. Q: At the end of the UNIX Review Interview you say that it was not so much that the UNIX system is friendly but that the people who use it are. Do you have any sense of what about UNIX makes this true? Lions: Not really. That was just my experience. I think you ought to remember that BTL is a very special place, and its Research Department is also very special. Q: What would you see as an appropriate way to commemorate the 25th anniversary of the creation of UNIX in 1994? Lions: I gather Usenix is attempting to organize a meeting. -------------------------------------------------------------------- Reprinted from The Amateur Computerist Vol 6 no 1 Winter/Spring 1994 From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!EU.net!uunet!zib-berlin.de!rs1-hrz.uni-duisburg.de!news.rz.uni-duesseldorf.de!hp817s.rz.uni-duesseldorf.de!not-for-mail Tue Nov 29 18:35:13 CST 1994 Article: 83500 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!EU.net!uunet!zib-berlin.de!rs1-hrz.uni-duisburg.de!news.rz.uni-duesseldorf.de!hp817s.rz.uni-duesseldorf.de!not-for-mail From: vieth@hp817s.rz.uni-duesseldorf.de (Ulrik Vieth) Newsgroups: alt.folklore.computers Subject: Re: Did Knuth write in MAD ? Date: 28 Nov 1994 23:22:23 +0100 Organization: Heinrich Heine Universitaet Duesseldorf, Rechenzentrum Lines: 74 Message-ID: <3bdl6v$sma@hp817s.rz.uni-duesseldorf.de> References: <3avf30$dfi@nyheter.chalmers.se> <3b0og1$pfs@news2.delphi.com> Reply-To: Ulrik Vieth NNTP-Posting-Host: hp817s.rz.uni-duesseldorf.de X-Newsreader: NN version 6.5.0 #3 (NOV) Status: RO PIVEN@news.delphi.com (PIVEN@DELPHI.COM) writes: >rittri@cs.chalmers.se (Mikael Rittri) writes: >>Hello, >> >> I remember a rumor that the first paper that D. E. Knuth published >> appeared in MAD Magazine, and described >> >> the Potzrebie system of weights and measurements. >> >> As I am writing a paper on dimensional analysis, I would love >> to throw in a reference to this paper, if it really exists and >> was written by Knuth. >> >> Could someone give me a full reference? >It does exist, and was published in _MAD_ #33. (I have no idea how that >translates into month/year.) > > *** The Potrzebie System of Weights and Measures *** [...] >- - - - - - - - - - >This work, putatively Knuth's first published work, is reprinted in full >(including artwork!) in _Completely Mad: A History of the Comic Book and >Magazine_, by Maria Reidelbach (published by Little, Brown; ISBN >0-316-738913). This is as close as I've ever seen any one book come to >being an entire wasted childhood in one convenient package! I cannot resist to throw in Knuth's personal account of his MAD article, or rather what he told his Stanford class about it in 1987. (This is quoted from: MATHEMATICAL WRITING, by Donald E. Knuth, Tracy Larrabee, Paul M. Roberts, MAA Notes 14, The Mathematical Association of America, ISBN 0-88385-063-X.) Here it is: Excerpts from Class, November 4, 1987: Today, Don said, we are going to talk about the use of pictures and illustrations in mathematical writing ... But first, by popular demand, Don showed us his first publication. This was a description of a system of weights and measures known as the Potrzebie System, which appeared in the pages of MAD magazine in 1957. Any resemblance to the Metric System is purely coincidental. It is an extremly natural and logical system, Don told us. For example, the units of time were named after the editors of MAD (the new editors substituted their own names). He felt there was a need for new units of counting, and so coined the MAD; 48 things constitute one MAD (or 49, a baker's MAD). Don didn't publish a better illustrated work until The TeXbook, he claimed, nor another paid one until he wrote for ACM Computing Surveys some 12 years later. MAD forked over no less than $25 for this research paper, no mean sum thirty years ago. `The Potrzebie System' still heads the list of publications on his C.V. MAD inexplicably declined Don's second article, ``RUNCIBLE: Algorithmic Translation of a Limited Computer'', which was picked up by Communications of the ACM in 1959. Perhaps this was because it contained what even Don admits is probably one of the worst ``spaghetti'' flow charts ever drawn ... - - - - - - - - - - So much for today's episode of Knuth trivia. The above-mentioned booklet, which is a transcript of a lecture series given at Stanford in 1987, is full of that, such as how Knuth wrote his novelette `Surreal Number' within only a week while on holiday, etc. Apparently, Knuth like so many other professors loves to tell stories to his class. Interesting reading! Enjoy! Ulrik Vieth