The random utterances of David Arno

QCon day 1: Craftsmanship & functional languages

I had been somewhat apprehensive of the first day of this year’s QCon London as the schedule didn’t really excite me. The “Architectures You’ve Always Wondered About”, “Non-Relational DBs & Web Oriented Data ” and “Solution” tracks aren’t really my thing and the “Dev and Ops: A single team” and “Software Craftsmanship” tracks sounded like jargon-laden fluff tracks that were likely to be full of hot air and waffle, rather than substance. That left just the “Functional Programming” (FP) track. Whilst I’m happy to learn about FP, I didn’t want to spend my whole day on the one track. Thankfully, my worries were baseless and the day turned out to be really very good.

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

Demystifying Monads
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:

  1. Monads are easy, so what’s all the fuss about?
  2. 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.


Share This Post...
4 comments so far, click here to read them or add another

4 Comments so far

  1. [...] QCon day 1: Craftsmanship & functional languages | The random … [...]

  2. Richard March 11th, 2010 22:37

    I think the point that Aino Vonge Corry was trying to reach before the discussion descended into the age old childish argument of which language is best, was that the patterns do exist where ever they can be applied but that some languages express them more elegantly, to the point at which they seem to vanish I think she cited Visitor as one of those patterns that are expressed so easily in FP that it need not be explicitly mentioned, it’s there, it’s just totally hidden.*

    A programming language is simply a way to describe the solution to a problem, the fact that one language describes a solution to a particular problem better than another one is neither here nor there. The solution still exists and a concise way to talk about the solution is to use the language of patterns as they are programming language agnostic.

    I am struggling to get my point across, this is due to my lack language but essentially the solution to a problem should be given as the “what” needs doing not the “how” it will be done, this is the job of the programming language itself.

    I am sure I haven’t been able to explain what I mean and for that will probably be flamed to death, but for all those that do disagree don’t simply say “your wrong”, there is nothing I can do with this advice, tell me why I am wrong.

    *By “hidden” I do mean VERY hidden, but at the end of the day remember that whatever language we express solutions with at the end of the day they all become state transfers and tuples in a Turing machine.

  3. Jon Harrop October 21st, 2010 00:02

    If you can improve upon the C# code Don Syme gave in his presentation by using new features of the language or .NET then I’d love to see your improved code!

  4. David Arno October 21st, 2010 09:20

    @Jon,

    Provide me the code and I’ll happily improve upon it :)