My fears about Software Craftsmanship were allayed by the excellent opening presentation by “Uncle Bob” Robert C. Martin. Robert is clearly a seasoned conference speaker, who also knows his subject. He started with an automated scroll through a ridiculously large class that must have been tens of thousands of lines long, before using it as a starting point into bad software and what can be done about it. There was nothing new there, but the advice on good software practices were delivered in a superb way. As the boss put it, even if we get nothing else from the conference, at least we can use Robert’s slide deck to teach best practice to junior dev staff.
The other great thing at the start was the announcement that some of the FP talks were being rearranged. In a stroke this removed conflicts between the FP and craftsmanship talks I wanted to attend and meant there was something for me at every session time.
Sharpening the Tools
First up was Dan North, talking about software craftsmanship. The key thing I took away from Dan’s talk is the blindingly obvious, yet easily missed, fact that software isn’t like riding a bike. To explain: one can learn to ride a bike, not go near one for 15 years, then get straight back on one and continue riding as if that 15 year gap had never occurred. I know this from personal experience.
Software is not like bike riding. Take a 15 year break and upon your return, the mainstream software industry will be unrecognisable to you. All software developers need to put effort into constantly learning about new frameworks, languages, tools, patterns etc just to stand still. Stop learning new stuff and your developer skills will rapidly atrophy.
Functional Approaches To Parallelism and Concurrency
The next talk was by Microsoft’s Don Syme. This was the weakest talk of the day for me. My take on it was that Don presented some long-winded C# example code that took no advantage of .NET parallel framework features. Then offered up some F# code that took full advantage of various parallel features of the language. Having “proven” how much more succinct F# was, the rest of the talk consisted of showing F#’s parallel features in operation.
The saving grace of the talk was at the end. When asked what F# wasn’t good for, he admitted that it is probably better to use imperative languages for presentation-related software, ie anything that uses a GUI. This accounts for around 80% of applications according to Don. This fits with my perception of FP that it really isn’t suited to the stateful, side-effect dominated, event-driven world of GUIs and that OO is a much better fit for that domain.
Functional Programming Patterns
Aino Vonge Corry was the first talk after lunch. She covered that fact that the 23 GoF patterns are a product of the Java language and how other languages remove the need for user-implementations of these patterns as they are supported directly by those languages. Any developer using a language that supports functions as first class objects doesn’t need the complexities of the Observer pattern for example. C# developers do not need to implement the decorator pattern as extension methods provide an inbuilt way of achieving the same thing. However that doesn’t mean these patterns have no use beyond the scope of Java. Knowing that extension methods is C#’s implementation of the decorator pattern aids communication between developers.
Next she looked at some FP-specific patterns that I’ll not go into here as I don’t yet understand them well enough to comment on. I’ll probably return to them another time.
Danger: Software Craftsmen at Work
My favourite talk of the day, but the one that is most difficult to summarise. David Harvey argued that one should treat the Software Craftsmanship movement with caution. Tying in with Dan North’s comments regarding software not being like bike riding, David highlighted our desire to borrow metaphors from other human endeavours to try and describe software. Computer science, software engineering, software architecture, software craftsmanship etc. Each of these words: science, engineering architecture and craftsmanship risks imposing negative baggage on the software industry and is at best a poor fit. So whilst software craftsmanship is a good idea, maybe we should just call it “best practices and professionalism”.
Amanda Laucher was unwell and so couldn’t make the conference. So her husband, Josh Graham, stepped in to do the last talk of the day instead.
I am unsure whether I missed the point for I came away from the talk thinking:
- Monads are easy, so what’s all the fuss about?
- Monads seem to be a solution to pure FP languages being rather useless in the real world by providing a facade onto stateful, non-deterministic, side-effect laden real world systems like IO. Other languages therefore don’t need them. So what is all the fuss about?
In essence, a monad is an abstract type (at the risk of indulging FP heresy, think “object”) that encapsulates two values: some set of data and a function. The monad then can apply that function to the set of data and generate a new set of data in the process. There’s various rules around the behaviour of monads, but that is in essence all there is to them.
The power of monads comes into play with languages like Haskell. Because the monad provides a facade that extrapolates away functionality from the main language, it can do all sorts of things that would otherwise break the pureness of the language. So IO, error and exception handling etc are all handled by nomads.
I will put a big caveat here though: I may have simply misunderstood everything about monads
And so ended day one of QCon London 2010.