http://invisible-island.net/personal/
Copyright © 2014-2021,2024 by Thomas E. Dickey
Richard "Dick" Wexelblat was a mid-level manager of a research group which I joined in mid-1983 while at the ITT Advanced Technology Center.
Checking for publications at first seems simpler. But there is a catch: most of those are essentially commentary (such as SIGPLAN Notices), some with interesting titles. Here are some (see dblp or the ACM profile):
History of Programming Languages (1981)
That is a reprint of the 1979 ACM SIGPLAN History of Programming Languages conference.
See History of Programming Languages—II (1996) for a sequel.
The Consequences
of One's First Programming Language (1981).
Cited by “Trystan” in Programming, A
Cognitive Systems Perspective, saying
The degree to which programming languages in particular influence cognition has received little attention. An informal survey conducted by Richard Wexelblat (1980) revealed that some programmers believe certain languages can interfere with abstract forms of reasoning such as data-structure design and high level engineering activities. Wexelblat expressed his personal concern over the popularity of “do it quick and dirty” languages, such as BASIC, and the generation of students indoctrinated to them. Although interesting, the usefulness of such self-reports is extremely limited. Accordingly, Wexelblat concludes with a call for controlled studies on the subject. Unfortunately, to my knowledge no such study has ever been conducted. Indeed, it's likely that an experimental approach to such research is not yet sufficiently developed.
Wexelblat moved from one place to another during his career, e.g.,
Aside from his involvement with committees (and general publications), Wexelblat is known as one of the people who received the first PhD in Computer Science. My wording may appear awkward, but there is more than one who might be the first. He was aware of that, mentioning the ambiguity in conversation as having been the first awarded by a Computer Science department.
Others have given more information, but first here is the publication information :
- Title
- A Problem Solving Facility
- Author
- Richard L. Wexelblat
- Organization
- Moore School of Electrical Engineering, Philadelphia PA.
- Abstract
- The objective of the reported work is to set up a computer with a large memory for on-line, real time use to aid in human problem solving, combining the computational abilities of the computer and its ability to store, retrieve and manipulate large masses of data. Information retrieval programs use Multilist techniques to simulate an associative memory. Multilang, the executive language, serves both as a control language and as a programming language.
- Publisher
- Defense Technical Information Center
- Date
- 20 Jul 1965
- Length
- 62 pages
and here are a few articles discussing the various first-PhDs:
According to Ralph London, the first Computer Science department as such was at Purdue, while Wexelblat's school had a group focused on the topic. According to International Biographical Dictionary of Computer Pioneers, edited by John A. N. Lee, Routledge (November 1, 1995), in discussing Saul Gorn said
While he was chair of the university's Graduate Group in Computer and Information Science, the university, under his guidance, granted the first named PhD in computer science ever given anywhere.
Mentioning Saul Gorn brings up the point that those using computers during its first generation likely regarded as pioneers those who had laid the groundwork for what they used, rather than being pioneers themselves.
While in Wexelblat's group, I had a specific task: to provide an assembler for computer chip then under development (a “cellular array processor”), which had no instruction set defined at that point in time. I did have some ideas how to proceed, and produced a workable meta assembler which I named spasm.
While working on the program, I did not pay much attention to the rest of the research/development group. Due to office shortage, at first, I sat on a stool in a storage area/laboratory (but using a BBN BitGraph terminal). The person who brought me into the group was someone I had worked with before, and he left late in the year just after I had completed the program. After that, I reported to Chris Jette for a few months.
I developed the meta assembler on a VAX/VMS system, and when that was working properly (September 1983), ported it to a BSD Unix system that the others in the research group were using. Shortly after, the Unix system was upgraded to 4.2BSD.
The computer was named after Wexelblat, as one might see in a 1984 Usenet map for New England:
Name: wxlvax
Organization: ITT Advanced Technology Center
Contact: Chris Jette, Dick Wexelblat
Phone: (203) 929-7341, Chris x963, Dick x187
Postal-Address: 1 Research Dr., Shelton, CT 06484
Electronic-Address: {decvax!ittvax!wxlvax!}newscontact, jette, rlw
News: ittvax
Mail: ittvax
I recall some discussion regarding how the Unix system was to be managed. The VMS system was run by another group (and cost center), but the research group had more direct control over the Unix system. Someone from the computer services organization worked with a clerical person (who was hired to operate the computer) to set it up.
More than one group used the Unix computer (the people working on the cellular array processor chip constituted the other large group), but Jette and the others in Wexelblat's group wanted to use Franz Lisp, which was available for the newer BSD release.
While Wexelblat's group, via Jette, had control of the computer, the clerical staff did not report to either of them. There were perhaps three or four of those people, who reported to yet another clerical person who was hired to supervise those.
One afternoon I asked Wexelblat if he would help me with an application for senior membership in one of the professional organizations I belonged to. I did that after noticing that several people whose work I was familiar with had done that.
He refused, saying that he was a member of the ACM, and one of the things he liked about the ACM was that they did not have any of that.
Times change:
but none of that affected Wexelblat.
On the other hand, according to ACM's website, Wexelblat received a distinguished service award in 1996 for the SIGPLAN work (apparently the first year for that award). ACM as a whole has done similar awards since 1970.
As a computer user, Wexelblat commented once that
the rm command really should prompt
the user by default, to avoid the consequences of doing this:
orrm -rf /*
and that at least one should guard against it, e.g.,cd / rm -rf *
alias rm 'rm -i'
Much later, I had that incident in mind as I responded to a thread on one of the FreeBSD mailing lists. A quick check of the CVS showed that the check to prevent removing "/" was only superficial and could be bypassed readily.
As a manager, Wexelblat did a few unusual things:
He did not care much for “administrivia” and sent mail telling us that his administrative assistant would fill out our time-sheets. That was cancelled shortly after.
He organized group meetings off-site. The first was at his house (November 3, 1983). I was impressed: he had more books than I did.
But our tastes in books did not coincide. Seeing him outside his office once, I mentioned Douglas Hofstadter's book. Wexelblat responded that he did not care much for that, finding it too “cutesy.” In Brian Hayes' review, I see that some others shared that opinion.
He decided that researchers should all have terminals at home, and obtained terminals (and 1200 baud modems) for us to take home.
My terminal was an Ann Arbor Ambassador 48-line terminal. I took it home and that Saturday started to explore the BSD Unix system. I noticed a directory named games, and (not actually being at work), investigated that. Most were uninteresting, but one, called “snake” was interesting. It recorded scores, and I could see that the others in my group had found it. The highest score was around 600 points, and curious, I found it was not that simple. After about two hours, I got the knack of it, and made a higher score.
While amusing, the home terminal was not immediately useful for much more than checking email. Most of my attention in late 1983 and early 1984 was in the lab at work. Besides developing a few interesting programs (a font editor and a program for removing markup from a Scribe document), we were supposed to be learning Lisp and Smalltalk to work on expert systems.
That lasted until late in March, one Monday morning Wexelblat came in and sat down on the chair next to my stool (resulting in my looking down at him during our conversation).
He said, “I'm afraid I have some bad news for you.”
Don't do that on a Monday morning.
After a pause, he went on to say that a new department was being formed, and that I was one of the ones selected to move.
Oh. I had other thoughts of where he was headed. I had no problem with the move.
Setting up the new department did not happen all at once, anyway. That took a couple of months, and for a while I sat on the same stool each day.
Bill Paulsen had the same opportunity, and thought to ask about the home terminals. Wexelblat said that he wanted us to keep them while we were in the new CAD department.
While I had no problem with the stool, some did. It was on the wrong side of a door.
Referring back to the snake program, the supervisor of the group's support staff had an issue with the door of the lab where my desk was. According to a company policy, only people who were supervisors (or a few senior technical staff) could have doors on their offices, because they had a business need for privacy. Notwithstanding the fact that the door was because it was a storeroom, the fact that I sat there made it an office.
Before continuing, a few interesting points:
The supervisor driving this process was a few steps below me; they were at the lowest step where one could be a supervisor.
They had a door on their office. But it was not always
used productively. On the BSD Unix system, someone had
installed an auditing program which let users see what
commands had been run. For instance, I noticed one user who
apparently did nothing all day except run the
man (manual) and
news (readnews) programs all day.
The supervisor had discovered the snake program. For more than a month, they spent an hour or more every day working to get a better score than I had in just over two hours.
At my next opportunity, I revisited the game, but found that my score was not recorded. Looking closer, I found that a few minutes after the supervisor had achieved a higher score, the system operator had changed the permissions so that scores would no longer be recorded.
Once or twice I had asked the system operator to install something (such as when I had modified dired), but it had not occurred to me that someone would do that. Still, observing someone who spends about a week full time to get a good score on a game says something about who you are dealing with.
Continuing, one day I was over in the storage part of the lab where I had a cabinet of computer printouts. The door opened, and in came one of the moving company's people. He was big (at least 6'8", though he seemed taller). I asked what he wanted. He said “I'm here to move you.” I replied “No, you're not. I haven't been notified. Go back to whoever sent you and tell them that.”
He went. It was 4-5 months before I was notified (via memo, of course).
That put me on the right side of the door.
Continuing, my new desk was a table facing the half-glass wall of the lab where I used to sit. It was part of the area where Tom Slack and two others used to sit. But I had less than a quarter of the space. The remainder of the area was used by one of the clerical staff, whose job it was to look for interesting articles in the newspaper and clip them out into a scrapbook for the director of the research groups.
By the time I was moved outside the lab, I was working in the new CAD department, e.g., the end of summer 1984. On my table I had an Apollo workstation and a Ramtek color terminal. On the floor I had a rather large Tektronix terminal (at the end, because there was not enough room to go around it). I used the Apollo; someone thought I could use the other equipment.
One day, as I was sitting at the computer and working, I heard the two (news-clipper and supervisor) talking. One said to the other, “I don't have enough room” and the reply “I'll see what I can do.” In this case, there was little they could do, but after a few months the management of the CAD department decided it would be best to have everyone sitting closer together. So I moved again.
Things were quiet in that direction for quite a while, but about a year later, Bill Paulsen told me that the supervisor had realized that we still had the terminals, and was taking steps to have our paychecks stopped. We contacted Wexelblat, alerting him to the problem so that he could resolve it. This happened just a few months before the end of our involvement with ITT; I do not recall whether we returned the terminals at that point, or as part of shutting down operations at the technology center.
That series of events spanned more than a year, but was best presented in one piece. During that time, a few other incidents are relevant to my experience with Wexelblat.
Wexelblat had a lot of books; I noticed a full set by Robert Louis Stevenson, which his sons may have enjoyed. At that time, both were in college.
During the summer of 1984 (while I still sat in the lab), Wexelblat created a summer job for one of his sons by having the computer's operator do something else. That let him be the computer operator for the BSD Unix system for the summer.
For the rest of us, that made an awkward situation. I had a manual for the EDT editor (a VMS program unrelated to BSD Unix). The summer operator took it from my desk. At the end of the summer I retrieved it, but it was too badly damaged to be useful anymore.
The following year, early in 1985, Bill Paulsen alerted me to a proposal to revive the research group. I read the proposal, which listed the people they would like to have in the new organization (which by the way, never happened).
I was not listed (I suspected that in Wexelblat's mind, I was that guy who wrote an assembler), but another from my project group was cited as a top researcher. Along with HCAB, there was a block router, based on The Berkeley Building-Block Layout System for VLSI Design (N. P. Chen, E. S. Kuh and C. P. Hsu, January 1983):
Automatic layout design of custom VLSI circuits depends on the building-block hierarchical approach in which macrocells of arbitrary shapes and sizes are given together with the net list. Our aim is to design an intelligent and practical automatic layout system which will interface with other design aids at Berkeley. The BBL system has a general purpose database, a smart global router which can dynamically adjust placement and efficient detailed routers, namely: the channel router and the switch-box router. The System incorporates several novel ideas and is based on a number of graph-theoretical algorithms. Experimental results indicate that the System is extremely effective.
Now… that raises an question: what makes a good researcher? The preferred developer had used others' research and their detailed description of results for a C program which he reimplemented in Fortran. That is, his contribution was the implementation, rather than either the concept or the methodology for evolving a good concept from tradeoffs between different goals. In his presentations, that distinction was lost however. Wexelblat was apparently convinced.
Not all of the implementation used best practices:
At one point I compared the amount of repeated statements (indicating select/paste) in the HCAB system where I was reducing that amount by integrating two phases of the program together—against the block router. HCAB had half as much repeated code (roughly 23% versus 46%).
The block router used the Fortran
assigned goto
several dozen times. Unlike an ordinary
goto, which showed the
destination immediately, the
assigned-code stored a
statement label in a variable, which would be used
later. Interesting things could happen if one passed
the variable to a function to use it there.
All of that was ultimately moot: the developer left to go to another company, where he was productive for a few years. Shortly after he left, ITT decided that they did not need us anymore. Wexelblat and I left in the same direction:
I interviewed at Philips (nice place, friendly people), and found that I would not fit in well enough because I wanted to build useful things (like an engineer) while they wanted to explore ideas which may not pan out. Those issues might have been negotiated, but the downside to the nice location of Philips was that I could not afford to live anywhere near it.
Wexelblat went there, and stayed a couple of years.
I interviewed at IDA, and found it even less suitable. Writing white papers is not a good substitute for building useful things.
Wexelblat went there, and stayed about six years.
Chris Jette appears to have continued in the same field for a while, co-authoring a couple of papers (see dblp), as seen in a 1995 panel discussion
Christina L. Jette is Vice President of Engineering at Ascent Logic Corporation where she leads a development team in the delivery of the largest commercially available SmallTalk application. She has over 13 years of experience managing the development of object-oriented systems in a variety of languages. She previously worked at ITT's Advanced Technology Center on telecommunication support software environments, and at Schlumberger's System Center where she led the development of a next generation well log interpretation system using a LISP based OO substrate and significant reuse.
before moving to Kaleida Labs, then to Blaze Software (leaving that in 1999). A Bloomberg profile at the end of 2018 (now obsolete) said:
Christina Jette serves as Vice President, Product Development of Abgenial Systems Inc. Dr. Jette has over twenty-five years of experience in software management and product development, with a strong emphasis on leading early stage companies. Since 1990, she has held the Vice President for Engineering role at Collabrys, Saqqara Systems, Blaze Software, Kaleida Systems and Ascent Logic. Prior to that she held various technical and management positions at Schlumberger and ITT. She has a PhD and MSc in Computer Science from University of Washington and a BSc in Mathematics from University of Massachusetts.