This month we have three speakers, and I am one of them! In my talk, "Erlang - Why should you care?", I will be giving a fairly non-technical introduction to Erlang. I'll be covering off the features of the language, some of its design goals and its history. I aiming to show that this language is not one that was spawned out of academia and that it has been applied in the real-world ever since its conception. If I have time, I'll also be giving a small demonstration of one of the neatest features of the technology.

I'll be posting the slides and demonstration code here on this blog as well as BFPG's home after the meetup has taken place.

Myself and my comrades, Tom and Tony, will aim to provide a fun and interesting evening at our new venue. Based on the RSVPs so far, it looks like we are going to have one of the biggest turn-outs to date. This is probably due to the exposure we got during last month's talk by Dave Thomas. There are still plenty of spots left, so if you're keen to come along, go and sign up. Bring your friends, your friend's friends and your mum.

I hope to see you there!

Update (6th July 2010): We had a fantastic turn-out of just short of 50 people (a record breaker for the group so far!). My talk seemed to be fairly well-received. No rotten tomatoes were thrown and the crowd seemed engaged through most of the talk. It felt good! I think many people wanted to see more code, but since that wasn't the focus of the talk they were a little disappointed. If people are keen for more Erlang goodness at future meetups, then I'll be happy to dive a little deeper.

As promised, here are the slides:

1. PPTX
2. PDF (Google Docs)
3. PPT (Google Docs)

If you have issues reading the slide deck, or would like it in another format, then please drop me a line.

The talk was covering Functional Programming and the NoSQL movement (which, as Dave himself puts it, should be called NoRDB). These are two areas of computing that are currently key interests of mine, so it won't come as a surprise to find that I thoroughly enjoyed the talk. I certainly wasn't the only one. Dave did such a great job of covering the positives of these two movements that we're already seeing more and more people signing up for membership to BFPG.

I'm not going to go into the gory details about what Dave covered in his talk as I don't want to spoil it for other people if he plans on doing it again elsewhere. There are a few things I would like to mention though:

• Functional Programming is here to stay. If you're not familiar with it, or haven't yet taken a look at it, I suggest you get started!
• If you're looking to get involved with FP and you're in or around the Brisbane area, be sure to come to one of our BFPG meetups.
• Don't fall into the trap of assuming that if your system needs a back-end data store that an RDBMS is the only option, because it's not!

This talk has inspired me to not only continue checking out the likes of Haskell, Erlang and Riak, it's pointed me at some languages that I never knew existed. Languages which are insanely powerful, very dense, yet still extremely useful. Some examples are J, K and Q. KDB+ in particular is very interesting as it ties in with the use of another type of technology that I was aware of but knew nothing about: Column Databases. Crazy stuff.

After seeing so many people excited by the prospect of Functional Programming after Dave's talk had concluded, I decided to set up a new website for BFPG so that we had a proper home rather than just a spot on Meetup.com. Check it out and feel free to send through some feedback if you have any, or drop us a line if you have any ideas for talks or would like to present something yourself.

That's it for today's brain-fart

"We're very happy with the work you've done for us as a contractor. We want to keep you on, but would like you to take a job as a permanent employee and continue to work on the project."

Once they've made this point, they then feel the need to harp on about the good points of becoming a permanent employee. Things such as job security, sick/annual leave and better hours tend to get mentioned. All of them are complete bullshit of course.

There is no such thing as job security. Sick and/or annual isn't enough to make up for the difference in pay. Hours tend to always be worse when you're working for the man, because you're expected to do whatever needs to be done regardless of the hours. This is worse if you're working on mission-critical stuff.

Now I have no aversion to doing my fair share of extra work and mission-critical stuff is way more interesting. I often enjoy it. What I don't enjoy is the expectation for me to give away my free time to my employer for no reward. I don't get extra time off in lieu. I don't get overtime pay. I don't get ownership of the software. I don't get to see the result of the extra effort I put in. I'm just expected to do it. In other situations I'd be happy to do it, but 999 times out of 1000, the situation isn't right.

I've even worked for companies in the past who expect you to give up a lot of your personal time even if there isn't anything critical that needs to be done. I was expected to write small applications and create other assets that the company could use in future projects. At first this seemed like it could be fun. But the cold hard reality was that all of the effort was totally wasted, because none of the things that were created ever got used.

As a contractor, the view from the perspective of the client is different, especially if you're on an hourly rate. Everything boils down to a financial cost. You're more likely to get a fair deal as a contractor than you are as a permy (at least here in the Brisbane market) because you're entitled to make them pay for the time and effort you put in.

I realise that this makes me sound rather mercenary. In all honesty, I'm not mercenary. I love technology. I love building software. I don't go to work just so that I can get paid. In many ways I would work for less pay if the conditions were right. Unfortunately, I am yet to come across a job where those conditions are right. I've certainly given it a shot in the past. I took a substantial pay-cut to work for Electronic Arts back in 2005 so that I could work on something that I really wanted to work on. I thoroughly enjoyed it. As far as the technology and the challenges are concerned, it's the most fun I've ever had at work. Unfortunately, the experience I had there led me to believe that the lifestyle isn't sustainable (at least not for me and my family).

Would I do the same again for another job? Definitely. But the only company I would do it for would be Basho and my Erlang-fu is not yet up to scratch so I wouldn't be considered. Outside of Basho I'm not aware of any other company or work that excites me as much. So for now I will probably remain a contractor, and try to move around and add as much value as I can on a variety of projects, keeping up to speed on many different types of technology.

So if you're reading this, give me a few good reasons as to why permanent work is better than contract work. Why should I consider it? Would you consider it? If you're a permy, are you looking to go contracting, and why?

Feedback and comments are appreciated

For some reason, it's a very common practice for those people who don't have expertise in a certain field to make decisions for people working in that field. The best example I can think of off the top of my head is the answer to the question: "Which technology should we use?"

Let me take a step back in time for a moment.

I applied for a job with a certain company (which shall remain nameless) that was looking for a number of C#/.NET developers of a certain level of experience. After confirming an interview date and time, I turned up to find myself facing a panel of 3 interviewers. One of those people held a technical position, though I found out later that the position he held was self-appointed and certainly not an indication of the person's level of technical knowledge or expertise. The other two were in non-technical positions.

During the interview we had the usual discussions and questions around technial knowledge, depth of understanding of certain areas of the .NET framework, views and approaches to dealing with people in teams, agile experience, etc. It all went very well. At the end of the interview I was given my chance to ask a few questions. The main one I wanted to ask was "Why did you decide to use .NET for this project?"

For the record, the previous version of the system was written using an older Microsoft technology stack. The decision had been made to go with .NET for this new version. Can you see the correlation?

The answer was quite stunning. The only reason the project was using .NET was because the previous version was a Microsoft-based solution.

The first thing I thought was "surely that can't be it?". As a matter of fact, that wasn't the only reason for it, but it was the main reason. The decision wasn't made by a technical person, it was made by someone in upper management.

Scary huh!?

In my personal opinion, there is one particular technology that I think would have done a much better job of solving this particular problem, and it's not a Microsoft solution. It's not a Sun solution, or any other mainstream option for that matter. In my view, Erlang would have been perfect.

I don't think that a company like that would have ever even considered Erlang as a viable option. Mainly for two reasons. The first is that the amount of skilled Erlang developers available on the East Coast of Australia is extremely small. The second is fear of the unknown/non-mainstream tech. That is, companies like to go with what other companies are going with.

The crazy thing about this scenario is that management go to market to hire people who are domain experts, and then proceed to tell them which technologies to use. Surely you would be better off hiring people to know how to solve problem X really well, and then listen to what they have to say about the technology stack that should be put in place? No, not in this industry. Probably not in my lifetime either!

So if you're a non-tech person leading a team of techies, please PLEASE listen to what they have to say. Ask them what they think is the right approach and the right toolset. Don't take control of the technical decisions. Let them do what you hired them to do: Solve the problem, and use the right tool for the job. If they don't know the answer, or the answer is always the same, then you've got the wrong developers.

Thanks for listening

I can thank Gabrielle Lana for this discovery, as it was his attempt at one of the katas that got me into it. He's also the reason I looked into Katacasts, which are simply screencasted recordings of people attempting to solve Code Katas.

This post is about my first Katacast, capturing my attempt at Code Kata #9 using Erlang and VIM with Rake as my build system. I've put the video up on Vimeo for the world to see/share. It's also embedded below for your convenience.

Before watching, I'd like to point out a few things about the video, and things that I have learned from the experience:

• I captured the video on my Linux Mint install. For some reason, capturing quality video in Linux is proving to be a bit of a pain for me. As a result, the video quality isn't that great. This partly due to the compression of the video, and partly due to the software failing to pick up some screen updates.
• I tried really hard to add a backing sound-track but all of my efforts failed in one way or another. If I did manage to get one to work it was either WAY too big (ie. > 1GB in size) or the quality was absolutely terrible.
• There were points during the process where I had to alt-tab out to a browser to do a bit of research on something that I didn't know (such as an Erlang syntax quirk). This resulted in a few points where I don't appear to be doing anything. In future, I'll remember to hit pause on the recording when this happens.
• I captured it in a non-standard resolution. I'm not sure if that's going to make it look bad or not. Feedback here is appreciated. I think in future I'll capture at a 800x600 resolution.
• This video is best viewed in full-screen mode.

So please excuse the lack of quality in this first Katacast. I'll be sure to improve when I next create one. That being said, on with the show!

As always, feedback/criticism/etc is greatly appreciated. I'd love to hear what you guys do and use to capture and edit your screencasts, particularly in Linux.

It's safe to admit that you just don't know! In fact, it's better if you do admit it. Pretending that you know what you don't not only makes you the butt of the jokes, but you end up being detrimental to the success of the project.

Stop trying to be a know-all. Let go of the idea that you need to be the one to approve everything. Take a step back and be honest to yourself and the rest of the team. You aren't a one-man-band. You aren't the technical guru that you think you are. You aren't even a specialist in a particular area, let alone a jack-of-all-trades.

When you attempt to do something and you fail, stop trying to make it sound like you haven't failed. Please stop yourself from trying to turn your wrong into a right. Everyone fails in one way or another during their working life, and as much as you don't want to admit it, it does include you.

Change your attitude. You'll be doing yourself a favour.

And while you're at it, how about you get up to speed with the technology you're working with. Then you won't have to pretend, and the likelihood of you failing will start to decrease.

Thanks for listening.

Remember, it's not about you, it's all about the software.

I know, this kind of thing happens thousands of times a day. Some arbitrary geek decided to build the next killer app and expects to make a crapload of cash out of it. While that would be nice, the ultimate goal isn't the cash. The goal for me is to build something that gets used, and for me to begin to master an area of technology that I've had a quiet passion for for a long period of time now.

My plan is simple. While learning the technologies that I will be using I'll be building another application and blogging about it so that all of you can learn with me. Meanwhile, I shall use my learnings to build this other application at the same time.

The final result should be a series of posts which help other people learn the technology stack, give better coverage and visibility to languages and technologies that a lot of the geek world doesn't know about (and really should!), and for me to carve myself a bit of a niche here on the East coast of Ozland. I am hoping to be able to consult my services out to other businesses as a result.

For those that are interested in following along, here is the full tech stack and toolset that I'll be using:

• Erlang - A fantastic cross-platform functional programming language that has some amazing features.
• Webmachine - A HTTP toolkit which sits on top of Mochiweb that makes it easy to build well-behaved HTTP applications.
• Nitrogen - An Erlang-based framework that makes it easy to build websites.
• Riak or CouchDB - Both of these amazing pieces of tech are potential candidates for the back-end storage. I'm not yet sure which one I'll go with.
• jQuery - A great JavaScript library for the front-end.
• VIM - My favourite text editor
• Xubuntu - Ubuntu Karmic Koala with XFCE as the window manager.
• Mercurial - My favourite version control system.
• Trac - A project tracking tool.
• VirtualBox - My choice for virtualisation. I tend to run Windows 7 as my primary OS, so most of my dev will be in a VM. When I get my desktop machine back up and running (with all three monitors!) it'll most likely multiboot Win 7 and Xubuntu.
• Google Wave - I'll be using this for communications with some really switched on people in the Erlang community who have kindly offered to help me with questions and whatnot specific to some of the areas of tech I've mentioned above.

During the course of my blogging/learning I'll be focussing on Webmachine, Riak/CouchDB, Erlang and Nitrogen. All the other tools will probably get mentioned along the way, but the primary goal is to focus on these things.

I'm really excited! I'm currently in the process of documenting my goals and the design for the main application. Once that's done, I'll get started with the fun stuff. I've got a lot to do and it should be a fun ride. I hope you enjoy following along!

Communities are arguably the life blood of technology. Without a good community the likelihood of the technology catching on is drastically reduced. Those communities which lack individuals that are happy to put time and effort in to help get others up to speed tend to stagnate. Any community which involves members that are abrasive, rude and downright offensive is destined to suffer long term.

The level of suffering will vary depending on quite a few things. Those things include existing user base, the age of the technology and the number of different ways that a given n00b can get information about that technology.

IRC is a very common and popular means for members of communities to interact. It provides a real-time element that you don't get with blogs, forums and other media like Twitter. It satisfies every geek's desire to get the answer and get it now. Experiencing support in real time via IRC can be extremely helpful and rewarding. It can work wonders for the popularity and image of the community and the technology itself.

If you're interested in seeing some active and extremely helpful communities, you should take a look at #haskell and #mercurial. Both of these channels are generally very active. The people that spend time in them are both helpful and friendly. Both of these channels indicate to me that there is a very healthy and vibrant community behind each of these pieces of technology.

Unfortunately, this kind of communication also has a downside. The real-time nature of IRC allows people to vent anger on newcomers without any means of moderation. The net result of this is that other individuals become to scared to offer their view or provide support for fear of receiving the same treatment. This goes for members with any level of skill or knowledge. There are some community channels out there containing hundreds of people, and yet there is no conversation. When questions are asked, nobody responds.

After my recent experience in a channel that fist this description, it's easy to see why. In less that half an hour of asking for clarification on certain points, I received a barrage of abuse which, in my view, was totally unjustified.

But let's say, for the sake of argument, that it was justified. That for some reason I annoyed someone in such a way that bombarding me with many 4 and 5-letter expletives was acceptable. Do you think that it paints a good picture of the community?

I think not.

In less than half an hour I went from excited to deflated. I lost interest in the piece of technology and lost faith in the community around it. Was my response justified or understandable?

I'm not sure about the answer to this

I feel that it's the job of the community to moderate other members of their community. If people get abusive then other members should step in and prevent it. In my case this wasn't possible due to the fact that the person in question was abusing me via a private chat so that the channel couldn't witness his venting. I'm guessing this wasn't the first time that he's done this to someone, nor will it be the last. I wonder how many others have suffered the same fate? If the silence of the channel is anything to go by, I'm guessing quite a few.

I guess what I'm trying to say here is this: don't underestimate the value and importance of your community. It's one of the most frequented faces of your technology. If it's bitter, unwelcoming and unsupportive, you will not only lose valuable newcomers who come looking for information and support, you will also lose future users due to the poor reputation. Ultimately, your tech will suffer.

If you're part of a community, do your bit to police it. Help those who need help. Stop those people who are abusive.

.. and if you don't have anything nice to say, then don't say anything at all!

A little bit of history...

Recently I've been delving into Haskell quite a bit. It's part of my apparently never-ending quest to learn as much as I can about as many languages as I can (well, those that appeal to me at least :)). While I love playing around with a language, toying with ideas, writing small programs, reading books, blog posts, etc it's not really the same as having an on-call expert to help and guide you.

While I'm aware of, and frequently visit, the Haskell IRC channell I find that the level of understanding there is so great that my piddly noob questions tend to get lost amongst the bombardment of much more advanced & interesting discussions. In short, while I find it a great place to go, it's not a great place to find someone who's happy to help guide me through the maze and go over topics in quite a bit of detail while I annoy them with questions.

Haskell is one of those languages where having a mentor is really beneficial. So I set about finding myself one. Thankfully, I found a rather helpful chap based in the UK, (he shall remain anonymous, as I don't want to violate the man's privacy), Peter Marks, who has been very forthcoming with information. He's humoured me and been incredibly patient so far, and I'm very grateful for his time.

One of the questions that I asked him was:

Why is it that everyone seems to strive to get their code into Point-Free style? I can see how a lot of the implementations are more concise, but many of those lose readability.

What is so special about it?

The discussion that followed was really insightful. That is what has inspired me to write this post.

Please note, any errors in this post are totally my own. They are not the fault of my mentor

The purpose of the post: Why aim for Point-Free style?

So it is just me, or does anyone else out there feel that there's a bit of a "thing" going on for Point-Free style? Sometimes I share my terrible code with people and I get shunned when it's not Point-Free and it could be.

Anyone?

I hope it's not just me Let's start with taking a quick look at what Point-Free style actually is.

So what is Point-Free style?

If we take a look at the Wikipedia we can see that..

Tacit [point-free] programming is a programming paradigm in which a function definition does not include information regarding its arguments, using combinators and function composition (but not ?-abstraction) instead of variables.

Simple eh? In essence, it basically means that your function definition doesn't reference any of its arguments/variables. For a crass definition, think point == argument and it should make sense.

So we're writing functions without directly referencing its arguments. For those not familiar with Haskell or other languages that support this, let's take a look at an example:

-- sum : take a list of numbers and add them all up to get a total
-- start with the base-case: an empty list
sum [] = 0
sum (x:xs) = x + sum xs

We can see that the above function is written in such a way that the arguments passed into the function are actually referenced in the body of the code. This is how a standard imperative programmer would write this function if he/she was new to Haskell. If we instead used a fold, we could define it like so:

sum xs = foldr (+) 0 xs

This does exactly the same thing as the previous definition, but as you can see the grunt work is done by the fold function. Now that we have this definition, we can easily move to Point-Free style:

sum = foldr (+) 0

Here we can see that no reference is made to the arguments of the function. Since we haven't referenced any "points", we have a Point-Free implementation.

Awesome. Cool. Sweet. Nifty.

But what does it give me? Why is it better?

Why use Point-Free style?

This section is based totally on my own opinion and is not an official definition I think that Point-Free style fits in the same category as many other coding patterns and styles, and that it's usually down to the individual programmer to determine the when and the why. So take my view with a pinch of salt.

In short, Point-Free style let's you focus on the how rather than the what.

It might be just me, but imperative programs seem to have a large focus on the data. The code which operates on the data is lost within a plethora of code that isn't necessarily specific to what the program needs to do. I've found that functional programming tends to be very different, at least in Haskell. Haskell lets me focus on what it is I need to do, and I feel that Point-Free is another step in the same direction. Is this good? I think so But I'll let you decide.

As well as the focus on the what I've found that aiming for a Point-Free solution can aid in helping you understand your problem better. This claim sounds like fluff, so let's go through an example and hopefully you'll see what I mean.

Where Point-Free helped me get a better understanding

Haskell developers use the composition operator (.) a lot. It actually aids in creating Point-Free style. I love the irony here. We add points (.) to remove points (arguments).

Anyway, the composition operator's definition, according to Prelude is:

(.)       :: (b -> c) -> (a -> b) -> a -> c
(.) f g x = f (g x)

This operator takes two functions and produces a function which is composed of the two. This function takes the output of one function and sends it through as the input to another function, returning the result of that call.

This is really handy. We can do some interesting things like:

ghci> let doubleAndAdd5 = (+5) . (*2)
ghci> doubleAndAdd5 20
45
ghci> :m +Data.List
ghci> let sumColumns = map sum . transpose
ghci> sumColumns [[1,2,3],[4,5,6],[7,8,9]]
[12,15,18]

Very handy indeed. While handy, it doesn't necessarily allow us to do everything we might want to do. One example is handling cases where we want to compose a function where the right-hand function takes two arguments instead of one.

So if we wanted to create a function that would take two values, add them together and double the result, all while using Point-Free style, we'd like to do something like this:

ghci> let addAndDouble = (*2) . (+)

:1:20:
    No instance for (Num (a -> a))
      arising from a use of `*' at :1:20-21
    Possible fix: add an instance declaration for (Num (a -> a))
    In the first argument of `(.)', namely `(* 2)'
    In the expression: (* 2) . (+)
    In the definition of `addAndDouble': addAndDouble = (* 2) . (+)
ghci>

As you can see, ghci doesn't like it. And rightly so! This is because the composition operator's signature is:

(.) :: (b -> c) -> (a -> b) -> a -> c

That is:

1. It takes an argument which is a function which takes a value of type b which returns a value of type c
2. It takes a function which takes a value of type a which returns returns a value of type b
3. It returns a new function which takes a value of type a and returns a value of type c

This doesn't work in our case, as we want our right-hand function to take two arguments. That is, we want a type signature that looks like this:

foo :: (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c

So everywhere we had (a -> b), what we really want is (a -> a1 -> b). Given that we don't have an operator that does that for us, let's define one. We'll start with the definition of the (.) operator and work towards a function that does what we need.

-- here is the composition operator again
(.) f g x = f (g x)
-- here's our new operator's definition
(.^) f g x y = f (g x y)

Simple! Let's see what ghci says about it:

ghci> let (.^) f g x y = f (g x y)
ghci> :t (.^)
a :: (t2 -> t3) -> (t -> t1 -> t2) -> t -> t1 -> t3

Looks good! This is exactly what we need. Now that we have a working function, let's aim to write this in Point-Free style. We do this by breaking down the function slowly and eliminating arguments by moving them to the far right hand side of the function definition.

The first argument to get rid of is 'y', as this is the last argument passed in:

-- start by moving y to the right
(.^) f g x y = f (g x y)
-- becomes
(.^) f g x y = f . (g x) $ y

These are functionally equivalent, and now that 'y' is out on it's own, we can drop it from our function definition:

ghci> let (.^) f g x = f . (g x)
ghci> :t (.^)
(.^) :: (b -> c) -> (t -> a -> b) -> t -> a -> c
ghci>

Excellent, we're a step closer. Now we need to do the same with 'x'. This takes a little more fiddling:

-- we need to take the original definition
(.^) f g x = f . (g x)
-- and change it so that it uses prefix notation instead of infix
(.^) f g x = (.) f (g x)
-- which is the same as
(.^) f g x = ((.) f) (g x)
-- what we're doing is calling g with x and applying the result to f
-- and hence we can compose the composition of f with the call to g
-- giving us the following
(.^) f g x = ((.) f) . g $ x
-- finally leaving us with
(.^) f g = ((.) f) . g

Phew I hope you can see the progression. We've managed to move x out of the picture, so now we're down to a fairly crazy looking definition. Let's see what ghci has to say:

ghci> let (.^) f g = ((.) f) . g
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

So we've got rid of two variables, but there are still two more to go! Remember, 'f' and 'g' are still variables, they just carry functions. So let's get rid of 'g':

-- start with what we had before
(.^) f g = ((.) f) . g
-- change to prefix notation again
(.^) f g = (.) ((.) f) g
-- and drop g
(.^) f = (.) ((.) f)

This is looking rather crazy Again, let's make sure we haven't done anything stupid:

ghci> let (.^) f = (.) ((.) f)
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

Excellent. We've still got what we need. One more point needs to be dropped, so let's get rid of 'f':

-- start with what we had before
(.^) f = (.) ((.) f)
-- which means that we're composing a composition with a
-- function composed of f and something else
(.^) f = (.) . (.) $ f
-- and we finally drop f
(.^) = (.) . (.)

Isn't that just crazy! Let's again check ghci:

ghci> let (.^) = (.) . (.)
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

So there we have it, our operator completely in Point-Free style.

This is where the penny dropped for me. The whole exercise of moving through to Point-Free made me really understand what it was I was doing in the first place. The final definition makes it very clear. We're composing two separate compositions.
Let's see if our function behaves itself using the example we listed above.

ghci> let addAndDouble = (*2) .^ (+)
ghci> :t addAndDouble
addAndDouble :: Integer -> Integer -> Integer
ghci> addAndDouble 10 15
50
ghci> addAndDouble 21 3
48

It does exactly what we need it too.

Conclusion

To sum up, Point-Free helps you tidy your code into more concise implementations which tend to aid you in understanding what it is you are trying to do. I feel it really helps you focus on what you're doing as opposed to what you're doing it to. It's down to you to determine whether you feel this is a good thing or not!

It is ultimately down to the developer to dictate when it should be used. There are definitely cases where the resulting function might not actually help in making things clearer. But on the whole, Point-Free style seems to help me understand what it is I'm doing (or, arguably, not doing).

Of course, you could just get sick and tired of trying to come up with variable names, in which case Point-Free is the bomb

Feedback of any kind is always welcome. Cheers!

A sample of the data might look something like this:

data = ({150,200,45,57,95,2,45,32,15,10,5,2,2,4},
         12,20,45,37,10,5,2,2,10,95,2,45,32,7},
         32,15,10,5,2,23,24,15,20,45,57,95,0,45})

So the first step would be to add 150, 12 and 32 and store the value. Then 200, 20 and 15, and store the value. Do this for all of the columns, then get a maximum and a minimum.

This little algorithm was going to be part of his project, and hence needed to be implemented in AS3. So I picked his brains about the AS3 syntax, because I have absolutely no clue given that I've never worked with any version of ActionScript in the past.

Together, we came up with the following solution:

var columnTotal:Number;
var biggest:Number;
var smallest:Number;
biggest = smallest = sum(vData, 0);

for(var i = 1; i < _scope.period_mcs.length; ++i)
{
  columnTotal = sum(vData, i);
  biggest = Math.max(biggest, columnTotal);
  smallest = Math.min(smallest, columnTotal);
}

// helper function
function sum(var data:Array, var index:Integer):Number
{
  var total:Number = 0;
  for(int i = 0; i < data.length; ++i)
  {
    total += data[i][index];
  }
  return total;
}

Does it work? Yes, it sure does. Is it optimal? Yes, and no I was lazy and used the Math.max and Math.min functions instead of doing the obvious...

if(biggest < columnTotal) biggest = columnTotal;

So if we did that, to reduce the need for function calls and unnecessary assignments, we end up with this:

var columnTotal:Number;
var biggest:Number;
var smallest:Number;
biggest = smallest = sum(vData, 0);

for(var i = 1; i < _scope.period_mcs.length; ++i)
{
  columnTotal = sum(vData, i);
  if(biggest < columnTotal)
  {
    biggest = columnTotal;
  }
  else if(smallest > columnTotal)
  {
    smallest = columnTotal;
  }
}

// helper function
function sum(var data:Array, var index:Integer):Number
{
  var total:Number = 0;
  for(int i = 0; i < data.length; ++i)
  {
    total += data[i][index];
  }
  return total;
}

I can't see many ways to improve on this without going overboard with optimisation. Any AS3 guru's are more than welcome to prove me wrong!

So after thinking about this in an imperative language, I couldn't help but have a look at what the functional version might look like. Of course, my current chosen Functional toy is Haskell and so I fired up VIM and GHCI and had a bit of a play.

First, I put the data into Haskell's list format:

vals = [[150,200,45,57,95,2,45,32,15,10,5,2,2,4],
        [12,20,45,37,10,5,2,2,10,95,2,45,32,7],
        [32,15,10,5,2,23,24,15,20,45,57,95,0,45]]

That was easy enough. The next step was to break the problem down so that I could use some of the built in functions of Haskell's Prelude libraries. My thought processes were:

1. Summing the column of the array could be done using sum, but I'd need to change the list so that rows become columns, and vice-versa.
2. To switch rows and columns, I could use the transpose function.
3. Then all I'd need to do is use maximum and minimum to get the right values out.

Being a bit of a primitive Haskeller, my first pass was something like this:

extremes n = (b, s)
  where
    l = map sum $ transpose n
    b = maximum l
    s = minimum l

The function extremes is the function which takes the data (list of lists) and spits out a tuple of (max, min).

Before the end of the conversation with my designer colleague in arms, I pinged him my version of the solution in Haskell and needless to say he was a little surprised as how concise it was. I was sure to point out that there is no doubt a better way of representing this solution with regards to speed and conciseness.

The first thing that I thought could be improved would be using a custom fold to get the max and min while parsing the transposed list. This would allow us to calculate the values in a single pass and hence be a little better with regards to performance. That would obviously sacrifice a little bit of the conciseness we're looking for.

When the conversation ended, I jumped onto IRC and spoke to some more seasoned Haskellers. The first suggested improvement that popped out of that chat was to use arrows to remove the need for the where clause. That solution looks like this:

extremes = (maximum &&& minimum) . map sum . transpose

Nifty Of all the other options, this proved to be the most readable and concise, though not the best performing.

The next most notable solution included the fold which calculated the min and max in a single parse, not a double parse:

extremes = foldl1 (\(a, b) -> max a *** min b) . join zip . map sum . transpose

Folds really are fantastic aren't they. Again we're using arrows here to do a bit of heavy lifting and that keeps things looking a little nicer.

So after this little session, my designer friend was aware of how easy it can be to crunch certain types of data using a functional language, like Haskell. It made me think again about how it'd be nice to just be able to plug in whichever language we wanted whenever we felt it would do the job better than whatever the current tool is.

So how would you improve it?