I actually don’t KNOW “Who the heck is that?” I have an interesting practice with my illustrations. There are a few that I photograph, create or draw myself, but these are the minority. Most are pictures gathered from flickr, which people have chosen to license under a Creative Commons license that allows others to use it. You can identify these because clicking on the picture leads you to the original photographer’s site on flickr. In this case, I searched for a good photograph of someone pulling their hair out (preferably a woman since on my blog the “default” programmer is usually a woman). As it turns out, someone whose username is “dearbarbie” took an excellent picture of just that.

Precisely.. In one of my previous jobs, I was a junior maintenance developer. I had a project manager, who asked me to change something in the morning, and I completed it in the evening. He shouted at me asking why I took a day to modify not more than 20 lines of code.

I told him the story about an engineer who is asked to fix a machine in a factory. He spends a few hours investigating the machinery and marks the defective part with a chalk, asks the company to replace it, and sends a bill of 100. The company asks why 100 for a chalk mark. The engineer sends another bill – 1 for the chalk and 99 for knowing where to put the mark.

I guess he got the idea.. though I had to leave the company.

There are times when side-effects make life a whole lot easier. At the same time there are situations where side-effects can cause a whole lot of trouble.

As a general rule: eschew side-effects that you can do without, but don’t make things harder yourself by trying to make them easier.

The functional-programming ideology is very tantalizing, but it’s easily be taken to far. Not that I’m saying you’re guilty of this :).

I’ve done this in the past and it’s certainly not fun. I wouldn’t advocate that any programmer attempt to avoid side-effects completely. Not even Haskell programmers do that! Instead, they use handy dandy tricks like monads to keep them in check.

I had a REALLY difficult time writing this article, for two reasons. The first, was that it was difficult to come up with an example that was simple enough (short enough) to fit in the article. The second reason was that when I really dug into it, I discovered that I didn’t have a well-defined idea of just what I meant by code with “no side effects”.

I am now in the Justice Stewart state with regard to this: I know it when I see it. A simple setter method isn’t “side effects” (or at least not the kind that bothers me). A method called calculateRate() that updates the rate on an object is OK (but closer to the borderline). A method that loops through a list calling a function, but also caches some kind of total in an instance variable, that IS a “side effect”.

Certainly the second approach (without the instance variable) is DIFFERENT — the rest of the code would need to be different also. My claim is that IF the entire codebase were written this way, that it would be easier to maintain because the maintainer would have to “fully understand” a much smaller portion of the code in order to safely make the change.

Minimizing side effects can certainly be an advantage in some situations, but this doesn’t strike me as one of them. It hardly reduces the amount of work required in this example!

The claim that this is easier seems to hinge on the fact that callsites are better known (documented?) and hence easier to check. That sounds like it has very little to do with “the advantages of functional programming”.

We’ll ignore the potential performance penalty that results from doing this as I doubt it’s that important here.

Thanks for the interesting article, it was well written and entertaining, even if I don’t agree :).

May I recommend that your future illustrations include a caption. The immediate question I had was not “What did Michael write?” but “Who the heck is that?”

Roy