cbrad

Do not have the mind set that the day you release version 1.0 is the finish line, it’s the starting line, so hurry up and get there.

-- Sam Howley

From: Lessons learned from 13 failed software products via @ericries

In 2008 I commenced a coursework Masters in mathematics at the University of Queensland. I have downgraded this to a Graduate Diploma and should officially graduate in a few weeks.

My original goal for commencing postgraduate study was to improve my knowledge in programming languages and make the current research more accessible. Unfortunately the local universities teach very little (relevant) theoretical computing science, so I enrolled in mathematics with a focus on discrete mathematics, logic and abstract algebra. After the first year I discovered that there is no real future in programming language research here in Brisbane. I had achieved my goal in the context of the courses available and so switched my study to statistics as data analytics is both interesting and hopefully more viable locally.

To complete the Masters I need to do the equivalent of four courses in research. As I am enrolled in a coursework masters, I pay 2-3 times the standard undergraduate fees. The last course cost 2010ドル. Therefore there is approximately 8000ドル in fees remaining.

I would enjoy the remaining Masters research component if could find the right supervisor and topic. However employment as a researcher now generally requires a PhD, not a Masters and while a PhD is longer, it also has no fees. So if the circumstances were right to do the Masters research it makes more sense to consider a PhD anyway.

The value proposition for completing the Masters is too low. I have fulfilled the requirements for a Graduate Diploma and so will finish with that.

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.

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%.

Most software projects produce a mess and are a mess to manage. Projects that make it to production generally go on to a have a lifetime measured in years. While they are alive new projects are started, accumulating more mess. If the internal IT budget/group increases there is capacity to create an even bigger mess.

An obvious way to reduce the total mess, is for each project to be less messy. Unfortunately, there is little hope to do this at present due to the inherent nature of (current) organisations and the immaturity of software development in general. Another way is to do less software projects and make those smaller.

The business orientated technical managers I know seem to understand this at some level and are dealing with it by purchasing more off-the-shelf or outsourcing. This makes some of the costs of the mess more visible and attributable to (hopeful) benefits. However, it doesn't really address how poor we are at actually figuring out requirements, transforming them into usable, executable software and adapting to new requirements over time. With outsourcing, the mess is now less visible, but as a business relies on the systems and data, it will still experience similar effects from the mess over time.

From a purely technical perspective, does the world really need another bloated Java, Spring, Hibernate, Oracle, JUnit (削除) abomination (削除ここまで) application? Feel free to substitute other languages and libraries, such as Ruby and Rails, Groovy, etc.

Reduce the software mess. Do less software projects. Just say no!

I am using xUnit.net at work on an F# project. I wanted to incorporate FsCheck and check properties via xUnit.net, but there is no built-in integration. I tried this from Matthew Podwysocki, but it is out of date with respect to the versions I am using (xUnit.net 1.5, FsCheck 0.6.1).

EDIT 28/09/2009: Here is the new and improved version based on Kurt's comment.

module FsCheckXunit

open FsCheck
open FsCheck.Runner 
open Xunit 
 
let xUnitRunner = 
 { new IRunner with 
 member x.OnArguments(_,_,_) = () 
 member x.OnShrink(_,_) = ()
 member x.OnFinished(name, result) = 
 match result with 
 | True data -> Assert.True(true)
 | _ -> Assert.True(false, testFinishedToString name result) 
 } 
 
let config = {quick with Runner = xUnitRunner}

Below is the first version I adapted from Matthew's post and the FsCheck source code.

module FsCheckXunit

open FsCheck
open FsCheck.Runner 
open Xunit 
 
let xUnitRunner = 
 { new IRunner with 
 member x.OnArguments(_,_,_) = () 
 member x.OnShrink(_,_) = ()
 member x.OnFinished(name, result) = 
 match result with 
 | True data ->
 Assert.True(true) 
 data.Stamps |> Seq.iter (fun x -> printfn "%d - %A" (fst x) (snd x)) 
 | False (data,_,args,Exception e,_) ->
 Assert.True(false, sprintf "%s - Falsifiable after %i tests (%i shrinks): %A with exception %O"
 name data.NumberOfTests data.NumberOfShrinks args e) 
 | False (data,_,args,Timeout i,_) ->
 Assert.True(false, sprintf "%s - Timeout of %i milliseconds exceeded after %i tests (%i shrinks): %A"
 name i data.NumberOfTests data.NumberOfShrinks args) 
 | False (data,_,args,_,_) ->
 Assert.True(false, sprintf "%s - Falsifiable after %i tests (%i shrinks): %A"
 name data.NumberOfTests data.NumberOfShrinks args) 
 | Exhausted data -> Assert.True(false, sprintf "Exhausted after %d tests" (data.NumberOfTests) ) 
 }
 
let config = {quick with Runner = xUnitRunner}

Many people are trying to influence those in their field. In Confessions Of A Used Programming Language Salesman (Getting The Masses Hooked On Haskell) Erik Meijer talks about his journey and how he achieved massive influence on mainstream programming.

For many years I had been fruitlessly trying to sell functional programming and Haskell to solve real world problems such as scripting and data-intensive three-tier distributed web applications. The lack of widespread adoption of Haskell is a real pity. Functional programming concepts are key to curing many of the headaches that plague the majority of programmers, who today are forced to use imperative languages. If the mountain won’t come to Mohammed, Mohammed must go to the mountain, and so I left academia to join industry. Instead of trying to convince imperative programmers to forget everything they already know and learn something completely new, I decided to infuse existing imperative object-oriented programming languages with functional programming features. As a result, functional programming has finally reached the masses, except that it is called Visual Basic 9 instead of Haskell 98.

Infiltration is the key! Obviously Erik is a very smart guy who has put in the hard yards and knows his stuff. However to achieve major impact required joining an influential organisation and working on the inside, rather than an external activist or confrontational approach.

The whole paper is worth reading, although a large portion is naturally Microsoft orientated on .NET language/CLR features. Below are just a few interesting quotes.

From section 5.2 Standard Query Operators

It is quite surprising that Haskell is one of the very few languages that allows higher-kinded type variables. If, on the term level, parametrizing over functions is useful, doing the same on the level of types sounds like an obvious thing to do. As far as we know Scala is the only other language besides Haskell that also support higher-kinded types.

From section 6.2.3 Contracts

The static type systems of most contemporary programming languages are actually not that expressive at all. They only allow developers to specify the most superficial aspects of the contract between caller and callee of their code.
...
From a program-specification point of view, most programs are extremely dynamically typed!

It is a real shame Erik decided to join Microsoft rather than Sun or IBM. Although I guess he probably wouldn't have had the same level of influence on the JVM and associated languages.

I unsuccessfully tried to post a comment on Static Typing and Functional Languages.

First thing to note, is that Functional Java ‘looks’ so ugly, because Java is not naturally suited to expressing these abstractions.

Secondly, type inference appeared in the 1970s, well before Java existed.

Thirdly, the assumption that functional programming implies static typing is difficult. Type system research has been largely motivated by a number of factors over the years, including compiler optimisations for program performance and theorem proving.

‘CL is great and Blub is crap’ has not worked as a strategy for selling Common Lisp. People invest years of their life learning Blub and don’t want to hear this message. A strategy of infiltation is better.

-- Mark Tarver

From The Next Lisp: Back to the Future.

[フレーム]

Last night I spoke at the Brisbane Functional Programming Group. Tried to scribble on the whiteboard a bit to avoid "death by slides". The objective was to help imperative programmers new to FP become familiar with some of the core concepts, so I tried to go at a slow pace. I think it went for about 1 hour 20 minutes.

The first part of the talk covered history and the landscape of popular functional languages. The rest was on functions, partial function application, algebraic data types, pattern matching and tuples. I used Haskell syntax, but the concepts are transferable to other languages such as Scala and F#.

Just a quick comparison of F# Option orElse getOrElse functions in Scala. Given orElse and getOrElse are already defined in Scala, the equivalent code is:

def f(s:List[(Int, Int)]) = {
 def tf(g:Int => Boolean) = s.find {case (_,x) => g(x)}
 tf(_ < 0) orElse tf(_ == 0) map(_._1) getOrElse 10
}

The argument to orElse is defined as lazy in the function declaration via : => Option[B] rather than :Option[B]. However in the F# version, the actual argument type is changed from 'a option to 'a option Lazy.

Consider the following function that takes a Sequence of (pairs) int * int.

let f s =
 let o = Seq.tryFind (fun (_, x) -> x < 0) s
 if Option.isSome o then
 Option.get o |> fst 
 else
 let p = Seq.tryFind (fun (_, x) -> x = 0) s
 if Option.isSome p then Option.get p |> fst
 else 10

Essentially I am looking for the first pair in the sequence where the second element in the pair satisfies a particular condition and then returning the corresponding first element or a default (i.e. 10) if no satisfactory pair was found.

That code is pretty ordinary. First of all, I would like to improve on the two calls to Seq.tryFind.

let f s =
 let tf g = Seq.tryFind (fun (_,x) -> g x) s
 let o = tf (fun x -> x < 0)
 if Option.isSome o then
 Option.get o |> fst 
 else
 let p = tf ((=) 0)
 if Option.isSome p then Option.get p |> fst
 else 10

Now if the Scala Option orElse and getOrElse functions were available as well as the Haskell backquotes infix syntax then we could really make a difference.

orElse : 'T option -> 'T option -> 'T option
let orElse o p = if Option.isSome o then o else p

getOrElse : 'T option -> 'T -> 'T
let getOrElse o d = match o with | Some x -> x | _ -> d

// N.B. this is not valid F#

let f s =
 let tf g = Seq.tryFind (fun (_,x) -> g x) s
 tf (fun x -> x < 0) `orElse` tf ((=) 0) |> Option.map fst `getOrElse` 10

Neither orElse or getOrElse exist in the F# Option module. However the Core function defaultArg is essentially getOrElse.

Unfortunately F# doesn't have a way to use a (non-operator) function in infix form, like the backquotes in Haskell. However, we can define operators, which are essentially just infix functions.

let (|?) = orElse

let (|?|) = defaultArg

Now we can write a valid F# version.

let f s =
 let tf g = Seq.tryFind (fun (_,x) -> g x) s
 tf (fun x -> x < 0) |? tf ((=) 0) |> Option.map fst |?| 10

Laziness and Composability
Notice that in the original example, the second tryFind is only executed if the first one is unsuccessful because the then expression of an if statement is lazy, i.e. it is only evaluated if the condition is false.

However functions in F# are strict by default i.e. their arguments are evaluated prior to application. Consequently both tryFinds are evaluated, irrespective of their values, as they are arguments to orElse.

So here is an example where laziness is required to achieve reasonable composability. Implementing this gives the final code.

let orElse o (p:'a option Lazy) = if Option.isSome o then o else p.Force()

let (|?) = orElse

let (|?|) = defaultArg

let f s =
 let tf g = Seq.tryFind (fun (_,x) -> g x) s
 tf (fun x -> x < 0) |? lazy (tf ((=) 0)) |> Option.map fst |?| 10

I was one of the founders of Workingmouse and started as the CTO. Over time the other founders moved on, one to property valuation, another to .net development/project management and the last became the CIO of one Australia's largest retail companies. I took over as managing director, but stayed involved in development and project management until the end.

Workingmouse' history can be considered as consisting of three broad periods, that don't necessarily have distinct boundaries, but serve to characterise some important aspects of the organisation at the time.

1. Central Control
Workingmouse was founded by four software professionals in January 2000 and incorporated the following month. The company grew rapidly to about 19 people, servicing one major client. The Tech wreck of 2000/01 greatly impacted us and so we went through the unpleasant task of letting most of the staff go and then living off our own personal savings/credit to be able to pay the few remaining people.

In those early days we operated in a fairly traditional manner for the time - waterfall style process, multi-tiered Java applications with specialists in each particular technical role, e.g. Java programmer, DB programmer, HTML/JavaScript programmer, system administrator. I was probably the only person technically across all roles.

We grappled with the usual issues of such a situation. How do we do fixed price, fixed scope work and

1. make a profit


2. have a happy customer


3. have happy staff


4. actually do a good job technically

I eventually concluded that it was very difficult (if not impossible in our context) to achieve all four.

2. People/Agile
Initially one of the other founders was highly focused on quality customer service, while I was driven to balance factors such as technical quality and work/life balance (as I had small children with a medical condition at the time). This dynamic, anchored by a developing mutual respect for one another drove radical changes in Workingmouse. Many things we did bucked the local trends of the time and I discovered just how dysfunctional the international software industry is.

The key changes that started brewing in 2001 were a shift from primarily procedural coding to OO domain modeling, waterfall to agile and an emphasis on hiring and empowering talented, passionate, innovative developers. While I describe these individually, they were very much intertwined chronologically.

N.B. this is intended to convey a historical perspective and I don't necessarily hold these opinions or discuss issues in these terms now.

I was driven to optimise our development speed by trying to work smarter rather than longer. When I discovered the idea of modeling the client's problem domain in an OO style, it appealed to me for several reasons.

• The prevailing multi-tiered architecture ideas of the time involved transforming essentially the same data structure between the implementations in each tier. This seemed like a gross waste of time and energy when a lightweight object model could act as a common data structure (and behaviour), utilised across the entire application.


• The object model could predominantly contain and enforce the various 'business rules' and 'validation rules', making them easier to locate and reducing duplication across the application.


• Objects could provide a more natural mapping between the code and the client's description of their world, thus making it easier for the developer to do the mental translations between them. The benefits being efficiency and less complexity and therefore hopefully less errors.


• Application errors could be reduced by composing small robust objects that ensure their interface doesn't provide a way to manipulate them into an invalid state.

Early on we did all our work with simple servlets and straight JDBC in the Resin servlet engine. I thought we had better catch up with everyone else and I investigated EJB around version 2.0. It didn't take too long to figure out that O/R mapping was what we needed, but CMP/BMP was terrible. Tried out Castor for a while, but it had issues and moved on to Hibernate.

The only Application Server that was remotely usable in development was JBoss. At the time I just couldn't believe how vendors could sell such rubbish and customers would actually spend tens of thousands of dollars buying it. Not only that, but they would then incur massive programmer costs trying to work with it. Running WebLogic in development was akin to applying a giant handbrake. We stuck with Resin until Tomcat eventually stablised enough to use it in production.

For some time both clients and Workingmouse had been facing the high cost of dealing with content changes in web sites/applications. We decided to solve this and build a Content Management System. This was our first (and only) product and we sold it as a service. While it was good, I believe it suffered from two business problems. Firstly the market wasn't ready and secondly we targeted the wrong segment (SME when we should have chosen enterprise). Consequently a decision was eventually made to retire it and focus our energies on services, which was profitable.

At some point I investigated the Spring framework and we originally adopted it to discard our own proprietary configuration libraries. It was only later on, when we moved to TDD, that we valued it as a Dependency Injection container. Back when we started with it though, heavyweight EJB and an App Server was "Best Practice". As far as I know we were the first doing Hibernate/Spring/POJO development in Brisbane and possibly in Australia.

Extreme Programming (XP) is the first agile methodology I explored deeply. It looked attractive as it attempted to address the issues we were experiencing.

• Clients don't really know what they want and programmers are terrible at estimating. Short cycle, iterative development with feedback attempts to address this.


• Clients change their mind regularly. XP attempts to positively support that rather than fight it.


• The genuine opportunity to do a good job. Traditionally, everyone pays lip service to quality, but when push comes to shove, other drivers usually take precedence.


• Emphasis on sustainability, of which maintaining a healthy work/life balance is important.

Like many groups, we struggled with getting stakeholder involvement and enterprise structures. Some experiences are documented in this presentation. We explored TDD and pair programming and questioned the costs and benefits in relation to the capabilities of our people.

The name 'Agile' is a misnomer though. I think of sustainable business agility, but most developers think of freedom. Freedom from being held to estimates they couldn't realistically make in the first place or freedom to do a quality job (from their perspective) or freedom to work in a more social/group manner. Technical people try to spin business benefits on top of all this, often with a long-term outlook. However, because of their essentially self motivated position, they don't credibly understand the short vs long term business issues. Consequently hiring existing Agile professionals was sometimes challenging and naturally I don't fit into the orthodox Agile community particularly well.

From around 2003 when we started hiring again, we focused critically and selectively on finding the right people. We looked for technical talent, passion for improvement and honesty with the hope that we could provide an environment for such people to thrive. Sometimes we made mistakes and commercial realities did intrude, but other times I like to think we really got things right. In the Mythical Man Month, Fred Brooks writes of the massive difference in abilities between programmers. This is consistent with my observations of many people employed as programmers, both staff and clients. The differences in productivity and quality are surprisingly large.

When Ruby started emerging as a fashion, we like many Java developers that used TDD, wondered whether Ruby + TDD would be better. It was easy to dismiss the claim of 10x productivity gains, but while skeptical we undertook a few Rails projects. One of those projects was quite long running and exposed issues with reasoning about larger Ruby applications. Our interest in functional programming was emerging throughout this time and it easily eclipsed our interest in Ruby.

3. Functional
In 2006 I employed Tony Morris, who had previously worked for IBM on Tivoli and their JDK. Tony is one of the most intelligent people I know and he seriously challenged our ideas about software development. We thought we were critical and open minded but he took that to a whole new level and many passionate debates ensued. After some investigation into functional languages Tony and I began learning Haskell.

For some people this was a difficult time within the organisation. I was busy unlearning much of what I had built up, while those involved in ongoing projects didn't have the time to be involved in such a journey. I have always tried to be honest with staff and clients and so because of my fundamentally changing ideas I could no longer participate as easily in the general technical discussions. This situation brought about uncertainty as to the ongoing direction of the company.

In 2007 I decided that for all Haskell's elegance it was not going to be a viable option for enterprise software development services in Australia. Therefore we conceded on Scala as a compromise. It is far more expressive than Java, but still executes on the JVM and interoperates with existing Java code, making it far more commercially palatable. We completed our first Scala project in late 2007.

2008 saw Workingmouse in a position to confidently offer general Scala development and training services. Several more of our (highly capable) people had undertook learning Haskell and Scala. It was interesting to observe how difficult the transition can really be. It is relatively easy to learn the syntax of a new language, but much more difficult to fundamentally change the core abstractions one thinks and expresses ideas with.

After breaking the shackles of Java it is painful to go back to it. Workingmouse needed to find some Scala projects, but the global economic situation was deteriorating and so the clock was ticking. In general, technical management is very conservative here in Australia (that may deserve a blog post of its own) and so only one more Scala project was forthcoming. This was not sustainable and with financial markets crashing it was time for this services business to call it a day.

I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.

- James Strachan

From Scala as the long term replacement for java/javac?

In his keynote at QCon London 2009, Tony Hoare attempts to characterise science and engineering as two ends of a continuum that describes the roles of software people (industry and academia) and their relationships with one another.

The comments about engineers general dislike of mathematics are consistent with my observations. As someone who is currently studying maths, I wonder how much of that is due to the way it is taught at University?

His humble and pleasant responses to the questions at the end is wonderful. I observe a genuine search for truth and clarity with disciplined thought, that is often lacking in much software discussion.

Video and slides here.

[埋込みオブジェクト:http://www.ustream.tv/flash/video/1610777]

Speakers: Martin Odersky (EPFL), Nick Kallen (Twitter), David Pollak (Lift)

Martin gives a good overview of who is using Scala, where it came from and where it is going in the first 16 minutes.

Throughout the video, Nick provides the most plausible comments I have heard to date regarding Twitter's motivation/experiences in moving from Ruby to Scala.

Installing F# on Mac OS X is easy (with MacPorts):

$ sudo port install fsharp

I have version 1.9.4.19 installed. Microsoft released a newer version several weeks ago, however it doesn't seem to have made it into MacPorts yet. Then to start F# Interactive:

$ fsi --readline --no-gui

There is basic history with the up/down arrows, but the usual emacs key bindings are not available, so entering and editing text is very slow and painful. I tried to fix this with rlwrap.

$ sudo port install rlwrap

As fsi is already using readline, rlwrap needs the -a option, See the man page for details, but on the mac you are required to provide a string (representing a password prompt the wrapped application might show) argument for this option. It is completely unnecessary for me at the moment, so I just picked something obvious as a placeholder.

$ rlwrap -aPassword: fsi --readline --no-gui

F# Interactive starts up with the usual splash text, but there seems to be some control characters automatically input and the console clears to something like this:

- 0;3R0;3R;3R;3R;3R;3R;3R

The emacs key bindings work, so this text can be deleted with C-a C-k and terminating the now empty line as per normal in fsi with ;; brings up the usual fsi prompt.

Unfortunately, if you type in an invalid expression eg. x = 3;;, the cursor is placed in the middle of the error message. When pressing up arrow to go back through the history, sometimes the prompt is replaced by partial text from a viewed history line.

So this is a pretty dodgy solution. If anyone knows how to get it to work properly, please leave a comment.

A peak into how derivatives trading works at Barclay's and their supporting Haskell application.

QOTD

As we performed the work outside of a traditional it team, management was willing to take a risk on something that promised a good fit and rapid development process.

Abstract

The Functional Payout Framework, fpf, is a Haskell application that uses an embedded domain specific functional language to represent and process exotic financial derivatives. Whereas scripting languages for pricing exotic derivatives are common in banking, fpf uses multiple interpretations to not only price such trades, but also to analyse the scripts to provide lifecycle support and more. This paper discusses fpf in relation to the wider trading workflow, and our experiences in using a functional language in such a system as both an implementation language and a domain-specific language.

The paper is here.

Some quotes from The Future of Computing: Logic or Biology, by Leslie Lamport.

• Computers interact with users through metaphors. Metaphors are not based on logic, but they are not illogical. Metaphor and logic are not opposites. They are complementary. A good program must use good metaphors, and it must behave logically. The metaphors must be applied consistently—and that means logically.

• Floyd and Hoare pointed the way by showing how mathematics could be applied to tiny programs. We need to learn how to extend what they did to the real world of large programs.
  
  Extending what they did does not mean trying to mathematically prove the correctness of million-line programs. It means learning how to apply the idea of a program as a mathematical object to the task of building large programs that we can understand, and that do what we intend them to do.

• In addition to the task of learning how to apply mathematics to large systems, we also face the task of teaching programmers and designers to think logically. They must learn how to think about programs as mathematical objects. They must learn to think logically. We will not have understandable programs as long as our universities produce generation after generation of people who, like my former colleagues, cannot understand that programs are different from automobiles.

Well it was actually a restaurant, not a bar. Anyway, while we were there, Dan North asked me what I thought about Clojure, to which I replied that I preferred strong, statically typed languages. This sparked a huge debate between Dan, Joshua Bloch, Dave Thomas, Bas Vodde and I.

I managed to describe a little of Kristian's Ruby example, which received some agreement. However the best part, was probably Dave and Josh almost yelling at each other trying to get their point across. Admittedly the restaurant was a bit noisy, although I think we were making most of it. :-)

I had a great time, thanks for dinner guys.