Live data from Hacker News

Read this post ‘unless’ you’re not a Ruby developer

jesseduffield.com

201–210 of 326 posts

Re: Read this post ‘unless’ you’re not a Ruby developer

#201

Earlier quoted context omitted.

Indeed. I personally never fail to avoid not using "unless", unless there isn't a lack of extra conditions such that not refraining from instead using "if" wouldn't avoid not being less clear.

I'm not sure that making this sentence as obtuse as possible is a great idea to convey your point.

Making it as obtuse as possible was very likely the point.

Re: Read this post ‘unless’ you’re not a Ruby developer

#202

Earlier quoted context omitted.

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.

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

Re: Read this post ‘unless’ you’re not a Ruby developer

#203
post #165

Earlier quoted context omitted.

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

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 th…

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.

Re: Read this post ‘unless’ you’re not a Ruby developer

#204
post #203
post #165

Earlier quoted context omitted.

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 th…

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.

Re: Read this post ‘unless’ you’re not a Ruby developer

#205
post #194

Earlier quoted context omitted.

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?

Re: Read this post ‘unless’ you’re not a Ruby developer

#207

statement unless condition is a wonderful bit of syntactic sugar. It reads like natural English if the variable or method it is evaluating is named well. Yes, sometimes you have to refactor into a traditional if. Sometimes you make the conditional its own method (which you’d end up doing anyway, assuming it didn’t stop at two or three conditions.) These are light tasks as the project grows. Starting a line with unles…

>It reads like natural English That's a problem for those who learn it as a second language and have to translate "unless" to "if not" every single time.

Don’t you know the word after awhile? Ruby core and standard libraries have many English words in them that are harder to learn than basic one-syllable words on the level of “if not.”

Re: Read this post ‘unless’ you’re not a Ruby developer

#208

Earlier quoted context omitted.

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,…

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.

Re: Read this post ‘unless’ you’re not a Ruby developer

#209
post #22
post #15

Earlier quoted context omitted.

To be fair, Ruby inherited "unless" from Perl. And Perl literally has the opposite design principle, TIMTOWTDI or "there is more than one way to do it". I'm not arguing here -- I prefer the "one obvious way" principle. But you can design a beautiful programming language without regard for the long-term learnings of software engineering. I always liked Perl's "unless", and I always made sure to not abuse it with doubl…

Ruby is basically Perl++

Ruby is Perl 6

Re: Read this post ‘unless’ you’re not a Ruby developer

#210

I really don’t understand the author’s point about adding extra conditions. They admit that many people will find a single condition with `unless` more readable. They then complain that it becomes unreadable when adding another condition. OK, so swap it out for an `if` at that point. No one is forcing you to keep using `unless` if the requirements change. “You should use a suboptimal solution to cater for unknown fut…

Indeed. I personally never fail to avoid not using "unless", unless there isn't a lack of extra conditions such that not refraining from instead using "if" wouldn't avoid not being less clear.

SURGEON GENERAL'S WARNING: reading this sentence before consuming caffeine may cause significant brain damage
Post reply on HN