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.

> 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!

Unconscious clarity trumps literary fluidity when reading code.

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.

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.

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).

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

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.

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'.

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.

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).

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.

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

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.

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.

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.