Functional programming = more reliable software?

Functional programming = more reliable software?

Is there actual data showing that functional programming leads to more reliable software? I hear this claim a lot but have never seen data supporting it. One counterpoint is that real-world safety-critical software (for instance, avionics software) is typically written in a simple procedural style — see for instance the JPL / MISRA-C guidelines — because it is more amenable to static analysis. MISRA-C and functional styles are strongly at odds with one another — for example, some purely functional languages (e.g., Haskell) eschew loops entirely in favor of recursion, whereas recursion is prohibited by MISRA-C.

So, what real-world examples are there of safety-critical software that is written in functional style? Any Mars rovers? Antilock brake controllers? Nuclear reactor monitors? Pacemaker firmware?

I ask because a cursory examination of the subject leads me to believe that all safety-critical software is written in a strictly imperative style. If this is indeed the case, it strikes me as extraordinarily foolish to abandon this proven method (and its associated coding standards) in favor of an unproven one.

  • MISRA-C are guidelines for programming C. MISRA-C guidelines are at odds with functional programming because imperative and functional programming are at odds, i.e. they are very different programming paradigms. It basically just doesn’t make sense to transport the guidelines from one paradigm to the other.

    It is very likely that functional programming concepts are used in mission critical software. Imperative programming and FP are not contradictions. For example as C++ evolves (C++11, C++14, etc.) more and more FP concepts are adopted.
    Regulation, on the other hand, adopts new concepts only slowly. I suspect that you can wait a decade before FP ‘trickles down’.

    As to your very first sentence: “Is there actual data showing that functional programming leads to more reliable software?” Good question…

    • It basically just doesn’t make sense to transport the guidelines from one paradigm to the other.

      Agreed; I’m not saying I think the JPL or MISRA-C guidelines are directly applicable to FP. Rather, I’m remarking on how FP’s hype — that FP applications are/will be much more reliable than imperative/OO applications because of thought experiments X, Y, and Z — strikes me as hollow in the absence of actual safety-critical software written using FP.

      To be fair, the same conservatism through which I’m viewing this question might very well be dissuading any real-world safety-critical applications from being first through the breach. (If I were developing software for monitoring nuclear reactors, I’d sure as heck want to “play it safe”, too.)

      Still, it seems like some should be reliability data out there on this topic. Maybe there is and I just haven’t looked hard enough!

      Imperative programming and FP are not contradictions.

      While I agree that the styles don’t inherently contradict each other, there are definitely some “impedance mismatches” in the ways they are commonly used (e.g., the use/prevalence of recursion, as mentioned in the post).

      As to your very first sentence: “Is there actual data showing that functional programming leads to more reliable software?” Good question…

      This would actually be a fun research project, next time I have a few spare months 🙂

  • I can’t bring any examples from aerospace, medicine, automotive, etc. But I know that the finance industry is using functional programming (e.g. Haskell). The software in finance is mostly written in C++ and it regularly hits the “complexity-sound-barrier”. And there have been spectacular software ‘glitches’ (e.g. Knight Capital in 2012), most of which we don’t hear about…

    • Interesting! I’d be extremely curious to know what the failure rates are of financial programs written in Haskell compared to those written in, for example, C…

      • Schalk Dormehl

        Haskell imo isn’t really the ideal language. It completely denies the existence of Commands and produces really strange code in places. Its purity also makes for optimization problems, which can be solved, but sometimes make for even stranger code. Haskell’s primary benefit is forcing the functional agenda and making programmers better functional programmers in other languages.

        Solidity with a “pure” keyword, some implied typing and lamdas would produce excellent functional code. (and no constant doesn’t count)

  • Schalk Dormehl

    Having worked with libraries like ReactiveExtensions, that evaporate hard concurrency problems to the point where new programmers understand them as easily as arrays, I can only assume that not all sound approaches gain adoption immediately and really nothing guarantees they do at all. It is however trivially apparent once you gain some experience in the techniques that defects are radically reduced.

  • Schalk Dormehl

    Also lots of functional code exists in those languages, just as lots of object oriented code exists in C. The principles can be applied in most languages, but require extra discipline.

    Lots of functional code made it into Quake and Doom’s code for instance. http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php

Comments are closed.