4 ms·

Simplicity is Complicated

28 points by laktek 17y ago

aristus 17y 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.
DavidSJ 17y 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?
lg 17y ago
don't need the & before :+
- bodhi 17y 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 17y 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 17y ago
But see also: http://news.ycombinator.com/item?id=289020 http://news.ycombinator.com/item?id=289020 and http://www.infoq.com/interviews/katz-merb 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 17y ago
edward de bono has already hit this nail on the head http://www.amazon.com/Simplicity-Edward-Bono/dp/0140258396 http://www.amazon.com/Simplicity-Edward-Bono/dp/0140258396
suprgeek 17y 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.
bajsejohannes 17y ago
This reminds me of one of Dave Thomas' Code Katas (http://codekata.pragprog.com/2007/01/kata_eight_conf.html 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 17y 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.

28 points by laktek 17y 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.

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

lg 17y ago

don't need the & before :+

bodhi 17y 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 17y 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 17y ago

But see also: http://news.ycombinator.com/item?id=289020 http://news.ycombinator.com/item?id=289020 and http://www.infoq.com/interviews/katz-merb 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 17y ago

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

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

bajsejohannes 17y ago

This reminds me of one of Dave Thomas' Code Katas (http://codekata.pragprog.com/2007/01/kata_eight_conf.html 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 17y 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.