TUHS

tuhs@tuhs.org

12 participants
6534 discussions

DEC and Dave Cutler (was Re: The John Snow's of the UNIX family)

by Paul Winalski

On 1/16/19, Kevin Bowling <kevin.bowling(a)kev009.com> wrote: > I’ve heard and personally seen a lot of technical arrogance and > incompetence out of the Masshole area. Was DEC inflicted? In > “Showstopper” Cutler fled to the west coast to get away from this kind of > thing. > Having worked at DEC from February 1980 until after the Compaq takeover, I would say that DEC may have exhibited technical arrogance from time to time, but certainly never technical incompetence. DEC's downfall was a total lack of skill at marketing. Ken Olsen believed firmly in a "build it and they will come" philosophy. Contrast this with AT&T's brilliant "Unix - consider it a standard" ad campaign. DEC also suffered from organizational paralysis. KO believed in decisions by consensus. This is fine if you can reach a consensus, but if you can't it leads to perpetually revisiting decisions and to obstructionist behavior. There was a saying in DEC engineering that any decision worth making was worth making 10 times. As opposed to the "lead, follow, or get out of the way" philosophy at Sun. Or Intel's concept of disagree and commit. DEC did move towards a "designated responsible individual" approach where a single person got to make the ultimate decision, but the old consensus approach never really died. Dave Cutler was the epitome of arrogance. On the technical side, he got away with it because his way (which he considered to be the only way) was usually at least good enough for Version 1, if not the best design. Cutler excelled in getting V1 of something out the door. He never stayed around for V2 of anything. He had a tendency to leave messes behind him. A Cutler product reminded me of the intro to "The Peabodys" segment of Rocky & Bullwinkle. A big elaborate procession, followed by someone cleaning up the mess with a broom. Cutler believed in a "my way or the highway" approach to software design. His move to the west coast was to place himself far enough away that those who wanted to revisit all his decisions would have a tough time doing so. On the personal side, he went out of his way to be nasty to people, as pointed out elsewhere in this thread. Although he was admired technically, nobody liked him. -Paul W.

6 years, 5 months

Fwd: Posters

by Warner Losh

Meant to reply all on this.... Warner ---------- Forwarded message --------- From: Warner Losh <imp(a)bsdimp.com> Date: Sat, Feb 2, 2019, 11:37 PM Subject: Re: [TUHS] Posters To: Grant Taylor <gtaylor(a)tnetconsulting.net> I'll take pictures tomorrow. No zeppelin though... I had hoped that I still had my ultrix version of Phil Figlio's original usenix artwork. I can find the Usenix one and the Unix one, but not that one online. Anybody have one they can share? Warner On Sat, Feb 2, 2019, 7:32 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org wrote: > On 2/2/19 6:35 PM, Warner Losh wrote: > > Is there any interest from this group in photos of any of these? > > I would be interested in pictures of the computer related pictures to > see if I'd be interested enough to pay for and / or for shipping on any > of them. > > > > -- > Grant. . . . > unix || die > >

6 years, 5 months

Re: [TUHS] OSI stack (Was: Posters)

by Norman Wilson

Noel Chiappa: {And apologies for the non-Unix content, but at least it's about computers, unlike all the postings about Jimmy Page's guitar; typical of the really poor S/N on this list.) ====== Didn't Jimmy Page's guitar use an LSI-11 running Lycklama's Mini-UNIX? And what was his page size? Norman Wilson Toronto ON

6 years, 5 months

Posters

by Warner Losh

I found 3 tubes of posters I'd been hoarding since college (well, since my first job after college). There's the usual 18-year-old-boy stuff (Pink Floyd, Led Zeppelin, etc), but mixed in are a bunch of OSI/ISO network stack posters (thank goodness that didn't become standard, woof!), a couple movie posters, an 10th Anniversary poster for RT-11. The ones that will interest this group, maybe, are the Unix Feuds poster with the wizard among the waring armies, A 20th Anniversary of Unix poster by Tenon Intersystems which has a nice picture of Unix through 1990 or so (with Tenon's Mach^ten 1.0 for Macintosh derived from BSD 4.3 and Mach) on it. It's in decent share, but not in collector ready shape. Oh, and I have a Eunice poster that mixes the best of VMS and BSD 4.1 into a seamless environment. Is there any interest from this group in photos of any of these? Warner

6 years, 5 months

Re: [TUHS] Archeology: AberMUD, BCPL, ec.

by Doug McIlroy

> I have tried to OCR program listings before, with rather > poor results. I OCR'd a sizable manuscript written on a pretty shabby portable typewriter. I scanned each page twice, making sure to move the paper between scans. Then I ran both diff (by words, not lines) and spell to smoke out trouble. The word list for a program listing is quite short and easy to generate. (Print a list of all the apparent words and visually eliminate the nonsense.) And a spell check is an easy pipeline of standard utilities. doug

6 years, 5 months

Archeology: AberMUD, BCPL, ec.

by Richard Salz

Some folks are trying to figure out how to get AberMud source online and working; see https://twitter.com/larsbrinkhoff/status/1056823314272960512 Sample code at https://raw.githubusercontent.com/larsbrinkhoff/abermud/master/abermud1/tex…

6 years, 5 months

qed-archive - please reclone

by arnold＠skeeve.com

Hi All. I had a bad commit message in the qed-archive I mentioned here a few weeks ago. I fixed it with a 'git push --force' (even though that's not recommended) since I expect it to be a read-only archive going forward, and I wanted it to be right. In short, if you cloned it, please remove your copy and reclone. Thanks! Arnold

6 years, 5 months

Knuth and Unix

by Dave Horsfall

Time for a new thread :-) As today is Knuth's birthday (posted over in COFF), I was wondering (in the cesspool that is my mind) how much of Unix would have been influenced by Knuth? We have qsort() of course (which Hoare actually wrote, based on one of Knuth's algorithms), but I'm guessing that Ken and Dennis would have been familiar with his work? Or am I spreading fake news again? :-) Look, I love being corrected if I make a mistake on a technical mailing list, so fire at will if need be... -- Dave

6 years, 5 months

Re: [TUHS] V6 networking & alarm syscall

by Paul Ruizendaal

> Where did you find the BBN TCP/IP stack? Easiest place to find it is the TUHS Unix Tree page: https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP Several tapes of it survived in the CSRG archives, currently held by the Bancroft Library at Berkeley. A late version of the tcp/ip routines survived at the Stanford SAIL archives, currently online here: https://www.saildart.org/[IP,SYS]/ (mixed in with sources for WAITS). A much evolved version is in the BSD SCCS history: https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet Note that the location ‘deprecated’ is where the code ended up. Back in 1985 it would have been in the normal build path, but SCCS does not preserve that. Paul

6 years, 5 months

Extra Two CDs in CSRG CD-ROM Set

by Warren Toomey

All, I just found out in the past few days that Kirk McKusick has added another two CDs in his set of CSRG Archives CD-ROM set. Some details of these CDs can be found here: https://www.mckusick.com/csrg/index.html I've purchased the two additional CDs, and I've put a file listing and set of checksums for all files on all six CDs here: https://www.tuhs.org/Archive/Documentation/CSRG_CDs/ Cheers, Warren

6 years, 5 months

The John Snow's of the UNIX family

by alan＠alanlee.org

I've been on a Data General Aviion restoration binge lately and re-familiarizing myself with DG/UX. In my case 5.4R3.1 running on a MC88100 based AV/300 and MC88110 dual core AV/5500. The more I experience, the more I am impressed. There are a few things about the system that seem impressive. - Despite coming from a System V core, there is a lot of BSD influx - especially on the networking side. This is a personal taste issue as other ports have tried to mix the best of both worlds. But after a prior month-long Sun/Solaris restoration binge of similar era hardware (Super/Hyper/Ultra SPARC) and software (SunOS 4 through Solaris 9), DG/UX is a welcome and refreshing change! Especially out of the box. - It has a system of file security that seems unique for that era - at least in my experience - of explicit and implicit directory tags with inheritance. There is even a high security extended version of the OS. - It has a built-in logical volume manager supporting multiple virtual to physical disk mappings, striping, mirroring, and even archiving - something several entire sub-industries were created for in other ports. I am guessing this contributed to EMC's purchase of Data General for the Clariion disk storage product lines. - It leveraged open-source tools early. The default m88k compiler installed with the system is GNU C 2.xx. - It was among the earliest of operating systems to support NUMA aware affinity on MP versions of the MC88110. (IRIX, Solaris, BSD, Linux, and Windows support all came much later). - Many others. It does have it's quirks. However I get the overall impression the folks working at DG were on their game and were a leader in the industry in many areas. It is unfortunate a) the fate of the Motorola 88K was tied to Data General's place in the UNIX world, and b) by the time they migrated to IA86, enterprise business was more interested in Microsoft NT & SQL server or Linux than an expensive vendor's UNIX port. That being said, I don't see DG/UX mentioned much in UNIX history. In fact, I am researching an exhibit I'm putting together for the Vintage Computer Festival Southeast 7.0, and DG/UX isn't mentioned on any of the 'UNIX Family Tree' diagrams I can find so far. It doesn't even make Wikipedia's 'UNIX Variants' page. It's own Wikipedia page is also rather sparse. Like John Snow in season 1, there is a junk of missing and plot impacting history here - centered around the people involved. To a lesser degree, IRIX is also a red-headed step-child. It's omitted from half the lists I can find. It just seems the importance, even if it's an importance by being the 'first' rather than # of users, of these ports are pretty significant. Just curious of others' thoughts. And I wondering if anyone has first-hand knowledge of Data General's efforts or knows of others that can illuminate the shadows of what I'm discovering is a pretty exciting corner of the UNIX world. Thanks, -Alan H.

6 years, 5 months

DEC and Dave Cutler

by Paul Winalski

Forgive me if this is a duplicate. My original message appears to have bounced. On 1/16/19, Kevin Bowling <kevin.bowling(a)kev009.com> wrote: > I’ve heard and personally seen a lot of technical arrogance and > incompetence out of the Masshole area. Was DEC inflicted? In > “Showstopper” Cutler fled to the west coast to get away from this kind of > thing. > Having worked at DEC from February 1980 until after the Compaq takeover, I would say that DEC may have exhibited technical arrogance from time to time, but certainly never technical incompetence. DEC's downfall was a total lack of skill at marketing. Ken Olsen believed firmly in a "build it and they will come" philosophy. Contrast this with AT&T's brilliant "Unix - consider it a standard" ad campaign. DEC also suffered from organizational paralysis. KO believed in decisions by consensus. This is fine if you can reach a consensus, but if you can't it leads to perpetually revisiting decisions and to obstructionist behavior. There was a saying in DEC engineering that any decision worth making was worth making 10 times. As opposed to the "lead, follow, or get out of the way" philosophy at Sun. Or Intel's concept of disagree and commit. DEC did move towards a "designated responsible individual" approach where a single person got to make the ultimate decision, but the old consensus approach never really died. Dave Cutler was the epitome of arrogance. On the technical side, he got away with it because his way (which he considered to be the only way) was usually at least good enough for Version 1, if not the best design. Cutler excelled in getting V1 of something out the door. He never stayed around for V2 of anything. He had a tendency to leave messes behind him. A Cutler product reminded me of the intro to "The Peabodys" segment of Rocky & Bullwinkle. A big elaborate procession, followed by someone cleaning up the mess with a broom. Cutler believed in a "my way or the highway" approach to software design. His move to the west coast was to place himself far enough away that those who wanted to revisit all his decisions would have a tough time doing so. On the personal side, he went out of his way to be nasty to people, as pointed out elsewhere in this thread. Although he was admired technically, nobody liked him. -Paul W.

6 years, 5 months

Re: [TUHS] Knuth and Unix

by Doug McIlroy

Tsort was a direct reference to Knuth's recognition and christening of topological sort as a worthy software component. This is a typical example of the interweaving of R and D which characterized the culture of Bell Labs. Builders and thinkers were acutely aware of each other, and often were two faces of one person. Grander examples may be seen in the roles that automata theory and formal languages played in Unix. (Alas, these are the subjects of projected Knuthian volumes that are still over the horizon.) Doug

6 years, 5 months

RE AT&T 5620 emulator

by Doug McIlroy

Norman is right. The Seattle museum has a 5620. Having seen "5620" in the subject line, I completely overlooked the operative words "real blit or jerq" in Seth's posting. Doug

6 years, 5 months

RE AT&T 5620 emulator

by norman＠oclsc.org

Seth Morabito: I'd love to see a real Blit or jerq in person some day, but I don't even know where I'd find one (it looks like even the Computer History Museum in Mountain View, CA doesn't have a 68K Blit -- it only has a DMD 5620) Doug McIlroy: The Living Computer Museum in Seattle has one. Ad like most things there, you can play with it. === It's a couple of years since I was last in Seattle, but I remember only a DMD 5620 (aka Jerq); no 68000-based Blit. Though of course they are always getting new acquisitions, and have far more in storage than on display. (On one of my visits I was lucky enough to get a tour of the upper floor where things are stored and worked on.) Whether they have a Blit or only a Jerq, it's a wonderful place, and I expect any member of this list would enjoy a visit. I plan to drop in again this July, when I'm in town for USENIX ATC (in suburban Renton). Norman Wilson Toronto ON

6 years, 5 months

RE AT&T 5620 emulator

by Doug McIlroy

> I'd love to see a real Blit or jerq in person some day, but I don't even know where I'd find one The Living Computer Museum in Seattle has one. Ad like most things there, you can play with it. Doug

6 years, 5 months

practice of aliasing C compiler with occ?

by Nigel Williams

We've been recovering a 1980s programming language implemented using a mix of Pascal and C that ran on 4.1 BSD on VAX. The Makefile distributed to around 20+ sites included these lines for the C compiler. CC= occ CFLAGS= -g It seems there was a (common?) practice of keeping around the old C compiler when updating a BSD system and occ was used to reference it. Anyone care to comment on this observation? was it specific to BSD-land? how was the aliasing effected, a side-by-side copy of the compiler pieces? As at 4.1 BSD the C compiler components were in /lib (Pascal though was in /usr/lib). # ls -l /lib total 467 -rwxr-xr-x 1 root 25600 Jul 9 1981 c2 -rwxr-xr-x 1 root 89088 Jul 9 1981 ccom -rwxr-xr-x 1 root 19456 Jul 9 1981 cpp -rwxr-xr-x 1 root 199 Mar 15 1981 crt0.o -rwxr-xr-x 1 root 40960 Jul 9 1981 f1 -rwxr-xr-x 1 root 62138 Jul 9 1981 libc.a -rwxr-xr-x 1 root 582 Mar 15 1981 mcrt0.o

6 years, 5 months

V6 networking & alarm syscall

by Paul Ruizendaal

I'm still happily experimenting with my combination of a V6 kernel with the 1981 tcp/ip stack from BBN, for example figuring out how one would write something like 'ping' using that API. That brought me to pondering the origins of the 'alarm()' sys call and how some things were done on the Spider network. These are my observations: 1. First of all: I understand that early Unix version numbers and dates mostly refer to the manual editions, and that core users had more frequent snapshots of a constantly evolving code base. 2. If I read the TUHS archive correctly, alarm() apparently did not exist in the original V6 edition of mid-1975. On the same basis, it was definitely there by the time of the V7 edition of early '79 (with sleep() removed) - so alarm() would seem to have appeared somewhere in the '75-'78 time frame. 3. The network enhanced NCP Unix versions in the TUHS archive have alarm() appear next to sleep(). Although the surviving tapes date from '79, it would seem to suggest that alarm() may have originated in the earlier part of the '75-'78 time frame. 4. The Spider network file store program 'nfs' (source here: http://chiselapp.com/user/pnr/repository/Spider/dir?mtime=0&type=flat&udc=1…) uses idioms like the below to avoid getting hung on a dead server/network: signal(14,timeout); alarm(30); if((read(fn,rply,100)) < 0) trouble(); alarm(0); The 'nfs' program certainly was available in the 5th edition, maybe even in the 4th edition (the surviving 4th edition source code includes a Spider device driver). However, the surviving source for 'nfs' is from 1979 as well, so it may include later additions to the original design. 5. Replacing sleep() with alarm() and a user space library routine seems to have happened only some time after alarm() appeared, so it would seem that this was an optimization that alarm() enabled, and not its raison d'être. So here are some questions that the old hands may be able to shed some light on: - When/where did alarm() appear? Was network programming driving its inception? - Did Spider programs use a precursor to alarm() before that? (similar to V5 including 'snstat' in its libc - a precursor to ioctl). Paul

6 years, 5 months

Re: [TUHS] V6 networking & alarm syscall

by Paul Ruizendaal

> / uses the system sleep call rather than the standard C library > / sleep (sleep (III)) because there is a critical race in the > / C library implementation which could result in the process > / pausing forever. This is a horrible bug in the UNIX process > / control mechanism. > > Quoted without comment from me! Intriguing comment. I think your v6+ system probably has a lot of PWB stuff in there. The libc source for sleep() in stock V6 is: .globl _sleep sleep = 35. _sleep: mov r5,-(sp) mov sp,r5 mov 4(r5),r0 sys sleep mov (sp)+,r5 rts pc The PWB version uses something alarm/pause based, but apparently gets it wrong: .globl _sleep alarm = 27. pause = 29. rti = 2 _sleep: mov r5,-(sp) mov sp,r5 sys signal; 14.; 1f mov 4(r5),r0 sys alarm sys pause clr r0 sys alarm mov (sp)+,r5 rts pc 1: rti I think the race occurs when an interrupt arrives between the sys alarm and the sys pause lines, and the handler calls sleep again. sleep() in the V7 libc is a much more elaborate C routine. When I first read the race condition comment, I thought the issue would be like that of write: _write: mov r5,-(sp) mov sp,r5 mov 4(r5),r0 mov 6(r5),0f mov 8(r5),0f+2 sys 0; 9f bec 1f jmp cerror 1: mov (sp)+,r5 rts pc .data 9: sys write; 0:..; .. This pattern appears in several V6 sys call routines, and would not be safe when used in a context with signal based multi- threading.

6 years, 5 months

Re: [TUHS] V6 networking & alarm syscall

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > As I dimly recall ... it returns the number of characters in the input > queue (at that time) Well, remember, this is the MIT V6 PDP-11 system, which had a tty driver which had been completely re-written at MIT years before, so you'd really have to check the MIT V6 sources to see exactly what it did. I suspect they borrowed the name, and basic semantics, from Berkeley, but everything else - who knows. This user telnet is from 1982 (originally), but I was looking at the final version, which is from 1984; the use of the ioctl was apparently a later addition. I haven't checked to see what it did originally for reading from the user's terminal (although the earlier version also used the 'tasking' package). Noel

6 years, 6 months

Re: [TUHS] V6 networking & alarm syscall

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > It would not seem terribly complex to add non-blocking i/o capability to > V6. ... Adding a 'capacity' field to the sgtty interface would not > have been a big leap either. ... > Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does > it'? This point interested me, so I went and had a look at how the MIT V6+/PWB TCP/IP did it. I looked at user TELNET, which should be pretty simple (server would probably be more complicated, due to PTY stuff). It's totally different - although that's in part because in the MIT system, TCP is in the user process, along with the application. In the user process, there's a common non-premptive 'tasking' package which both the TCP and TELNET code use. When there are no tasks ready to run, the process uses the sleep() system call to wait for a fixed, limited quantum (interrupts, i.e. signals, will usually wake it before the quantum runs out); note this comment: / uses the system sleep call rather than the standard C library / sleep (sleep (III)) because there is a critical race in the / C library implementation which could result in the process / pausing forever. This is a horrible bug in the UNIX process / control mechanism. Quoted without comment from me! There are 3 TCP tasks - send, receive and timer. The process receives an 'asynchronous I/O complete' signal when a packet arrives, and that wakes up the process, and then one of the tasks therein, to do packet processing (incoming data, acks, etc). There appears to be a single TELNET task, which reads from the user's keyboard, and sends data to the network. (It looks like processing of incoming data is handled in the context of one of the TCP tasks.) Its main loop starts with this: ioctl (0, FIONREAD, &nch); if (nch == 0) { tk_yield (); continue; } } if ((c = getchar()) == EOF) { so that ioctl() must look to see if there is any data waiting in the terminal input buffer (I'm too lazy to go see what FIONREAD does, right at the moment). Noel

6 years, 6 months

V6 networking & alarm syscall

by Paul Ruizendaal

Clem, Ron, Thanks for the explanations! Some comments below. >> 1. First of all: I understand that early Unix version numbers and dates >> mostly refer to the manual editions, and that core users had more >> frequent snapshots of a constantly evolving code base. > > Eh? They primarily refer to the distributions (Research V6, V7, PWB, the > various BSD tapes). > I'm not sure what "core users" are referring to. Most of us had many > versions as we hacked and merged the stock releasesx. I was too brief. I was referring just to the pre-V7 versions, and I had the implicit assumption that alarm() originated at the labs. My understanding was that the labels 5th, 6th and 7th edition had little meaning inside the labs, as there just was a continuously developing code base. Maybe this is a mis-understanding. > "alarm was introduced as part of Unix/TS" "PWB [..] had both sleep() and alarm() as system calls" Thanks for those pointers! I'm not sure I fully grasp the lineage of Unix/TS and PWB, but the TUHS wiki has a page about it: https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 From that, and from the TUHS Unix Tree web page I get that PWB1.0 from mid 1977 was probably the root source of alarm() for people outside AT&T. As PWB apparently got started much before that, it is possible that alarm() goes back much further as well. > A bigger networking issue was select() (or the like). It used to be an > interesting kludge of running two processes inorder to do simoultaneous > read/write before that. Yes: the NCP Unix team (Grossman/Holmgren/Bunch) also mentioned that as the big issue/annoyance that they ran into in 1975. As discussed in this list before, 3 years elapsed before Jack Haverty came up with await() for V6. I was told that there was a lot of discussion in the 4.1x/4.2 BSD steering group in 1981/2 whether this functionality should be stateful (like await) or stateless (like select). Looking at the implementations for both, I can see why stateless carried the day. > Right and select(2) was created by Sam and wnj during the 4.2 development. I've forgotten which sub-version (it was in 4.1c, but it might have been in b or a before that). There was a lot of arguing at the time about it's need; the multiple process solution was considered more 'Unix-like.' That is an interesting point, and it got me wondering about another related feature that could have been in Unix in the 1975-1980 time frame, being both useful and practical even on a 11/40 class machine, but for some reason wasn't: It would not seem terribly complex to add non-blocking i/o capability to V6. It could have been implemented as a TTY flag and it is not a big conceptual leap from EINTR to EAGAIN. Adding a 'capacity' field to the sgtty interface would not have been a big leap either. This would have allowed user processes to scan a number of tty lines e.g. once a second in a loop and do processing as needed. In NCP Unix this would not have been hard to extend to network pipes. The NCP Unix / Arpanet crowd certainly had a need for it, it would have been very useful for Spider/Datakit connections and probably for uucp as well. And from there it is not a million miles to replace the timed user loop with something like select(). Yet non-blocking I/O and select() only appear in 1982. Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does it'?

6 years, 6 months

AT&T / Teletype DMD 5620 Emulator

by Seth J. Morabito

Hello folks, I realized I should mention this here on TUHS, since it is likely of interest to at least some of you! I recently wrote a DMD 5620 emulator, currently available on Linux and Macintosh, with Windows support coming soon. Here's a brief demo of the Mac version: https://www.youtube.com/watch?v=tcSWqBmAMeY I wrote it because DMD 5620s are becoming incredibly rare, and showing them off in person is quite difficult nowadays. This emulator is using ROM version 2.0 (8;7;5) dumped from my personal 5620. If anyone out there has a DMD 5620 with an older ROM, I would be incredibly grateful if you could dump the ROMs. I'd like to find versions of 1.x (8;7;3 or earlier); so far I've had no luck. The main reason I'm interested in older ROMs, besides pure preservation reasons, is that the 'mux' and 'muxterm' system on Research UNIX V8/V9 is hard-coded for the 1.1 ROMs. It doesn't work with the emulator without significant tweaking of the source. It DOES work perfectly well with the DMD Core Utilities package for the AT&T 3B2, however. All the best! -Seth -- Seth Morabito Poulsbo, WA, USA web(a)loomcom.com

6 years, 6 months

Re: [TUHS] Happy birthday, C.A.R. Hoare!

by Paul McJones

In the June 1966 CACM [1], Wirth and Hoare published "A contribution to the development of ALGOL”, which describes a language very similar to Algol W. In Wirth’s Turing Award lecture (published in the Feb 1985 CACM [2]) "From programming language design to computer construction”, he noted: “The Working Group assumed the task of proposing a successor and soon split into two camps. On one side were the ambitious who wanted to erect another milestone in language design, and, on the other, those who felt that time was pressing and that an adequately extended ALGOL 60 would be a productive endeavor. I belonged to this second party and submitted a proposal that lost the election. Thereafter, the proposal was improved with contributions from Tony Hoare (a member of the same group) and implemented on Stanford University's first IBM 360. The language later became known as ALGOL W and was used in several universities for teaching purposes.” In particular, Hoare’s work on “Record Handling” (see [3]) had a strong impact on Algol W and Wirth’s later languages. [1] http://doi.acm.org/10.1145/365696.3657022 [2] http://doi.acm.org/10.1145/2786.2789 [3] http://www.softwarepreservation.org/projects/ALGOL/standards/. > On Jan 10, 2019, at 7:06 PM, clemc(a)ccc.com wrote: > > From: Clem cole <clemc(a)ccc.com <mailto:clemc@ccc.com>> > To: Dave Horsfall <dave(a)horsfall.org <mailto:dave@horsfall.org>> > Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org <mailto:tuhs@tuhs.org>> > > Dave. The w in Algolw was Wirth. He was at Stanford at the time. It was written in PL/360 btw. The sources are googlable. FWIW Pascal was done a couple of years later with lessons learned from Algolw and reaction to Algol68. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >> On Jan 10, 2019, at 6:52 PM, Dave Horsfall <dave(a)horsfall.org <mailto:dave@horsfall.org>> wrote: >> >> [Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.) >> >> Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language). >> >> -- Dave >

6 years, 6 months

Happy birthday, C.A.R. Hoare!

by Dave Horsfall

[Not sure whether this is more appropriate for COFF instead, so it's here; advice (apart from STFU) gratefully accepted.) Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a computer pioneer (one of the greats) he gave us things like the quicksort algorithm (which became qsort() in Unix) and ALGOLW (a neat language). -- Dave

6 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS