Posts Tagged ‘Functional Programming’

Hyperproductive Monadic Programmer for the 21st Century

September 15, 2008 5 comments

I recently attended the “Introduction to Scala” course at Working Mouse. The course was run by Tony Morris with the help of Tom Adams. I had feared that the course would be a introduction to Scala with Haskell-coloured glasses … and it was just that. However, it was just this that made it interesting. I already know Scala at a basic level so a truly introductory course would have offered little. I knew that Tony was into Haskell and on one hand I wanted to come away with an idea of what a monad was and on the other hand I didn’t want to learn Haskell with Scala syntax. Luck would have it that there turned out to be just two attendees – myself and John Ryan-Brown. Tony was able to accelerate through the introductory material with help from Tom Adams. This freed us up to begin working on monads and emulating type-classes in Scala. It was a really wonderful course that I can’t do justice to in this short post. I did come away knowing what a monad was (but now I’m not quite so sure). I did learn Scala through “Haskell glasses” but that was what was really wonderful about the course.

So what are monads? Well it appears to be an “ultimate interface” with 3 special methods – return (also called unit), bind and join (where join can be derived from return and bind). My current understanding is that monads are the “ultimate iterator” but I figured I’m supposed to understand that they are an “abstraction over computation”. This is going to take a while to sink in. Here are the signatures for the 3 special methods:

  return :: Monad m => a -> m a
  bind   :: Monad m => m a -> (a -> m b) -> m b
  join   :: Monad m => m (m a) -> m a

In terms of List, return is cons, bind is flatMap and join is flatten. I wasn’t familiar with flatMap but it’s a more general version of map. Map can be implemented in terms of bind/flatMap and unit/cons.

    List(1, 2, 3) map (n => n + 1)
    List(1, 2, 3) flatMap (n => List(n + 1))

Since then I’ve been learning a little more about Haskell and Category Theory. It’s really great to have a new avenue of things to study. Haskell certainly has come a long way since I looked at it last.

Oh and the title of this post… Well it’s kind of a bad joke from day 3. After 3 days of indoctrination I realised that it was leading to the conclusion that a new breed of programmer was required – the hyper-productive monadic programmer for the 21st century. This new breed of programmer would eschew side effects and even OOP in preference to algebraic data types, type classes, implicits, higher order functions, monads and higher kinds. They would impress their friends with deep knowledge of mathematical principles and have an IQ 50 points above decent developers of today. These programmers would be trained to be 10x more productive than their imperative colleagues (coding in Java and C#) – allowing some of us to retire for a better life (perhaps as an economist or financial advisor). All that remains is to work out how much of this is hyperbole and how much sound.

Misunderstandings about closures

September 15, 2004 Leave a comment

Even the “big names you know” in the Java software development community can make mistakes when it comes to closures.

Gavin King thinks that closures wouldn’t work in Java because of checked exceptions. However, since the use of checked exception is optional you can use “closures” (annonmous inner classes) pretty well if you either don’t use checked exception or alternatively wrap checked exceptions with unchecked exception (like the JDBC template in Spring). I was wondering if it would be possible to have you cake and eat it too on this point with Java 1.5 generics – another poster says it is possible to parameterise on the checked exceptions. I hope that’s true because that’s the best of both worlds – “closures” and checked exceptions – or at least living life without wrapping every last damn checked exception in an unchecked one ;-).

James Strachan commented that closures have made it into C# 2.0. Another poster correctly pointed out that this is just *not* the case. I can understand why you’d thnk that – you really have to read between the lines in those Microsoft articles ;-). With all the good .NET stuff coming out of Microsoft lately I’m surprised they didn’t correct this properly in C# 2.0. I much prefer their implementation of generics – it’s not based on type erasure like in the Java.

Martin Fowler (if you follow the link through to his article) is right on the money. Closures are good. Lisp is good. Ruby is good. Smalltalk is good. You gotta love Martin.

The Koan of Side Effects

August 29, 2004 Leave a comment

I had a laugh at this (via comp.lang.functional).