Live data from Hacker News

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

jesseduffield.com

291–300 of 326 posts

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

#291
post #259
post #240

Earlier quoted context omitted.

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

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

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.

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

#292

Earlier quoted context omitted.

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

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

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

#293
post #270

Earlier quoted context omitted.

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.

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

#294

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

[deleted]

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

#296

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…

The author's point is that conditions in code tend to add up. What may start as a simple single condition, may not remain that way a year later. Since there's always the possibility of a certain conditional becoming more complicated, it makes sense to opt for the equivalent solution that makes adding those additional conditions easier. The alternative is to change the keyword when you add those additional conditions,…

While I agree with the other comment re premature optimization, when using guard clauses you can also break up your conditions into multiple statements which is arguably the most readable solution. The author’s example could be written as:

  return unless valid_token
  return if expired?
This scales extremely well if you’re concerned about future conditions.

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

#297
post #257

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…

> “You should use a suboptimal solution to cater for unknown future requirements” is a terrible argument Not exactly the same, but over the years I've heard people argue against having super customized shell configurations (e.g. completions, prompts, highlighting) because they won't be available if you have to use a different environment (e.g. sshing into a temporary cloud server to debug something failing in CI). I…

As an analogy to your shell customization thing:

I switched from QWERTY to Dvorak a long time ago, a few years after learning to touch type. Does it make me more efficient on my own computer? Probably slightly -- Dvorak really is a well-designed keyboard layout, but it's impossible to know whether my WPM is any higher than it would've been on QWERTY. However, I make way more mistakes and type way more slowly whenever I sit down at a QWERTY keyboard. I had to re-learn how to touchtype QWERTY after switching to Dvorak, and my skill never got back to the same level. It also leads to extra inconvenience every time I lend my computer to someone else, install a new OS, etc.

I think this means my average typing speed (weighted average of the time spent at Dvorak keyboards + QWERTY keyboards) is probably flat or possibly lower than if I had just stuck with QWERTY. When combined with all the effort I spent learning Dvorak, re-learning QWERTY, and making many mistakes in the early years, I think my lifetime productivity is probably even lower. I don't recommend that people switch, even if I think Dvorak really is a better layout.

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

#298
post #35

Earlier quoted context omitted.

It's not pointless, it makes code read better. It's another option to have. It's not meant for every use case. It indicates you don't understand Ruby if you find yourself using an "unless" in a complex boolean operation. It's meant for simple cases like an inline return statement return unless User.exists(id=100)

God that's such a landmine when reading code. Seeing a return without an explicit change of scope... Why ? To save one line ? Yep that's why I hate ruby - worked on one mature codebase for a year and after seeing various such gems used across the project - from >10 devs - I'm confident I will never touch the language again.

Those are called Guard clauses and they are implement in plenty of systems.. this paradigm has nothing to do with "Ruby".

In any case, the Ruby community already has good guidelines on the "Unless" usage, there are few scenarios where they are useful but it's not like you find them everywhere in a codebase.

For example, we don't use "Unless" with "Else", or use Unless with negation (like the article), or use Unless in nested If statement, etc. Rubocop will catch many of these and warn you.

My point is that experienced engineers will use the language as it was intended to and not abuse its features.

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

#299
post #30

Earlier quoted context omitted.

Sadly `¬` never caught on. But I suppose being visually similar to `-` isn't much better.

If it's not a shift+ key on a popular keyboard layout, it's not going to gain widespread adoption in programming.

¬ is shift+` on the most common UK keyboard layout, but yeah, it would probably need to be popular in America.

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

#300
post #244

Earlier quoted context omitted.

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

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!
Post reply on HN