The only thing that flies faster than time is the progress of technology. Once after lunch, a chip-designing friend excused himself quickly with the deft explanation that Moore’s Law meant that he had to make his chip set 0.67 percent faster each week, even while on vacation. If he didn’t, the chips wouldn’t double in speed every two years.
Now that 2017 is here, it’s time to take stock of the technological changes ahead, if only to help you know where to place your bets in building programming skills for the future.
From the increasing security headache of the internet of things to machine learning everywhere, the future of programming keeps getting harder to predict.
There are naysayers who claim the chip companies have hit a wall. They’re no longer doubling chip speed every two years as they did during the halcyon years of the ’80s and ’90s. Perhaps — but it doesn’t matter anymore because the boundaries between chips are less defined than ever.
In the past, the speed of the CPU in the box on your desk mattered because, well, you could only go as fast as the silicon hamster inside could spin its wheel. Buying a bigger, faster hamster every few years doubled your productivity, too.
But now the CPU on your desk barely displays information on the screen. Most of the work is done in the cloud where it’s not clear how many hamsters are working on your job. When you search Google, their massive cloud could devote 10, 20, even 1,000 hamsters to finding the right answer for you.
The challenge for programmers is finding clever ways to elastically deploy just enough computing power to each user’s problem so that the solution comes fast enough and the user doesn’t get bored and wander off to a competitor’s site. There’s plenty of power available. The cloud companies will let you handle the crush of users, but you have to find algorithms that work easily in parallel, then arrange for the servers to work in synchrony.
The Mirai botnet that unfolded in this past fall was a wake-up call for programmers who are creating the next generation of the internet of things. These clever little devices can be infected like any other computer, and they can use their internet connection to wreak havoc and let slip the dogs of war. And as everyone knows, dogs can pretend to be anyone on the internet.
The trouble is that the current supply chain for gadgets doesn’t have any mechanism for fixing software. The lifecycle of a gadget usually begins with a long trip from a manufacturing plant to a warehouse and finally to the user. It’s not usual for up to 10 months to unfold between assembly and first use. The gadgets are shipped halfway around the world over those long, lingering months. They sit in boxes waiting in shipping containers. Then they sit on pallets at big box stores or in warehouses. By the time they’re unpacked, anything could have happened to them.
The challenge is keeping track of it all. It’s hard enough to update the batteries in the smoke detectors every time the clocks change. But now we’ll have to wonder about our toaster oven, our clothes dryer, and pretty much everything in the house. Is the software up-to-date? Have all the security patches been applied? The number of devices is making it harder to do anything intelligent about monitoring the home network. There are more than 30 devices with IP addresses connected to my wireless router, and I know the identity of only 24 of them. If I wanted to maintain a smart firewall, I would go nuts opening up the right ports for the right smart things.
Giving these devices the chance to run arbitrary code is a blessing and a curse. If programmers want to perform clever tasks and let users have maximum flexibility, the platforms should be open. That’s how the maker revolution and open source creativity flourishes. But this also gives virus writers more opportunity than ever before. All they need to do is find one brand of widget that hasn’t updated a particular driver — voilà, they’ve found millions of widgets primed to host bots.
When the HTML standards committee started embedding video tags into HTML itself, they probably didn’t have grand plans of remaking entertainment. They probably only wanted to solve the glitches from plugins. But the basic video tags respond to JavaScript commands, and that makes them essentially programmable.
That is a big change. In the past, most videos have been consumed very passively. You sit down at the couch, push the play button, and see what the video’s editor decided you should see. Everyone watching that cat video sees the cats in the same sequence decided by the cat video’s creator. Sure, a few fast-forward but videos head to their conclusion with as much regularity as Swiss trains.
JavaScript’s control of video is limited, but the slickest web designers are figuring clever ways to integrate video with the rest of the web page in a seamless canvas.
