So here I am back up, computer back on, reacting to "A New Way to Squash Bugs." Let me be perfectly clear: Author Charles Scalfani's functional programming does no such thing. "Functional programming" means subroutines without side effects, no changes in the computer state that persist after the subroutine exits. Mathematical functions work this way, but not much else. Any benefit he may get from trying to force-fit other kinds of problems into the Procrustean functional bed is probably the same benefit realized from trying to force-fit non-object-oriented problems into an OOPS bed: You must think extra hard to make it work at all, and it is the extra thinking that eliminates the bugs, not the tool.
He credits the programming language Haskell, created in 1990 with being "the first purely functional language to become popular." I know better, LISP was popular for AI applications for the previous three decades, and it was originally created as a purely functional language. It didn't stay that way, because too many programs need state and side-effects.
My PhD dissertation in 1985 invented and described "Transformational Attribute Grammars" which were in effect a purely functional language. You can download a working TAG self-compiler from my website, which implements the insights of my dissertation. It is still a purely functional programming language -- well, not quite: I needed a global variable to hold the generated output code, and I could have simulated it in a state variable carried around everywhere, but that was much too slow. LISP probably had the same experience. Both Haskell and Scalfani's own functional programming language "PureScript" can read and write data files, which are side effects. If nothing else, you can write your global variables to a file and read them later. It's even slower than carrying around a giant state variable, which means there are at least two different ways to code non-functional subroutines in what Scalfani claims is a purely functional programming language. It's just slow and difficult.
Scalfani argues his case for a purely functional programming language by analogy with the banishment of GOTO from so-called "structured" programming languages (pretty much everything today), but he got his facts wrong. I code in Java every day, and I use GOTOs all the time, except they are spelled "break" and "return" and "throw." They are not quite as anarchic as the old GOTO, but they do just about everything I need in a GOTO, and the rest I program around using global state variables. And yes, my programs are hard to read and hard to maintain, but it's not the fault of the GOTOs, it's because I build very complex programs that most programmers couldn't even begin to do.
The other problem Scalfani thinks his functional programming solves is null pointers. Maybe he has banished null pointers as such, but he has not solved the problem, only made it worse. Null pointers (data that has not been given a legitimate value) are not the problem, sloppy code is the problem, and the solution he offers in his goofy PureScript syntax is just as easily implemented in readable Java code -- I know, because my T2 (Java) compiler does it essentially the same way, but I need to ask for it each time. I could have made it default on, but I aimed my programming language at a much broader class of programs than Scalfani contemplates.
Most problems that come before a programmer have occasions to refer to invalid data. For example, you'd think that numerical data is just numbers -- except when the input failed or you tried to divide by zero, stuff like that. Before Professor Kahan made his case to the IEEE standards committee, numbers were just numbers, and Kahan could take a standard off-the-shelf commercial 12-digit calculator and do a simple (standard) 30-year mortgage calculation that was wrong by whole dollars. Kahan's whole career was dedicated to getting accurate, correct calculations, and his "NaN" (Not a Number) innovation wasn't the most important in our* standard (correct rounding was far more critical), but it was part of what made our standard universally accepted today. Null pointers are a useful and important (and easily tested, no extra hardware needed as for NaNs) way to represent invalid data. Take that away and programmers will get around the limitation by building more complex data structures with a flag that means "invalid" or co-opt one of the legitimate data values to mean "invalid" and you will have exactly the same (or worse!) bugs, but the compiler and run-time cannot help you find them. As I said, it's not the functional language that offers this help, but a simple use of data flow analysis already done in most compilers, including my own Java.
I have spent maybe five or six years teaching programming, and an order of magnitude longer using -- and writing compilers for -- a variety of languages, so I understand the problems Scalfani thinks he is solving. He has one idea correct: we want the compiler to catch as many programmer errors as possible, but that does not necessarily require a more limited language like functional programming. He just doesn't know what he doesn't know.
IEEE Spectrum used to print author contact information, but not this issue. They also have no feedback (letters) page, so I have no way to tell Scalfani what I think of his idea and his product. He probably wouldn't want to know anyway. He has a goofy toy language that solves toy problems by making them harder to program (so you think harder, and therefore make fewer mistakes), and being told it's only a toy would be disaffirming, and the American edu-factories do nothing so well as teach little kids the importance of unearned self-esteem (at which we rated highest, while being dead last among industrial nations in actual math and science). Whatever.
* Our standard -- Yes, I was on the original IEEE 754 Floating Point Standard draft committee with Dr.Kahan, his student Jerome Coonen, and John Palmer, an engineer at Intel. We were sometimes called "the Gang of Four" and the draft standard was first composed on my computer.