CUFP Workshop - Featuring F#
The workshop is co-located with ICFP, and will be held in Freiburg, Germany, on 4 October . We had a terrific response to our call for talks, and there are twelve (!) speakers describing commercial applications, variously written in
The talks are informal, and there are no proceedings. We’ll just have fun learning about functional programming used to solve real problems. Do come!
Simon Peyton Jones
One of the important themes in programming languages over recent years has been a move to embrace ideas from functional programming.
Language features such as lambda expressions in C# and generics in .NET 2.0 have roots in functional languages, and LINQ is directly based on functional programming techniques. Through LINQ and Parallel FX, ideas from functional languages are helping us address some of the biggest challenges facing the industry today, from the impedance mismatch between data and objects to the challenges of the multi-core and parallel computing space.
Several of these key technologies have started out as projects in Microsoft Research. One of the really promising current projects from MSR is the F# programming language, spearheaded by Don Syme. F# stems from the functional programming tradition (hence the ‘F’) and has strong roots in the ML family of languages, though also draws from C#, LINQ and Haskell. F# is designed from the outset to be a first class citizen on .NET. This means that F# runs on the CLR, embraces object-oriented programming, and has features to ensure a smooth integration with the .NET Framework.
I am a big fan of technology transfer between a research organization and a product development organization so that we can “productize” the great research ideas and deliver to customers in a timely manner. This is one of the best things that has happened at Microsoft ever since we created Microsoft Research over 15 years ago. Here is another great example of technology transfer at work. We will be partnering with Don Syme and others in Microsoft Research to fully integrate the F# language into Visual Studio and continue innovating and evolving F#. In my mind, F# is another first-class programming language on the CLR.
Our interest in F# is motivated by several factors. As I mentioned above, we aim to continue the flow of good ideas from functional programming world into mainstream development. Furthermore, the somewhat mathematical slant of functional programming just seems naturally appealing to professionals whose primary domain is described with mathematical notation - domains such as financial, scientific and technical computing. On top of the syntactic appeal, the strong type system yields the sort of guarantees which are often crucial in these domains, and enables a superb tooling experience through Visual Studio.
Another motivation is to continue to invest in making the .NET Framework a great choice in academia. Many computer science departments around the world teach functional programming languages today. We believe that through F# and languages such as IronPython and IronRuby we can help offer students and educators choices beyond the current mainstream and enable the use of these languages across the curriculum. This helps educators have the option to use Visual Studio as a consistent tool set from course to course.
You can find out more about F# in Don Syme’s blog, and at http://research.microsoft.com/fsharp.
We stumbled upon an interesting result recently whilst toying with numerical benchmarks ported from OCaml. Typically, OCaml programs are very easy to port but run more slowly under F# because the performance characteristics of the languages are different. However, we recently observed that some benchmarks optimized for OCaml actually run substantially faster in F# without having to make even a single change.
Specifically, the OCaml implementations of the numerically-intensive spectral-norm and n-body benchmarks from the Computer Language Shootout run more quickly in F#. We believe the reason is essentially that Microsoft’s .NET compiler is much better at optimizing simple numerical algorithms, particularly loops over floating point arrays. Indeed, the results are all the more compelling because F# on vanilla 32-bit Windows XP Pro outperforms a longer, hand-optimized OCaml implementation running on OCaml’s best-case platform for numerical programs, 64-bit Linux. In particular, bounds checking incurs a significant overhead in the spectral-norm benchmark and, we believe, the bounds checks are automatically hoisted from the inner loop in F# but this must be done manually in OCaml.
This clearly shows that F# can achieve excellent performance on common machines for an important class of numerical algorithms.