Loading ...
Sorry, an error occurred while loading the content.

My starting point, short-term and long-term

Expand Messages
  • gac@cs.duke.edu
    I have two different starting points in this discussion, one for short-term issues and one for long-term. Short-term: there s a terrible tension (or perhaps
    Message 1 of 4 , Apr 23, 2001
    • 0 Attachment
      I have two different starting points in this discussion, one for
      short-term issues and one for long-term.

      Short-term: there's a terrible tension (or perhaps "collision")
      between software actions and human attention. I've lost track
      of how many times I've been typing something into a Windows-
      based program, only to discover that mid-word, another program
      has grabbed the focus. That's just a tiny example, of course.
      Why do mobile phones still ring when I'm driving? Or in a
      meeting with my boss?

      In general, technology has shown complete contempt for the
      value of human attention. And I feel like perhaps we've
      been willing to pay so far, but now we're simply tapped out.
      Advances from now on will have to be at least attention-neutral,
      if not attention-improving.

      In the long term (and this follows on Guy's post, I think),
      I'd like to know what it means for software to behave more
      like a living organism. Right now, a piece of software
      is more or less a completely static work: a statue of a horse,
      maybe, but you can't really ride it.

      Can a piece of software change? Learn? Reproduce? Or, if
      a single copy isn't the right unit of analysis, can a species
      of software evolve? Cooperate?

      Can software die? Is it desirable that it would? Immortality
      might sound nice, but I'm reminded of Vernor Vinge's _A Deepness
      in the Sky_, with dashing heroes hacking 8000 years of legacy
      code.

      Geoff
    • Richard P. Gabriel
      ... This reminds me of the goals of the old, old Advice Taker project that John McCarthy proposed around 1960 and which I worked on in the 1980s (!). He was
      Message 2 of 4 , Apr 24, 2001
      • 0 Attachment
        At 21:17 +0000 4/23/01, gac@... wrote:
        >Can a piece of software change? Learn? Reproduce? Or, if
        >a single copy isn't the right unit of analysis, can a species
        >of software evolve? Cooperate?
        >
        >Can software die? Is it desirable that it would? Immortality
        >might sound nice, but I'm reminded of Vernor Vinge's _A Deepness
        >in the Sky_, with dashing heroes hacking 8000 years of legacy
        >code.

        This reminds me of the goals of the old, old Advice Taker project
        that John McCarthy proposed around 1960 and which I worked on in the
        1980s (!). He was interested in programs that could learn, which was
        of interest at the time, but he said that a program that could learn
        was one step beyond one that could be told or taught to do things,
        and so he proposed developing a program that could take advice.

        Several people on this list have talked about how diversity, change,
        learning, and flexibility are important aspects for future software
        while current software practice favors static, inflexible, unchanging
        programs.

        As I look at Geoff's comments above about whether a piece of software
        can change, learn, or reproduce, I ask whether we can get to a place
        where a running system can be changed, be taught or told something
        that changes its behavior permanently, or be copied with changes.
        What many people in computing seem to think today is that, of course
        we can do that. We simply edit the source code, recompile and relink
        or reload it all up, and there you are. But that's installation, not
        changing things on the fly.

        A related story is the one about the e-storefront company that Paul
        Graham started about 6 years ago. You would surf over to the site,
        and if you wanted to start a store, the site would ask questions
        about inventory, images, billing, fulfillment, etc, and then it would
        create a Common Lisp program that was your store, compile it up, and
        run it in the Common-Lisp-based webserver they had. So you'd have
        your store within about 10 minutes. This company was sold to Yahoo
        about 3 years ago for $35m, and YahooStores (or whatever it's called)
        is this program.

        Paul gave a talk a while back on this endeavor, and he was asked what
        aspect of Common Lisp made this easy to do beyond being able to
        compile and execute code on the fly. He said it was keyword
        arguments. In Common Lisp you can define a function to take named
        arguments rather than positional arguments. So you can can call a
        function like this like this:

        (foo :x-position 12 :y-position 13 :thickness 7
        :karmic-capabilities ...)

        This is instead of (actually, in addition to) positional arguments
        (you know an argument's role by its position in the function call).
        Keyword arguments can be supplied in any order, and the function
        definition can specify how to default unsupplied arguments based on
        the values of the others and also on which others were supplied. That
        is, there is a lot of flexibility in supplying arguments and
        defaulting.

        Paul said they made every function in their store take keyword
        arguments only. This way, he said, if someone's store crashed or the
        site crashed, and they discovered that they had made a bad decision
        on the interface to a function, they could retain the old one for
        compatibility while adding (or removing in effect) arguments from the
        function. Then they could just amend the running system and
        *continue* its execution from the failing place without the customer
        even knowing that the system had been revised - it appeared as a
        network slowdown only.

        I recall a discussion I was having sometime in the last 6 months
        where we were talking about how to use standards to effect change.
        The person I was talking was explaining how he put together and set
        an obscure standard for heat and RF emanations from buildings and
        then lobbied Congress to pay attention to it. It worked. In the
        discussion I proposed a standard for well-formed deployed systems
        which would require that the length of time from when edits to a
        1-page "function" (including interface changes) were completed to
        when the running system was amended would be at most 30 seconds.

        I think these two ideas *could* form a way to proceed.

        * Think about the characteristics of running systems, especially
        their changability, that we want and write them down.

        * Try to figure out a way to require or encourage developers and
        computer scientists to create systems with these characteristics,
        either through a "Seal of Approval"-type approach or through
        standards enforcement.

        -rpg-
      • Dave West
        ... I used to annoy my students by insisting if objects were done correctly (i.e. if they were to realize the full potential of the Alan Kay cell metaphor)
        Message 3 of 4 , Apr 24, 2001
        • 0 Attachment
           

          "Richard P. Gabriel" wrote:

          As I look at Geoff's comments above about whether a piece of software
          can change, learn, or reproduce, I ask whether we can get to a place
          where a running system can be changed, be taught or told something
          that changes its behavior permanently, or be copied with changes.
          What many people in computing seem to think today is that, of course
          we can do that. We simply edit the source code, recompile and relink
          or reload it all up, and there you are. But that's installation, not
          changing things on the fly.
           
          I used to annoy my students by insisting if "objects" were done correctly (i.e. if they were to realize the full potential of the Alan Kay cell metaphor) they would have to modifiable at run time.

          Making a single class called object and an object as a collection of messages, methods, and knowledge with the ability to swap out any occurence in any of those collections addressed some design issues.

          Knowledge could be "data" (primitive objects like integers, characters, strings - or collections of same) or it could be rules.

          This meant that the rules would have to be modifiable at runtime as well.  This led to the idea of "self evaluating rules" which one of my former students and I then created.  (We wrote a paper on them which was never submitted for publication because we wanted to add stuff about applications and editors.)

          Our self-evaluating-rules ended up being a reification of the Smalltalk expressions (unary, binary, keyword).  So we have the means to "write programs" on the fly at run time.  (Subject to the existence of a VM to interpret those programs of course.)

          When I return to school for a second Ph.D. (in CS this time) in the fall, I intend to use these ideas to explore artificial life models for my dissertation.

          davew

        • Joshua L. Kerievsky
          I was too darn tired to come and our baby Sasha was feverish (she s better now). I ve been going non-stop for weeks now and it is catching up with me. I did
          Message 4 of 4 , May 6, 2001
          • 0 Attachment
            I was too darn tired to come and our baby Sasha was feverish (she's better
            now). I've been going non-stop for weeks now and it is catching up with me. I
            did buy tickets and arrange to come but I had to stop myself the night before I
            came. I'm sorry about that and about missing it. I'd love to know how it
            went.

            best,
            jk
          Your message has been successfully submitted and would be delivered to recipients shortly.