Comments on: Code Read 9 - John Backus and Functional Programming http://www.upayasoftware.com/2007/04/29/code-read-9-john-backus-and-functional-programming/ Looking for the skillful techniques which make it easier to build software well Fri, 21 Nov 2008 04:45:40 +0000 http://wordpress.org/?v=2.6.3 By: Andrew Sacamano http://www.upayasoftware.com/2007/04/29/code-read-9-john-backus-and-functional-programming/#comment-3 Andrew Sacamano Wed, 02 May 2007 11:06:26 +0000 http://www.upayasoftware.com/?p=16#comment-3 Thanks for the feedback, Weave Jester. You make some very important points, particularly about testing. And I whole-heartedly agree with you that side-effect free programming is the most important idea to come out of FP, and is now generally accepted to be one of, if not the most important, distinguishing ideas of FP. Like you say, "there are considerable advantages to building software in a language that is entirely free of side effects."<br/><br/>But in Backus's paper, side-effect free programming was a definite tangent - his primary argument was that FP was more expressive and conceptually clearer than imperative programming (VNP).<br/><br/>And FP is not the only side-effect minimizing tool. Another style of programming that encourages side-effect free code (but is even less popular than FP) is dataflow programming - look at Prograph, for example.<br/><br/>Lastly, in terms of efficiency, I'm still not convinced. Call by reference, which inherently produces side effects, is a significant performance advantage. It may be possible for skilled FP coders to work around that issue, but I'm not sure. Convince me, somebody... Thanks for the feedback, Weave Jester. You make some very important points, particularly about testing. And I whole-heartedly agree with you that side-effect free programming is the most important idea to come out of FP, and is now generally accepted to be one of, if not the most important, distinguishing ideas of FP. Like you say, “there are considerable advantages to building software in a language that is entirely free of side effects.”

But in Backus’s paper, side-effect free programming was a definite tangent - his primary argument was that FP was more expressive and conceptually clearer than imperative programming (VNP).

And FP is not the only side-effect minimizing tool. Another style of programming that encourages side-effect free code (but is even less popular than FP) is dataflow programming - look at Prograph, for example.

Lastly, in terms of efficiency, I’m still not convinced. Call by reference, which inherently produces side effects, is a significant performance advantage. It may be possible for skilled FP coders to work around that issue, but I’m not sure. Convince me, somebody…

]]> By: Weave Jester http://www.upayasoftware.com/2007/04/29/code-read-9-john-backus-and-functional-programming/#comment-2 Weave Jester Mon, 30 Apr 2007 11:36:23 +0000 http://www.upayasoftware.com/?p=16#comment-2 The primary difference, in my opinion, of functional programming compared to more traditional imperative methods, is its attempt to minimise side effects. The more side effects are done away with, the more 'functional' a language is. If there are no side effects whatsoever, then the language is purely functional. The elimination of side effects is not, itself, a side effect - it's one of the basic principles by which FP is defined.<br/><br/>A lack of side effects is not only useful for parallel programming; it's also useful for testing and reliability. You can unit test a pure function however much you want, safe in the knowledge that for any argument x, you'll always get the same return value, y. You can also be sure it won't inadvertently change your system in any way.<br/><br/>Combined with a robust type system, you have further opportunities to check your program is correct. Since all effects of a function must occur through its return value, this means all the effects of a function must also be typed. A type system in a purely functional language is more pervasive than one in an imperative language can be.<br/><br/>Regarding efficiency, pure functional languages are not significantly any less efficient than their imperative equivalents in most cases. Certainly the difference is much smaller than the difference between, say, C++ and C#.<br/><br/>Whilst FP languages can be hard to read and understand, I'm not certain that has to be the case. And even if that is the case, I don't think a programming language has ever died from being too complex :). Maybe pure FP will never be mainstream, but I don't think it will disappear, either; there are considerable advantages to building software in a language that is entirely free of side effects. The primary difference, in my opinion, of functional programming compared to more traditional imperative methods, is its attempt to minimise side effects. The more side effects are done away with, the more ‘functional’ a language is. If there are no side effects whatsoever, then the language is purely functional. The elimination of side effects is not, itself, a side effect - it’s one of the basic principles by which FP is defined.

A lack of side effects is not only useful for parallel programming; it’s also useful for testing and reliability. You can unit test a pure function however much you want, safe in the knowledge that for any argument x, you’ll always get the same return value, y. You can also be sure it won’t inadvertently change your system in any way.

Combined with a robust type system, you have further opportunities to check your program is correct. Since all effects of a function must occur through its return value, this means all the effects of a function must also be typed. A type system in a purely functional language is more pervasive than one in an imperative language can be.

Regarding efficiency, pure functional languages are not significantly any less efficient than their imperative equivalents in most cases. Certainly the difference is much smaller than the difference between, say, C++ and C#.

Whilst FP languages can be hard to read and understand, I’m not certain that has to be the case. And even if that is the case, I don’t think a programming language has ever died from being too complex :). Maybe pure FP will never be mainstream, but I don’t think it will disappear, either; there are considerable advantages to building software in a language that is entirely free of side effects.

]]>