Depending on your perspective and proximity to the bleeding edge, the world of programming evolves either too fast or too slow. But whether you're banging out Cobol or hacking Node.js, one fact remains clear: Programmers must keep an eye on the latest programming trends to remain competitive in ever-shifting job markets.
From JavaScript everywhere to everything on the JVM, the times and the tools are a-changing. So too is the way programmers work, thanks to the rise of frameworks and walled gardens, as well as a shift away from openness. Concerns around bandwidth, energy, and scalability are finding a place at the programming table, as are parallelism and the video card. There's so much happening that you might find yourself thinking of going back to school, if only traditional education wasn't fading from relevance.
[ Find out which 7 programming languages are on the rise, verse yourself in the 12 programming mistakes to avoid, and test your programming smarts with our programming IQ test: Round 1 and Round 2. | Keep up on key application development insights with the Fatal Exception blog and Developer World newsletter. ]
Every so often, our understanding of the ways and means of programming needs to be renewed or replaced just like an operating system or a library. Here we offer a look at 11 recent trends that capture how programming is changing.
Programming trend No. 1: The JVM is not just for Java anymore
A long time ago, Sun created Java and shared the virtual machine with the world. By the time Microsoft created C#, people recognized that the VM didn't have to be limited to one language. Anything that could be transformed into the byte code could use it.
Now, it seems that everyone is building their language to do just that. Leave the job of building a virtual machine to Sun/Oracle, and concentrate your efforts on the syntactic bells and structural whistles, goes the mantra today.
As a result, the list of JVM-dependent languages is long and growing. Ruby lovers like how much better JRuby works under heavy loads. Scala and Cloture allow developers to write code that is more functional and often faster than Java when running on the same JVM.
Even Java-heads like to use the JVM without writing Java. Take the scripting langauge Groovy, which is fully integrated with the JVM and Java API. Write Groovy shorthand, and if you also adopt Grails, you can enjoy Rails-like coding-by-convention. Need to link in Java libraries? Voilà. It's designed to work seamlessly, giving you all the power and stability of Java without the curly brackets.
Programming trend No. 2: JavaScript is not just for JavaScript anymore
The JVM isn't the only cross-platform solution open to all comers. JavaScript, the langauge your kid sister uses to add an alert box to her band's website, is not just for JavaScript coders any longer. The list of languages that cross-compile to run on the fancy, just-in-time JavaScript engines is even longer than the list that runs on the JVM.
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.
One of the newer arrivals is CoffeeScript, a shorthand language that's compiled down to JavaScript by inserting all the punctuation that scripting-language users hate to type. The idea is so popular that there are already CoffeeScript spin-offs like Coco, Parsec-Coffee-Script, and Contracts-Coffee-Script, each of which adds its own sophisticated metaprogramming structures to make it easier to spin out elaborate code.
Some extensions are so successful they've almost become languages unto themselves. Think of all the Web developers banging out workable code with jQuery, without remembering or knowing anything about JavaScript scoping.
If that's not enough, there are experiments linking pretty much any language to JavaScript, including Ruby, Python, Lisp, Scheme, Haskell, and OCaml.
Programming trend No. 3: No code is an island
A friend once told me he was heading to the woods in Northern Michigan where his father and uncles built a cabin by themselves. It was theirs and theirs alone. They hauled the wood and the rock, and they could sit afterward and gaze at the sunset with deep pride in their accomplishment.
Writing a program used to be like this. Push the compile button, and after it churned, the code would take over your machine. Sure, it was interacting with the OS layer, but it was easier to point to a tangible thing that you built, just like that cabin. See that file with the EXE suffix? I built that one, mom.
That distinction is disappearing. Our code is living increasingly in ecosystems. Many PHP programmers, for instance, create plug-ins for WordPress, Drupal, Joomla, or some other framework. Their code is a module that works with other modules.
Sometimes the fragments are even smaller, just bits of code dropped into fields. Many Drupal modules can be customized with PHP, for example. The programmer is just filling out forms with snippets of code, not building something new that stands alone.
When these mechanisms work, the results can be uplifting. More often than not, the results are mixed. While your snippets can work well with what's under the hood, they often need plenty of debugging. In many cases, the errors come from deep inside the system where you're not supposed to be looking. And there is little documentation because no one expected you to interact with the system this way.
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.
These tools often work for small extensions and simple tools that have been anticipated by the authors of the original framework. Anything else is an invitation to hit-or-miss debugging cycles. There's no substitute for having all the source code available to be read and traced with your own stack, but that's becoming less common.
Programming trend No. 4: Plantations everywhere
There's a dark side to these tightly integrated stacks of code: the walled garden.
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, then 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, suddenly 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 well keep the lion's share of the income derived from the work of independent developers. The revenues that trickle down to the programmers in the company town will be just enough to keep the server Ethernet lights flickering.
These walled gardens also threaten to balkanize the coding world into separate camps according to language. One look and you can see programmers moving from stubborn individualists in the open frontier to hired hands. Welcome to the new plantation.
Programming trend No. 5: Openness retreats
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, but 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, but 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.
This is bound to limit innovation in the future. After the garage hackers and programmers finish building tools that put a smile on their faces, they turn around and create companies that do the same tasks for the average person. Slicing off the open source experiment in this area destroys the aftermarket. And it becomes harder for companies to hire the programmers they need because open source tinkering produces skilled programmers that can fill jobs.
There remain glittering exceptions, usually when the code is shared between programmers. Some projects like Apache still thrive and attract the kind of financial support they need to pay top talent. Github and Sourceforge continue to add more projects. Others work well for developers experimenting with the bleeding edge. But there are few examples of pure openness succeeding with the end consumer, who seems drawn to the siren call of proprietary gardens.
Programming trend No. 6: Bandwidth is no longer free
Web programmers have grown up believing bandwidth is free and getting ever faster. No need to worry about slow download times -- in a year, everyone's connection will be zippier, and the problem will disappear. Unfortunately, those days are over, thanks to more and more ISPs adding bandwidth caps and metering.
Regardless of whether you see this as a need to crack down on bandwidth hogs destroying the commonwealth or as a power grab by those who own the pipes and, by coincidence, want to sell pay-per-view video feeds, bandwidth is something programmers need to worry about consuming.
This will change many of the gimmicks built around the cloud because traffic from your home machine to the cloud will be metered. Will radio stations be able to stream every bit that we hear and still make enough money on the pennies from ads? Will online backup be viable?
Optimizing bandwidth consumption when designing apps is becoming imperative. Minimizing JavaScript files and CSS files isn't just for speed; it also saves bandwidth. If programmers don't heed this trend, users of their code could be driven away by higher bandwidth charges in the near future.
Programming trend No. 7: Energy is no longer free, either
The cost of keeping a computer plugged in has never been an issue. It never mattered how much energy your rack of servers sucked down because the colo just sent you a flat bill for each box.
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 but 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 by server programmers, who could always take power for granted. You worry about speed, but 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. While 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.
Programming trend No. 8: Traditional education fades from relevance
Ask any project manager and they'll say there's not enough talent from top-tier computer science departments. They may go so far as to say they would hire a new CS major from a top school without reading the résumé. But ask this same desperate project manager about a middle-aged programmer with a degree from the same school, and they'll hesitate and start mumbling about getting back to you later.
Indeed, it isn't unheard of to find major technology companies complaining to Congress that they can't find Americans capable of programming, all while defending themselves in age-discrimination lawsuits from older programmers with stellar résumés and degrees from top universities.