Strangelights

F# is on dotnetrocks again, this time it’s Amanda Laucher and Ted Neward’s turn to talk F# with Carl and Richard. I have to say of all the F# podcast there have been so far this is my favourite. Why? Amanda and Ted do a really great job of articulating what I’ve been thinking about F#, and functional programming in general, for some time now. I think this is because Amanda and Ted have a similar background to me – they both come from the world of line of business applications. This is interesting because if you read the marketing blurb from Microsoft F# is clear target at the scientific/mathematical world, with a foot note that it is a general purpose programming language that can be used for anything you like.

So where’s the interest in F# for the average line of business application, well in short: it’s the business logic. Its seems to be widely agreed that the business logic (or “the domain” if your that way inclined), is the hardest part of the application. If you want simple CRUD app with no business logic, why not use COBOL? It’s great for cracking out that sort of thing. One of the main things developers of complex business logic want is for it to be testable. This is where pure functional programming excels; if a function receives the same input it always returns the same output. What could be more testable than that? While F# doesn’t force you to be pure at least it leads you in that direction. But it’s more that testability, in the world of business logic we’re talking about algoritms, we’re talking about verbs (rather than the nouns of the OO world), and it were talking about really complex business logic we’re probably talking about maths, all things that functional programming is good at. Functional programming encourages us to abstract further, to focus on the what we want to do rather than the how. Taken to its natural extreme this means using language oriented programming techniques and building DSLs to handle business logic. In the world of handling complex business logic being able to design a language that accurate and concisely describes the logic is something of a hole grail. No one’s going to pretend that designing a good DSL is easy in F#, there are no silver bullets, but it does at least hand you some of the tools you need. F#’s rich and flexible type system, gives you a union type that’s excellent for focusing on describing the semantics of a problem and it also gives you several integration points, workflows and quotations, that allow you to tweak or reinterpret the syntax.

People may see this as an attack on the dominance of OO in the programming world, a new FP/OO, but nothing is further from the truth. There’s much more synergy here that people release. It seems to me the concerns of OO and FP are largely orthogonal. OO is concerned with the nouns describing the nouns of a system, with encapsulating data, and describing its structure of data. Its big bother component orientation has really taught us how to put together great libraries. While FP focus on actions and algorithms. In fact there are some that believe people take the whole OO/FP thing too seriously, and that the real advantage of F# is it allows you forget all that and just write great programs for the domain your focusing on.