Live data from Hacker News

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

jesseduffield.com

51–60 of 326 posts

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

#51
post #44

Earlier quoted context omitted.

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.

If you're returning who cares about the scope? Are you saying visually you'd like to have indentation inside the if body? If that's the case there is also nothing stopping you in most languages from doing something as nasty as: a=1;b=2;c=3;d=a+b==c?4:5;return d

I do because return means end of scope. Except in your example it hides the fact that it's creating it's own scope.

I'm not arguing other languages can't produce bad code, just that ruby is particularly suited for it especially as number of developers working on code increases. I've seen people propose a linter to enforce consistency - but at that point I might as well chose a language with better design choices - plenty of alternatives these days.

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

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

I came to Ruby from Perl, and I love `unless`. One of the first things I do in any Lisp is build my own unless macro unless the dialect already has it :)

No post body was provided.

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

#53
It’s a bit awkward to grasp initially but personally I like it. I don’t wish it in all languages but it works in ruby. It especially works well in templates and checking collections.

Honestly, I find negative checks like `if !something` ugly, I would much rather check if the result is true than !true. The same with unless, I would prefer to check unless false than unless not false or unless !false

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

#54
post #39
post #11

I'm mildly surprised the article doesn't mention that Perl, one of the languages that influenced Ruby, also has unless.

In Perl you can write postfix conditionals: `thing() unless $condition`, which at least is more natural usage of "unless" to a native English speaker than the other way around. That's the best way to use it IMO.

It's the same in Ruby. It's even mentioned in TFA.

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

#56
You need to use it when you want to be negative of ALL the thing after unless.

Basically, do_something unless A

Then it's simple now to manipulate the inside of A, as you only take care of the positive ! That's beautiful and simple design.

Example is you want to validate something.

raise Error unless someValidCondition.

Now decompose someValidCondition by just using positive connectives, simple right ?

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

#57

Unless would drive me insane. I do use IF NOT but when reading code my brain understands this format most clearly: IF some-expression ELSE Do-something

`unless` is generally used for guard clauses (eg `return unless authorized?`) or when there’s only one branch. You don’t tend to see `unless` used with multiple branches.

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

#58

I don't have a problem with double negation but I hate ruby for this kind of design - pointless aliases for everything. It's the exact opposite of pythons "There should be one– and preferably only one –obvious way to do it" - they intentionally create solutions that have zero practical benefit - it's just fuels arguments based on preferences and introduces mental overhead due to inconsistency.

And I love it for exactly this kind of design. It's what makes well-written Ruby read well. And while it's one more way of making badly-written Ruby read badly, in my opinion at least with Ruby you have the option of writing code that reads well. I've yet to see Python code that looks readable to me.

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

#59
I've been writing Ruby for 20+ years and "unless" (the whole language, actually) immediately clicked for me when I first learned it.

That said, I only use it in 2 cases:

* as a trailing condition (do_something unless this), mainly for early returns * as the only arm of a multi-line block (unless this ... end, no "else" blocks - Rubocop would yell at me anyway)

And then only if the condition is either a simple value, or a combination of simple values (this && that, this || that).

That's it. Never had a problem with double negatives or accidentally inverting the logic.

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

#60
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)

I'll admit I'm not a Ruby developer, but wow it allows return conditionally inside an expression? What were the language designers thinking?! I can't think of any other language that allows return inside an expression (or break/continue). Let's see: C, C++, C#, Python, Javascript, Object Pascal, Java, Rust; all nope. That is indefensible.

Kotlin has this, check out https://kotlinlang.org/docs/returns.html
Post reply on HN