

Simplicity is Complicated - laktek
http://avdi.org/devblog/2009/10/29/simplicity-is-complicated/

======
aristus
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.

------
phugoid
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.

------
suprgeek
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.

------
jamesbritt
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."

------
bajsejohannes
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.

------
DavidSJ
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?

------
lg
don't need the & before :+

~~~
avdi
Heh. I love that you can publish dozens of technical language-tips articles in
relative obscurity, then have one purely philosophical post shoot up reddit
and HN - and all the language lawyers come out and quibble about the code
samples!

Not that I'm complaining, mind you, I actually learned something from this
comment. Thanks!

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

