In a fascinating interview in this issue of Simple-Talk, Don Syme discusses his work on the F# programming language, its journey from it academic roots in ML and Ocaml, to its burgeoning status as the hottest new thing in .NET. A central pin in the forthcoming "parallel processing, multi-core revolution", it may or may not be, but F# has certainly captured people's attention as a simple, multi-purpose language that can be used for anything from performing complex calculations, building websites, or as a powerful scripting language.

I've been slow to latch on to F#, but it was this apparent enthusiasm for F# as a scripting language that finally prompted me to take a look, along with an observation by Simple-Talk's Laila Lotfi that it was a language "that is surprisingly intuitive for any SQL Developer". Could this possibly be the "unifying" scripting language for developers and DBAs?

Being essentially a functional language, F# has a markedly different philosophy to an imperative language such as C#. Instead of providing a detailed set of instructions that must be followed to achieve the desired result, F# applies a series of transformations and filters (in the form of functions). This certainly sounds very "SQL like" in its approach, but how does it work in practice? Coincidentally, Chad Miller wrote a small blog post on SQLServerCentral showing how to script out all the tables in a SQL Server database using F# and SMO. Leaving out the few lines required to import the SMO libraries and so on, the code is as follows:

let svr = Server(@"ServerName\InstanceName")
let db = svr.Databases.["DatabaseName"]
   for t in db.Tables do
   for s in t.Script() do
   printfn "%s" s;;

It is certainly a very clean, short, uncluttered script, but it isn't, as the author acknowledges, very F#-like. One of the strengths, though some would argue weaknesses, of F# is that it allows many different ways to tackle the same problem. Here, we simply waddle through the usual for loop, scripting out the contents of the SMO Tables object. One could write a very similar-looking script in PowerShell or Python. If we express the script in a way more idiomatic of the F# language, it might look something like this:

db.Tables
   |> Seq.cast
   |> Seq.collect (fun (t:Table) -> t.Script() |> Seq.cast)
   |> Seq.iter (fun s -> printfn "%s" s);;

What this code does, in simple terms, is get a list of tables into a parameter of type table (t:Table), and then apply a pipeline of "transformations", scripting out each table, concatenating the results (seq.collect) and then "selecting" each one out (seq.iter) and printing it. The seq.cast function translates the Ienumerable type that's delivered by SMO into something F# can use. As a fully-fledged part of the .NET framework, one would hope that over time the need for these sorts of translations will disappear.

Overall the code is still short, at least, but certainly looks a lot less intuitive at first glance! However, if you start to think of those pipeline characters (|>), which funnel values from one transformation to the next, as akin to connecting arrows in a SQL execution plan, then perhaps one can start to see how, after a little practice, this style of scripting may come fairly naturally to the SQL developer and DBA. Or maybe not!

Perhaps I will forever hope in vain for a common scripting language to unite DBAs and developers, but I do see some potential in F# and, as powerful as PowerShell undoubtedly is for database maintenance, you can't reuse what you've learned to build websites or "bond" with your developers. How proud would developers be of their DBA if he scripted database tasks using F#?!

As always, we love to hear your thoughts and objections, so please add them as comments. This week, a $50 Amazon voucher goes to randyvol for his excellent contribution to the "Reckless Drivers" blog.

Cheers,

Tony.