Simplicity is Complicated

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

by laktek • 17 years ago

28 10 17 years ago

aristus• 17 years ago

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.

lg• 17 years ago

don't need the & before :+

bodhi• 17 years ago

Huh! learn something new everyday. From `ri Enumerable#inject`

> If you specify a symbol ... each element will be passed to the named method of _memo_

Also, the `sum = ` part isn't really needed either.

"Fore!"

avdi• 17 years ago

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!

jamesbritt• 17 years ago

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

haydenchambers• 17 years ago

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

suprgeek• 17 years ago

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.

DavidSJ• 17 years ago

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?

bajsejohannes• 17 years ago

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.

phugoid• 17 years ago

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 is Complicated

Related Stories