Phillip Trelford's Array

POKE 36879,255

The only 3 apps you’ll ever write…

At last week’s F# eXchange Robert Pickering gave a talk on Expression Oriented Programming with F#, with one of the slides condensing the only apps you’ll ever write down to 3:

OnlyThreeApps

In the same week fsharpWorks conducted an F# Survey, the results of which are well worth a look.

One of the questions was ‘What kind of learning material would you like to see more of?’ with a popular answer being ‘More material with short "cookbook" style information’.

So lets take a look at 2 out of 3 of the only apps you’ll ever write :)

Command line

An easy place to get started with F# is to use a popular IDE, for Windows there’s the free Visual Studio 2013 Community edition, and for Mac and Linux there’s Xamarin Studio and MonoDevelop.

To create a new console app in Visual Studio hit File –> New Project and select the F# Console Application project:

image

For the ubiquitous hello world app write:

printfn "Hello World"

Then run with Debug –> Start without Debugging (Ctrl+F5), which runs the app and waits for you to press a key.

To make things a little more exciting we could display all the files in the working directory:

let files = System.IO.Directory.GetFiles(".")
for file in files do printfn "%s" file

GUI App

An easy option in F# for creating a GUI app is to use the Windows Forms library.

To do this simply add a reference to you’re existing console application. In Visual Studio right click the project’s references folder and select the System.Windows.Forms.dll reference.

Then right click the project and select Properties to change the application type to a Windows Application:

image

Now insert the following code to display a form:

open System.Windows.Forms

[<System.STAThread>]
do let form = new Form()
   Application.Run(form)

You should see an empty window on the screen.

Let’s make things a little more interesting with a grid with some data, carrying on the file information theme:

open System.IO
open System.Windows.Forms

[<System.STAThread>]
do let form = new Form()
   let grid = new DataGridView()
   grid.Dock <- DockStyle.Fill   
   form.Controls.Add(grid)
   form.Load.Add(fun _ ->
      let files = Directory.GetFiles(".")
      grid.DataSource <- [|for file in files -> FileInfo(file)|]   
   )
   Application.Run(form)

When you run it you should see something like this:

image

That’s all folks! Just a few lines of code and we’ve got a grid up.

Summary

Hopefully you can see in this F# introduction creating a console app or GUI app is a relatively simple task.

If you’d like the complete set, then check out Tomas Petricek’s tutorial on MSDN: Creating Windows Services in F# or Mike Hadlow’s recent self-hosted web service sample: A Simple noWin F# example.

F# Exchange 2015

This Friday saw the first ever F# eXchange, a one-day 2 track conference dedicated to all things F#, hosted at Skills Matter in London and attracting developers from across Europe.

There was a strong focus on open source projects throughout the day including MBrace (data scripting for the cloud), Fake (a DSL for build tasks), Paket (a dependency manager for .Net), the F# Power Tools and FunScript (an F# to JS compiler). In fact all the presenters used the open source project FsReveal to generate their slides!

Keynote

Tomas Petricek opened proceedings with a keynote on The Big F# and Open Source Love Story:

Slow development

One of Tomas’s observations, on slow development for open source projects resonated with many, where successful projects often start as just a simple script that fulfils a specific need and slowly gather momentum over time.

As an example, in Steffen Forkmann’s presentation he talked about how Fake had started as a simple F# script and over the years seen more and more contributors and downloads, with the addition of high quality documentation having a huge impact:

Talks

All the talks were recorded, and all the videos are already online!

Speakers

The videos:

Steffen also took advantage of his talk to make a special announcement about Paket:


Panel

The day ended with some pizza, drinks and a panel organized by prolific F# contributor, Don Syme:

Panel Discussion

Each panel member pitched why they thought F# was good in their core domain area from cloud, games, design, data science, scripting through to web.

There were some interesting discussions, and some mentions of the recent fsharpWorks led F# Survey.

2016

The date for next year’s F# eXchange 2016, the 16th April, is already in the calendar, hope to see you there, and please take advantage of the early bird ticket offer, only 85GBP up until the 16th June!

String and StringBuilder revisited

I came across a topical .Net article by Dave M Bush published towards the tail end of 2014 entitled String and StringBuilder where he correctly asserts that .Net’s built-in string type are reference types and immutable. All good so far.

The next assertion is that StringBuilder will be faster than simple string concatenation when adding more than 3 strings together, which is probably a pretty good guess, but lets put it to the test with 4 strings.

The test can be performed easily using F# interactive (built-in to Visual Studio) with the #time directive:

open System.Text

#time

let a = "abc"
let b = "efg"
let c = "hij"
let d = "klm"

for i = 1 to 1000000 do
   let e = StringBuilder(a)
   let f = e.Append(b).Append(c).Append(d).ToString() 
   ()
// Real: 00:00:00.317, CPU: 00:00:00.343, GC gen0: 101, gen1: 0, gen2: 0
   
for i = 1 to 1000000 do
   let e = System.String.Concat(a,b,c,d)
   ()
// Real: 00:00:00.148, CPU: 00:00:00.156, GC gen0: 36, gen1: 0, gen2: 0

What we actually see is that for concatenating 4 strings StringBuilder takes twice as long as using String.Concat (on this run 0.317ms vs 0.148ms) and generates approximately 3 times as much garbage (gen0: 101 vs gen0: 36)!

Underneath the hood the StringBuilder is creating an array to append the strings into. When appending if the current buffer length is exceeded (the default is 16) then a new array must be created. When ToString is called it may, based on a heuristic, decide to return the builder’s array or allocate a new array and copy the value into that. Therefore the performance of StringBuilder is dependent on the initial capacity of the builder and the number and lengths of the strings to append.

In contrast, String.Concat (which the compiler resolves the ‘+’ operator to) calculates the length of the concatenated string from the lengths of the passed in strings, then allocates a string of the required size and copies the values in, ergo, in many scenarios it will require less copying and less allocation.

When concatenating 2, 3 or 4 strings we can take advantage of String.Concat’s optimized overloads, after this the picture changes as an array argument must be passed which requires an additional allocation. However String.Concat may still be faster than StringBuilder in some scenarios where the builder requires multiple reallocations.

But wait there’s more, going back to the ‘+’ operator, if we assign the integer literal expression 1 + 2 + 3 the compiler can reduce the value to 6, equally if we define the strings as const string then the compiler can apply the string concatenations at compile time leading to, in this contrived example, no cost whatsoever.

The moral of the story is when it comes to performance optimization - measure, measure, measure.