"But don't worry it isn't happening anytime soon in the form of singularity."
Probably not soon. Worth noting that the Go victory happened a decade or two before it was predicted to though.
(To clarify, I was not trying to establish that any intelligence explosion is on the immediate horizon. Rather, I was trying to establish that it's a pretty sensible concept when you think about it, and has a solid chance of happening at some point.)
>Just like other people in other jobs, we sometimes come up with more efficient ways of doing things than our bosses thought possible, and then we have some extra free time to do what we like.
Yes, I'm a programmer (UC Berkeley computer science)... I know.
> (To clarify, I was not trying to establish that any intelligence explosion is on the immediate horizon. Rather, I was trying to establish that it's a pretty sensible concept when you think about it, and has a solid chance of happening at some point.)
Well first you were saying programmers may hesitate to create an AI singularity because it may cost them their job. I said we would love to but probably won't anytime soon. Now you're saying that it's likely that it will happen some day. I'm not sure these points follow a single train of thought.
>Well first you were saying programmers may hesitate to create an AI singularity because it may cost them their job.
The line about programmers fearing automation only once it affects them was actually an attempt at a joke :P
The argument I'm trying to make is a simple inductive argument. Once something gets automated, it rarely to never gets un-automated. More and more things are getting automated/solved, including things people said would never be automated/solved. What's to prevent programming, including AI programming, from eventually being affected by this trend?
The argument I laid out is not meant to make a point about wait times, only feasibility. It's clear people aren't good at predicting wait times--again, Go wasn't scheduled to be won by computers for another 10+ years.
The fact that programming is an exceptionally ill-defined task. Computers are great at doing well-specified tasks. In many ways, programming is the act of taking something poorly-specified and making it specific enough for a computer to do. Go, while hard, remains very well defined.
I hope for more automation in CS. It will help eliminate the boilerplate and let programmers focusnin the important tasks.
> In many ways, programming is the act of taking something poorly-specified and making it specific enough for a computer to do.
Software development in the broad sense is that, sure; not sure I'd say programming is that -- taking vague goals and applying a body of analytical and social skills to gather information and turn it into something clearly specified and unambiguously testable is the requirements gathering and specification area of system analysis, which is certainly an important part of software development, but a distinct skill from programming (though, given the preference for a lack of functional distinctions -- at least strict ones -- within software development teams in many modern methodologies, its often a skill needed by the same people that need programming skills.)
Probably not soon. Worth noting that the Go victory happened a decade or two before it was predicted to though.
(To clarify, I was not trying to establish that any intelligence explosion is on the immediate horizon. Rather, I was trying to establish that it's a pretty sensible concept when you think about it, and has a solid chance of happening at some point.)
>Just like other people in other jobs, we sometimes come up with more efficient ways of doing things than our bosses thought possible, and then we have some extra free time to do what we like.
Yes, I'm a programmer (UC Berkeley computer science)... I know.
But don't listen to me. Listen to Stuart Russell: https://www.cs.berkeley.edu/~russell/research/future/