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.
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
&:fnnotation 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?"