Just my opinion...

ADDENDUM: In a comment to my “Why F#?” post Greg pointed me to a thought provoking article over at Object mentor.  Go check it out.

I’m still waiting for my “ah-ha!” moment with functional programming.  I may be closing in but I’m still falling just a bit short.  I think I’m on the correct line of investigation though.  Once I found this line, I thought it might help you if I shared it before you have to stumble around with functional programming until you find it.  Perhaps, this “starting point” is apparent to everyone except me.

Working with lists of things is pretty common in functional programming implementations.  Recursion is the common method of iteration over lists.  What’s the most common limitation of recursion?  Of course, overflowing the stack.  So, you soon need to learn to refactor recursive functions to use “tail recursion“.  Examples of tail recursion in basic FP tutorials and courses soon lead you to the topic of “folds” over lists.  Studying folds and lists may lead you to the concept of catamorphism.  And so on.

I thought I would write an insightful post detailing some of these concepts but quickly decided that I would just compile a somewhat ordered set of links.  Some are theory and some are related to F#.  The links to background theory are generally to Wikipedia while the links targeted at F# will generally be to blog articles, most notably, Brian McNamara’s blog and a series of posts I’m reading through.  The following sequence of links should be read/learned in order.  Clearly, some of them could be paralleled and the order isn’t written in stone but I have tried to order them so that they are coherent.  The link to functional programming already shown in this post is probably a must-read preliminary to set context.

Some background theory:

Why Functional Programming Matters
High-order functions
Laziness
Anonymous functions (lamdas)
Fold (not that Map and other HOFs aren’t important)
Catamorphism
Currying
Closures

Now for some practical articles:

F# function types: fun with tuples and currying
Catamorphisms, part one
Catamorphisms, part two
Catamorphisms, part three
Catamorphisms, part four
Catamorphisms, part five
Catamorphisms, part six
Catamorphisms, part seven
Catamorphisms, part eight (just for Brian’s sake to be complete)
How does functional programming affect the structure of your code?

The series of posts that Brian has written about catamorphisms is great.  Doing web searches on catamorphism lead me to his series and I’m very grateful that he’s written the series.  I think trying to understand them otherwise would take me an order of magnitude more time.

It was duing the study of catamorphism that I got my first little spark of self-actualized functional thinking.  Maybe I’m biased now but if anyone out there gets the “ah-ha!” moment because of going through the links I’ve pointed out, then I’m a happy guy.  I’ll be even happier when the light-bulb finally stays lit for me.

I answered a question via email at work recently and realized that it might be worth sharing that explanation here.  Not because I am a great F# and functional-programming guru but because, I am hoping some of you out there can chime in and correct anything I may have said in error or add useful information to my colleagues and me.  I’m saying “Thanks!” in advance.

A little background first:  The project I’m currently working on is still in the requirements gathering and technical research stage.  I’ve been asked to do some forward-looking research and help make decisions about what new technologies we may want to consider.  In this project, it will be beneficial to us to be able to create new entities in the problem domain without having to code these entities as classes.  Furthermore, these entities will have rules applied to them in various combinations to allow for the analysis of anomaly detection, therefore, a domain specific language (DSL) is a reasonable option for us to consider.  I suggested in an email that some folks go look at NaturalSpec for an example of what others have done in F# to create a DSL.

I got the following response (edits made for privacy concerns):

From: <Paul>
Sent: Thursday, April 16, 2009 1:32 PM
To: <a bunch of folks>
Subject: RE: A cool DSL

This is great, just want to mention a few things: 

1) Why F# and not C# with development environment tools? modify coding standards?

2) Can your conceptual DSL input formulae constants from a manufactures recommended operating limits document and/or a units Standard Operating Procedures (SOP)?

3) How well can F# handle mathematical routines like non-linear partial differential equations, FFT’s, and inferential statistical routines? How efficient is the compiler at generating fast running code in these areas? Could one build a neural net in F#?

My response:

From: Cilyok, Carey
Sent: Thursday, April 16, 2009 3:02 PM
To: <A bunch of people>
Subject: RE: A cool DSL

Wow…  This is going to be a long answer Paul.
 

Question 2: Handling formulae, vendor specifications, and unit level SOP is WHY we want a DSL.  The inverse question that begs a DSL (or, at a minimum, a configurable analysis engine) is “How do we handle those things?”  We could clearly do this with C# but F# was actually designed (in part) as a language to support the creation of DSLs and, as such, includes tools (fslex/fsyacc) to allow the creation and maintenance of grammars to specify DSLs.  Our big problem will be coming up with an expressive enough language to support our needs.  We don’t want to compound that problem with a parser/emitter problem and implementing/maintaining a hand-coded recursive descent parser (or top-down parser, or whatever technique we use).  Again, codifying “Gold Standard Libraries” and vendor specifications is the problem.  I’d propose that F# is a better tool to address an implementation so we can work the problem.

Questions 1 & 3 actually go together:

First, I’m NOT suggesting we use F# for everything, only for the specific, targeted areas of the architectural implementation where it provides clear advantage.  Which leads to –

“Where does F# provide a clear advantage?”

You nearly answered that question with question 3.  As stated above, F# supports the creation of DSLs.  Also, F#, as a functional language, is designed to excel at mathematical expression and computation.  Much of the mathematical community already uses functional languages like Haskell, Caml, Mathematica, etc.

“How efficient is the compiler at generating fast running code in these areas?” – Efficiency in processing has little (if anything nowadays) to do with the optimizations of the compiler.  Most compilers are efficient at exploiting the target hardware, fsc.exe included.  True gains in efficiency are now a function of how well the developers exploit the potential of the hardware via multi-threading and parallelizing concurrent tasks.  The complexities of thread management in an imperative language like C#, is another reason functional languages have gained renewed recognition over the last few years.  For instance, concurrency of data access is one of the stumbling blocks to multi-threaded programming.  In functional languages, data immutability is directly supported as a feature of the language which aids in parallelizing tasks, in turn making it easier for the developer to exploit the potential processing power of the host machine (whether it be multi-processor or multi-core, etc.) and eliminating the need to even worry about things like semaphores, mutexes, and exclusive locks.  Moore’s Law still predicts a doubling of computing power approximately every two years.  Great!  The problem lies with us, the developers.  We can’t effectively exploit this power in “traditional” imperative languages.  Luckily for us we seldom need that much power, after all, a GUI thread can do nothing, waiting on a user to click a button REALLY fast.  Unfortunately, for us in <our project>, we’re going to be asked to do some tasks that ARE computationally intensive.  We do need to try to exploit the full potential of the hardware.  Experts applying the combination of Gustafson’s Law and Amdahl’s Law have suggested that in order to exploit this computing power, new approaches to factoring problems and implementing the solution need to be used.  That’s where functional languages fill the gap.

“Could one build a neural net in F#?” – I have VERY little experience or background in artificial intelligence so I haven’t the faintest idea about this one.

All is not all peaches and cream in the F# world.  Learning to truly apply a functional language like F# is VERY difficult.  It requires a new approach to factoring problems.  In the imperative programming (waterfall, object-oriented, etc.) world we’re all used to, you specify the steps required to accomplish the outcome.  In the functional programming world you specify the conditions of the problem and your goals (essentially specifying the outcome) and the computer works out the steps.  Totally foreign concept to most of us.  Very few programmers will look at F# code and “get it”.  Our minds simply aren’t wired to approach programming that way.

We have to develop a new system and one of the requirements of that system is to scale to either bigger machines or more machines and gain performance (I just quickly went looking for that stated in the requirements and couldn’t find it but I’ve read it in one of the specs).  My objective in researching F# is to fulfill that requirement.  It’s incredibly unlikely that if we field without having given due process to this requirement that we will ever revisit the issue.  Honestly, how many times have you seen performance as a requirement addressed after a product hits the field?  I’d prefer to take the pain now instead of later.

A potential argument can be made against using F# because it’s still not supported as part of the standard VS 2008 delivery.  In VS 2010 F# will be available as an additional add-on language to VS 2010 and a fully supported .NET language.

Hopefully I’ve answered the questions.  I may not have given the answers you wanted to hear.  After all, I’d love to be able to say F# is THE way.  It isn’t – it’s an option to solving some of the core problems we face.

Carey

I’m still working on my research into functional programming but my study was interrupted by a trip for work. I spent 4 days watching the people for whom I’m going to be writing software, doing their job. That’s much more valuable to me than the research is at the moment. Now that I’m back to the research, I should have something to say soon.