Hacker News new | past | comments | ask | show | jobs | submit login

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 which I am not proficient. Stuff like ’unless’ is such a pointless obstacle in these scenarios.

So ”elegance” doesn’t come free. The cost is a loss of transferable knowledge from other languages. Your intuition is that this cost is low relative to the benefit of ”elegance,” I have the opposite intuition. Why stray from such universal conventions in favour of one person’s subjective aesthetic preference?




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.


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.


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.


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


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." This was my main problem: that the critique of `unless` was much more plausible than the defence.


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.


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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: