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

301–310 of 326 posts

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

#301

Post by j33zusjuice »

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…

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

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

#302

Post by hosh »

layer8 wrote: post #285
mjevans wrote: post #262

Earlier quoted context omitted.

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

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.

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

#303

Post by hosh »

dlkf wrote: post #286
hosh wrote: post #259

Earlier quoted context omitted.

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…

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

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.

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

#304

Post by aqme28 »

soiler wrote: post #239
aqme28 wrote: post #93

Earlier quoted context omitted.

I love Ruby for this kind of stuff. You don't have to have arguments about which syntax you prefer, you can just use the one you prefer and let your coworkers use theirs. However, a lot of developers love very strict style guidelines. I've never understood why, but it's a discussion I get into very very often.

Hm, I have the exact opposite interpretation. This is exactly the kind of feature that leads to arguments. If `unless` didn't exist, what argument could people be having about using `if !`? In a shared codebase, I think there should be as few (equally effective) ways to express an idea as possible. (Obviously there can be more- and less-efficient ways to write a function; I'm referring only to style.) The more arbitr…

> In a shared codebase, I think there should be as few (equally effective) ways to express an idea as possible...The more arbitrary choices people have, the more time is wasted on choosing one.

I highly disagree! In my experience, forcing arbitrary style leads to so much more time wasted as people debate exactly which styles to enforce.

> But in a shared codebase, developers writing in different styles is a net negative on quality & readability. Spending time debating which style to prefer is a worthwhile, but unnecessary time sink

I disagree with this too. I have never found this type of style to be something that actually impacts readability and quality. If you using `if !` and I using `unless` is the problem with the codebase, that's not so bad.

I have to say, this is why I'm a huge fan of Python's black. It lets me write however I want, while you get to read my code in a consistent style.

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

#305

Post by nanny »

fl_ciq wrote: post #287
nanny wrote: post #171

Earlier quoted context omitted.

Lua, Elixir, Common Lisp, Scheme, Racket, Clojure. Most statically-typed languages don't let you evaluate 0 as a boolean. IMO, 0 is a value, and values should be truthy. 0 being falsy is only a wart from C.

Thanks for that, I had no idea. Do you know if zero is truthy in erlang? It makes sense for elixir (based on ruby) but I'm wondering if erlang is that way too.

>Do you know if zero is truthy in erlang?

I don't know off the top of my head, but I would assume that yes, zero is truthy in Erlang as well, since Elixir is fully compatible with it.

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

#306

Post by hosh »

antod wrote: post #291
hosh wrote: post #259

Earlier quoted context omitted.

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.

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

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

#307

Post by drewbug01 »

Alas, it seems I've missed my chance to discuss one of my favorite things: Ruby. If you're a latecomer to this submission like myself, here are three things to keep in mind as you read the replies:

- Many remarks concern the difficulty of understanding "unless" for those with a first language other than English. It may be interesting to note that Ruby was created in Japan, and that "unless" has been in the language since the very first release. [1]

- Matz has a very interesting and famous quote about the principle of least surprise: "it means the principle of least surprise after you learn Ruby very well." [2]

- Computers don't care how programs are structured. Businesses don't care how systems are architected. The canvas does not care how paint is applied. Software engineering is an art. [3]

---

1. You can verify this yourself - check `parse.y`: https://web.archive.org/web/20071109044522/http://eigenclass...

2. The rest of the quote is also wonderful: https://www.artima.com/articles/the-philosophy-of-ruby#part4

3. The article that contains this line has fundamentally altered how I view our profession: https://www.neversaw.us/2022/01/30/the-canvas-cares-not/

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

#308

Post by shakow »

nine_k wrote: post #264
shakow wrote: post #204

Earlier quoted context omitted.

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

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

#309

Post by Joker_vD »

jjgreen wrote: post #175
Joker_vD wrote: post #72

Earlier quoted context omitted.

The "logical negation" sign used to have the vertical line as long as "|", so e.g. "¬A" looked more like "‾|A" but fully vertically aligned with the letter. Sadly, this glyph fell out of usage in fonts in favour of "minus with cedilla/descender".

I'd always understood it came from Frege's Begriffsschrift , a small descender from a horizontal line (part of a larger diagram), so like a short wide T, then lost its right arm later. Would you have some examples? (a quick google images shows nothing like that ...)

It was definitely a thing in Soviet works on mathematical/symbolic logic. But here's an example from Curry [0]. As I said, it was mostly a stylistic choice.

[0] https://www.google.ru/books/edition/Foundations_of_Mathemati...

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

#310

Post by qubitcoder »

afandian wrote: post #271
marcosdumay wrote: post #266

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

Post reply on HN