11 programming trends to watch

Take Google Web Toolkit. You write Java code like you're writing for the Swing framework from the '90s, and the GWT compiler turns it into JavaScript that runs in a browser on a desktop, smartphone, or tablet. There's no need for a Java applet plug-in or JVM on the client because JavaScript in the browser offers machine independence.

The worst examples

In the worst examples, the errors come from someone else's snippets, and there's no way to debug the two simultaneously because they own their code and you own yours. Often the best solution is to get the other programmer on the phone, of all things.

The Internet began with the premise that there would be no gatekeepers. Every packet would be delivered to its destination, with our data free to wander. Alas, that promise is eroding, and not because the ISPs are increasingly turning to traffic shaping or deep packet inspection technologies.

These days, everyone seems to be retreating to walled gardens, where everything is safer and simpler. If you want to develop for the iPhone, you'll have to write code to Apple's vague specifications, at the time Apple -- and Apple alone -- will decide whether it will run on its machines. It's not up to you, the programmer, and it doesn't matter what the users say, either.

It's not just Apple. Creating games for Facebook means getting Facebook's permission to connect to Facebook users. It doesn't matter how many people click the Like button if Facebook decides to lock out your code. Microsoft, without warning the most open and least restrictive of the big companies, is widely believed to be looking in awe at the success of these gardens and wondering why the Department of Justice treated Internet Explorer so differently. Only a naive programmer thinks that the other companies won't follow along.

There are deeper problems with walled gardens, beyond loss of control. Purveyors of walled gardens could very then keep the lion's share of the income derived from the work of independent developers. The earnings that trickle down to the programmers in the company town will be just enough to keep the server Ethernet lights flickering.

The success of open source software

For all the success of open source software, the ability to engage in pure tinkering is slipping away in many corners. The success of the iPhone has everyone looking to find ways to wall off the commons. Sure, the new car computer systems are built with Linux, nevertheless don't for a second think you'll be typing "make" and deploying to your car.

Even if we concede that it would be creepy and dangerous to reprogram your brake system, why can't we hack the nav system? The car companies are touting how their fancy computer systems integrate with your phone, however they're not open the way your desktop is open. Hardly anything is as open as the desktop used to be. Even desktop systems may be more locked down, with some wondering whether the new secure booting infrastructure for Windows 8 will make it impossible to run alternative OSes.

No longer -- energy consumption is a big issue, whether you're programming for smartphones or the server farm. The biggest limitation of my Android phone is that it can drain its battery in 8 hours doing nothing nevertheless sitting there. Design an app that eats up battery power faster than GPS features do and watch downloads of your app plummet.

The problem is less understood

The problem is less understood by server programmers, who could always take power for granted. You worry about speed, nevertheless rarely the cost of energy for completing a database transaction. Google is one of several companies in front of this issue, investing in finding the lowest-cost electricity to do extensive searches. It's likely the company is already deciding how to fine-tune a search based on energy costs and how much ad revenue the search will generate.

Cloud computing is helping make this issue more obvious. Some of the more sophisticated clouds -- like Google App Engine or Amazon S3 -- don't bill by the rack or root password. They charge for database commits and queries. During this is a new challenge for most programmers, it's making the cost of energy more transparent. Get ready to start thinking about the cost of each subroutine in dollars, not in lines of code or milliseconds of execution time.

Indeed, it isn't unheard of to find major innovation companies complaining to Congress that they can't find Americans capable of programming, all during defending themselves in age-discrimination lawsuits from older programmers with stellar résumés and degrees from top universities.