Friday, February 19, 2010

F# examples talk at BFG

Earlier this week I gave a short talk at the Brisbane Functional Group on F#. The idea was to give an introductory feel for the language by way of some simple examples. The talk was intended to be short so I assumed knowledge of previously discussed idioms such as tuples and curried type signatures.

I took the examples (with permission :-) from the environmental sensing project I work on at MQUTeR. This post is intended as a reference for those who attended rather than a self-contained introduction to F#.

  1. The uncurry function was first up.
    let uncurry f (x,y) = f x y
    We talked about the syntax of function definition, tuples and type inference in Visual Studio. We inserted the function into F# Interactive (the REPL available in Visual Studio) by highlighting it and pressing ALT-Enter. The F# Interactive transcript went something like:
    val uncurry : ('a -> 'b -> 'c) -> 'a * 'b -> 'c

    > 1 + 2;;
    val it : int = 3

    > uncurry (+) (1,2);;
    val it : int = 3

    > (+) 1 2;;
    val it : int = 3
    This lead to a discussion on operators and infix/prefix notation. The post F# Option orElse getOrElse functions should cover that.

  2. Next was the |> operator, which has type signature 'a -> ('a -> 'b) -> 'b.
    // Haskell catMaybes
    let catOptions xs = Seq.filter Option.isSome xs |> Seq.map Option.get

    let euclidianDist (x1, y1) (x2, y2) = (x1 - x2) ** 2.0 + (y1 - y2) ** 2.0 |> sqrt

    let spt' t a =
    let m = Math.Matrix.ofArray2D a
    allPeaks t m |> removeSmall |> dilate t m |> Math.Matrix.toArray2D

    // type signatures
    // allPeaks : float -> matrix -> matrix
    // removeSmall : matrix -> matrix
    // dilate : float -> matrix -> matrix -> matrix
    // spt' : float -> float [,] -> float [,]
    We briefly compared |> with the Haskell $ function, which has the type signature (a -> b) -> a -> b.

  3. A quick look at type annotations, pattern matching and Haskell like guards. The example is an implementation of the MATLAB smooth function, which calculates a moving average. We didn't dwell on the entire function, just the relevant parts.
    (* 
    yy = smooth(y,span) sets the span of the moving average to span. span must be odd.

    If span = 5 then the first few elements of yy are given by:
    yy(1) = y(1)
    yy(2) = (y(1) + y(2) + y(3))/3
    yy(3) = (y(1) + y(2) + y(3) + y(4) + y(5))/5
    yy(4) = (y(2) + y(3) + y(4) + y(5) + y(6))/5
    ...
    *)
    let smooth s (a:float []) =
    let n = (s - 1) / 2
    let f i _ =
    let (b, l) = match i with
    | _ when i < n -> (0, i*2+1)
    | _ when i + n < a.GetLength(0) -> (i-n, s)
    | _ -> (i-(a.GetLength(0)-1-i), (a.GetLength(0)-1-i)*2+1)
    Array.sum (Array.sub a b l) / (float l) // TODO try Array.average here
    Array.mapi f a

  4. Records are a common kind of data type. The labels are not automatically available as functions like they are in Haskell.
    type 'a Rectangle = {Left:'a; Top:'a; Right:'a; Bottom:'a; Width:'a; Height:'a;}

    let inline cornersToRect l r t b = {Left=l; Top=t; Right=r; Bottom=b; Width=r-l; Height=t-b;}
    let inline lengthsToRect l t w h = {Left=l; Top=t; Right=l+w-1; Bottom=t+h-1; Width=w; Height=h;}
    let fcornersToRect (l:float) r t b = cornersToRect l r t b // for C#
    let left r = r.Left
    let right r = r.Right
    let top r = r.Top
    let bottom r = r.Bottom
    let bottomLeft r = (r.Left, r.Bottom)
    let width r = r.Width
    let height r = r.Height
    let inline area r = r.Width * r.Height
    The F# overload-o-phone covers our discussion on arithmetic operators. The inline keyword is mentioned in the comments.

  5. Finally we looked at available API documentation. I find that I generally skim API documentation by first looking at function type signatures. The F# PowerPack is a useful library developed by the F# team and the format of the documentation supports my approach.

    The F# API documentation was previously in this format. It has now been moved to MSDN and the list of function type signatures is not presented for each module, rendering it almost useless.
Along the way there were a few comments about F# being strictly evaluated and having no effect tracking system, no higher-order parametric polymorphism and no type classes.

Thanks to everyone that participated in the discussion and I hope the talk was interesting.

Friday, February 12, 2010

QOTD

The role of the proof for mathematics is similar to that for orthography or even calligraphy for poetry. A person, who had not mastered the art of the proofs in high school, is as a rule unable to distinguish correct reasoning from that which is misleading. Such people can be easily manipulated by the irresponsible politicians.

-- V.I. Arnold

From: The antiscientifical revolution and mathematics

Thursday, February 4, 2010

Pair Programming again

I saw a local bank advertising a position to promote so called "sustainable software development" practices. These included Pair Programming, TDD, BDD and 100% code coverage.

I have written about Pair Programming before, but it needs re-iterating.

  • The value of pair programming is not constant - it is a function of the problem, people and technologies at hand.

  • If the problem at hand is not new or not complex the value is often significantly reduced.

  • On common information systems / web projects (such as at this company) the problem at hand is often neither new nor complex.

  • Therefore, if there is a project rule stating that all production code is to be paired on, the business value of the project will immediately be sub-optimal.
This is not rocket science. Consider a couple of competent developers pairing on the usual crud/plumbing code that makes up such a large proportion of these kinds of apps. What value is the second person really adding here vs doing something else?

Anecdotally, with skilled developers of reasonable talent and discipline, the pair programming time on these types of projects doesn't need to be above 50%.