19 January 2010

Don Syme: Geek of the Week

It came as a surprise to many of us when Microsoft pulled from it's hat a rabbit in the form of an exciting, radical, language that offers an effective alternative to the Object-oriented orthodoxy. The creative force behind this language, F#, turns out to be a brilliant Cambridge-based Australian called Don Syme, already well known for his work on generics in .NET. F# has taken the specialised power of ML and OCaml and developed a versatile general-purpose .NET language. We sent Richard Morris across the road to investigate.

918-ds.JPG

There are legions of developers across the world who would like to shake the hand of the famously sleep-deprived Don Syme. For he, along with his team of Cambridge-based researchers, has been the driving force behind the development of the F# language at Microsoft. Smoothly combining the simplicity and power of its functional programming forebears (ML, Ocaml) with the object-oriented capabilities of the .NET framework, F# provides the much sought-after combination of type safety, performance and scripting. According to many developers, it is the most original new face in computer languages since Bjarne Stroustrup developed C++ in the early 1980’s.

Starting with Microsoft in 1998, Don also created Generics in C# and in the .NET Common Language Runtime. He has been a functional programmer since 1989. Before this he was a PhD at the University of Cambridge, and before that grew up in a small country town in Australia.

RM:
I’m sure it’s a question everyone asks but how did the name F# come about?
DS:
In the F# team we say ‘F is for Fun.’ Programming with F# really does make many routine programming tasks simpler and more enjoyable, and our users have consistently reported that they’ve found using the language enjoyable.
RM:
Were there any particular problems did you have to overcome in the development of the language?
DS:
Combining object-oriented and functional programming poses several challenges, from surface syntax to type inference to design techniques. I’m very proud of how we’ve addressed these problems.

F# also has a feature called ‘computation expressions,’ and we’re particularly happy with the unity we’ve achieved here.

RM:
Good developers will always say that they would have done things differently in developing a language. Is there anything you would have modified?
DS:
In a sense, we’re tackling this now. Some experimental features have been removed as we’re bringing F# up to product quality, and we’ve also made important cleanups to the language and library.
RM:
F# is heavily rooted in OCaml but what elements have you borrowed from other languages?
DS:
The aim of F# from the start has been to ensure that typed functional programming in spirit of OCaml finds a high-quality expression on the .NET framework. These languages excel in tasks such as data transformations and parallel programming as well as general purpose programming.

As it developed, F# borrowed more ideas from other languages: Haskell was influential in many ways, from basic syntax elements such as the ‘light’ syntax, to rich constructs such as sequence expressions and computation expressions, which are ways of generating and composing data structures.  Python was also influential, and of course C# has had a huge impact on F#, since F# includes an object model that is closely aligned to that of C#.

RM:
Did it help that Simon Peyton Jones, one of the key designers of Haskell is just down the corridor from you at Microsoft Research at Cambridge?
DS:
A lot! Simon PJ has been a great help with F#, so I have a lot to thank him for. He gave a lot of feedback on the feature called “asynchronous workflows” in particular, and also on “active patterns”, a form of user-specified pattern matching for F#.
RM:
Has the .NET framework played an important role in bringing the programming camps together?
DS:
Overall the last 5 years has seen a lot of idea sharing in the language community, at conferences such as Lang.NET.   The common vision of ‘many languages, many niches, high level interoperability’ has driven a wave of language research and excitement. Furthermore, .NET has brought language researchers more directly in touch with the “real world” of applied programming, and allowed us to conduct experiments where more variables are controlled – e.g. we can test out new ways of expressing solutions to existing problems without changing the underlying libraries or runtime machinery.
RM:
What attracted you to functional languages in the first place?
DS:
I’ve worked with many languages, from BASIC to assembly code. One of the last checkins I made when implementing generics for .NET, C# and VB had a lot of x86 assembly code. My first job was in Prolog. I think programmers should learn languages at all extremes.

Functional languages attract me because of their simplicity even when solving complex tasks. If you look through the code samples in a book such as F# for Scientists they are breathtaking in their elegance, given what they achieve. A good functional program is like a beautiful poem: you see the pieces of a ‘solution’ come together.

Of course, not all programs end up so beautiful. It’s very important that we tackle “programming in the large as well”. That’s what the object-oriented features of F# are for.

RM:
 Do you think it’s good practice for all programmers to learn languages at all extremes?
DS:
Yes, I do. I think all programmers have a curiosity about different languages, and should be familiar with the basic alternative computational models: functional, procedural, relational.  However it’s inevitable that programmers will concentrate on the tools they need for their immediate work, so what’s more important is an open mind and a willingness and excitement to see problems in a different way when necessary.
RM:
Why did Microsoft decide to develop F# and how does it fit into Microsoft’s overall strategy and philosophy?
DS:
Microsoft’s decision to invest in further F# is very much based on the fact that F# adds huge value to the .NET platform. F# really enables the .NET platform to reach out to some new classes of developers, and appeal to some domains where .NET is not heavily used.  This is especially true in data exploration and technical computing. We’re also exploiting functional techniques in parallel programming.
RM:
What is the best program you’ve seen written in F#?
DS:
That’s a good question! I’ll give several answers. I’ve mentioned the samples from F# for Scientists, which are very compelling. For sheer F# elegance, I like Dustin Campbell’s series of Project Euler solutions. For commercial impact then the uses of F# in the finance industry have been very convincing, but probably nothing beats the uses of F# to implement statistical machine learning algorithms as part of the Bing advertisement delivery machinery.

I’m intrigued by the potential to use F# to script data-oriented tools such as AutoCAD and ArcGIS. These domains are well suited to functional programming, and F# can interoperate with these tools very nicely. You can now use F# with the .NET APIs for these tools, which opens up many possibilities.

We’ve recently really focused on ensuring that programming in F# is simple and intuitive. For example, I greatly enjoyed working with a high-school student, who learned F#. After a few days she was accurately modifying a solar system simulator, despite the fact she’d never programmed before. You really learn a lot by watching a student at that stage.

RM:
Why would a programmer choose to write apps in F# rather than C#? Do you think F# will take over the industry in much the same way as c++ has? Do you think there’s a danger of F# becoming too ‘expert friendly’ in the same way that C++ has?
DS:
Concurrency is increasingly important for many applications, and the shift to many core brings abundant parallelism to the desktop. The web, Silverlight and distributed systems increase the demand for asynchronous solutions. F# is a succinct and expressive typed functional programming language for the .NET platform that makes major contributions to productivity in parallel and asynchronous programming, making these both fun and easy.

Regarding C# and VB.NET, well they are clearly the elder statesmen of.NET languages and it’s hard to imagine a really major .NET project where these languages doesn’t play a significant role.

So the approach we take with F# is that it is definitely complementary to C#. We expect there will be many F# projects that incorporate C# components. For example, the designer tools we use with F# emit C# code, and you then call your F# code from those the event handlers. A working knowledge of C# is thus very useful for the F# programmer.

F# is a really simple language to use, especially if you’re just implementing some data manipulation using an existing set of libraries. Some people see it as a sort of strongly-typed Python, up to syntactic differences.

RM:
How do you think more programmers can write quality code (as opposed to quantity) and still keep their jobs?
DS:
Many programmers choose to explore a problem in F# because it lets them focus more on the problem domain and less on programming itself. That’s a big benefit in some of the data exploration, algorithmic and technical computing domains, and so we’ve seen a lot of interest in using F# here, where C# may not have been an obvious choice.

So to me the question is not just about quality code, but about code that solves appropriate domain tasks and problems. For example quality algorithms, quality visualizations and quality data analysis.

RM:
How do you see the future for procedural programming languages?
DS:
People thirst for simplicity.  People need simple solutions to the problems that really matter: data access, code development, deployment, cloud computing, web programming, parallel programming to name but a few. One of the exciting things about working in the Visual Studio team is that there are world experts in all of these domains working in unison. We won’t cover all of these bases with the first release of F#, but over time we’ll be operating in all these domains.

At the language level, people say that languages are converging in the direction of mixed functional/OO programming. However I expect many important developments from this base. For example, we’re seeing language oriented towards “big, powerful data structures” such as tables and OLAP-like data cubes, perhaps with support for transactions. Merging these techniques into general purpose languages should bring great dividends.

RM:
Have you received much feedback of the language so far? If so, what has this been focused on?

DS:
We’ve received lots of feedback – we’ve been in almost continual engagement with the F# community for the last three years. This has been extraordinary. People have been very helpful, and have come up with many great ideas and suggestions. However, we’re just as glad to get the “this is broken” emails as we are glowing praise – indeed even more glad – we want to know when things don’t add up, or don’t make sense.

Some programmers do have a hard time adjusting their mindset from imperative programming to OO, though most find the transition enjoyable. Learning new paradigms can sometimes be easier for beginners than experienced programmers. However, one of the great things about F# is that you can “change one variable at a time,” e.g. continue to use your OO design patterns, but use functional programming to implement portions of your code.

Keep up to date with Simple-Talk

For more articles like this delivered fortnightly, sign up to the Simple-Talk newsletter

This post has been viewed 38490 times – thanks for reading.

  • Rate
    [Total: 83    Average: 4.6/5]
  • Share

Richard Morris

View all articles by Richard Morris

Related articles

Also in .NET

Posting Form Content via JavaScript

Web-based applications run smoother if instead of using the traditional form method, they use JavaScript to post data to the server and to update the user interface after posting data: It also makes it easier to keep POST and GET actions separated. SignalR makes it even slicker; it can even update multiple pages at the same time. Is it time to use JavaScript to post data rather than posting via the browser the traditional way?… Read more

Also in BI

Relational Algebra and its implications for NoSQL databases

With the rise of NoSQL databases that are exploiting aspects of SQL for querying, and are embracing full transactionality, is there a danger of the data-document model's hierarchical nature causing a fundamental conflict with relational theory? We asked our relational expert, Hugh Bin-Haad to expound a difficult area for database theorists.… Read more

Also in Geek of the Week

Clive Sinclair: Geek of the Week

Although most of the geeks of the IT industry are famous for their software, it was the geeky entrepreneurs that changed society by bringing cheap microcomputers to the market. Sir Clive Sinclair is most famous for applying his background in electronic engineering to provide a whole generation, both in America and Europe, with their first taste of programming.… Read more

Also in Opinion

The 2015/2016 Simple-Talk Awards

Once more it is time for our readers to vote on the top nominations for the Simple Talk Awards. Here we list the top nominations and the dazzling award badges. Every vote makes our awards more valuable for the recipients!… Read more
  • Anonymous

    Thanks
    hi thanks a lot guys for your inspiring and more informative interview regarding F#. though ave not put my hands on it i can tell its a good programing language and am sure i will learning it in the future since .net is taking over. Thanks again.

  • Mike Gale

    Smart subject choice
    I am pleased to see this choice of subject.

    F# is a smart thing to be talking about and you do a great job of it. It’s refreshing to see both smart interviewer and interviewee. Thanks.

Join Simple Talk

Join over 200,000 Microsoft professionals, and get full, free access to technical articles, our twice-monthly Simple Talk newsletter, and free SQL tools.

Sign up

See what's happening behind the scenes

Take a peek at the bowels of the ship – the lower decks – the actual servers of SQL Server Central itself.

See what's happening