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.
Some of this may suggest that education doesn't have the same value it used to hold. Older workers with degrees that used to be valuable are saying companies want only young, unfettered bodies that will work long hours. It leaves you to wonder whether it's the age and implied lower pay expectations, not the knowledge that makes fresh college graduates so desirable.
Others are simply moving beyond such questions, looking instead to exploit what they see as a market distortion caused by our infatuation with the four-year diploma. Venture capitalists are paying top talent to skip their undergraduate years. Others are actively recruiting people with odd degrees and pushing them through a boot camp that teaches them practical skills, not the theoretical analysis common in university courses.
The most prominent rejection of a traditional university education is the program run by PayPal founder Peter Thiel. He's recruiting top programmers who are just leaving high school and paying them to "stop out" of college. The kids get a job and he gets young, malleable talent.
Others are looking at the staggering rise in tuition and suggesting that shorter, more focused education makes economic sense. Paying off a degree from a top-flight university over a 40-year career can easily consume $1,500 per month ($250,000 at 6.8 percent). Online courses and training from the vendors themselves can be dramatically cheaper.
One article from Fast Company asked the question, "Why hire a PhD when a self-taught kid is just as good?" It then answers the question by describing internship programs that companies can use to hire people with real talent but no fancy degree.
Programming trend No. 9: Accuracy fades as scalability trumps all
Years ago, ACID ruled the database roost. The challenge was to build a bulletproof machine that always gave a correct and consistent answer when queried. Hurricanes, nuclear weapons, and errant janitors unplugging the rack could not scramble the database. The big customers were banks, hotels, and airlines, and they wanted to make sure bank accounts and reservations were consistent and correct.
Today, the industry is trying to find an easy way to store ephemera from our lives. From the places we visit to the toss-away comments between friends, the goal is to find a fast and efficient way to store endless tidbits from everyone on earth.
The smartest people approaching this problem quickly realized they could make their job dramatically easier by cutting corners and blithely ignoring any glitch. If some status update disappeared, who would notice? If somebody checked in to a service while at a coffee shop and failed to be crowned mayor of that coffee shop, it wasn't a big deal because they would probably return again tomorrow. After the new class of data caretakers recognized that they could save a fortune on compute cycles and infrastructure simply by loosening requirements, they started building NoSQL and other so-called data stores.
Now, saving time and money by trading away accuracy rules the Web. Try searching for an older email message with some of the Web-based tools. They're quietly leaving some of the older ones out of the index. This often reflects a slow erosion of standards for search. Google, for instance, quietly ended the ability to use true boolean searches with the plus sign. Expect to see more and more Web engineers subtly tossing aside the fanatical commitment to accuracy once common among database administrators.
Programming trend No. 10: Real parallelism begins to get practical for all
Computer architects have been talking about machines with true parallel architectures for years, but the programmers in the trenches are just starting to get the tools that make it possible.
The parallelism is appearing in two prominent areas: multinode databases and Hadoop jobs. Some mix the two.
Most NoSQL data stores offer to help spread the workload over multiple machines. Some offer automatic sharding, which splits the data set into pieces, synchronizes the machines that host a given piece, and directs queries to the right machines as necessary. Some offer duplication or backup, a feature that's a bit older; some do both.
Hadoop is an open source framework that will coordinate a number of machines working on a problem and compile their work into a single answer. The project imitates some of the Map/Reduce framework developed by Google to help synchronize Web crawling efforts, but the project has grown well beyond these roots.
Tools like this make it easier than ever to toss more than one machine at a problem. The infrastructure is now solid enough that the enterprise architects can rely on deploying racks of machines with only a bit of hand-holding and fussing.
Programming trend No. 11: GPUs trump CPUs
Was it only a few years ago that the CPU manufacturers created the chips that fetched the most money? Those days are fading fast as the graphics processors are now the most lustworthy. It's easy to find kids who will spend $300 on their entire computer and operating system, then $600 on a new video card to really make it scream.
The gamers aren't alone in their obsession with video cards. Scientists who need high-powered computation are reprogramming GPUs to analyze protein folding or guess the secrets of the smallest particles. Nvidia runs conferences for nongamers using the devices, and they're selling video cards by the palletload to scientists who want to build supercomputers. Oak Ridge National Laboratory, for instance, plans to put 18,000 Tesla GPUs from Nvidia into one room so that they can call it the fastest supercomputer. They're presumably going to build elaborate models for the Department of Energy, not to brag about the frame rate they get while playing Doom.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.