Lightning Talk: In Defense of Unless

Ruby

Spike Ilacqua

@spikex

#ruby

#code-quality

#programming-languages

#software-design

#lightning-talks

Lightning Talk: In Defense of Unless

by Spike Ilacqua

In the talk titled "In Defense of Unless," presented by Spike Ilacqua at the Rocky Mountain Ruby conference in 2011, the speaker advocates for the use of the word "unless" in programming and language. He addresses common criticisms of "unless," which typically fall into two categories.

Criticism of Redundancy: The first group believes that "unless" is simply redundant when compared to "if not". Ilacqua refutes this claim by arguing that languages, including English, do not typically favor exact duplications of meaning.
Connection to Perl: The second criticism connects Ruby to Perl through the usage of "unless", with some developers expressing discomfort with this association.

Ilacqua illustrates the semantic differences between the phrases "if it's nice, we go to the park" and "unless it's nice, we'll go to the movies." While the first statement is neutral, the use of "unless" inherently implies a certain negativity, introducing a connotation that suggests an expectation of poor weather. He reiterates this point with other comparisons, such as between "if it rains, we'll go to the movies" versus "unless it rains, we'll go to the park."

Another critique he addresses is the belief that constructing sentences with "unless not" is invalid. Ilacqua counters this by presenting valid sentence structures that illustrate how both "if it's not raining, we'll go to the park" and "unless it's not raining, we'll go to the movies" can make sense, albeit with different nuances. He explains that while the latter may sound awkward, it's not incorrect.

Ultimately, Ilacqua emphasizes that the primary goal should be clarity and readability in code. He posits that if using "unless" enhances understanding and makes code or statements clearer, it should be embraced. Conversely, if it complicates understanding, it should be avoided. In conclusion, the talk champions thoughtful usage of language constructs to improve code readability, advocating for personal preference in their application as long as clarity is maintained during coding practices.

00:00:04.799 All right, so in a talk yesterday that will remain nameless, someone criticized the use of 'unless'. People are always dissing 'unless', and so I'm here to stand up for poor 'unless'. Wow! One person in the audience.

00:00:20.840 I think there are basically two kinds of people who dislike 'unless'. First, there are those who think it's just a useless duplication of 'if not'. Then, there are others who find it a painful reminder of Ruby's connection to Perl. For the first group, you're wrong.

00:00:42.680 Languages, especially English, but languages in general, don't favor duplication. You really have to work hard to find two things that mean exactly the same thing. For example, if you look for a word that refers to someone by themselves, you get all of these, which range from statements of fact to something somewhat pathetic or kind of heroic. They all have slightly different semantic meanings, and the same holds true for 'unless' versus 'if not'.

00:01:04.400 If you say 'if it's nice, we go to the park' versus 'unless it's nice, we'll go to the movies', the first statement is neutral: if it's nice, we're going to the park. The second statement implies a certain negativity, suggesting that it's probably not going to be nice. The same concept applies to the statement 'if it rains, we'll go to the movies' versus 'unless it rains, we'll go to the park'. It's the same kind of reasoning.

00:01:54.040 Another common complaint I hear is that 'you can't say unless not' – that it's somehow incorrect. 'Unless' is acceptable, but some argue that 'unless not' is never usable. For instance, 'if it's not raining, we'll go to the park' and 'unless it's not raining, we'll go to the movies' are both valid sentences. The latter might indicate a certain perspective on what we think the weather will be like, but it can also sound awkward.

00:02:16.160 For example, 'if it's not nice, we'll go to the movies' sounds fine, while 'unless it's not nice, we'll go to the park' can feel a little awkward. It's worth noting that if you're negating a positive statement, using 'unless' can become a bit cumbersome, whereas negating a negative statement can work quite well.

00:02:41.159 The key is how it reads: does it make your code more understandable? If using 'unless' helps convey information clearer, then you should use it. There were several discussions yesterday about how to make code easier to intuit and improve readability. Does using 'unless' enhance readability? If so, then use it; if it makes things confusing, then don't.

Spike Ilacqua

@spikex

Rocky Mountain Ruby 2011