I found this talk by Rich Hickey pretty... well, wholesome. He does a good job of talking about design issues that I think would strike close to home for many of us at FunMobility, regardless of which project we're working on. ^_^ Watch it at your own leisure; I won't mind if you skip it. In fact, I don't want to distract you from your work. XD
_Summary_: The easiest system to build is often completely different from the simplest system to understand. This is because many of our tools tend to drive us toward complexity, either by making it easier for us to build it, or by making it easier for us to recover if something goes wrong. The tools are useful, but they're not a substitute for a well-conceived design. If we separate parts of the program so that they don't depend on each other, we can understand them well in isolation, and if we also make them similar to each other, we can understand them in groups. He goes into several examples that he hopes will illustrate how one might systematically apply this philosophy to individual cases that come up in practice.
_For some context, Rich Hickey is the designer of Clojure_, a JVM language whose goal in life is to be the basis for very modular JVM programs. He heavily favors functional programming and disfavors type systems, which makes him like lisp variants more than other languages. But in this talk, I think he still manages to talk about the underlying issues he cares about without straying too far into these particular details. This is probably because he's not recommending we use a particular tool, like Clojure. He's examining ways (well, one big vague way) to improve programs regardless of what tools we use for them.
Here's a followup to the talk. I listened to it, and aside from the main point, did not get much out of it. Of course, it may be because I was quite busy at the time and I don't work in the same kind of languages as Rich. Or not.
