Hacker News Reader

Comment by nickelcitymario | Hacker News Reader

I'd consider myself a writer more than a developer, but I've been working in Rails for over 15 years, and one of my absolute favourite things is "unless".

Why? Because it allows you to express yourself more elegantly.

The click-bait title is misleading. It's meant to ridicule "unless", but actually achieves the opposite.

If you were to write the title of the post as code, it would be:

  unless !ruby_dev
    read article
  end

That would be a terrible use of "unless"! That should clearly say "if ruby_dev", not "unless !ruby_dev".

But what if you wanted to write an article meant for anyone other than ruby developers?

Which of the following is better?

  if !ruby_dev

  unless ruby_dev

Both work, but I consider the second option more elegant. Just as I wouldn't verbally say "if you're not a ruby developer" rather than "unless you're a ruby developer".

Honestly, I don't see the issue. It's a style matter. Just use it properly. All language can be abused if you try hard enough.

View on HN

There’s a cost-benefit analysis here that you are refusing to do: Of the two variants you’ve posted, the first will click immediately with a generalist dev who doesn’t know Ruby. The second will have them reasoning out loud, and then reaching for the docs to double check that their common-sense intuitions are correct.

This is not a contrived example. I regularly find myself having to read some code in a language in which I am not proficient. Stuff like ’unless’ is such a pointless obstacle in these scenarios.

So ”elegance” doesn’t come free. The cost is a loss of transferable knowledge from other languages. Your intuition is that this cost is low relative to the benefit of ”elegance,” I have the opposite intuition. Why stray from such universal conventions in favour of one person’s subjective aesthetic preference?

That's a really powerful tool. I can force you to slow down an make sure that you the reader focus on one section of code I've written?

A statement that forces you to switch out of inaccurate skiming mode is insanely useful

I get your point, though it's also worth pointing out that it doesn't force anything. Admittedly, syntax highlighting will generally help but it's always possible that a skim simply misses the keyword.

Practically speaking, that's not how I know Ruby to be written. The convention I follow is to use `unless` when there is no `else` case and only when there is no negation in the expression.

It is not all about cost-benefit.

You say there is a difficult time transferring knowledge from other languages when they see the `unless`. That's fair.

My response to that is that, to idiomatically think in Ruby is write code that reads well, and `unless` fits that. Every language has an idiomatic way in which one thinks and reasons with the language. While there are principles that can be transferred over across languages, the way to think in that language does not necessarily transfer. The Ruby community has a heavy emphasis on creating embedded DSLs that seems natural enough to written English, and the Ruby community's style guide is written for that.

In contrast to Ruby, Python has idioms that seem to be the inverse of Ruby. The intuitions on what is good, idiomatic Ruby is counter-intuitive in Python. This even extends to the design of Ruby bundler vs. Python virtualenv/pip. As a long time Rubyist, Python rubs me the wrong way (what is intuitive in Python is counter-intuitive in Ruby) until I realized that I used to write that style of code a long time ago with Pascal.

This is a great comment. The language I use most is Python, and I am definitely biased toward its conventions. It's interesting to hear from the other side of the fence.

I want to suggest a slight reframing: instead of saying: "It is not all about cost-benefit," you could say "here is an addition to the 'benefits' column that hasn't been considered yet."

It's a totally reasonable argument; much better than "elegance." This was my main problem: that the critique of `unless` was much more plausible than the defence.

I agree that thinking in terms of this as additional benefits is an excellent way of thinking about this.

However, we don’t always make decisions purely on cost vs benefit. Some types of decisions, such as strategic thinking, involves unfair advantages. If cost-benefits are reasoned from a finite space in which one can find the optimal choice, unfair advantages cheats that, and operates on a potentially infinite space with imperfect information.

Not that I am saying Ruby or Python are unfair advantages :-) I’m just saying that cost-benefit is not the only way in which one can decide on something, and may not be appropriate for every situation. Being able to think in a language can potentially change how you think, and framing that as a benefit can be problematic.

I explored Ruby because I wanted to explore eloquence, semantics, and pattern languages (in the Christopher Alexander sense). I spent over ten years on it until I had my fill. Now I am exploring concurrency, reliability, uncertainty, self-healing and distributed systems — Elixir and Kubernetes. And while I still use Ruby in some tooling, it doesn’t give me the joy that Elixir does.

I have a long history of Python and it fits my brain well, but the last 7 or so years have been in Ruby shops. I still struggle with trying to write idiomatic Ruby sad to say.

I do like `unless` in Ruby, but only when it is the one liner form and the exception happens pretty rarely. The multi line form often takes a lot of effort to parse for me if it is more than a very simple expression.

Probably the biggest thing is where and what is being encapsulated. Ruby is inspired by Smalltalk. Objects sends messages to each other, as if the objects are autonomous. They can receive a message, but it is within the object’s discretion on how that is interpreted.

Python exposes those methods. What you see is what you get. Classes and objects are not considered as autonomous agents so much as data structures bound with functions that can operate on it.

More controversially than “unless” is Ruby’s way of calling an anonymous function. Almost every other language, if “f” is a function, you can call it with f(). In Ruby, an anonymous function is an object, and you call it by sending a message “.call()”; the shorthand for “call” being “f.()”. Everything is an object.

This trips up even polygots who like Ruby. But if your mind can shift in such a way where that is ever seen intuitive, then you’re probably well on your way to being able to think in Ruby. (Assuming someone _wants_ to think that way).

Personally, I don't think "readable by people that don't know the language" is a reasonable feature to optimize a language around.

And if you go on that direction, almost the everything on the language is a larger roadblock than an oddly placed conditional.

I never suggested we ”optimize the language around this feature.” I only suggested that it is a higher virtue than some user on HN’s subjective concept of ”elegance.”

What do you think is more important: the speed at which C programmers can navigate your code base, or one person’s subjective idea of ”elegance”?

"Elegance" can mean many things, some irrelevant, some very important. But the speed at which C programmers can navigate some non-C code is absolutely irrelevant.

Specifically about Ruby, with it's infinite levels of metaprograming and "you can even redefine the meaning of blank space" philosophy, it's not 'unless' that will stop anybody.

I wrote Ruby for years (for fun). I always had to stop and think twice about 'unless' and translate it into 'if not'.

Exactly the same here. I write Ruby for a living and use 'unless' where it makes sense or fits with existing code.

That said, when reading code, I often have to pause and mentally translate "unless" to "if not". This is especially true for more complex logic.

Elegant, yes. Additional mental overhead at times, certainly.

unless is one of those things I have to read 2-3 times and it totally bogs me down.

Interesting! I wouldn't want to argue against your experience.

I do wonder if it's an issue of "unless" being misused? Programmers using it just for fun rather than considering whether it's the best choice in context?

I feel like I have read if statements so many times that I have fast pattern matching circuits in my brain for them.

When I come across an `unless`, I can't use them; I have to come back out into "conscious reading" mode, or something like that. Makes me crazy.

That makes sense!

I'm a recovering rubyist (actually I still love ruby, just never get to write it anymore). The only times I felt `unless` was truly more readable than `if !something` was when it was used in the conditional suffix form like

    do_something unless already_done?

This is the poster child use case for "unless", IMHO.

Anything else (at least for me) is more difficult to read, it's probably due to being exposed to all thos other languages that do not have that syntactic construct. Using C syntax conditionals feels more natural to me, but again this is all opinionated.

do_something if not already_done?

Problem with so much syntactic sugar is you need to retain/recall the semantics of the vocabulary. As a polyglot programmer who doesn't write much code anymore, it slows me down.

Same here. I can handle chaining conditions and narrowing things down, but once there's a De Morgan's filter on the thing, there's just too much state to juggle because what's in front of my eyes is not a refresher for what I actually need to remember ("ok, it says `n < 0`…(De Morgan filter)…n is positive" is too much IMO).

That said, I feel it's really down to double+ negation being hard to handle. `if` with a single negation is fine; `unless` is automatically a negation, so you're just off to a bad start on that front. I feel like the only viable use is in a case like Rust's `let … else { diverge }` where anything that fails the condition is guaranteed to diverge (typically, return) and I can just ignore it when reading the overall codeflow. But Ruby mixes that up and does `diverge unless …` which puts the diverging part "up front" and "in the way" for such readings.

Man, I feel like you hit the nail on the head here... this is definitely the best way I could think to articulate why `unless` throws me off so much.

Weirdly, Ruby was one of the first languages I learned early in my career, and at the time I had no problem with `unless`. But after years of experience with other languages, I similarly feel that `if` statements now trigger the fast pattern matching circuits in my brain, while `unless` makes me do a double-take and basically translate it into `if not`

At first I thought I was just becoming dumber with age, but I like your explanation better :P

Also as a non-native English speaker, unless always makes me do a double take. It is not a word that naturally translates in my head, but that might just be me.

I think it is also an issue of familiarity with English. Not all developers are fluent in English.

In Ruby (and Crystal), I tend to use `unless` for guards at the top of the method, or returns. These are typically `return foo unless baz`.

When I write Elixir, `unless` gets awkward in a functional style of programming, and Elixir has guard clauses and pattern matching. I pretty much never use `unless` in Elixir despite using it in Ruby for years.

Sometimes, I'll add extra methods with a negation in the name itself. So for example

  # instead of
  return "invalid" unless valid?
  return []        if empty?

  # I define invalid?() and do
  return "invalid" if invalid?
  return []        if empty?

Perl also had that delayed syntax check style as an option and I HATED IT.

THING if logical condition

Filter First is far better self-documentation: if condition THING

That's a matter of what fits better with the structure of how you think internally, and not necessarily that there is an objectively better way for self-documentation.

For example, I can totally see how imperative-first would mess up people with neurodivergant brains.

Tangent -- Ruby takes a lot of inspiration from Perl.

It works well in cases where you have an operation that consists of a certain sequence of statements, where one of the statements has to be omitted in a particular atypical situation. Instead of having interrupt the sequence with an if, you just tag the particular statement with the omitting condition at the end. That’s also when unless tends to be intuitive, because it suggests an atypical condition.

That is usually where I used it too.

When I started writing these as pipeline execution. Then I’ll use a maybe?() instead if the conditional does not need to depend on the result of a previous operation.

I have a similar problem with list.filterNot() in Kotlin

Just reread until you get it.

Admittedly, until (as the negation of while for loops) tends to be more straightforward to grasp than unless.

You've demonstrated that it is trivially replaced by 'if' and negation. I think that's almost the definition of inelegant.

Only if you definition of elegance is "please express yourself in as convoluted a way as possible, so as to minimize the number of words I need to know."

The truth is there is a balance in all languages. Nearly every word was invented to prevent having to say a string of other words to mean the same thing.

"Unless" is a single word to mean "If not". I consider that elegant.

However, some languages take this too far, in my opinion. German famously has a word for nearly everything. I'm not sure that's elegant, in that it requires learning a far greater number of words.

English has many words that I wouldn't consider elegant, simply because they're uncommon or convoluted. Never use a 10 dollar word when a 5 cent word will do.

So, if, like me and the ruby community, you prefer to optimize for developer happiness, "unless" is an elegant choice.

If you prefer to optimize for peak computing performance, if may be more computationally efficient use "if not".

But, _unless_ you're saying that you never use the word "unless" in everyday language, I think we can agree it's a good word that has good applications. I don't see why that wouldn't be true in programming.

The best example of vocabulary size and its tradeoffs this is the Guy Steele talk "Growing a Language". One of the best talks ever given.

Unconscious clarity trumps literary fluidity when reading code.

> German famously has a word for nearly everything. I'm not sure that's elegant, in that it requires learning a far greater number of words.

That's not quite how it works though, right? Compound words are exactly that, combining two or more words to narrow down the meaning, without having to invent a new word. It's almost like "if not" vs "unless"...

Correct. The chief difference between English and German in this respect is the use of spaces (and what is considered a word). In German, you can basically drop the spaces from a noun phrase and call it a word, but it's basically a low-consequence surface syntax difference.

Side note: ancient Greek didn't use spaces, and many other languages (Thai and Written Chinese are the ones with which I'm most familiar) either don't use spaces or make spaces optional. The distinction between a phrase and a word gets a bit blurry at times, and I find the distinction is seldom useful, particularly when making comparisons across languages.

Fascinating! I had no idea. I stand by my main point, but perhaps German wasn't a good example. It's just the one that comes up all the time when people say "Did you know X language has a word for Y?", it's almost always German. Now I know why!

It's Ruby though, where Array has "size", "length", and "count", all of which are equivalent. The programmer chooses which one they prefer based on the context or their style or the phase of the moon.

Ruby inherits the Perl philosophy of "There's more than one way to do it". Compare with Python, and its "There should be one — and preferably only one — obvious way to do it."

It's true that it makes the compiler less elegant, but Ruby optimizes for the programmer at the expense of the compiler.

Equivalent in output but not in implementation / performance. Does that matter? Not usually, no, but it depends.

Not exactly the same. It's been a while, but if I recall, count takes a predicate block so you can do things like `numbers.count { |n| n.even? }`

It can also take an argument and will then return the count of the number of items which compares equal to the argument.

"count" is only equivalent to "length" and "size" when called with no argument and no block, and should be slower for that case (it includes a comparison of arity and a call to rb_block_given_p() in MRI before it returns the array length).

Negation makes code harder to read and understand.

I'm getting the impression that this is not universally true. It's true for me. I find the word "unless" helpful when it eliminates double negatives.

But there are enough people on this thread who feel differently that it makes me wonder if maybe we're wrong. If code is meant to be read and understood by all, and if "unless" is confusing to a large number of people, maybe those of us who like it should knock it off.

I do find it more elegant and easier to read, but maybe you and I can process double negatives easier than the anti-unless crowd are able to process "unless" logic.

If that's the case, I'd be willing to sacrifice my preference for "unless" for the greater good.

> double negatives

Could you give an example of a double negative in this case?

I ask because using "if" does not lend itself to double negatives in my experience, but just thinking about "unless" I see double negatives being an issue (since unless is already negating the operand).

Maybe he means unless this and|or|xor that. That's what I use it for rather than negate every paraneter.

People are different, so different things click with how they think.

I would likely not be a programmer if it weren’t for Ruby and it doing things different.

I had tried to learn programming for years (JavaScript, Python, Java, C#), none of it stuck or progressed beyond following tutorials and one of the things I had serious issues with was negation.

Then I came across Ruby and it just kinda clicked into place like no other language had. With Ruby I was able to do my own things within a month.

Now I don’t really have a problem picking up other languages anymore. But there’s others out there right now struggling to learn programming and there should be as many programming languages doing things different as possible to increase the chance that they come across one that is obvious for the way they think.

This idea of there should only be one way of doing things is poison in my opinion.

Sometimes adding a temporary boolean variable is a good way to resolve a double (or single) negative.

Unless has negation built in.

Which is why unless is such a hard concept for people to grasp, not just in code, but also in regular English.

At least the "if not" makes the negation explicit, which can then be easily eliminated using several different techniques (early return, swap with the else condition) if the negation is confusing enough.

However, "unless" necessarily includes negation because that's how the word is defined.

> Which is why unless is such a hard concept for people to grasp, not just in code, but also in regular English.

This is the first I've heard about this confusion over the word "unless" in English.

In spoken English I do notice that most often the "unless" comes after a statement. Example: "I'll be there on time, unless the bus is late." That is more clear (to me) than "I'll be there on time, if the bus is not late." Maybe not by coincidence, I tend to like "unless" when it follows the action in in Ruby code, too.

A for can be replaced by a while and a jump, that does not make it more or less elegant.

IMHO, something ‶elegant″ in programming is not something that can't be built form something else (or we will all end up in writing only CMOVs), but something that conveys the meaning of its author precisely and concisely – which makes it inherently subjective. I'm in the `unless` team, I can perfectly understand if you are in the `no unless` team, but this argument does not make a lot of sense.

The `for` is a very ergonomic syntax to mapping a computation to every element of a sequence. The `while` does a really different thing, it's not about sequences at all, but about checking some bit of mutable state repeatedly.

> The `for` is a very ergonomic syntax to mapping a computation to every element of a sequence.

The very ergonomic solution to map a computation to every element of a sequence is `map`. In this case, `for` is filled with bookkeeping that does not matter.

I edited out "syntax sugar" that was in the post initially.

Also, the `for` operator definitely predates the `map` function. Some people also prefer `map` to be more or less pure and expect it to return a usable list; `for ` has no such expectation, it e.g. may consist solely in printing elements.

> Also, the `for` operator definitely predates the `map` function

And `CAS/Compare Accumulator with Storage` definitely predates `if`, still you are most probably using the latter.

Note that I said 'trivially'. The structure and meaning of an 'unless' construction is the same as 'if', adding or removing only a negation. Using 'while' and a jump to construct a loop is much more expressively distant from 'for'.

One of the hallmarks of Ruby is a full embrace of the notion of There's More Than One Way To Do It. Generations of developers around the world have seen this as being a core part of Ruby's elegance—at least to their minds (myself included).

Go to the store and get milk, unless we already have some.

Go to the store and get milk, if not we already have some.

By the same token, using until instead of while and negation would be inelegant, but I think until is less of a stumble block than unless.

In lisp, "unless" is a great way to signal that there will not be a dual branch. Similarly, they have "when" for the positive case only. They also have the advantage of not needing a "progn" segment if you want to do more than 1 thing on the case that they are "true".

I confess at first I thought they were somewhat superfluous, but they are more readable now that I'm used to them. Completely agreed on it being stylistic, mainly.

For me honestly it's one of the (many) things I dislike the most about Ruby.

Sure, I understand the "elegant" aspect, two symbols are shortened to one (although I'd argue that's not that important when it comes to clarity and legibility).

But every time I read "unless" in code it's quite jarring. I have to consciously translate it to "if not", and even then seeing the "unless" keeps tripping me off, perhaps because it's awkward in English to start a sentence out of the blue with "unless".

It's a matter of taste, but I tend to agree that the more features or constructs a language has, no matter how terse or convenient, the more unnecessary complexity is generated by using that language.

The `unless` keyword makes the interpreter slightly more complicated and is another piece of language the human brain needs to recognize. It may seem inconsequential, but grains of sand make a hill, as they say.

My ideal language would leave out pretty much anything that can be achieved with more basic constructs. It would of course have if-else, and leave out `unless`, but there would also be no switch statements or ternaries. Branching must be done with if-else or by looking up a value in a hash. No `for` or `while` loops because a simple `loop` construct with `continue` and `break` statements can do everything that `for` and `while` could do in other languages. No classes or inheritance because they're magical and they can be effectively simulated by the end developer if that's what they really want.

What I think would be really cool is to have a language with a syntax like Ruby but with only the most basic of programming language constructs.

Many language implementations internally translate source into a simplified de-sugared dialect as you describe as an early compilation step. I believe both ghc and rustc currently do this.

Though, I think it's rare to expand a pattern match/switch into an if-else tree, and much more common to expand an if-else into a 2-way pattern match/switch.

If you're really keen on such a language, you could fairly easily implement such a language as a pre-commit hook source code re-formatter so that all of the source in your repository is in your favorite language subset.

Why bother with loop, continue, and break when you can have a more generic if+goto that can handle all the cases?

You can simulate the loop behaviour if that's what you really want

I've thought about that, but that's closer to the metal than I prefer and I think it's not beneficial for less experienced programmers.

Structured programming is, I believe, a good idea for the vast majority of use cases. Though one can technically use structured programming while using goto, encouraging goto can therefore allow programmers to go down a path that is counterproductive. It's basically the opposite end of the spectrum from OOP where encouragement of rampant objectiveness and inheritance makes programmers write code that is way too complicated.

There's absolutely a place for goto. I once made a "language" (actually YAML) specifically for developing for the Amazon Alexa platform, and it used something similar to goto called "go to scene" and "go to random". For that sort of thing, goto can be much more practical and even easier to reason about than "better" constructs in general purpose high-level programming languages. It's just not something I would consider appropriate for the kind of language I am proposing, though I still ponder on it.

I have problems with 'unless' even in plain English text. I'm pretty good at English, I live in the USA, but I was not born here and my native language does not have a word for 'unless' (you have to use 3 words to express that idea!). I love Ruby, but the 'if' variation always get immediately parsed by my brain, while the 'unless' variation requires many seconds of thinking.

How about if you could write except if instead of unless?

Nothing will ever come close to "if not" due to the decades of experience I have reading it everywhere.

Came here to say this. If you don't like it, don't use it, but it sure does seem to make things easier for other developers (Ruby and not-Ruby-but-assigned-to-this project) to understand. I like it.

I treat the 'if' statement and the '!ruby_dev' conditional as separate entities. That allows thinking of the conditional alone in boolean logic terms, instead of having to consider the outside prefix statement too.

Therefore, coming from a computer science background I don't like 'unless'.

I could see that. Maybe it really is because I'm more of a writer than a computer scientist.

(For context: I dropped out of comp sci and took a job as a web dev ~18 years ago. Never looked back. But have ended up learning more about copywriting and marketing than computer science along the way.)

I'm a computer scientist and not much of a writer yet I prefer the use of "unless" over a negated "if". Then again, at the start of my career I used quite a bit of Perl and it was created by a linguist.

Doing Rails for half a year now and usually are pretty good at mental models.

I always have to stop at an unless because the double-negative is really hard to evaluate in the mind IMHO.

IMHO unless leads to unnecessary nesting. In your example, it reads like _most_ people are ruby dev. I try to keep the most-often excecuted flow as flat as possible (happy path) and just try to nest for additional/special cases. Unless just tries to do... different.

The unless is still harder for me to grok.

The if !ruby_dev (read as "if not ruby_dev") is so much easier.

Fascinating! I find it slightly easier to understand "unless" than "if not". But only oh-so slightly, and probably not enough to justify making it harder for others to read my code.

For some reason this one feels right to express with if-not to me too.

The one place I’ll often use unless is things like:

    return unless valid

    raise unless h.key?(k)

I think it might have something to do with:

1. How abundantly clear it is that the condition is a Boolean; and

2. The “false” condition indicating a “no work to do” situation.

I think I only use them for postfix return, break, next, and raise.

I agree with you. I think the complaints come down to "don't give people more confusing ways to write conditionals". And I agree with the complainers that it is easy to write conditionals in a confusing way, and that there are simply more confusing ways to write them when you can also use unless. But I think the problems come from not taking the time to make the conditional easy to parse, which is an issue whether or not you have unless. And it's not just trading if ! for unless (or if for unless !) -- sometimes it's "if valid" vs "unless !valid" vs "if !invalid" vs "unless invalid", depending whether it was easier to write the predicate for valid or for invalid. Even working in a language without unless, I frequently find myself encountering these difficulties, and I find that the only thing that helps is treating it like writing and deciding what logical progression will be the most helpful for the reader. What's most helpful for the reader won't always be to use unless, but sometimes it will, so it's nice to have the option.

“If you are [not]” serves a different function than “unless.”

“Unless” is a conjunction, and its presence creates a double negative with the end of the sentence making the sentence extra clunky (“unless you’re a Ruby dev, you shouldn’t read this article.”)

A few iterations later, we get to the correct syntax, “read this article if you’re a Ruby dev.”

'if !<something>' clicks instantly. for 'unless' I have to read out the statement in my head, and draw mental logic lines about what condition this is checking.

> Which of the following is better?

  if !ruby_dev

  unless ruby_dev

As a ruby dev of 5+ years, I still have an easier time with `if !ruby_dev`. I have to translate `unless` to `if !` every single time to grok something. Almost like an extra step in an algebraic expression being simplified.

Different taste I guess. I work in Python and always go out of my way to write "if thing is True" or "if thing is False" nowadays to make conditions clear and uniform.

Should I read the damn article or not? I still have no idea

That's how I see it as well. Also, if you need to tag on more conditions, convert it to an `if`

The `unless` is idiomatic to the Ruby way of thinking.

as a non-native speaker, unless requires additional time to parse than "if not"

Also note that unless itself contains another negative ( < medieval onlesse)

It's just easy to see if more than one conditions are evaluated:

if (!ruby_dev && cpp_dev)

unless (ruby_dev && !cpp_dev)

Nope. It's needless confusion. We're programmers who have stuff to do, and syntactic stuff like unless are not helpful.

if (true) and if not(true) is simple and elegant, and doesn't require any person on my team to stop their flow to puzzle out what the code is supposed to be doing at that point.

But inventing totally new languages even for billion dollar projects is totally fine?

You want a well-justified, inclusive, and consistent yet adaptable style when collaborating with people. It would be selfish to gatekeep a policy without regard for those principles.

"if" is almost always easier to reason with, "unless" can be elegant, but it's so often misused that it doesn't really matter

I agree entirely that it can be misused. I'm not sure how often it's misused versus used properly. But I don't see why I should give up a useful logic tool just because others don't know how to use it well?

Let me put it this way: Are there _any_ programming paradigms that don't get poorly used? We need to learn how to use our tools well, not reduce them to banality.

On this note: I’m sad ruby style guides generally ban “and” and “or”.

   raise(“a long error string”) unless valid

This reads much worse, when the string pushes the line near max width, than:

    valid or raise(“..

Of course it’s another idiom to learn but it’s not a difficult one when used simply.

That’s a very Perl idiom, did you previously write Perl?

No, I just think for all ruby is bought into these guard clauses, it's sad that we generally reject the feature that allows putting either the condition or the consequence first, depending on which reads better.

the 2nd form implicitly returns the value of valid if it's truthy and nil if it's falsey; the 1st form always returns nil

Indeed, but the return value of a guard clause shouldn't be important!

I used to work at a garage, and while an impact wrench can be the fastest way to put a tire back on a car, I eventually banned it entirely.

Everyone's lazy or overwhelmed at some point, and it made mistakes too easy to make (the problem is that it overtightens the lug nuts because the ease of use removes the proper physical feedback).

In situations where you don't have the bandwidth to perfectly educate everyone and enforce rules, sometimes it's easier to limit the toolset. A tire iron can be misused too, but it's a little harder.

Reply on news.ycombinator.com