3 ms·

I agree with the OP that junk programming will likely die. But so will junk math. I don't think programming is going to be automated anytime soon, but I'd imagi

by jart 7y ago

I agree with the OP that junk programming will likely die. But so will junk math. I don't think programming is going to be automated anytime soon, but I'd imagine that the inputs of an optimizer capable of doing so would look more like vagueish business goals and policy constraints that businessmen / politicians like to write, rather than some functional monad, which I guess is why they still continue to be the master character classes of humanity.

mattkrause 7y ago
I'm skeptical of these sorts of claims for two reasons. 1. Creativity. What objective function do you optimize to write the first Super Mario Bros? Can you then get from there to RocketLeague or Braid? (I think not). 2. Imagine that you somehow obtain a magical technology that takes in a natural language spec and emits highly-optimized code, just like a human. Who's writing that spec? For interactions with actual humans, there's usually a professional drafter (lawyer, contracting officer, etc) carefully specifying what the other parties should and should not do. We'd presumably need the same thing even with some fancy AGI. This is perhaps a bit different from worrying about whether foo() returns a Tuple or List, but it's not totally dissimilar from programming.
- qqii 7y ago
  I agree with your first point, such objective function would have to optimise something extremely abstract like player enjoyment. As for the second, the point is not to have a specificition on the human side. Most of the time when communicating with others we don't need lawyers, and spoken contracts are valid and by law. Even with lawyers contracts can be disputed in court as there is not a formal definition of every exact scenario. Assuming we had the power to do (1), all we'd need in (2) is something that doesn't provide unexpected outcomes.
  - mattkrause 7y ago
    If you don't have some kind of specification, how are you going to control what you get? It's true that you can turn to a teammate and say "hey, can you write me a pipeline to import data from JSON files?" and you'll usually get something usable. However, you and your teammates have shared goals and background information about your particular project and the world at large, etc. Projects go off the rails all the time because the generally intelligent (allegedly, anyway) humans don't share these things. Right now, the front page has an article called "Offshoring roulette" about this. If you don't want to click through, here's my story about a contract programmer working in the lab. I asked him to look into a problem: the software running our experiments crashed after a certain number of events occurred. It turned out that the events were being written into a fixed-size buffer, which was overflowing. This could have been fixed in many ways (flush it to disk more often, record events in groups, resize the buffer). However, he chose to make the entire saving function into a no-op. This quickly "fixed" the problem--but imagine my delight when the next few runs contained no data whatsoever. In retrospect, although this guy had a PhD, he wasn't particularly interested in the broader context, namely that it crashed while collecting data that I wanted. An optimizer is going to take all kinds of crazy shortcuts like that unless it's somehow constrained by the spec. You could certainly imagine building lots of "do-what-I-mean" constraints into this optimizer but that requires even more magic.
qqii 7y ago
As with some of the other commenters, I don't fully agree. Programming is messy, and most end users don't care about the beautiful abstractions you used. Junk programming will always exist, and just good enough programming will always be the mainstream. When I'm purchasing a chair, I don't normally care about the detailed specifics of wood types, craftsmanship and the specifics of the joins, nor doesn't matter if a master craftsman doesn't approve.

by jart 7y ago

mattkrause 7y ago

I'm skeptical of these sorts of claims for two reasons. 1. Creativity. What objective function do you optimize to write the first Super Mario Bros? Can you then get from there to RocketLeague or Braid? (I think not). 2. Imagine that you somehow obtain a magical technology that takes in a natural language spec and emits highly-optimized code, just like a human. Who's writing that spec? For interactions with actual humans, there's usually a professional drafter (lawyer, contracting officer, etc) carefully specifying what the other parties should and should not do. We'd presumably need the same thing even with some fancy AGI. This is perhaps a bit different from worrying about whether foo() returns a Tuple or List, but it's not totally dissimilar from programming.

qqii 7y ago
I agree with your first point, such objective function would have to optimise something extremely abstract like player enjoyment. As for the second, the point is not to have a specificition on the human side. Most of the time when communicating with others we don't need lawyers, and spoken contracts are valid and by law. Even with lawyers contracts can be disputed in court as there is not a formal definition of every exact scenario. Assuming we had the power to do (1), all we'd need in (2) is something that doesn't provide unexpected outcomes.
- mattkrause 7y ago
  If you don't have some kind of specification, how are you going to control what you get? It's true that you can turn to a teammate and say "hey, can you write me a pipeline to import data from JSON files?" and you'll usually get something usable. However, you and your teammates have shared goals and background information about your particular project and the world at large, etc. Projects go off the rails all the time because the generally intelligent (allegedly, anyway) humans don't share these things. Right now, the front page has an article called "Offshoring roulette" about this. If you don't want to click through, here's my story about a contract programmer working in the lab. I asked him to look into a problem: the software running our experiments crashed after a certain number of events occurred. It turned out that the events were being written into a fixed-size buffer, which was overflowing. This could have been fixed in many ways (flush it to disk more often, record events in groups, resize the buffer). However, he chose to make the entire saving function into a no-op. This quickly "fixed" the problem--but imagine my delight when the next few runs contained no data whatsoever. In retrospect, although this guy had a PhD, he wasn't particularly interested in the broader context, namely that it crashed while collecting data that I wanted. An optimizer is going to take all kinds of crazy shortcuts like that unless it's somehow constrained by the spec. You could certainly imagine building lots of "do-what-I-mean" constraints into this optimizer but that requires even more magic.

qqii 7y ago

As with some of the other commenters, I don't fully agree. Programming is messy, and most end users don't care about the beautiful abstractions you used. Junk programming will always exist, and just good enough programming will always be the mainstream. When I'm purchasing a chair, I don't normally care about the detailed specifics of wood types, craftsmanship and the specifics of the joins, nor doesn't matter if a master craftsman doesn't approve.