I am a big C# fan. As a general purpose, imperative, object-oriented language, C# has begun to take on some functional language capabilities that I like very much. LINQ just rocks, for example. And LINQ is a very functionally-oriented technology. It's so easy and expressive to get set-oriented work done using LINQ and it's functional underpinnings are the reason why.

I have been thinking a lot recently about why F# might be important to the future of all software development. If you think about it, there's really little in F# that doesn't already exist in other languages like OCaml and Haskell. But F# is significant and different because Microsoft is behind it and because of the tight integration with the .NET framework. But beyond the who of F# is the why of its importance. And the why, in my mind can be summed up with these five bullet points:

• ORMs are failing to gain mindshare not because they aren't good domain modeling tools (as some complain about). They are failing because the imperative, object-oriented languages in which we use ORMs are unfriendly to sets and tuples.The database is full of nothing but sets and tuples. So we read them into objects and wonder why there's an impedence mismatch. F# is not only set and tuple friendly. You can't really think properly in F# without these first-class constructs.
• Domain Specific Languages (DSL) are becoming more and more important in the marketplace. And functional languages are great for building language compilers. Language parsing into discrete intermediate forms is a problem that benefits greatly from the lambda calculus and functional decomposition. F# is appearing at the right time and place in history to serve in the critical role of helping us to build new DSLs.
• Many of our time-honored design patterns are workflow-oriented. So, why do we shoe-horn them into data structures? Workflows are, by definition, composed of functions invoking higher-order functions. Step 3 invokes on the result of Step 2 which invokes on the result of Step 1. So, why do we code the Visitor Pattern to walk a tree into a data structure like an object? It makes no sense, really. F# allows us to revisit these time-tested patterns and view them in the light of functional decomposition. And the result will allow many who have been unable to grasp those patterns though an imperative lense to "get it" for the first time.
• Service-Oriented Architecture (SOA) is predicated on the idea that strict operation contracts exist that take discrete, strongly-typed inputs and return strongly-typed results. F# rolls like that. There's no object-orientation in SOA, per se. In fact, SOA sort of shuns OOP to a certain degree. And good service design also avoids side effects, another tenet of functional languages. So, if SOA is important, and I think it is, then languages that follow the patterns of SOA will also be important in building compliant architectures. I think good architects will recognize the pattern and find interesting ways to expose services via F#. We will code the guts of services in C# and Java in the future. No question there. But the workflow, scheduling and execution core of SOA will be based on functional languages like F# instead.
• Moore's law is breaking down. Intel and other companies are all moving to put more computing cores into their packages because they can't scale computing power vertically beyond what modern physics will allow. So, they are scaling horizontally to meet customer demand. The problem with this concept is that the marketplace isn't really ready for this kind of change. Massive pools of threads attempting to use Many Reader, Single Writer Mutexes with Starvation Avoidance ain't gonna work, my friends. We need a new model that will make parallelism invisible. But for parallel computing to become invisible, we need to move to a model that doesn't require the programmer to be involved in locking and serializing access to their code. F# is ready to help us think that way. And it's .NET! Beauty, eh?