Keeping it Simple

I posted this on worse than failure's sidebar because I just had to share it, but I'm putting it here in my diary for keeps:

I'm a hack looking for a new job. Hack that I am, even I know that simplicity is a laudable goal in software development. I was quite amused to see one poster proudly declare, "Our software is among the most complex ever created". That is some accomplishment! Not sure how long google cache link will last.

This brings to mind some quotes from a couple luminaries:

• UNIX is simple. It just takes a genius to understand its simplicity - Dennis Ritchie
• There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. - C.A.R. Hoare
• Increasingly, people seem to misinterpret complexity as sophistication, which is baffling---the incomprehensible should cause suspicion rather than admiration. Possibly this trend results from a mistaken belief that using a somewhat mysterious device confers an aura of power on the user. - Niklaus Wirth
• The belief that complex systems require armies of designers and programmers is wrong. A system that is not understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not be built. - Niklaus Wirth
• Inside every large program, there is a small program trying to get out. - C.A.R. Hoare
  

I can imagine the laughter that would generated if I included as a bullet point on my resume, "My software is among the most complex ever created".

Object Oriented Programming and Functional Programming as inverse of each other

While listening to John Harrop on .NET Rocks!, I noted something he said which seems quite illuminating to me.

I'm going to paraphrase here, but this is my distillation. OO and FP are basically inverse to one another:

• OO takes a problem and breaks it down by actors. You end up portioning functionality into all the various methods of the classes. If a group of objects all need to implement the same function, you put that in an interface.
• FP takes a problem and breaks it down by actions. Then you model your actors (the class hierarchy from OO) with a single data type (as in a tree). You pattern match over the data, and functions do different things based on the match - the type of actor.

On oversimplification to be sure, but it sure seemed to turn on a light bulb in my head. BTW, I suspect that F# has a very bright future. I can foresee even 80%ers like me making use of it given a problem that lends itself to FP. Especially since it can play with other .NET assemblies written using traditional OO languages.

Iterative solution to Towers of Hanoi

When I was going through SICP, one of the early assignments was to come up with an iterative solution (rather than the traditional recursive one) to the classic Towers of Hanoi puzzle.

The first thing to understand (something I didn't before going through that chapter) is that "iterative" doesn't mean that it doesn't make use of recursive functions. A recursive solution is one that relies on the previous executions of some function; an iterative one does not. So an iterative solution can take the towers in any legal state and complete the puzzle (regardless of whether it makes recursive calls); a recursive one cannot. The challenge was to discover some local rule that would determine the next move.

It took me awhile to discover one. After examining the only other example I could find, I realize that mine is probably naive (story of my life). Nonetheless, I figured I'd post it since it does work and I would imagine may be of interest to someone else.

The rule is two-fold (Consider that the rings are numbered from smallest = 1 to largest = total count of rings):

1. Odd / even rings always travel in opposite directions. The direction each ring travels varies with the odd/even count of total rings. If you have four total rings, then:
• Odd rings: next move is always to the left (circling around to the other side when no more remain to the left).
• Even rings: next move is always to the right.
2. When deciding which piece to move next, scan the tops of each pile and move the largest ring which may legally move following the above rule.