Skip to content

Instantly share code, notes, and snippets.

@steveklabnik
Created February 13, 2012 19:12
Embed
What would you like to do?

You're right, I think, about there being an inverse relationship between power and readability in code.

I strongly, strongly disagree with this. Mostly because 'readability' is entirely subjective. For certain audiences, things can be more powerful and more readable at the same time.

For example, let's examine a case in Ruby, that also pertains to Haskell: Symbol#to_proc. A new Rubyist may write some code that looks like this:

[1,2,3,4,5].each {|number| number.to_s}

However, a more experienced Rubyist will write this code like this:

[1,2,3,4,5].each &:to_s

This is not a language feature, but a library method, called Symbol#to_proc. It's original implementation was created in Ruby on Rails, and looked like this:

class Symbol
  def to_proc
    Proc.new { |obj, *args| obj.send(self, *args) }
  end
end

After Ruby 1.9.1/1.8.7, this was included in Ruby's standard Symbol class, re-written in C for performance.

Anyway, this is a constant debate amongst people new to Ruby: they see this as incredibly not readable. However, to people from a Haskell background, or anyone well versed in a functional mindset, the Symbol#to_proc version tends to be more readable, because they've internalized the idea of mapping a function over a list. All of the ceremony of using an explicit block gets in the way. For someone not from this background, or not familiar with the pattern, the block makes it more readable.

So yes, without an audience in mind, I don't think 'power and readability are inversely related' is a statement that one can make.

@zackdouglas
Copy link

This isn't the proper forum for comments, but I've also never seen anyone use Gists for showing off Markdown, so:

Perhaps a stronger inverse correlation would be power:accessibility. I consider myself a fair distance behind your expertise in functional programming style, and while the &:fn notation makes sense, it's not necessarily the most intuitive for learners.

For instance, I would follow up in seeing this implementation with "Can I call a function not registered directly on the list item?"

@steveklabnik
Copy link
Author

@zackdouglas
Copy link

I think you're agreeing with my statement, but more callously recanting that all code has an audience, and occasionally you have to raise the barrier to entry with terseness in order to keep the higher concepts first in mind.

I consider learning a DSL's "magic" akin to learning another language, where the two become interchangeable when read. It was the same epiphany I had when grokking prototypal inheritance.

I suppose it boils down to this: Consider your audience when you write anything -- code, prose, whatever -- because someone else is bound to read it and they'd better understand.

@steveklabnik
Copy link
Author

Exactly. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment