Over at Bill Seymour’s, I made the mistake of getting into the topic of comparative programming languages. Ow. My bad!
A guy named R. Murphy (he claimed that Murphy’s Law was written in his honor but I doubt it) was one of the team I worked with at the ULTRIX Resource Center at Digital. The URC was a pre-sales group – our job was to help positively influence sales by showing prospective customers that Digital had the capabilities to solve their problems. Or something like that. It was a great job for a young, energetic, systems guy who wanted to learn absolutely everything there was to learn about computing, specifically UNIX environment. I got pulled into some really weird and wonderful projects including a few tech demos that went on to become products for the customer, that one time literally made billions off of the code. In those days I was living in the academic mindset my parents raised me in: tell all you know, publish or perish, and if you move harder and faster than everyone else nobody can catch up to you.
The way it worked, my boss and mentor, Fred A. had a meeting each week, with the current project list, and we briefly summarized where we were. If Fred had a new thing come in, he’d have a 1 page writeup in the form of: problem statement, logistics and timeline, contact info, notes on possible resources. He’d go through the stack of writeups (usually only one or two) and hand them off to the team; there were 4 of us. From there, Fred’s role was to bulldog things, offer advice, and make introductions if we needed more resources. Fred knew everyone in the company, so one time I was having trouble with a device driver interrupt for a synchronous I/O capture card and Fred said, “wait” and called Matt T (“the Code Warrior”) who solved the problem for me in 2 minutes of extremely dense code, recited over the phone. Literally, Matt wrote a driver patch for a multiprocessor-safe driver, off the top of his head and it did the crucial part for me and then I added on all the chassis stuff.
Anyhow, one day Fred had a project that was a 2 person gig. We needed to implement a framework demo for a logistical system for a client so they could benchmark it against a similar thing Sun was doing. HP was in the mix, too. So we needed to scope a database, write network APIs for it (there was a time when not all databases were networked) it had to be fault tolerant to a degree, and there needed to be a user interface forms capability for adding and searching and fiddling with the data. Fred gave it to me and Murphy. We repaired to Murphy’s office (which meant: standing outside while he smoked cigarettes) and divvied the work up. I proposed to do the network stuff because at the time I was a good sockets programmer and Murphy nodded and said, “I’ll do all the UI stuff. I’ve done a lot of that.” We agreed to check in on eachother at the end of the next day, and went off to our cubicles.
Murphy is the old schoolest old school DECcie. I remember when he used to hang out on comp.sys.dec and sometimes someone would buy a PDP-8 at a computer fair and try to get it running. They’d post something like, “I powered it up and all it says is ‘4J'” Murphy’d follow up instantly, “that’s a diag code; make sure the I/O processor is correctly seated in the unibus. If it does it again, enter ‘JC3 IPL’ and tell me what it says.” That kind of stuff. Murphy had been a field service guy for the first PDPs, see… He was like that about everything. We all regarded him with an awe close to worship. I, literally, wanted to be like him when I grew up.
So I went back to my cube, hopped onto my hotrodded DECStation 3100, and started putting together a socket-based API atop a database running on a MicroVAX (because at the time VMS databases were much better than the stuff available on UNIX) and having a whale of a good time coding away like a rabid squirrel. Picture the Squirrel in Ice Age – that’s how I coded in those days.
At the end of the next day, I dropped by Murphy’s office and as he lit up I told him where I was and concluded I’d have my part working in another day or 2 and we could integrate around the APIs I had put together. Murphy nodded. I asked him how he was coming along. “Oh, it’s done.” What?!
I honestly don’t know what I expected Murphy to do, because I was not at all worried about his part of the project and was totally head down in mine. I guess I expected he’d get stuck into some kind of curses-based thing, writing a scripting system for placing cells on the screen or whatever. Nah, Murphy had used COBOL. What?! Then he gently explained that there were programming languages written specifically to do forms on screen and, basically, all the stuff he was supposed to be doing, and what he had done yesterday was finish his cigarette then wander back into his office and threw together his side of the system. Total time: 25 minutes. Then he cocked an eyebrow at me and said, “the best part is I don’t have to test anything because the way it works is – if it works at all, it works perfectly. I, of course, had been whacking away in C/UNIX sockets land, where you’ve got to worry intensely about race conditions and buffer space and stuff like that. Murphy had simply picked up the right tool for the job. [Nowadays, of course, it would have been a simple matter of using an SQL engine and some of the many existing APIs to talk to a networked SQL engine, but that stuff literally did not exist at that time – collectively, computing was in the process of figuring out that a common network database capability would be a good thing.]
I worked as a consultant at the database research group at University of Maryland for a while (UMIACS) with some really amazing people. The project was … another networked database. It had been developed as a consulting offering for NASA under contract, and was not working right. It was a sort of interesting problem because (to my knowledge there still aren’t) debugging distributed applications is a tricky problem, especially if there are timing problems and race conditions. The application had been developed using Sun Microsystems’ remote procedure call system (RPC) which was basically an API for exporting APIs between multiple systems over a network. As I dug in, I concluded there was something wrong with how RPC was working. It was ugly. I obtained the source code for the RPC layer and developed my own debugging layer for RPC, in which all the parts of the procedure calls reported synchronously to a central log that I could monitor. Oddly, that solved the problem. Uh-oh. So I had to keep digging and it turned out that RPC communications used un-connected networking, with a timeout and a retransmit. UDP packets. If the database was slow responding, the RPC layer went “aha, must have lost the packet containing our query” and re-sent it. So, the database was crunching away on the query contained in the first packet, when another copy of the query came flying in, and it started crunching away again and… if there were caching effects in the database, the database eventually caught up and the RPC layer threw away all the duplicate replies but sometimes the database would just get buried behind a queue of identical queries. So, I wrote a TCP-based query stack that didn’t need to retransmit, and waited (much more efficient) and suddenly the whole system was more reliable and hundreds of times faster. Job done! So, they let me go. From there I went to Welch Medical Library researching hypertext stuff for the National Library of Medicine and Howard Hughes Medical Institute, and was in on the early stage of the Human Genome Mapping project, and also did some experiments with reverse-engineering phototypesetting systems and implemented “distributed tocs and docs” which was basically a web-like thing, implemented as a shell script, in 1989. OOps. I didn’t make any attempt to do anything with it beyond show it to a few people who said “that’s cool but aren’t you supposed to be working on something else?”