Alan Kotok died May 26, 2006. He was 64 years old. Alan was one of the original hackers and a contributor to Spacewar, the world's first video game, which ran on a PDP-1 computer at MIT. His obituary is in the June 3, 2006 New York Times. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Good grief, he was a panelist at the Computer Museum PDP-1 celebration a couple of weeks ago,a dn seemed just fine! (Although he couldn't remember how to turn on the HALT STORE console indicator lamp.) --rwg
At 04:49 PM 6/3/2006, R. William Gosper wrote:
Good grief, he was a panelist at the Computer Museum PDP-1 celebration a couple of weeks ago,a dn seemed just fine! (Although he couldn't remember how to turn on the HALT STORE console indicator lamp.) --rwg
NYTimes: Alan Kotok, 64, a Pioneer in Computer Video Games, Is Dead By JOHN MARKOFF Published: June 3, 2006 Alan Kotok, a computer designer who helped create the first video game program as a member of a small group of M.I.T. students in the early 1960's, died at his home in Cambridge, Mass., on May 26. He was 64. The cause was a heart attack, his daughter, Leah Kotok, said. As a student at the Massachusetts Institute of Technology, Mr. Kotok developed an interest in computers after joining the M.I.T. Model Railroad Club in the late 1950's. Its membership included several other young men who shared his interest, and the organization became a kind of incubator for the computer design field. The students were the original computer hackers, at least as they defined the term. Today it also refers to a computer outlaw, but the term originally described a member of a subculture of passionate hardware and software designers. A "hack" was a project without constructive end, according to a dictionary compiled by the Model Railroad members. Their original video game, Spacewar, was designed in 1962 as a hobbyist project on an early Digital Equipment PDP-1 computer. Spacewar was the original "twitch" game, requiring lightning reflexes. Each player used keyboard controls or a joystick to maneuver a tiny ship able to fire a stream of torpedoes as it slid across the screen. The leader of the group, Steve Russell, was a procrastinator, and although the group passionately discussed a video game with a science-fiction theme, he delayed writing the necessary code until Mr. Kotok drove to Digital Equipment and returned with a paper tape containing the necessary math subroutines. Though Mr. Kotok did not write any part of the original code, he was an inspiration to the group and contributed to the game's design, Mr. Russell said yesterday. Neither man foresaw the creation of an entertainment medium that would one day be a ubiquitous aspect of popular culture. "The only money I made from Spacewar was as a consultant for lawsuits in the video game industry in the 1970's," Mr. Kotok said in an interview in 1990. "I have all this fame, but it's in a very narrow circle." Mr. Kotok was born in Philadelphia. He entered M.I.T. as a 16-year old prodigy, having skipped two grades. He received a bachelor's and a master's degree in electrical engineering there. As an undergraduate he was involved in the design of chess-playing computer programs with the computer scientist John McCarthy, and his work became the basis for his thesis. He went on to spend 34 years at Digital Equipment in a number of roles. He was the chief architect of the PDP-10 family of computers and a senior consultant to Digital's Alta Vista project, an early Internet search engine. More recently he was the associate chairman of the World Wide Web Consortium, an Internet standards organization. Besides his daughter, of Ashburnham, Mass., he is survived by a stepson, Daryl Beck, of Greenfield, Mass.; and a stepdaughter, Frederica Beck, of Prescott, Ariz.
Markoff is remarkably accurate, although it is a crime that tangential involvement with Spacewar outweighs
He went on to spend 34 years at Digital Equipment in a number of roles. He was the chief architect of the PDP-10 family of computers [...] Starting with the PDP-6. These have to have the most beautiful order codes of any machine ever, and should have had a greater influence on future architectures and languages. --rwg
Hennessey & Patterson's book "Computer Architecture: A Quantitative Approach" put the last nail in the coffin re pretty order codes: http://citeseer.ist.psu.edu/context/386764/0 Any mention in a modern computer architecture class of pdp-6/10, etc., order codes elicits the same sort of giggles that are also associated with Lionel train sets, tie bars, pocket protectors and slide rules. An inconvenient truth is that those things got us to the Moon, and (at least as of yet) WinXP & 4GHz Pentia haven't been able to get us back there. I'm afraid we're now all considered dinosaurs. At 03:43 AM 6/4/2006, R. William Gosper wrote:
Markoff is remarkably accurate, although it is a crime that tangential involvement with Spacewar outweighs
He went on to spend 34 years at Digital Equipment in a number of roles. He was the chief architect of the PDP-10 family of computers [...] Starting with the PDP-6. These have to have the most beautiful order codes of any machine ever, and should have had a greater influence on future architectures and languages. --rwg
Some of us think that the Hennesey and Patterson book is the worst thing to happen to computer architecture ever. The obsession with performance, as measured by broken benchmarks written in languages which are incapable of rational expression made the entire field a bad joke. The only thing that saved their collective butt was the improvement in silicon technology. Imagine what we could do with that technology and a decent architecture and language. On Jun 4, 2006, at 1:39 PM, Henry Baker wrote:
Hennessey & Patterson's book "Computer Architecture: A Quantitative Approach" put the last nail in the coffin re pretty order codes:
http://citeseer.ist.psu.edu/context/386764/0
Any mention in a modern computer architecture class of pdp-6/10, etc., order codes elicits the same sort of giggles that are also associated with Lionel train sets, tie bars, pocket protectors and slide rules. An inconvenient truth is that those things got us to the Moon, and (at least as of yet) WinXP & 4GHz Pentia haven't been able to get us back there.
I'm afraid we're now all considered dinosaurs.
At 03:43 AM 6/4/2006, R. William Gosper wrote:
Markoff is remarkably accurate, although it is a crime that tangential involvement with Spacewar outweighs
He went on to spend 34 years at Digital Equipment in a number of roles. He was the chief architect of the PDP-10 family of computers [...] Starting with the PDP-6. These have to have the most beautiful order codes of any machine ever, and should have had a greater influence on future architectures and languages. --rwg
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
I hope that people realize that I agree with TK. Sometimes irony doesn't come through very well via email. At 11:28 AM 6/4/2006, Tom Knight wrote:
Some of us think that the Hennesey and Patterson book is the worst thing to happen to computer architecture ever. The obsession with performance, as measured by broken benchmarks written in languages which are incapable of rational expression made the entire field a bad joke. The only thing that saved their collective butt was the improvement in silicon technology. Imagine what we could do with that technology and a decent architecture and language.
On Jun 4, 2006, at 1:39 PM, Henry Baker wrote:
Hennessey & Patterson's book "Computer Architecture: A Quantitative Approach" put the last nail in the coffin re pretty order codes:
http://citeseer.ist.psu.edu/context/386764/0
Any mention in a modern computer architecture class of pdp-6/10, etc., order codes elicits the same sort of giggles that are also associated with Lionel train sets, tie bars, pocket protectors and slide rules. An inconvenient truth is that those things got us to the Moon, and (at least as of yet) WinXP & 4GHz Pentia haven't been able to get us back there.
I'm afraid we're now all considered dinosaurs.
Lacking background about order codes (what is it?) and not a native english speaker I may miss the point here. Anyway: * Tom Knight <tk@csail.mit.edu> [Jun 05. 2006 08:29]:
Some of us think that the Hennesey and Patterson book is the worst thing to happen to computer architecture ever. The obsession with performance,
Me: obsessed with performance. What exactly is _bad_ about it?
as measured by broken benchmarks
Hmmm... my copy of H/P "Computer Architecture, A Quantitative Approach" is the second edition. It is very critical about benchmarks, see pp.21ff Synthetic benchmarks and MIPS get a royal spanking at pp.44ff
written in languages which are incapable of rational expression made the
FORTRAN, and C However, these are compiled, at least today, to machine code that is very close to what a highly experienced coder can achieve with pure assembly. 99.9 percent of all programmers will not be able to improve on what the compiler emits. Assuming you'd like to see lisp here: wouldn't lisp-benchmarks just show how close the algorithms in the lisp-engine come to peak performance? And then, isn't lisp written in C? :o)
entire field a bad joke.
I've seen enough art for art's sake publications in computer science to be very happy about H/P's approach. I wish there was a up to date (wrt. current CPUs) edition.
The only thing that saved their collective butt was the improvement in silicon technology. Imagine what we could do with that technology and a decent architecture and language.
What should it look like? CPU: for some reason internal-RISC, external-CISC seems to have won the race. Note how spectacular the latest approach (Itanium) has failed. Surely not for lack of budget. Language: ruby, python, caml, scheme, ... All bad? Not naming nose-to-CPU languages here (such as C).
On Jun 4, 2006, at 1:39 PM, Henry Baker wrote:
Hennessey & Patterson's book "Computer Architecture: A Quantitative Approach" put the last nail in the coffin re pretty order codes: [...]
me clueless, jj
Your understanding of English is just fine. "Order codes" are "instruction sets" ("ISA's" in modern computer architecturese). Unfortunately, we're going to have to take this particular discussion off-line, as it is very long and (to the non-interested) very obscure. An emphasis on "performance" is wonderful, but it begs the question about what you're trying to optimize. The use of benchmarks is intended to provide the corpus that you use to evaluate the ISA. The hope is that the benchmarks will be representative of "real" programs, so that not only will the benchmarks run fast, so will the "real" programs. So the choice of benchmarks is critical to the end result of the optimization process. Unfortunately, computer languages also follow Zipf's Law, which means that if you want improvement in the implementation of a very complex system with thousands of different algorithms & modes, you may have to consider hundreds of portions of the code -- i.e., if you sort the "hot spots" in the code in order of popularity, even the hundredth most popular has a measurable influence. So small benchmark sets cannot possibly provide good enough coverage to adequately represent "real" systems. As I have argued in a series of papers in the early 1990's, many benchmarks themselves are flawed, because they don't solve the actual problem they are intended to solve in the best possible way. Thus, any ISA optimization that utilizes such a benchmark will enshrine bad programming practise because the "bad" programs will run faster than they "should", and the "good" programs will run slower than they "should". I don't know what benchmarks are currently being used, so the following example isn't accurate, but it may give you an idea what I'm talking about. Suppose that a benchmark uses a suboptimal "bubble sort" algorithm (O(n^2)) instead of a more efficient (O(n*log(n))) recursive algorithm. Any ISA that is optimized utilizing this benchmark will place a greater emphasis on the shuffling the data, than on making sure that the recursion is fast. I think that ISA's should be designed to reward good programmers rather than penalize them. There's an even longer discussion about what constitutes a "good" programming language. The human race has been programming for somewhere between 60-80 years (depending upon whether you want to go back to Church or Von Neumann), whereas human language has probably been around for perhaps 100,000-500,000 years. I would claim that progress in programming languages still has some ways to go, but most CS textbooks consider computer languages to be a dead issue (= solved problem), and C/C++/C#/Java are the culmination. I would imagine that this is another of the issues that TK was trying to touch on. I don't know who corrupted the phrase "lies, damned lies, and statistics" into "lies, damned lies, and benchmarks", but it is probably even more true of benchmarks. Following Euler's/Gauss's Law (the name on a theorem is almost always wrong), this famous phrase is usually attributed to Twain or Disraeli, but in fact, Twain incorrectly attributed it to Disraeli: http://www.york.ac.uk/depts/maths/histstat/lies.htm At 12:30 AM 6/5/2006, Joerg Arndt wrote:
Lacking background about order codes (what is it?) and not a native english speaker I may miss the point here. Anyway:
* Tom Knight <tk@csail.mit.edu> [Jun 05. 2006 08:29]:
Some of us think that the Hennesey and Patterson book is the worst thing to happen to computer architecture ever. The obsession with performance,
Me: obsessed with performance. What exactly is _bad_ about it?
as measured by broken benchmarks
Hmmm... my copy of H/P "Computer Architecture, A Quantitative Approach" is the second edition. It is very critical about benchmarks, see pp.21ff Synthetic benchmarks and MIPS get a royal spanking at pp.44ff
written in languages which are incapable of rational expression made the
FORTRAN, and C However, these are compiled, at least today, to machine code that is very close to what a highly experienced coder can achieve with pure assembly. 99.9 percent of all programmers will not be able to improve on what the compiler emits.
Assuming you'd like to see lisp here: wouldn't lisp-benchmarks just show how close the algorithms in the lisp-engine come to peak performance? And then, isn't lisp written in C? :o)
entire field a bad joke.
I've seen enough art for art's sake publications in computer science to be very happy about H/P's approach. I wish there was a up to date (wrt. current CPUs) edition.
The only thing that saved their collective butt was the improvement in silicon technology. Imagine what we could do with that technology and a decent architecture and language.
What should it look like?
CPU: for some reason internal-RISC, external-CISC seems to have won the race. Note how spectacular the latest approach (Itanium) has failed. Surely not for lack of budget.
Language: ruby, python, caml, scheme, ... All bad? Not naming nose-to-CPU languages here (such as C).
On Jun 4, 2006, at 1:39 PM, Henry Baker wrote:
Hennessey & Patterson's book "Computer Architecture: A Quantitative Approach" put the last nail in the coffin re pretty order codes: [...]
me clueless, jj
participants (5)
-
Eugene Salamin -
Henry Baker -
Joerg Arndt -
R. William Gosper -
Tom Knight