Previously, we saw how just using functions in Ruby, we could create a lot of powerful code. Let’s continue the theme of “programming with constraints” and try to solve an actual problem. nil.

The following is an aimless journey through a degenerate form of Ruby, in an effort to learn a bit more about functional programming, simplicity, and API design.

Suppose that the only way we have to organize code in Ruby is to make lambdas, and the only way we have to structure data are arrays:

square = ->(x) { x * x }
square.(4) # => 16

person = ["Dave",:male]
print_person = ->((name,gender)) { 
  puts "#{name} is a #{gender}"
}
print_person.(person)

This is the most bare-bones essence of functional programming: all we have is functions. Let’s write some real-ish code this way and see how far we get before it starts becoming painful.

We all want better code. Rails creator David Heinemeier Hansson said that the only way to evaluate a code change is if the new code is “better” than the old. Of course, he didn’t define what he meant by “better”. At Scottish Ruby Conf, Dave Thomas said that good code is code that is easy to change. This is a bit more specific, but not really enough to give any real direction.

Let’s see if we can derive a real understanding of code quality.

In my Ruby style guide, I mention the preference for using Ruby’s tap:

When you must mutate an object before returning it, avoid creating intermediate objects and use tap:

I thought it might be interesting to expand on this.

Was reading the slides from Aaron Patterson’s Magma Rails talk and noticed some pretty innocuous Rails code that, upon further reflection is the beginning of disaster for a growing application. As many other Rubyists are beginning to realize, spreading your application logic across only models and controllers leads to a mess. Let’s look at the code, understand why it’s bad, and create a better version.

Yesterday, I tweeted:

x = Hash.new { |_,_|lambda {}}.tap { |hash|hash[:key] = lambda {}}x[attr].callFilthy?I kinda like it

— ❺➠ David Copeland (@davetron5000) May 15, 2012

This may seem crazy, but it’s a really just an enhanced use of what Steve McConnell, in “Code Complete”, describes as Table-Driven Methods. Let’s see what that has to do with my crazy Hash construct.

I really enjoyed reading Jesse Storimer’s recent post, 4 Months of ebook Sales, about the sales of his book “Working with Unix Processes”. His feelings echo my own regarding my book, “Build Awesome Command-Line Applications in Ruby”:

I’m ecstatic with the results so far, but I have no idea how they compare.

Our books complement each other quite well, and came out around the same time. He wrote his largely on his own, going the self-publishing route, while I wrote mine with the Pragmatic Programmers. I thought I’d write a similar piece from my experience going the “traditional” route.