However, a recent review of my book, The Book Of Ruby, by Peter Cooper, contains a few assertions and omissions that I think are misleading and I’d like to take the opportunity to correct these. Peter has also made one or two statements that seem to have been inserted for humorous effect at the expense of accuracy.
I should first make it clear that Peter are I not unfamiliar to one another. While we have never met, we have, over the years, exchanged dozens of emails on a variety of topics: Ruby in general, my company’s software, the business of technical writing and Peter’s own Ruby book, ‘Beginning Ruby’. Peter once recommended my Little Book Of Ruby as a “cool” eBook. In 2007, he emailed me to ask for my endorsement of his book on Amazon and, as I liked the book, I was happy to provide one.
His principal objection to my book is that I do not code in the style preferred some other Ruby coders. Ruby is a language which has a broad variety of syntactical constructs many of which do, more or less, the same things. Some Ruby coders (particularly those who refer to themselves as ‘members of the Ruby Community’ or ‘Rubyists’) choose to adopt a shared set of conventions – for example, by restricting their use of certain constructs and adopting a similar set of naming and indenting rules. Ruby doesn’t enforce this. They’ve just chosen to do it. The end result is what they term the ‘Ruby idiom’. I have nothing against the Ruby idiom. It’s not an idiom I personally like but if other people do, that’s fine by me. I’ve previously explained my approach to style issues and I won’t repeat that here.
Style Wars
In order to persuade the reader just how wrong I am, Peter chooses some excerpts from my book that appear to show a horribly inconsistent coding style. These are his first two examples:
puts 'hello world' # on page 1
puts( "Hello #{name}" ) # on page 2
This certainly makes it look as though I must have had a brainstorm between pages 1 and 2. What Peter fails to remark upon is, first, that the example on page 2 is a fragment of this larger example:
print( 'Enter your name: ' )
name = gets()
puts( "Hello #{name}" )
And, vitally, it is followed by this explanation:
Although this is still very simple, a few important details need to be explained. First, notice that I’ve used print rather than puts to display the prompt. This is because puts adds a line feed at the end of the printed string, whereas print does not; in this case, I want the cursor to remain on the same line as the prompt.
On the next line, I use gets() to read in a string when the user presses ENTER. This string is assigned to the variable name. I have not predeclared this variable, nor have I specified its type. In Ruby, you can create variables as and when you need them, and the interpreter “infers” their types. In the example, I have assigned a string to name so Ruby knows that the type of the name variable must be a string.
Incidentally, the parentheses following gets() are optional, as are the parentheses enclosing the strings after print and puts; the code would run just the same if you removed them. However, parentheses can help resolve ambiguities, and in some cases, the interpreter will warn you if you omit them.
Peter then has a big boxout showing that the number of spaces in my indentation varies from 1 to 6. While I am impressed that he’s spent the time counting the spaces, I am surprised that he has not recognised the fact that code blocks are frequently substantially reformatted in the process of designing and laying out a book. In real life, my habit is to let my IDE (Ruby In Steel) take care of indentation using auto-indenting and auto-reformatting. When publishing a book, I am happy to let the book designer take care of the finer points of code formatting. Since tab-spacing is not significant in Ruby (unlike in Python), this has no effect on code behaviour but it does make the book look nicer.
The Joy Of Parentheses
To hammer home his dislike of my use of parentheses, Peter puts in a programming joke: “if you like Lisp you’ll love this book because there are parentheses almost everywhere.” Let me correct that: if you like Lisp you probably won’t love this book because there really aren’t parentheses “almost everywhere”. Still, I wouldn’t normally object to a joke; apart from the fact that, for the sake of his joke, Peter omits my explanation. In fact, I have many explanations for my use of parentheses in this book. Parentheses even have their own index entry so my explanations are easy to find. I’m surprised that Peter did not think it useful to quote one or two of them. Here are a few examples from the Book to fill in the gaps:
(page 85 – discussion of Ruby’s two alternative styles of Boolean operators)
Be careful, though: The two sets of operators aren’t completely interchangeable. For one thing, they have different precedence, which means that when multiple operators are used in a single test, the parts of the test may be evaluated in different orders depending on which operators you use.... As a general principle, you would do well to decide which set of operators you prefer—stick to them and use parentheses to avoid ambiguity.
(page 137 – methods and local variables)
Methods may share the same name as local variables. For example, you might have a variable called name and a method called name. If it is your habit to call methods without parentheses, it may not be obvious whether you are referring to a method or a variable. Once again, parentheses avoid ambiguity.
Finally, there is this example, which Peter specifically highlights:
Is this an empty hash, or is it a block associated with the puts method?
puts{}.class
Frankly, I have to admit I don’t know the answer to that question, and I can’t get Ruby to tell me.
Peter comments: “This is the first time I’ve read a book that claims to delve into "secret inner workings" where the author admits that they don’t know the answer to a verifiable and straightforward problem.”
I’m assuming Peter is giving reign to his humour again here. Because, while this may be a funny remark, it is not an accurate commentary on what I have actually written. The point of the example above is that curly braces are used to delimit two quite different Ruby constructs: blocks and hashes. At first sight, a programmer coming to Ruby may not be able to tell whether a set of empty curly braces is a block or a hash and the normal way of determining the class of an object (with its class method) is not useful. Peter once again omits my explanation, so let me append it here. This is the passage in the book that follows the above example:
print{}.class
Once again, this prints nothing at all in Ruby 1.9, but in Ruby 1.8 it displays nil (not, you will notice, the actual class of nil, which is NilClass, but nil itself). If you find all this confusing (as I do!), just remember that this can all be clarified by the judicious use of parentheses:
print( {}.class ) #<= Hash
The point being made is that the use of parentheses makes the meaning of your code explicit, clear and unambiguous. Without parentheses, I suggest that it is not. But Peter’s selective quotation makes it sound as though I have, for some inexplicable reason, written some random bit of code on a whim and then scratched my head and (presumably) muttered to myself, “Duh, well blow me down, I just can’t figure this out.” So while Peter’s version may be funnier than mine, it is not a fair characterisation of what I have actually written.
Format’s Last Theorem
Throughout his review, Peter principally objects to code formatting preferences such as the fact that I place block arguments on a new line. This, he seems to feel, is a major crime.
Look, I know that programmers get very passionate about code formatting. I’ve had plenty of arguments about formatting with colleagues writing in other languages (oh, the happy hours we’ve spent debating whether an opening curly brace in C# should go on the same line as the code preceding it or on a new line!) but this is not a matter that we elevate to the realms of an inviolable Truth. As a professional developer, I have more important things to do than debate whether “my idiom is better than your idiom”. It’s a personal preference, that’s all. As it happens, the chief architect of our IDEs likes his curly-brackets on the same line so that’s the convention we adopt. Microsoft generally prefers curly brackets on a newline. If I worked for Microsoft, no doubt that’s the convention I’d adopt. Either way, it’s not a matter I’ll lose sleep over. I get the impression that some Ruby programmers do pass sleepless nights over these kinds of things, however...
In writing The Book Of Ruby, I am principally addressing people (like me) who feel there are more fundamental issues to good programming than the precise placement of underscores in identifier names or the placement of newlines. There are lots, and lots of Ruby books that will tell you all about the ‘best’ use of camel case and snake case and how many spaces to indent by, and if you think that’s hugely important then The Book Of Ruby is most definitely not for you. If you want to navigate the gnarly highways and byways of Ruby and learn how to write defensively in order to avoid falling into a few gaping bear-traps, then The Book Of Ruby probably is the book for you.
Add
to del.icio.us