4 ms·

Tell me the stories, and I'll comment on them. If you are computing on a $1000 computer, you are computing in the past. Part of the idea here is that you want

Tell me the stories, and I'll comment on them. If you are computing on a $1000 computer, you are computing in the past. Part of the idea here is that you want to do research and development on supercomputers of the present that will give you the resources that will be available at lower prices in the future. With salaries as they are today -- and real estate much worse -- it is actually more expensive to fund the same kinds of research today. The past was similar to today in that most people in computing back then were orbiting around some local vendor's and local fads notions of computing. And it was a lot harder to make computers and other tools back then. It wasn't a crazy professor having an impact back then, but a whole research community that was required to make an impact.

david927 10y ago
The stories I know came from Dealers of Lightning and what I remember (correctly I hope) is that the weekly meetings were quite contentious and that he would even encourage haranguing the presenter. Is that true? Did the people there feel it as healthy constructive criticism? I would worry that this would more likely stifle creative thought than encourage it. If you are computing on a $1000 computer, you are computing in the past. I know that this was true in the past but it's my contention that hardware has had Moore's Law where software has stagnated, and that the passing of time has meant that now current software doesn't often take full advantage of the hardware available. If you did architect based on where the puck is going (optimized for multi-core, no main memory) current hardware wouldn't slow you down the same way as it did before and sometimes you would even see a performance gain. By the way, thanks for doing this.
- alankay1 10y ago
  The research community was "an arguing community", and knew how to argue "in good ways" (i.e. no personal attacks, only trying to illuminate the issues, etc.) This worked pretty well almost always ... (The weekly meetings were not for being creative, but for discussion ...) Let me respectfully disagree with your contention. The point that is missed is not what the hardware could do, but what can you do without optimizing. It is very very hard to put on the optimization hat without removing the design hat, and once you've removed the latter you are lost. The key to the Parc approach was to be able to do many experiments in the future without having to optimize. (There was a second part to this "key" but I'll omit it here)
  - david927 10y ago
    I should have assumed, given the results that PARC had, that it must have been that way. It's fantastic that I just got the answer to that question from... you. For my second point -- I definitely didn't mean optimization that way. I guess the word I meant to use was "targeted", as in "targeted for multi-core" but I see your point and respect it fully. I'm thrilled and deeply, deeply honored to have had this time with you, Dr. Kay. Thank you so much again. If you're ever in the Bay Area on the first Saturday of the month and feel inclined to stop briefly by the 2020 group meeting (which is an attempt at a replacement for the Future of Programming Workshops that used to take place at Strange Loop), we would be over the moon. You can reach out to Jonathan Edwards if you need the details.
    - alankay1 10y ago
      The basic principle of both points above is that "problem finding" is the hardest thing in "real research", so a lot of things need to be done to help this ... (this is a very tough sell and even "explain" today -- almost everyone is brought up -- especially in schools -- to solve problems, rather than to actually find good ones) -- and virtually all funders today want to know what problems their fundees are going to solve - so they underfund (to the point of 0!) the finding processes ... The ARPA/Parc process "funded people, not projects" -- and today this seems quite outre to most. As you probably know, Jonathan is doing some work with us ...
      - david927 10y ago
        Yes I know about Jonathan, which is why I mentioned him because I didn't want to publish the details of the group here and he's been something like an adviser to the group. And that group is probably also the reasons for my views. I would never qualify to be in HARC and yet I don't just want to be content to scorn the state of the industry and state of the art. I see that there's additionally interesting research coming from garages and weekend projects. I feel that "problem finding" is somewhat interchangeable with "point of view" and that can come from surprising sources. Funding might be needed for the hardware but my own experience, for what it's worth, hasn't borne that out. The main component then is time, and while weekends aren't much, they'll have to suffice. The last step is to see if we can't get further as a community, giving that feedback so critical at PARC, and so that is why the group was created.

david927 10y ago

The stories I know came from Dealers of Lightning and what I remember (correctly I hope) is that the weekly meetings were quite contentious and that he would even encourage haranguing the presenter. Is that true? Did the people there feel it as healthy constructive criticism? I would worry that this would more likely stifle creative thought than encourage it. If you are computing on a $1000 computer, you are computing in the past. I know that this was true in the past but it's my contention that hardware has had Moore's Law where software has stagnated, and that the passing of time has meant that now current software doesn't often take full advantage of the hardware available. If you did architect based on where the puck is going (optimized for multi-core, no main memory) current hardware wouldn't slow you down the same way as it did before and sometimes you would even see a performance gain. By the way, thanks for doing this.

alankay1 10y ago
The research community was "an arguing community", and knew how to argue "in good ways" (i.e. no personal attacks, only trying to illuminate the issues, etc.) This worked pretty well almost always ... (The weekly meetings were not for being creative, but for discussion ...) Let me respectfully disagree with your contention. The point that is missed is not what the hardware could do, but what can you do without optimizing. It is very very hard to put on the optimization hat without removing the design hat, and once you've removed the latter you are lost. The key to the Parc approach was to be able to do many experiments in the future without having to optimize. (There was a second part to this "key" but I'll omit it here)
- david927 10y ago
  I should have assumed, given the results that PARC had, that it must have been that way. It's fantastic that I just got the answer to that question from... you. For my second point -- I definitely didn't mean optimization that way. I guess the word I meant to use was "targeted", as in "targeted for multi-core" but I see your point and respect it fully. I'm thrilled and deeply, deeply honored to have had this time with you, Dr. Kay. Thank you so much again. If you're ever in the Bay Area on the first Saturday of the month and feel inclined to stop briefly by the 2020 group meeting (which is an attempt at a replacement for the Future of Programming Workshops that used to take place at Strange Loop), we would be over the moon. You can reach out to Jonathan Edwards if you need the details.
  - alankay1 10y ago
    The basic principle of both points above is that "problem finding" is the hardest thing in "real research", so a lot of things need to be done to help this ... (this is a very tough sell and even "explain" today -- almost everyone is brought up -- especially in schools -- to solve problems, rather than to actually find good ones) -- and virtually all funders today want to know what problems their fundees are going to solve - so they underfund (to the point of 0!) the finding processes ... The ARPA/Parc process "funded people, not projects" -- and today this seems quite outre to most. As you probably know, Jonathan is doing some work with us ...
    - david927 10y ago
      Yes I know about Jonathan, which is why I mentioned him because I didn't want to publish the details of the group here and he's been something like an adviser to the group. And that group is probably also the reasons for my views. I would never qualify to be in HARC and yet I don't just want to be content to scorn the state of the industry and state of the art. I see that there's additionally interesting research coming from garages and weekend projects. I feel that "problem finding" is somewhat interchangeable with "point of view" and that can come from surprising sources. Funding might be needed for the hardware but my own experience, for what it's worth, hasn't borne that out. The main component then is time, and while weekends aren't much, they'll have to suffice. The last step is to see if we can't get further as a community, giving that feedback so critical at PARC, and so that is why the group was created.