I've just recently discovered the functional programming style and I'm convinced that it will reduce development efforts, make code easier to read, make software more maintainable. However, the problem is I sucked at convincing anyone.
Well, recently I was given a chance to give a talk on how to reduce software development and maintenance efforts, and I wanted to introduce them the concept of functional programming and how it benefit the team. I had this idea of showing people 2 set of code that does exactly the same thing, one coded in a very imperative way, and the other in a very functional way, to show that functional programming can made code way shorter, easier to understand and thus maintainable. Is there such an example, beside the famous sum of squares example by Luca Bolognese?
I came up with a little trick recently to make lambdas, passed into my extension methods look more F# ish. Here it goes:
What I wanted to do was something like:
Now the extension method for that is easily implemented:
What I didn't like is that I am specifying the index here:
ForEach(index => action())
although it never is used, so I replaced it with a_
and gotForEach(_ => action())
That's nice, but now I was motivated to have my calling code look similar
(I never liked the "()" at the beginning of the lambda expression), so instead of:
3.Times(() => ...);
I wanted3.Times(_ => ...);
The only way to implement this was to pass a fake parameter to the extension method, which never gets used and so I modified it like so:This allows me to call it like this:
Not much of a change, but I still enjoyed, that it was possible to make that little tweak so easily and at the same time removing the "()" noise makes it much more readable.
A simple example of a task that is often easiest done in a functional style is the transformation of data from one form to another. "Sum of squares" is a trivial example of data transformation. Luca's talk at last year's PDC showed how to use this sort of data transformation for something more practical, downloading and analyzing stock quotes. The demo is done in F#, but the concepts are the same and can be applied to C# or most other programming languages.
http://channel9.msdn.com/pdc2008/TL11/
Algorithms involving backtracking search and simplifying undo support in GUIs are two places I've used functional style in practice.
Not really answering the question, but this is a very good link for those who want to know about functional programming in C#
http://blogs.msdn.com/b/ericwhite/archive/2006/10/04/fp-tutorial.aspx
If by the 'functional style' you mean the usage of concepts like 'map', 'apply', 'reduce', 'filter', lambda functions and list comprehensions, then it should be evident that code that has to deal with operations on lists is almost always more concise when written in the 'functional style'. But if you're mixing 'functional style' with imperative code in a mostly imperative language, it really is just a matter of style.
In python for example, you can reimplement the Haskell qsort crackmigg posted like so:
Although writing the last line as
is arguably more 'pythonic'.
But this is obviously more concise than the implementation here:
http://hetland.org/coding/python/quicksort.html
Which, incidentally, is how I would have thought about implementing it before I learned Haskell.
The functional version is extremely clear if and only if you are acclimated to functional programming and grok what
filter
is going to do as easily as the well-worn C++ programmer groks afor
loop without even having to think much about it. And that's clearly what the real issue at stake here: functional 'style' programming is a completely different mindset. If the people you work with aren't used to thinking recursively, and aren't the type to get excited about, not just a new technology, but a whole other way of thinking about solving their problems, then any amount of code comparisons isn't going to win them over.If you've only just discovered functional programming, I do not recommend trying to speak authoritatively on the subject. I know for the first 6 months while I was learnig F#, all of my code was just C# with a little more awkward syntax. However, after that period of time, I was able to write consistently good code in an idiomatic, functional style.
I recommend that you do the same: wait for 6 months or so until functional programming style comes more naturally, then give your presentation.
I gave an F# presentation to the .NET users group in my area, and many people in my group were impressed by F#'s pattern matching. Specifically, I showed how to traverse an abstract syntax tree in C# and F#:
The code above is written in an idiomatic C# style. It uses the visitor pattern rather than type-testing to guarantee type safety. This is about 218 LOC.
Here's the F# version:
This is 65 LOC. Since it uses pattern matching rather than the visitor pattern, we don't lose any type-safety, and the code is very easy to read.
Any kind of symbolic processing is orders of magnitude easier to write in F# than C#.
[Edit to add:] Oh, and pattern matching isn't just a replacement for the visitor pattern, it also allows you to match against the shape of data. For example, here's a function which converts Nand's to their equivalents:
Its not possible to write this code concisely at all in C#.