Learning F# – Part 1

I decided to take some time out on Silverlight and have a play around with Microsoft’s new language F#, I’ll be making notes as I go along and post them here so maybe they’d help satisfy some of your curiosity too!

Disclaimer: I do not claim credit for the code examples and much of the contents here, these are mostly extracts from the book by Chris Smith, Programming F#: A comprehensive guide for writing simple code to solve complex problems. In fact, if you’re thinking of learning F# and like what you read here, you should buy the book yourself, it’s easy to read and the author has gone go great lengths to keep things simple and included a lot of code examples for you to try out yourself.

Before you start, you need to download F# from:

http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/release.aspx

and install it for either VS2008 or VS2010 beta.

Hello, World

In VS2008, open a new project and choose F# Application, in Program.fs type in:

printfn “Hello, World”

Hit Ctrl+F5, and voila:

You might notice that your program worked without an explicit Main method.

Here’s a slightly more complex Hello, World to show off the syntax of F#:

image

The let keyword binds a name to a value, unlike most other programming languages, in F#, values are immutable by default (meaning they cannot be changed once initialized).

image

F# is also case-sensitive. The name of a variable can contain letters, numbers, underscore, or apostrophe (‘) and must begin with a letter or an underscore. However, you can enclose the value’s name with a pair of tickmarks in which case the name can contain any character except for tabs and newline:

let “this.Isn’t %A% good value Name$!#“ = DateTime.Now.ToString(“hh:mm tt”)

printfn “%s, %s at %s” greeting thing “this.Isn’t %A% good value Name$!#“

Other languages like C# use semicolons and curly braces to indicate when statements and blocks of code are complete, but it clutters the code.

In F#, whitespace (spaces and newlines) is significant. The F# compiler allows you to use whitespace to delimit code blocks. For example, anything indented more than the if keyword is considered to be in the body of the if statement. Because tab characters can indicate an unknown number of space characters, they are prohibited in F# code. You can configure the Visual Studio editor to automatically convert tab characters into spaces in Tools -> Options -> Text Editor -> F#.

The earlier code also demonstrated how F# can interoperate with existing .Net libraries:

let timeOfDay = DateTime.Now.ToString(“hh:mm tt”)

F# can take advantage of any .Net library by calling directly into it, conversely any code written in F# can be consumed by other .Net languages.

Comments

Like any language, F# allows you to comment your code. To declare a single line comment, use two slashes (//).

For larger comments that span multiple lines, you can use the multiline comments using (* and *) characters.

For F# applications written in Visual Studio, there is a third type of comments: an XML documentation comment. If a comment starting with three slashes (///) is placed above an identifier, Visual Studio will display the comment’s text when you hover over it:

 


F# Interactive

Visual Studio comes with a tool called F# Interactive or FSI. F# Interactive is a tool known as a REPL (read-evaluate-print loop), it accepts F# code, compiles and executes it, then prints the results. This allows you to quickly and easily experiment with F# code similar to how snippet editor allows you to do the same with C# code.

Once it’s open, it accepts F# code until you terminate the input with ;; and a newline, the code entered will be compiled and executed. After each code snippet is sent to FSI, for every name introduced you will see val <name> : type value, for example:

Notice when you don’t give a variable a name, FSI will simply call it ‘it‘.

FSI allows you to write code in Visual Studio editor which offers syntax highlighting and IntelliSense, but test your code in the FSI window. You can copy the entire code body from the example earlier and test the main method in FSI by calling it:

Managing F# Source Files

The F# language has some unique characteristics when it comes to managing projects with multiple source files. In F#, the order in which code files are compiled is significant.

You can only call into functions and classes defined earlier in the code file or in a separate code file compiled before the file where the function or class is used. If you rearrange the order of the source files, your program may no longer build!

The reason for this significance in compilation order is type inference, a topic to be covered later on.

F# source files are compiled in the order they are displayed in Visual Studio’s Solution Explorer, from top to bottom. You can rearrange the files by right-clicking and selecting Move Up or Move Down. The equivalent keyboard shortcuts are Alt+Up and Alt+Down, though these don’t seem to be working in VS2008 with Resharper, or maybe I just need to tweak my key mapping.

Buzzword Buster – AOP

Definition:

Aspect Oriented Programming (AOP) is a programming paradigm where each application can focus on its primary functions and core concerns by encouraging greater modularity and increasing separation of cross-cutting concerns (such as logging and authentication).

Purpose:

In any real-world applications, when you’re writing code to address the problem domain (say, booking an order) you might need to address other concerns such as:

  • persistence – writing to the database for example
  • transaction handling – defining transaction scope and setting rollback strategy, etc.
  • security – user authentication for example
  • logging – for auditing and debugging

So effectively you’re mixing multiple domains with fine-grained intersections and likely to end up with:

  • tangled code – making it more difficult to work out what the code is doing to address the core concern
  • boilerplate code at every intersection point – introducing duplicated code and increasing the size of the code base and the blast radius of any change that are not related to the problem domain, e.g. changing the persistence media..

AOP aims to address these problems by separating cross-cutting concerns into single units called aspects, each aspect encapsulates behaviours that affect multiple classes into reusable modules.

Parting thoughts..

As far as I can think of, the only drawback of AOP is that you no longer see all the behaviours of your class when you open it and it requires knowledge of the whole system to know what else are happening under the cover. Which interestingly, is the flip side of the same coin because you employ AOP when you don’t want to deal with cross-cutting concerns all the time!

One of the ways to mitigate this problem is to build up a culture in your team and standardise how AOP is implemented so that everyone is on the same page and there are few surprises.

Frameworks:

PostSharp provides a lightweight AOP framework for the .Net platform and is establishing itself as the de facto standard much like the way AspectJ has done for Java.

Adoption problems with WPF

I was having an email conversation with a friend on WPF yesterday and he suggested putting it into a blog post after I went on and on for a bit (sorry Raj!).

Having spent some time learning Silverlight (which is a subset of WPF for the web, Microsoft’s equivalent of Flash) I have really come to like the new programming model in WPF and how easily it allows you to do things that were simply impossible to do in WinForms (ever tried to put a rounded corner to a rectangle anyone?).

To those not familiar with WPF, it’s powered by DirectX so you get hardware acceleration and can use features such as transparency, gradients and transformations. Its programming model enables clear separation of the UI from business logics because you now have to build your UI using a declarative language – XAML (Extensible Application Markup Language).

The event model has also been revamped and it’s now possible to ‘route’ an event so it originates from one element but is raised by another. WPF supports several types of routed events, but Silverlight only allows bubbled events which cascades up the containment hierarchy from deeply nested element to its containers.

Why is Declarative UI better?

Whilst declarative UI is something of a shock to the system to most of us (web developers not included!) it actually makes perfect sense because it helps solve one of the biggest problems in UI development – business logic embedded in UI.

A declarative UI makes it harder to write business logic into the UI because you’re writing less code. However, it’s not about separation of tiers, but separation of concerns, so when you find problems there is a smaller blast radius! Which again, all comes down to loose coupling – the same thing people are trying to achieve with IoC and Dependency Inversion from a dependency point of view.

So all’s well with WPF and industry veterans are all raving about it (there’s a number of shows on DotNetRocks alone which covers WPF and Declarative UI) so why is there still a distinct lack of real-world apps out there? Besides the odd project on CodePlex like Family Show and Scott Hanselman’s BabySmash, I haven’t found too many examples out there (it’s a shame Photology‘s dead.. :-( )

Problems:

I think there are two main reasons why a lot of people are still not adopting WPF, neither has anything to do with the technology itself which is like a fancy new drug which makes you never want to go back! And there are plenty of industry support both in terms of third party support (well known UI controls producers like teleriks, infragistics already offer numerous UI packages for WPF and Silverlight) and backing from the industry veterans.

1. it’s still fairly young

Having only made it into the core .Net platform since .Net 3.0 (nov 2006) it is still fairly new to most developers considering that most people are still happy using .Net 2.0 (I know this is definitely true in the banking/enterprise world!) which equates to:

  • a lack of existing expertise in the field, making it hard for would-be adopters because it adds to the cost of adoption in time and expense regardless of their strategy to acquire these expertise, i.e. new recruit vs. training existing staffs
  • an additional risk with adopting WPF because you have to first migrate your platform to .Net 3.0, which, should be minimal because it’s really just an add-on to the .Net 2.0 framework. But then again, “why fix what’s not broken?”

2. it’s only a viable option for new developments

Because WPF introduces a completely new set of technologies and a new programming model to boot, it’ll require significant time and effort to convert an existing UI application. This means WPF is only worth considering for new developments.

The future:

As with all things Microsoft, there’s a strong focus on enterprise users and I’m sure their representatives would continue to make a push for their partners to adopt WPF and dare I say once they decide to jump on board MS would have a problem stopping them from coming back for more! Yup, WPF is that good!

With the .Net platform going strong as ever (mentioned in 44% of developer jobs posted in the UK in the last 6 months), the universal adoption of WPF as the de facto standard for developing UI application should only be a matter of time. Given the risk-adverse nature of large enterprises (who, given their size and financial muscles, have more say on technology trends than anyone else), it’s no surprise to me that WPF has not really caught on, but as more and more enterprises jump on the WPF bandwagon they’ll in turn increase the size of the talent pool available to others and really set the ball rolling.

Further reading:

WindowsClient.Net

Prism: patterns & practices Composite Application Guidance for WPF and Silverlight site

Imperative vs. Declarative Languages

Following my previous post on multi-language (polyglot) and multi-paradigm (poly-paradigm) development, I thought I’d continue on the same thread for a little and do some comparisons on some of the popular types of programming languages.

Definition:

An imperative programming language such as C# or Java allows you to specify step-by-step how a problem should be solved using a series of statements which change a program’s state. It’s important to remember that whilst Object Oriented Programming is how we are all taught to do imperative programming these days, it’s not the only way – C and other procedural languages are also imperative languages.

A declarative programming language on the other hand, is a higher level programming language which allows you to express what you want without specifying how to get it. SQL is probably the most widely used declarative language today and in SQL you don’t tell the query analyzer how to go about fetching the data, you just state what data you want to retrieve and it takes care of the rest. It’s also worth nothing that

How they compare:

The benefit of declarative language is that it separates the process of stating a problem from the process of solving it. It’s essentially an extension of design by contract where producers of the declarative input describe what they need and how they need it, allowing producers of the declarative program to determine the best way to get it.

Approximating this in an imperative language is possible because at heart, everything is imperative. The challenge in doing so is that an imperative program operating on declarative input must be prepared to check pre and post conditions and have a plan to deal with every eventuality!

Declarative languages allows for greater extensibility, agility and productivity. Think how quickly you can create a table, input some data and then get the data back in some form or another in SQL and then imagine the time and effort it’d require if you were to implement these in C#.

However, as a user of a declarative language, you have limited or no control over how your inputs are dealt with and therefore have no option but to mitigate the impact of any imperfections/bugs in the underlying language and rely on the providers of the declarative language to address the issues.

Less is MORE

Just finished watching an interesting seminar video by the guys from Object Mentor (a consultant company founded by Robert C Martin, the father of agile development) at:

http://www.infoq.com/presentations/polyglot-polyparadigm-programming

The video is about an hour long and covered a large number of topics around using different languages (polyglot) and different programming paradigms (poly-paradigm) to simplify and speed up the software development process. The main thing I took away from this was:

“Less code is better, so less code is more. With less code, all your problems become smaller, be it maintenance, testing or performance.”

which most developers would agree I’m sure, after all, one of the reasons we refractor our code is so we end up with less code.

For young developers like myself, we have come into software development in an era dominated by the object oriented paradigm and a small handful of mainstream OO languages like C++, C# and Java. So for me at least, it’s refreshing to see how other paradigms and languages can be used in conjunction with those I’m familiar with to achieve:

  • greater productivity from the developers
  • more agile and extensible solution

Summary:

If you don’t have the time to watch the video (or simply not interested enough to do so!) then hopefully the list of key points I’ve compiled together would at least give you some idea what it’s all about:

  • There’s no silver bullet in software development
  • OO paradigm not always the best solution for the problem
  • Statically-typed languages (C#, C++, Java, etc.) are compiled for greater speed and efficiency at the cost of lowering productivity
  • Dynamically-typed language (ruby, python, JavaScript, etc.) are interpreted for greater extensibility, agility and productivity at the cost of lowering runtime performance
  • Ola Bini‘s Three layers – Domain layer (Domain Specific Languages), Dynamic layer (JRuby, etc.) and Stable layer (Java, C#, etc.)
  • Scripting languages increases pace of development
  • Aspect-oriented programming makes it easier to deal with cross-cutting concerns
  • Functional programming makes concurrency easier, because:
    • functions are side-effect free and stateless
    • nothing to synchronize, so no locks, semaphores, mutexes
  • Functional programming is cloud computing friendly
  • Functional languages and DSLs are more declarative than imperative
  • Scala is cool!
  • Advantages of the polyglot and poly-paradigm approach are:
    • able to use the best tool for a particular job
    • minimize the amount of code required and keep them closer to the domain
    • better decoupling between components
  • Disadvantages of this approach are:
    • multiple tools, languages, libraries to manage and learn
    • need to manage the different metadata models and overhead of calls between languages
  • It’s nothing new! For example, web developers often have to work in different paradigms and languages on a website
  • Higher end-user expectations and tighter schedules are driving the popularity of higher level languages such as functional and scripting languages
  • Developers have to deal context switching between different languages, so as the application grows larger and more complex, you have to start partitioning the teams (should be second nature to those working in the enterprise world!)

Parting thoughts..

As the presenter stated several times throughout, polyglot and poly-paradigm programming (PPP) has all been done before (despite now being mentioned with unfamiliar terminologies), and I certainly see a lot of familiarity of it in my line of work where in a typical 3-tiered application you’d have:

  • the data access layer using SQL (relational paradigm)
  • the business layer written in C#/Java or other OO languages
  • the UI can be in any number of different languages or paradigms depending on its form (HTML/CSS/Java/C#, etc.)

and numerous scripting languages (Perl, for example) are also used in various places (hell, after all, there are over 5000 applications being actively used within Credit Suisse alone!).

Watching this video has helped me identify with what I already know and put names (polyglot, poly-paradigm) to familiar faces (which is why jargon are important and I keep blogging about buzzwords :-P ), watch it, and see if it can help you too.

Further readings:

Ola Bini’s blog post on writing different layers of code in different languages