Simplicity is Complicated

Instead of "simple" it's likely they really mean something more like "elegant". Elegance can resemble simplicity because they are both small or appear easy to understand at first glance. To my mind, elegance also leverages deep principles and idiosyncrasies in its environment.

Iterating "by hand" in Ruby is simple in the way a homemade chair is simple. The second example is elegant because it actually takes advantage of the things that differentiate Ruby from Generic Imperative Language X.

Wow. I've often wished programming blogs were more polite, but God how it makes them boring.

"Some people like to wake up really early and use ternary operators. But some people much prefer to sleep in..." versus

"Get up at 5:00, drink your damned coffee and ask people interview questions about pointers or else you're stupid and lazy and you just don't care about your craft."

And then somebody comes along and says "wtf!?! you're the stupid lazy guy who doesn't even program anymore and obviously coffee brewed before 9:00 isn't fresh because the water in the pipes has been sitting there all night."

Now someone has to smash me down saying "Fool! Politeness and boringness are utterly orthogonal" ....

Edit: the code examples were great! by themselves, on a black background, they would have shocked and awed me.

Simplicity needs to looked at from a customer point of view. "Will this code make it simpler for the customer?" should be THE primary consideration. If we consider two equally valid choices (back-end code for example that is not exposed to customers) then the code that is easiest to maintain (or the code that is very easy to follow) is simplest. Think of the person maintaining your code as your customer. Too many people get suckered into writing "fancy" code, "elegant" code, "design pattern" code, what not. In my experience this practice almost always led to more issues than helped in any measurable way.

But see also: http://news.ycombinator.com/item?id=289020

and http://www.infoq.com/interviews/katz-merb

In particular, "It's just a bunch of things in Merb that we don't do. For instance, is like the classic one of Symbol#to_proc, which Rails does. Actually, Rails recently took out a bunch of use of it, because is 10 times slower on Ruby 1.86, so it's just the things that we don't do in Merb that give us a lot of performance right out the box."

This reminds me of one of Dave Thomas' Code Katas (http://codekata.pragprog.com/2007/01/kata_eight_conf.html), where one objective is to write some code as readable as possible. It turned out to be much less well defined than I thought when I started out.

Is it just me, or is his average_time_of_day missing a "/ times.length" at the end?

Also, why is he calling :to_time there but not in the iterative example?

don't need the & before :+

edward de bono has already hit this nail on the head http://www.amazon.com/Simplicity-Edward-Bono/dp/0140258396