Back when I started programming (on an Apple ][e, to help date things), there were two kinds of programmers. Real Programmers talked assembly language. Other programmers weren’t real, because they didn’t need to know the inner workings of their computers, and therefore didn’t really understand computers. More important from a pragmatic standpoint, Real Programmers could get the computers to do anything that was physically possible with the hardware– and the programs ran 10x faster.

Over the next decade or so, as compilers got better and computer hardware became tuned toward compiled code (rather than assembly language), C programmers were allowed to join the Real Programmer club. These days, Real Programmer usually implies C or C++. And now that even lowly Javascript runs within spitting distance of C, the distinction is nearly 100% machismo and 0% practical considerations. (Down from about 50%/50% in the early days and 80%/20% in the C days.)

But there’s still a practical reason for hiring a Real Programmer. Modern languages insulate you from having to think like a computer. That’s good, because 99% of the time you don’t want to think like the computer– you want to think like the users. But that other 1% of the time, if you can’t think like a computer, you’re going to run into major trouble. Assembly and C are weeder languages– it’s easy to weed out the good programmers from the bad ones. Java, C#, and the other modern languages make it really hard.

What’s worse, the language features in C that have gone away (manual memory management, for example) are now really, really bad ideas on modern multi-core, networked computer architectures.

Enter functional languages. They’ve been around since the 1960s, and have mostly been limited to the artificial intelligence community. They’re also well suited to failsafe, networked computing applications. (Google repopularized them with the Map-Reduce programming style it uses internally.) The basic idea is that you design using mathematical functions, rather than machine operations. The practical difference being that in traditional languages you modify variables, whereas in functional languages you apply functions to constants to obtain new constants. Because you avoid variables, you avoid all sorts of difficult problems where multiple processors are trying to edit the same thing at the same time. It also means that the computer has incredible flexibility in being able to cache partial results, retry calculations, split up the code between multiple processors, and otherwise optimize or handle hardware failure.

Functional programming isn’t hard if you’re mathematically inclined. If recursion doesn’t throw you for a loop, it can be just as easy as traditional programming. But it’s hard enough to separate the Real Programmers from the code monkeys. And its advantages are compelling enough for programmers to switch to functional models. The main thing keeping functional programmers from being considered Real Programmers by the C/C++ crowd is the cultural divide. Real Programmers take pride in knowing exactly where their ones and zeroes are. (Except they don’t anymore, thanks to virtual memory, three or more levels of cache, and processors that rewrite their code on the fly.) Functional programmers pride themselves on keeping their code in the mathematical realm, far from any real processors. But as it becomes more clear that the “hard core” programming problems are best solved by the programmer writing specifications which enable the computer to use all its fancy optimization tricks, we’ll see more and more Real Programmers switch to functional programming.

As what may be an opening salvo, the Go language was designed in part by some of the people who invented C, and is named after one of its functional features.