[Blog Map] [Table of Contents] [Next Topic] This blog is inactive. New blog: EricWhite.com/blog
We're now ready to talk more about some of the core FP concepts.
Imperative languages are state based. Object-oriented programming languages such as C#, C++, and Java have extensive capabilities to maintain and modify state. To extract and transform data from a data source in an imperative language, you typically need to iterate through the data, write code to filter the data, and write more code to create the data in your desired result set. In many cases, you create intermediate result sets.
In contrast, declarative languages are transformative in nature. Instead of coding algorithms that extract data and produce result sets, writing data transformation code in LINQ is more akin to describing the results of each successive transformation, without using state to manage the transformation. In many cases, if a purely lazy approach will work, code written in the functional style works in a streaming fashion.
This is a much more powerful approach. There are significantly more opportunities for bugs when keeping extensive state. Another major advantage of the declarative approach is that the resulting code may be more comprehensible at a glance. In contrast, to figure out the functionality of a block of involved imperative code might involve detailed perusing. You have to understand the state that is created at each step of the process. Of course, a bad programmer can still write bad declarative code, and a good programmer can write clear, commented imperative code.
Another advantage of the declarative approach is that the resulting code is typically smaller.
Sometimes when you are transforming data, for performance, you may materialize intermediate results. A typical scenario is one where you have a massive amount of source data, and you transform it into another form that allows for easy, quick access. For instance, you may transform a big collection of word documents into a much smaller sorted dictionary that is used in further transformations. But in the functional approach, once you have created and populated the dictionary, you don't modify the contents of it further.
[Blog Map] [Table of Contents] [Next Topic]
I'd write this:
Sequence.Range(1, 10).ForEach(i => Console.WriteLine(i));
... personally... :)
Agreed with barrkel.
And I'd use Action<T> instead of introducing duplicated VoidFunc<T0>(T0 a0);
I am using Visual Studio 2008 Beta 2, I can't seem to detect this:
Sequence (I can't find a namespace for it too)
Is this built by you or?
One of the big problems when doing functional prigramming in C# are the data structures in C#/.NET, they are not side-effect free!
In functional programming, you are used to be able to add a element to a list or tree, but the old part of the tree can still be used elsewhere (unchanged!).
I haven't decided if I should use F# more, or if I should start using the data structures of F# in C#. The reason for continuing to use C# is tools like R#, and that it is easier to let other programmers enhance the program.
WRT side-effects and C#/.NET, this is absolutely true. C# relies on the discipline of the developer to write code that has no side-effects. However, this allows approaches where you write code that is locally impure, but globally pure, and this results in far more readable code.
I've been contemplating what it would look like to write a C# compiler that would enforce purity for methods that are private to a class. Of course, this brings problems with things like partial classes - how do you enforce purity for all private classes.
In your code sample, you need to change Sequence. to Enumerable. in order to run and compile on VS2008 RTM.
LINQ extensions .nogen ideer til hvad vi mangler?