Google announced that they’ve built an AI that can beat top players at Go and Facebook shut down an app development platform.

AI and Machine Learning

Let’s talk about Go for a moment, and for once I don’t mean the programming language. Instead, let’s focus on the game with that name.

Go is a very old and complex game, and the number of potential moves in the game is higher than the number of atoms in the universe. Because of this, for a long time (at least since Deep Blue defeated Kasparov in a series of chess games) Go was seen maybe not quite as the holy grail of AI research, but as one of the great targets to aim for. Or rather, the goal was to build an AI that can consistently beat top human players.

But then, last week Mark Zuckerberg mentioned on Facebook that his AI team was quite far along building just such an AI. It was far from perfect, but just the fact that they’re making good progress on it is pretty amazing. Or rather, it was amazing for about 10 hours as that was how long it took Google to announce that they had actually built one already called AlphaGo¹. I don’t mind saying that I was very impressed when I read that article. Not even just the results (AlphaGo beat the European champion five games out of five, with a match against the world champion scheduled for March), but how they achieved this.

Traditionally for things like chess, when the AI needs to make a move it will go through a decision tree to find the most desirable path based on what future moves can be made. Considering the potential number of moves in Go this tree would be far too big to quickly parse for any currently existing hardware. Which is the reason why it was seen as such a hard thing to do. Instead, how Google attacked this problem is by using neural networks and most importantly machine learning.

Dumbed down (as I’m not even close to an expert in it), machine learning is a technique where you train a computer by providing it with a lot of data in order to help it make future decisions by itself. In this case, a large part of that was done by making AlphaGo play games against itself. What makes machine learning so powerful is that it doesn’t require a computer to have knowledge of every situation, but just that it needs to know how to make decisions about what it encounters.

And that last part is what makes this breakthrough from Google so important in my mind. It’s not that they managed to build a computer that can play a game, but what the way they did it means. The most relevant application of machine learning that people will one day encounter is self driving cars. The best documented trials for this are (once again) from Google. In order to make their self driving cars work they map out every centimeter of the roads they drive on. This is currently necessary to ensure the cars can focus on the traffic instead. With the introduction of AlphaGo however it looks like Google’s machine learning capabilities are along even further than I imagined so this will become less and less necessary.

While obviously Google won’t be able to transfer the abilities of AlphaGo to a self driving car, they do now have the knowledge of how to build such an advanced system. To be honest, it wouldn’t even surprise me if they already have several systems in development that will make AlphaGo look like a fairly simplistic AI. Those will probably take some years before they see the light of day, but I’m certainly looking forward to the day they can put those into cars or other useful purposes.

No more Parse

Facebook announced that their development platform Parse is going to shut down. Parse was a bit like a backend as a service, you hook up your application to it and you don’t need to think about that anymore. Services shut down all the time of course, but as this was run by Facebook there was a lot of trust in it and therefore a lot of users. Unfortunately that means now that the developers of apparently hundreds of thousands of applications need to stop using their current backend. As the shutdown is extremely well managed (including an open source server that replicates most functionality) they’ve been given a year to do so, but it still means a big investment in both time and development resources.

As pointed out in this article by Allen Pike, that also means that there are going to be a lot of apps that won’t be updated and a year from now will no longer work. This can be because the developers don’t have the resources to work on them, or because the app was already abandoned as so many are².

While this can again be taken as a reason against using high-level platforms like Parse in the first place, I don’t quite agree with that. While I personally do prefer to use lower level infrastructure/services I can imagine that when you’re starting out with a new app (or even just prototyping) you want to focus on that instead of the backend. So while in this case it hurts the developers who made that decision, they may have saved a lot of time earlier on when they needed it more.

Services like this do lock you in by making it more difficult to move away, but that behavior isn’t limited to higher level services. You’re no doubt aware that I am a big fan of the work done by AWS, but there you have the same thing. Unless you only use EC2 instances, their more powerful features also lock you in. To be fair, most of those can be replicated if you want to move elsewhere, but it’s not a perfect fit and you’re likely to have become dependent on the one feature that can’t be replicated easily. The same really goes for any cloud solution, and unless you build your own servers and host them yourself you still need to trust someone³.

It’s easy to tell people they made the wrong choice when they decided who to trust and at what level of the stack, but maybe they thought about those details and decided it was worth it. No stack lasts forever, and different projects have different requirements. If using Parse saved a startup from spending a lot of money on a systems engineer when they couldn’t afford it, then having to change platform within the next year can very well be an acceptable tradeoff.