Arc Forumnew | comments | leaders | submitlogin
6 points by akkartik 5289 days ago | link | parent

"I still think that the bug in akkartik code is a result of too complicated one liner."

I'll make 2 objections to that:

a) That particular case was not a bug, but a performance issue.

b) The response to bugs isn't a more verbose formulation. Verbosity has its own costs to pay. Patterns that you could see in a single screen can no longer fit side by side, which can cause their own bugs.

If one-liners are to be avoided, you could just replace the call to reduce in your example with an explicit loop. But that's a bad idea, right?

Imagine a program where "x += 1" should really be "x += 2". Saying "x += 2 // always make sure we're adding 2 to x." doesn't seem like the appropriate response. The appropriate response is practices like automated tests and 5 whys (http://en.wikipedia.org/wiki/5_Whys, http://www.startuplessonslearned.com/2008/11/five-whys.html)

---

Perhaps you're finding right-to-left hard to read. Stick with it; you'll find that it becomes easier to read with practice. Many of us started out with similar limitations. It's like learning to ride a bicycle; I can't explain why it was hard before and isn't anymore, but vast numbers of people had the same experience and you will very probably have it too. As you read more code you'll be able to read dense one-liners more easily. There is indeed a bound on how dense a line should be, but this example is nowhere near it.

Further reading: http://www.paulgraham.com/power.html, http://www.paulgraham.com/head.html, http://www.paulgraham.com/popular.html section 3 "Brevity"