Moore's Law states that every 18 months a CPU's transistors will shrink in size by a factor of two. This means every 18 months you can stuff twice as many transistors onto a CPU, making it twice as fast. This law has been in effect since the late 1950's, and as technology advances, not only have the CPU's been able to hold more transistors, but they have been getting smaller in size as well. Intel recently released plans for a 14 nanometer CPU this September. 14 nanometers is only about 60 times larger than a silicon atom, which means you can fit billions of them on a chip, over a million times more than you could in the 1950s.
Throughout the 20th century, Moore's Law was the software developer's best friend because, as a result of the increasing CPU speed, every 18 months software became twice as fast without any extra effort on the developer's part. However, in 2002, limitations in a CPU's circuitry demanded a new architecture if Moore's Law were to hold true. Out of these limitations the multicore processor was born. This essentially means that before 2002 you had one CPU in your computer and after 2002 you have multiple CPUs -- or cores -- in your computer. Each individual core has not gotten much faster since 2002, but the amount of them is doubling every 18 months, which means Moore's Law is still holding true.
In order for today's developers to benefit from the speed increases Moore's Law offers, they need to take advantage of multicore processors. But it's not that simple. For the past 50 years developers have written programs to run on a single CPU. Most of the tools, programming languages, college curriculums and research have followed suit. A program designed using all of that knowledge and experience will only run on a single core of a multicore CPU, and those cores aren't getting faster. Now developers have to rethink their programming approach and coordinate -- or parallelize -- programs across cores--no easy feat.
An apt metaphor for describing the difficulties of multicore programming is the game "telephone." For those of you who aren't familiar with this childhood game, the basic premise is that several children stand in a line and the first child whispers a word or phrase to the next, who whispers the same word or phrase to the next child, and so on. When the last child hears the word or phrase, he says it out loud so everyone can hear, and it is never the same as it was at the beginning of the chain. I remember once starting one of these infamous chains with the phrase "I think Jenny's cute" only to have it end with "Jenny smells like monkey poop"--clearly not the desired outcome. Multicore programming is like this but with millions of kids whispering millions of words, a million times a second.
Today's most popular programming languages (C, C++, C#, Objective-C, Java, Python, Ruby) are ill-equipped to stand up to the challenge of multicore programming. While developers can still use these languages for single CPU programming, they face the drawback of leaving the speed of the program stuck in 2002. And unfortunately, this is what is happening with much of the code being written today.
However, within select academic communities, programming languages have been developed that make multicore programming far less daunting. These languages are known as "functional programming languages" and while they don't completely solve the difficulties of multicore programming, they certainly make them less daunting. To go back to the earlier metaphor, playing "telephone" with a functional programming language is more like playing with adults instead of children. There is still room for "monkey poop" moments, but they are less likely if adults have the right intent.
My favorite of these functional programming languages is called Scala. Scala is a language that runs on the Java Virtual Machine, which is great because it means that all of the knowledge a Java programmer has built up over their lifetime is 100% applicable to the Scala programming done in the future. It's also flexible enough so that a Java developer can ease into the language. Scala describes itself as a "object-oriented-functional-hybrid language." Java programmers have been doing object-oriented programming since its inception, so they simply need to adapt to a few of the functional programming paradigms.
Scala has been dramatically gaining in popularity over the past decade. Companies like LinkedIn, Twitter, Intel, Foursquare, and the Huffington Post are using it in production. Large communities have sprouted up all over the world through sites like meetup.com (also using Scala). And it's becoming easier to learn since free courses on the language are being offered through coursera.org.
Now it's easy for me to sing the praises of Scala, as an avid user and the organizer of both the New York Scala Meetup and the Boulder Scala Meetup. So I think it's only fair that I note there are a few other languages out there making programming on multicore processors easier. Some popular ones are Clojure, F#, and Go. These languages all have their upsides and downsides, as any language does, but because of the difficulty Moore's Law has posed to developers, it's in their best interest to start learning one.