And it's not just blue collar workers that are a target of this idea. We are already starting to see automated programming moving out of the research lab and into the commercial realm, e.g. GitHub copilot.
One of the great improvements in the second edition of FORTRAN, FORTRAN II, is that an application program can be written not as the output of a single compilation, but of many separate compilations.
[The above is liberally quoted and reorganized from the IEEE Annals of the History of Computing, 6(1), 01984.]
As soon as GitHub was acquired by Microsoft I knew their intentions were for automated coding tools. I wasn't concerned about this affecting my livelihood in the short to medium term, because state-of-the-art ANNs won't be able to grasp the context of business requirements without developing adult human level intelligence. Thus, even a full program built by such a system would need to be verified by a human to be sure it will behave as desired, obviating any gain in terms of automation. Even the rudimentary boilerplate that copilot spits out suffers from this problem.
I feel like the end result is just what we already have, game engines with visual programming and drag and drop editors. You don't add much value by automating the programming since you still have to define the input and outcome.
The real win was building the complex logic and state editor into a good UX.
I think we'll get to genuinely open ended sand box games.
Have a look at the video, it's quite impressive.
Even just watching the video, I came up with several possible improvements to try out. Eg adversarial training, that would really hone in on the situations and aspects where the model is weak so far, like edge conditions; instead of just using normal gameplay as input.
The other part about that GAN Theft Auto example is that it doesn't actually know what's going on, like there's no game state. All it knows is that "When I have a frame that looks like this, and they press that button, I think the next frame would usually look like this". So it's got no internal game logic, it's just really good at painting what games look like.
Even going about this very naively, you could at least use it to train a model against a supercomputer running the game, and then run the inference on much more modest end-user machines.
But you can be much more ambitious: have you seen eg style transfer? So you could probably do a bit of ML black magic to train your model on GTA, and then point it at the Google Earth data to get a GTA-like set in real-life London.
Or you could use something like style transfer to go for a cartoony look, or add ray-tracing like effects, even if you didn't have these effects in your original engine.
Or you can use a pre-trained model (eg on GTA), and then spend a relatively modest amount of extra training to get a different kind of game, eg one that has magic or so.
About the latter part: I do think their model is already running with some state. But even if it ain't, that's a relatively small thing to add with already known standard techniques (or you can come up with new techniques.)
I realise that you could define everything as data - laying a brick, you take the inputs of where to position the brick, etc. However I think we can make the distinction between chess where the data is "Pawn is on e4" and the much greater complexity of the real world where we are dealing with billions of atoms. Perhaps not everyone agrees with me.
It's fairly sucessful. We can simulate for example driving a car really well.
Simulating human behaviour is harder, but simulating brick laying is not that hard, we have the technology to do so already.
Simulating brick laying might be able to be done in a controlled environment, is it possible to make it low cost enough and accurate enough for all general purpose brick laying situations? Probably, given enough investment we could get closer. Is ironing out all the nuances cost effective? I don't know.
We can definitely simulate a driving environment but I given the recent struggles of self driving cars I don't think I would say that we are at the point where we've solved the problem of actually driving them in everyday situations.
Can you qualify this more specifically? In many domains (particularly safety critical ones) “reasonably well” may not be sufficient
But what do you mean by 'across the board'?
As far sources, a web search gives many articles about safety of self driving cars. See eg https://www.wsj.com/articles/self-driving-cars-could-save-ma...
Anyways:
> But what do you mean by 'across the board'?
By that I mean across all of the people driving in the US and their rate of incidence. For example, average miles driven, the amount of drivers and the rate of accidents. I think the most intriguing detail could be drawn from the rate of fatal accidents, since that's the most concerning, ignoring accidents that cause a casualty as I don't know the method for gathering that data off hand. One could glean a lot of info from that. Here's some rough numbers I gathered, and please forgive the naive approach to my data gathering to express a point:
Average miles driven/person[0]: 13,000 Average fatalities/year[1]: 37,000 Approximate number of licensed drivers[2]: 231,652,000
I don't have numbers for self-driving cars and the number of accidents, but regardless, would it perform the same with the same number of miles driven per car. Keep in mind that self-driving cars currently aren't navigating in all circumstances and will beep to make the human take control again. At least with Tesla.
[0] In 2019, there were almost 229 million licensed drivers in the United States. (Source: https://www.asirt.org/safe-travel/road-safety-facts/) [1] Over 37,000 Americans die in automobile crashes per year. More than 90 people die in accidents every day. (Source: https://www.thewanderingrv.com/car-accident-statistics/) [2] https://hedgescompany.com/blog/2018/10/number-of-licensed-dr...
Looking at fatalities would make the analysis easier, but when I last checked, Waymo hadn't driven enough miles to make a good comparison possible on that metric.
(They haven't killed anyone yet, but neither would the average human driver have done so, yet.)
So we would need to look at less dramatic accidents.
See https://www.forbes.com/sites/bradtempleton/2020/10/30/waymo-... which tries somewhat to correct for conditions.
[1] https://www.automotivetestingtechnologyinternational.com/ind...
Every step in programming tooling since programs stopped being input as manual hardware configuration has been automation of programming, and its just made more work, and higher paying work, for programmers.
The details of job changed, as more low level pieces of it were automated leaving the higher-level, more abstract bits, but for most of the changes, while some either bailed for other work or rode the dying embers of the old way to retirement, programmers generally adapted.
The funny thing about automation in programming - it has always opened up more doors - and led to more employment in programming.
We are so far from anything that resembles real automated coding - that coding automation should continue to be celebrated by engineers for a long time.
GitHub Co-Pilot and VS Code aren't going to replace you - they're just going to let your company offer a better product, release a new version sooner, test different versions, etc.
The closest a product that ever did this was Excel.
Domain experts are all using Excel, not any other automated tool.
I just hope we could improve on it.
See eg https://www.microsoft.com/en-us/research/podcast/advancing-e...
Any language any human would touch these days automates lots and lots of things for you.
(Even Assemblers do a lot for you nowadays.)
And on a casual level, nothing changes if the best in the world is a human or computer, so the casual player isn't particularly affected.
Not sure how important Netflix is here? There are lots of chess players on YouTube, too.
Go also get much more popular in the West for a while when Alphago came along.
By comparison, brick laying is trivial.
Brick laying robots already exist. This isn't a problem that can't be solved, it's a question of making it economically viable.
But the future is pretty obviously going to be skilled machinery operators overseeing the automation.
Even more interesting its once you automate like this the constraints start changing: i.e. it's easier to have a robot lay bricks with epoxy then cement, whereas a non automated work flow would struggle.
There's a Perth based company which has a prototype which basically will layout an entire house on a concrete slab via a boom arm that uses this approach: pallets go in, structured bricks come out.
I agree. It will happen eventually, but the bigger point here that is more related to to discussions on HN is that despite a lot of enthusiasm, machine learning and AI are still in the amino acid phase of evolution, and everything still sucks.
It works poorly, therefore bricklaying has been automated. The programmers won. The bricklayers won too. It's only Grakel with his weird bet that lost.
For robot bricklaying, you can depend on the electrical supply. Everything else is a toss-up. I do think it's possible, but you don't choose your working environment or the weather conditions so everything is gonna be a lot more hassle.
1. According to the BLS link below it's actually closer to 50,000.
There are over 50,000 bricklayers in the US according to the BLS[1].
There's tons of "no code" solutions - but these are all just different versions of coding and programming languages - usually with GUIs and pictures instead of words.
There's more than 60,000 SWEs that work in my company. Amazon, Google, Apple, and MSFT could make >$10Bn/year each if they could automate coding.
The fact that none of them are even trying - when it sort of goes with their core businesses - should give you some indication that this is something unlikely to be automated any time soon.
The reason bricklaying ISN'T automated is probably because there's ONLY 59,000 bricklayers in the US (a $3B market), it's not generalizable, and even if it was - the cost to move a machine, set it up, and maintain it - it's hard to imagine massive cost savings - 50% seems generous.
If there were >1M bricklayers - and/or they made >$400k/year on average, the work was generalizable, and automating would bring huge cost-savings that could be captured - there would be a LOT more effort into automating bricklaying.
But none of these are true. How much of brick laying is generalizable (building a new house) vs custom (repairing some old wall with non-standard bricks)? I have no idea - but I'm guessing not a lot more than 50%. That's a $1.5B market. You'd be luck to cut the costs by 50% - that's maybe $750M.
It could easily cost more than than to automate bricklaying! Why even try?? No one is interested in investing in that risk / reward.
On the contrary - most of Radiology could be automated and most of it is generalizable. Since hospitals are monopolies and healthcare is a mess - you might be able to capture all the cost savings - which would be close to 100%!
Since there's ~35k Radiologists, and they're some of the highest paid workers in the world - there are a lot of efforts to actually automate this (and they're doing quite well).
If you think automating radiology is easier than building a hamburger-cooking robot, you're naive. If you think AGI is easier to achieve than building a tomato-harvesting machine, you're clueless.
There's just simply not hundreds of billions to be made automating cooking hamburgers and harvesting tomatoes more efficiently. And it's not easy to generalize and automate cooking or harvesting EVERYTHING. And even if there was, restaurants and groceries are commodities - not monopolies. You couldn't capture all the savings. A race to the bottom on prices would eventually just pass the savings on to the customer - not juice profits. That's not something you want to spend massive, risky R&D on. That's why we haven't automated cooking hamburgers and harvesting tomatoes. Not because it's harder than protein folding, fusion energy, or true AGI...
From another point of view - we've had machines that mop floors for decades - and there's still a lot of people employed to mop floors. Is this because mopping floors is incredibly complex and creative? No - it's because people who mop floors get paid minimum wage, and they do a lot of other things, too.
Perhaps a company that wants to display the current Bitcoin price on a screen and let you do currency conversions you can do that in "no code", but then again, a programmer can also do that with code in 15 minutes...
As a tradesperson myself, working in a highly automated part of the metal fabrication process, I feel an urge to say something like:
The only thing standing between a programmer and unemployment is a sufficiently advanced compiler
But only because I great contempt for the hubris on display in these sorts of threads.
At the end of the day though, it's a-little-bit-form-column-A-and-a-little-bit-from-column-B.
We went from not-flying to landing robots on another planet in a handful of decades, who knows what a little bit more processing power and a few more layers of abstraction could bring.
Automating programming definitely seems like an easier target in comparison.
I've never had a printer that didn't work: I've had plenty that wanted the correct offering to the HP website to be made and several hundred megs of adware installed before a postscript file made it to the actual hardware.
Well, car assembling plants are older than Deep Blue, IIRC and they are very complex and "very robotic" in a physical sense.
I would also say that the approaches taken by something like AlphaGo are more interesting, too. Because unlike chess the solution space for Go is too large to simply look at all possible moves.
Is that the same?
There's lots of them on YouTube. Here's one with two different robots.
Quick test: replace any pawn with a queen. See if the bot notices.