Interview with Mark Cuban on AI, Silicon Valley, Politics, Media and more
bothsidesofthetable.com
bothsidesofthetable.com
Hmm... Where have I heard this before?
> It is far more likely that the programming occupation will become extinct (through the further development of self-programming techniques) [...] More and more, computers will program themselves; and direction will be given to computers through the mediation of compiling systems that will be completely neutral so far as the content of the decision rules is concerned. (Herbert Simon, 1961) [1]
[1] https://www.princeton.edu/~hos/Mahoney/articles/miscellany/i...
I think it's often difficult to appreciate that one's own profession could be replaced by some code, but it's an issue that many areas of the working population will have to deal with in our (and our children's) lifetimes - what has happened with physical work - automation such as robots and machines will happen with the work we do with our minds in many cases.
Software engineering is not a zero-sum game where the AIs rise to the exclusion of humans - it's an expanding space.
*and then there's the meta: does using an oven qualify as cooked-by-machine?
The history of what used to be called "CASE" is absolutely full of people promising tools that would automate parts of programming that fail to deliver. The difficult (or at least most time-consuming) parts of programming are all to do with meaning, intent, purpose, communication, and prioritisation.
What is likely is that "code assistants" will gradually improve, both in the form of language constraints (Rust borrow checker) and IDE advice (Visual Studio's endless tooltips).
Meanwhile anything that has to do with the semantics and meaning is a much harder, much longer term problem. And one that's very different from the current fixation on ml.
So I'm not really selfishly worried about this. We'll go eventually, but we'll probably be amongst the last to go. By then society will have to figure out how to deal with mass unemployment, it's already a massive issue today and it's not going to improve any time soon.
And then there's the idea that new jobs are created when others disappear. I'm sure there will be jobs in the future that we can't imagine yet. Maybe we'll actually forcibly create new jobs in order to keep people busy.
Theoretically that role is generally called "business analyst" or "product manager" or "product owner" but you know the difference between theory and practice.
If we'd ever reach that point of automation my money's on many programmers just switching to some sort of "business analysis". After all, this job is all about making decisions, tons of micro-decisions.
GP doesn't seem to get much attention so we are far from this method being practical. Actually, I'm puzzled why GP is so unpopular compared to say, type system research, since it could have a vastly greater impact if it were to make progress.
That's an extremely difficult task for any but the most trivial problems. It shares many of the same issues with formal verification, which has also failed to catch on beyond the odd niche project.
Turning any kind of genetic / ML system loose on that? How would you even write test cases, short of backfeeding production data? And expecting the result to pass muster with auditors?
Differentiable Neural Computers [1] are getting us closer (by incorporating an explicit I/O operations on a memory) but it's uncertain how much test data you would need to build complex code routines.
Genetic Programming is not getting much attention because it is inherently inefficient, and there are much better optimization methods out there. Genetic Programming, similarly to Monte Carlo methods, is often the "easy way out" when you are trying to solve an optimization task where you cannot (bother to) model the process.
For example: You could train Neural Networks' weights with Genetic Programming, but that's extremely inefficient compared to gradient descent.
Bottom-line: Genetic Programming is not a magic bullet, and is not guaranteed to converge to a workable solution in a "reasonable" time.
It's just not gonna happen on a large scale. Nothing beyond simple CRUD if that.
For some reason I had this thought even 15 years back. I used to think once software is written it will continue to run with occasional interference by maintainer. But then people convinced me, look, there is lot of software is to be written so don't worry about losing job.
I now think the kind of software I and many others were writing at typical IT company (CRUDy apps) was very immature and buggy. But over 2 decades people have recognized some patterns and made the software run with much less maintenance work.
I have noticed 5 years back at my workplace where every weekend there will be firefighting with production issues. But now everything seems stable and generally better. No brand new software was written, no stack was replaced. It was things like upgrading to newer versions of software, more logging, more monitoring, more automation, better release process etc.
There used to be ~10 people in team and now there are ~4 people. Everyone who left was supposed to have replacement but no one was hired. The point I am trying to make is, yes, there can be new whizbang features, NoSQL backend with 10 more ppl on team and so on but from business perspective this thing is working fine and just keep it up and running without too many customer issues.
Suppose such an AI exists, one that can write perfect code and get the job done. How do you tell the AI what to code? Any language specific and accurate enough to tell the AI what to code, is in itself a programming language. Someone needs to write in that language, and that person is a programmer. All the AI does is make for a better compiler.
Programmers will be (and already are) augmented by technology and AI, but someone has to tell the computer what the goal is.
Btw, very tangentially, did you used to work in a startup with a certain zap to its name? I recognise your handle :)
I don't think it will write "perfect code" whatever that means. It will write code with its own idiosyncrasies its own writing style, etc.
Design is so much more important than code, knowing what you want and knowing what you need is more than half the battle. Finally don't over look that an AI will be 24x7 and no person can have that output
The problem is this is never how the transition would happen.
Today how does it work? Go far enough back. You'll have a user with problem X. Someone translates this problem into requirements to have others implement. You would never take the requirements and give them to a general AI because, as you said, you'd have to ensure it understood them.
What would actually happen is you'll tell your general AI that you need to solve X and it'll figure out the best way to do it and just do it. They wouldn't write software in the sense we have it today. They wouldn't produce an app. They would, instead, solve problems.
Here's an example. Today you think "I'm really hungry. It would be great to have an app that could show me what's around me then have someone pick it up for it after I make a selection". You have some basic requirements in your head, you write some software, you test it out. Maybe your app calls an API to place an order for pizza then calls an Uber to pick up your pizza and then bring it to your current location.
With a general AI you'll feel hungry and the AI will know you're in the mood for pizza from Dave's Pizzeria 3 blocks down. It'll dispatch an automated vehicle to pick up the pizza from a likely automated kitchen and bring it straight to you. You wouldn't even need conscious thought into it if we have a way to perfectly connect the AI and our brain.
On the other hand, automating all of programming is a pipe dream. If you could do that, you could also automate mathematics and by extension most of the sciences...
Is there any proof that it [automating programming, mathematics, scientific method] is or isn't possible? Is there a way to prove or disprove it mathematically?
It is merely unlikely to happen while there is anything else left which we can't automate...
Decidability results can be useful, but note that it's certainly possible to do automated reasoning for undecidable theories. So decidability results are more useful for predicting the difficulty and determining appropriate approaches than for actually determining anything about the possibility of creating a useful system.
E.g. the halting problem is famously undecidable, but there's lot of impressive work on termination checking. Misinterpreting undecidable problems as "impossible problems" is a classic undergrad mistake.
> Is there a way to prove or disprove it mathematically?
No, not really, unless you can be very specific about the exact subproblem you're interested in. And even then, probably not.
Good thing I am one. Thank you :)
It's just that now the word "self-programming" means something different because we've used all that automation to build ever more complex systems.
And that process will continue. Level of abstraction is increased, we figure out how to automate at that level, and then we raise the bar again to tackle ever more challenging problems.
Honestly, if we treated software engineering as a real engineering discipline, we would already have 90% of software created automatically. We just keep ourselves busy by building same CRUD apps, recreating same layouts, building same libraries over and over again.
When we start treating software engineering as engineering not as art, full automation of programming will be a matter of only few years.
There is a gray area in between the marketing, and the ambiguity is the real danger.
I'm just bothered by the whole market tendencies, it often sounds like it's appealing to salesmen, meanwhile doing real stuff with machine learning is tough and it is often the realm of research and universities.