Since Java and the JVM are getting proper closure support, now is as good a time as any for me to dump some thoughts about functional programming onto the site. I’ve got a few posts in mind, but I imagine this will be a somewhat sporadic series. Anyway…

When I was first introduced to functional programming, as part of my degree course, I didn’t really understand it. Not that I didn’t do well at the course, it was one of my strongest modules that year, but I really didn’t understand the benefits and potential. It did seem unusually neat, producing fairly compact code (we were taught Haskell, unsurprisingly), but also fairly burdensome. Avoiding side-effects and assignment was just too foreign, and I didn’t have enough real-world experience to really get the point. So, for a few years, I just forgot about it and got on with programming in other languages (Java, C, PHP, JS, etc).

Skip forward a few years, and as a reasonably experienced coder, I often found myself frustrated at the languages I was using. I would always try to make my code as neat and compact as I could, trying to minimise any wasteful re-use. If two classes were vaguely similar, then I’d look to find the common elements and make the differences abstract. Joel Spolsky talked about this when covering Javascript.

That’s all well and good but without certain key language features you can only get so far. The very constructs that hold the language together (loops, ifs, locks etc) are often the part that are either impossible or very difficult to abstract. This revelation brought me back to functional programming.

I now realise that the core of functional programming is freeing yourself from the constraints of the language, using different higher-order functions to express yourself more clearly and succinctly. A necessary consequence of this is lack of side-effects, and that’s a GOOD thing.

Stick around, I’ll be covering a number of libraries and ideas that make life simpler for the functional programmer.

I try to avoid anything remotely political on this site, for many reasons, but I feel it worthwhile discussing some of the issues around Peter Mandelson’s Digital Economy Bill: one of the most wrong-headed political policies I’ve seen in the technology space.

In this country we, by and large, have a solid basis for our justice system: we are all innocent until we’re proven guilty. Suspicion of committing a crime is not good enough, it must be proven beyond a reasonable doubt. The upshot of this is generally positive. We can’t be accused of something and be punished for it, without proof that we actually did it. This is a fundamental right that allows us the liberty we enjoy.

Importantly, you also can’t be tried by the victim of a crime. If you are accused of stealing from someone, that person cannot serve on the jury, nor can anyone with an obvious bias. You have the right to a fair trial by a jury of your peers.

If we did not have these rights, then it would be all to easy for society to be manipulated by scaremongers and sociopaths, the idiotic and the greedy. One accusation, and you’d be finished. This is not a hypothetical. In our past, we tried people as being witches with no evidence, just an accusation. This has happened before.

Now, the media industry is in a difficult place. They’re making less money than they used to, and want to blame piracy for their failing business models, rather than adapt. That’s a whole deep dark hole of debate by itself, but is not what I want to talk about today.

No, I want to talk about the Digital Economy bill. As a way of stopping the perceived threat of piracy, the Digital Economy bill will give media companies the right to accuse people of copyright infringement and have them disconnected from the internet. Think about that for a second: the accuser gets to blame anyone they like and with no evidence of copyright infringement, have a punishment inflicted upon them.

No trial, no right to see the evidence against you and fight it. You’re presumed to be guilty. This is, of course, the opposite of how justice works at present. We’re basically putting justice into the hands of very large companies to protect their revenue in the way they see fit, whether they are right or wrong. We’re handing liberties over to commercial interests for no benefits.

To me, that is very wrong and I hope you join me in signing the petition to stop this very wrong policy.

For more views, Open Rights Group have a great site up called Three Strikes.

As someone working in technology, I’m faced with a fairly moving landscape. The number of new technologies and ideas that pass through my domain of interest make is so that the skills that I had yesterday might not be useful today, and are probably going to start looking silly tomorrow.

A necessary outcome of that is that technologists rely a great deal on different forms of training material, from full-on seminars to simple tutorials and APIs. It strikes me that a great amount of this material, perhaps the majority, is terrible; lacking the ability to convey meaningful lessons to the reader.

Ignoring the material which is underdeveloped or simply inaccurate, my experience tells me that the next worse kind of material is that which runs through a series of steps: do x, do y, do z, you’re done. While this is certainly better than no material at all, it doesn’t help build any understanding, and that’s the key to any successful tutorial. If you build understanding, you’re doing a much better job.

Rather than simply run through steps, take the time and patience to indicate the goals. What will each step achieve, how exactly does it achieve that goal, and what other outcomes are there in slightly different circumstances? Each step should be there to help build understanding of your domain (by which I mean the fundamental components and ideas underpinning your subject matter), and in doing so ensures that the reader will be able to reason about your domain for themselves much earlier.

An extraordinarily good example of this is something like the Spring Framework manual. Each section introduces concepts with worked examples, alternatives, and consequences. The outcome is that given a small amount of time working with Spring you can fairly well reason about a new class that you’ve never encountered.

Always build on the domain understanding, always underline core concepts and always teach underlying principles, rather than simply stating steps.

A while ago now, I was stood behind two women at a bus stop. I wasn’t particularly listening in, but being that close meant I couldn’t avoid hearing what was being said. The first asked the other if she had seen a movie that had just been released yet, perhaps a week earlier. The other enthusiastically responded, “I’ve seen it seven times!”

Now, there’s absolutely nothing wrong with seeing a movie twice in a short space of time, particularly if you really enjoyed it. I can imagine seeing something three times over the few weeks of its release if it’s either particularly good or perplexing, but seven times? That’s just a failure of imagination.

Appreciation of cinema, as with any medium, is best enjoyed over time, allowing the passage of time and changes of context to enrich it and take your enjoyment in new directions, or to see it as something of its time. That’s true of music, art, tv, sport etc. Just about any hobby is best enjoyed in perspective.

An uber-obsessive, single-focus like that is almost childish; the attitude that seeing a two hour movie seven times in roughly a week is a form of lamentable one-upmanship.

To anyone who thinks that seeing something seven times really is fine, I say watch something else. Watch something worse, if need be. Watch something completely different, or something that makes you uncomfortable. By taking in a greater variety of your chosen medium, your context — your very understanding — becomes richer. When you finally see that film again, you’ll be seeing it with a new perspective and that’s far more worthwhile than obsessively watching the same thing in the same context time and again.

A big problem for security in software is that users have learned over the years that upgrading software is painful. Trying to click through dozens of settings and configurations, to then have to stop what you’re doing for an operating system restart has had the outcome of making upgrades a nuisance for most users. They avoid it.

In recent years, I’ve found that web-based upgrades have become less and less painful. WordPress, for example, is incredibly easy to upgrade these days. At first the single Subversion update command was a big improvement over the 5-7 step process. Now, it’s a single-click from your WordPress dashboard to upgrade, from downloading the update to installing it and running any necessary upgrade routines.

One-click. That’s how it should be. When you get one-click upgrades, then it becomes the default thing to do rather than the deferred thing. This benefits everyone.

That’s why I still hate upgrading vBulletin, the forum software that is abominable to upgrade. After having to upload the new version yourself (“upload a, b and C, but not d”), you have to click through dozens of screens to actually install it. If you’ve let it lapse more than a few minor version, and you will given the pain involved in upgrading, then you’ll have to do each and every incremental upgrade, one after the other.

The most annoying thing is that there is no interaction required here. You’re essentially clicking “next” a few dozen times. You know what? Software can hide this fact and just keep plowing on until it hits an issue (in which case it can let you know) or is finished.

Yes, it’s a commercial piece of software, but that’s no excuse. There are plenty of ways of allowing an upgrade automatically, after performing a license check. OAuth, for example, could be used to make this problem go away.

Instead, we have a terrible user experience: an upgrade that needlessly takes away administrator time from doing something else. Try harder, vBulletin.