Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jesseduffield.com

Post reply on HN
Print view View original

251–260 of 326 posts

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

#251

Post by gpvos »

TomSwirly wrote: post #109
gpvos wrote: post #68

Earlier quoted context omitted.

I only know `unless` from Perl, and it can make your code clearer if used sparingly. For example it allows you to express preconditions positively: die "You may only use port numbers 1024 and higher" unless $port >= 1024;

die "Port numbers below 1024 are forbidden" if $port is hardly unreadable spaghetti code.

Okay. Now compare:

    die "You may only use port numbers 1024 and higher"
        unless $port >= 1024 || is_root(current_uid());

    die "Port numbers 1024 are forbidden"
        if $port

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

#252

Post by lcnPylGDnU4H9OF »

8note wrote: post #246
dlkf wrote: 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…

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.

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

#255

Post by ravenstine »

8note wrote: post #250
ravenstine wrote: post #237

Earlier quoted context omitted.

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

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.

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

#257

Post by saghm »

shortcake27 wrote: post #62

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 don't pretend that other people will value tradeoffs the same as me, but it's a mindset I can't really imagine ever having. I'd rather be happy most of the time even if I know I'm going to be unhappy for short periods occasionally in the future, and I don't really think the slight efficiency gain in the uncommon case due to being used to not having nice features is going to outweigh the larger efficiency gain for the much more common case.

At the risk of straying entirely off-topic, I've seen this in non-professional contexts at times as well; I recently had a friend in an online game mention that he doesn't like to utilize a convenience feature that happens for a couple weeks each year as part of a special even because he would miss it too much the rest of the time. While I don't think the tradeoff is quite as obvious to me for this sort of thing, I feel like occasionally having a fun temporary addition is worth it just for the change of pace, and I'm generally able to adapt to the loss of a minor convenience relatively quickly after losing it. It seems sort of like a question of "maximizing peak happiness" versus "minimizing peak unhappiness" or even "maximizing average happiness"; I like having something to get excited about every now and then even if it leads to feeling blase about things for a bit later because I get bored if things stay the same for too long.

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

#258

Post by hosh »

nickelcitymario wrote: post #129

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

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.

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

#259

Post by hosh »

dlkf wrote: post #240
nickelcitymario wrote: post #129

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

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

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

#260

Post by hosh »

nickelcitymario wrote: post #162
bluedino wrote: post #155

Earlier quoted context omitted.

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?

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