[Blog Map] [Table of Contents] [Next Topic] This blog is inactive. New blog: EricWhite.com/blog
FP introduces the notion of pure functions/methods. A pure function is one that doesn't affect the state of anything outside of it, nor depends on anything other than the arguments passed to it. Also, given a set of arguments, a pure function will return the same result.
Among other things, if a method does any of the following, it is impure:
· Altering a parameter that was passed by reference
· Altering the members of a passed object (all objects are passed by reference)
· Altering external objects, static members of classes, etc.
The term for these things is "side effects". A pure function doesn't have any side-effects.
The benefits of writing pure functions are:
· If we write functions that don't have side-effects, then we can use them whenever and wherever we want to when composing our queries. Pure functions lead to composability.
· Testing is easy. Once we have tested all edge conditions on the arguments to our function, we can be certain that the function works properly.
· Concurrency is (at least theoretically) possible. If we know that a function relies on nothing other than its parameters, then we (or the compiler) might be able to execute the function in a new thread, or even a different CPU. This is one of the directions that the industry will take in the future to take advantage of multiple CPUs.
Any functions (utility functions, extension methods, lambda expressions, etc.) that we want to use within a query expression should be implemented in a pure fashion. In particular, when we write new query operators (extension methods that operate on IEnumerable<T>), we always want to write them to be pure.
Actually, there are two types of impurity
· The impurity is contained inside the method
· The impurity leaks out of the method. For purposes of threading and taking advantage of multiple core CPUs, and multiple CPU computers, impurity that is contained within a single method still may allow for queries to be parceled out to separate threads and possibly separate processors.
One of the sources of bugs in conventional-object oriented programs is something called broken invariants. There are invariants associated with many classes - for example, if one member has some value, then another member needs to have a particular range of values. This is a funny way to get rid of those types of bugs: just say no to state!
[Blog Map] [Table of Contents] [Next Topic]
I've just stumbled upon the concept of functional programming and I don't quite get it yet. Are there real life applications of FP except mathematical functions and scientific calculus?
Can something like an N-tier application improve with functional programming?
This has been an excellent series of posts. As you were introducing the concept of pure functions, I thought about working static methods in Asp.Net or that access external dbs. These are obviously not pure, but I often implement a series of helper methods that could be pure if I was focused on not using other impure static methods.
Well, it would be interesting if there were a pure keyword in addition to the static keyword. Obviously that would be impossible to implement into the current framework. But perhaps this could be done using attributes. Basically the pure attribute would only allow the method to access other pure functions, etc.
In this way, the compiler can enforce the purity of a method.
This is a response to both of the above posts. Sorry for being deliquent! :-)
It would be possible to annotate methods, indicating that they were pure, but given the semantics of C#, it would be very difficult to enforce.
Also, regarding applicability of functional programming, I believe that the sweet spot for FP is transforming data. Anytime that you have one set of data, and you want to transform it into another shape, FP would be applicable. WRT n-tier applications, I believe that FP is applicable in the small - i.e. there might be times when you need to generate XML that will be used to communicate from one tier to another, perhaps. The generation of the XML itself could be done in an FP manner.
Of course, I am still learning about all of this.
[Table of Contents] [Next Topic] LINQ query expressions look a lot like SQL, and that is intentional.