Jim's Coredump

Last week in Barcelona, I had an interesting conversation with Koen De Bosschere, the editor of ACM Transactions on Architecture, Compilers, and Optimization (TACO), about the computer science publication process. His contention is that the CS community's publication process, which treats conferences as the primary and certainly the most prestigious publication venues, is a major cause of gender inequality in the CS academic and research community. Because women are primarily responsible for child care, they quickly realize that regular travel to conferences is incompatible with a family but is necessary for career advancement. Hence many women leave the research field. In addition, conferences put researchers at non-US schools at a disadvantage because of the cost in money and time of attending conference that primarily occur in the US, and because of the airplane travel, is not sustainable. Koen argued for making fast-turnaround journal publication (as he is doing with TACO) th

The April 8, 2017 edition of the Economist had two articles whose juxtaposition amused me. The first was an excellent story “ Computers security is broken from top to bottom ” and the second “ How hospitals could be rebuilt, better than before ” described the virtues of increased computer usage in hospitals. I sent the Economist the following letter: F. Scott Fitzgerald wrote that a first rate intelligence is the ability to hold two opposing ideas in the mind at the same time and still retain the ability to function. I must commend the Economist for publishing “How hospitals could be rebuilt, better than before” and “Computer security is broken from top to bottom” in the same newspaper. More computers in healthcare; what could go wrong? (see article 2) More seriously, several crucial segments of the world economy — finance, communication, and transportation — can no longer function without computers. In a few years, other important industries automobile and healthcare most p

Many – but not all –   software developers would probably rather learn COBOL than capture and analyze in a research-type paper  the systems they have constructed . But, contrary to popular belief, research papers are one of the best way to capture the important aspects of a system in a concise and usable form. All developers should write (or be made to write) a paper when they do something that is worth sharing with others. [A paper does not need to be an academic research paper. It could be a detailed blog post like Joe Duffy's Blog , which contains the equivalent information in a less formal format.] It cannot be a system architecture description – hundreds of pages of detailed, hierarchical description that no one can (or does) read. Let me tell you a cautionary tale how Microsoft threw away $100 million, with little or no return, because developers said, “writing papers is not part of my job”. In Microsoft Research, Galen Hunt and I ran the Singularity project to write

Jim Gray was a pioneer in database systems and Turing award winner, but he was also a truly nice guy who went out of his way to support other researchers. When I was working at Microsoft Research, I wrote him email complaining about a paper being rejected, and got this reply from him: From: Jim Gray Sent: Tuesday, July 04, 2000 1:51 AM To: Jim Larus Cc: Michael Parkes Subject: RE: Visit? well, the <omitted> paper is in good company (and for the same reason). The B-tree paper was rejected at first. The Transaction paper was rejected at first. The data cube paper was rejected at first. The five minute rule paper was rejected at first. But linear extensions of previous work get accepted. So, resubmit! PLEASE!!! We did, and the paper was published. But, I value Jim's response more highly than the paper, and since then I have added to his list. My favorite is that T im Berners-Lee's paper on the World-Wide Web was rejected as a full paper at Hypermedia &#

The NY Times asked the wrong question about the Obama administration’s response to Russian hacking of the November US election ( " U.S. Reacting at Analog Pace to a Rising Digital Risk, Hacking Report Shows" ) .  The question is not why did it took 16 months to develop a response, but what could the US have done to prevent it? The disturbing answer is nothing. Computers are fundamentally insecure, and this sad situation is not going to change quickly. As someone who has spent his entire career computer science research, it pains me greatly to admit that Donald Trump is right when he told reporters “ You know, if you have something really important, write itout and have it delivered by courier, the old-fashioned way. Because I'll tell you what: No computer is safe."  Computers’ original sin is that they run software that is written by humans. People make mistakes at a predictable rate – roughly 10-20 defects per thousand lines of code. Testing can find and el