What I learned from Erlang
When I began learning Erlang, the thing that intrigued me most is this wholesale rejection of the concept of "state", "side effects", or even "loops". As I got to thinking about it, the hardest programming problems I've encountered almost always had too much state (be it local state, object state, or global state), too many convoluted loops, too many special cases, too much spooky action-at-a-distance caused by side effects, and too much duplicated, inconsistent state.
Well, actually Erlang still has loops, cleverly hidden as tail-recursive functions, or else calls to map and foldl. And Erlang still has state -- in the form of a list of parameters that gets repeatedly passed to a tail-recursive function. It's impossible to avoid side-effects completely -- after all, programming is all about creating side effects. But minimization of side effects is a noble goal.
Same thing applies with other aspects of programming, like coupling or local state. A program that has zero coupling between its components is by definition a program that doesn't work. Still, we always endeavor to remove needless coupling where it can be found. I agree with Steve, Reg, even Ken Thompson who said that he doesn't care about the length of a procedure, as long as there aren't too many local variables or too many levels of indentation. In my designs, I try to minimize state (local, object, and global), side effects, if statements, loops, and dependencies. And I find myself replacing temps with queries at nearly every opportunity.
Object-oriented programming had a big impact in the 80s and 90s, in that it taught programmers how to partition and hide state in these little bloblets called "classes". But this was only a partial mitigation to the problem of exponentially exploding complexity. Functional programming goes one step further, and teaches programmers to totally remove unnecessary state. Functional programming is the real "extreme programming". It takes all these good ideas that people have known for the longest time, and turns each knob up to 11 on all of them.
If you haven't taught yourself a functional programming oriented language (e.g., Haskell, Lisp, Erlang, etc.), you should take any opportunity to do so. Maybe you'll never use whatever esoteric language you chose to learn, but it will give you another perspective on programming, and maybe even open up another world for you in some of these mixed-paradigm languages like C# and Ruby, which have all these features that you may not have ever used.
