Hacker News Reader

Comment by reader_mode | Hacker News Reader

>Rightward assignment statement is added. >fib(10) => x

This is exactly the kind of stuff I hated when I had to work with ruby in my last gig and why I will never accept a job using it again - soo many pointless and inconsistent ways to do the same thing ... they have method aliases for collection operations like map/filter in standard library ! .NET went with non-standard SQL-like names (select/where) and I'm not a fan but at least they made their choice and stuck with it. And it's inconsistent all over the place - like '!' postfix means "operation mutates the object" in std lib BUT in rails it means the operation will raise an exception and not return an error code.

Now they add a pointless operator that means completely different thing in other languages to throw off even more people.

It's just a hell of a language to maintain someone else's code in.

View on HN

I love Ruby, but I agree with you about disliking that kind of thing.

I've done Ruby since 2014 or so at a few shops. My general anecdotal experience:

- Lone Ruby coders often use a lot of that cutesy/obscure/dense stuff.

- Teams of people writing Ruby, with healthy code review practices, tend to value simple, easy-to-read Ruby.

- A lot of Popular Ruby gems (and projects at aforementioned Ruby shops) have Rubocop-based style guides. Rubocop has some very strict ideas about Ruby coding style. The defaults are mostly quite sane and it's easy to disable/customize the ones you disagree with.

Not making excuses for some of the more florid parts of Ruby's syntax and stdlib, but in practice I do find things are manageable!

But that's what I love about Ruby! There's so many great ways to express logic, making Ruby a language that really rewards exploration. Of course, when working with a team on a production application, you'd set up standards everyone can agree on and understand with rubocop or prettier-rb (which I loathe and will not touch with a 10-foot long pole for my personal projects). That's also great for onboarding newcomers - they can get their feet wet with "standard" ruby at work, and then experiment with it more deeply in their own time, finding themselves in the ways they choose to express their logic. And then, every now and then if you find something really elegant and beautiful in your own exploration, you can introduce it to your team and add it to your team's style if they all agree on it. Between a language that makes all the choices for you, and a language that gives you the freedom to choose how you do things, I'd pick the latter nine times out of ten: at least in the latter, you can restrict yourself from the more wild stuff, but in the former you're forced into a narrow band of choices. I sure didn't ask for right assign, but I'll be trying it out in my personal projects!

> you'd set up standards everyone can agree on and understand with rubocop or prettier-rb

Things like that just often lead to bikeshedding. And then worse, powerful voices may approve ideas that work for them and not everyone else, or even more worse crippling a language to be too safe or bland to be truly useful.

I got into an argument a couple weeks ago whether an unprotected eval() in python should make it's way into production code of a fortune 500 company. The coder's argument was that, "Well the language has it so why not use it?"

"Because with great power, comes great responsibility..."

That's a problem with culture, not with the language. You can't say "you can get into accidents if you drive a car, so you're not allowed to drive"; you try to fix it by setting rules into place. At any rate, if you don't like bikeshedding, there's great, well appreciated standards in place for ruby which you can take up as-is: there's AirBnB, standard-rb/ prettier-rb and rubocop's default config. No bikeshedding involved, pick one and run with it

Which culture are you talking about? Company culture or programming culture?

My understanding was the general bikeshedding around formatting was the reason gofmt won for golang. That seems to hint the problem is a programming wide culture. Just in the same historical context programmers have had around tabs vs spaces...

> And then worse, powerful voices may approve ideas that work for them and not everyone else, or even more worse crippling a language to be too safe or bland to be truly useful.

but that same thing will happen if the powerful voices are the ones taking the decisions for the whole language.

The thing that most annoyed me about Rails (not Ruby) was that

    users.size
    users.length
    users.count

are all valid, all useful, all have different meanings, are all present in plain Ruby but with different meanings, and contain absolutely no information about what they do.

For reference, .length loads everything and gets the length of the collection, .count runs a SQL COUNT query, and .size uses length if the query has already been run and .count if it hasn't.

So why would you not just default to always using .size?

There are no guarantees that the count will remain correct after the first run of the query.

You usually want to know when you're hitting the database. "Hit the database if the value isn't cached" is useful behavior, but should probably be telegraphed a bit more precisely than just the word "size".

“size” is fine. The person you are responding to is trying to say that complaining about multiple options is a bit strange as you can just use one option. Why is it an issue that other options exist? Who cares. There are synonyms for English words as well, is that an issue as well?

They are not synonyms, they mean slightly different things. And that is the problem.

Because for small datasets the difference doesn’t matter this results in beginner programmers choosing randomly, which 2/3 of time is the wrong choice.

So if 'length' was the only option and I'd have to do ActiveRecord::Base.connection.execute('SELECT count(*) FROM users').values.first or something it would all be fine?

Other ORMs separate building the query from executing the query, which is less ergonomic but more explicit. Drawing on Rust, https://diesel.rs/ shows how this approach would work:

    users.select(count_star()).first(&connection)

which is really just a cleaned-up version of your suggestion.

Of course, you could imagine an ActiveRecord-like API to make this nicer:

    User.first{|t| t.count}
    User.first{|t| t.count}.execute!
    User.execute{|t| t.count}.values.first
    # ...etc.

but the underlying problem is that building the query and executing the query are two discrete steps, Rails streamlines them instead of making the separation obvious, and when a system hides complexity it becomes harder to know what it's really doing.

"size" is not fine. If I'm conditionally hitting the database, I want that to be as explicit as possible.

Ugh yes I don't like this as well. Even if they're all useful, I'd do it with one method that accepts some optional arguments, this is unnecessarily confusing.

I learned Ruby by itself and only worked on Rails code later... so I've had a lot fewer core Ruby complaints then most.

But Rails has definitely become a PR problem for the language in terms of how many complaints like this it leads to.

I would never share a Ruby code base with anyone either. It’s like issuing kindergartners a can of silly string and asking them to be sensible with it.

I consider myself a sensible developer, but even I’ve had some childish moments with Ruby: doing something I thought was clever and productive but which really just made my code inscrutable and unmaintainable...

...by other people. The flip side is I can just about figure out what I was trying to do when I read my own code: enough so that I still always use Ruby for personal projects.

Ruby is just too much fun and critically, to date, it’s the only language where I can write a page of code at the same speed I am thinking. It also usually executes first time without any errors, which is a joyous thing.

I am not claiming to be some kind of 10x uber hacker. Ruby just happens to be an incredibly wonderful language for thinking aloud with code.

Why wouldn't you share your Ruby code with others? As a Ruby developer I an assure you, us Rubyists can work and understand each other's code.

To be frank, the language just isn’t boring enough.

In my experience, a company’s code should be like the style of English used in an instruction manual. It should clearly and plainly express the business logic behind the company’s mission.

Ruby is more like writing poetry. There’s nothing stopping one from writing boring, unambiguous, clear code in Ruby of course. As a Ruby developer, I’m sure your code looks very clear.

The reality is that other languages make it easier to enforce clarity. See gofmt for example, which standardizes Golang’s formatting, taking one more axis of “creativity” away from the less disciplined developers.

Add rubocop to your editor.

You can get it to discipline you as much or as little as you like.

I second adding Rubocop. But sure, Ruby has a way richer syntax and a higher freedom degree than a language like Go. It's part of what makes Ruby what it is. If high degree of freedom isn't something you want Ruby isn't a good choice.

Ruby can also be an extremely decision-fatiguing language to write code in.

! means “dangerous”, not mutation. Yes, that’s how it plays out because it is one kind of danger, but it’s not inconsistent.

It's also not supposed to be used unless you have another method with the same name.

Also, what kind of danger are we talking here? I consider mutation dangerous. Danger could also mean it has side effects or that it can raise an error.

I wouldn't call it inconsistent but I would call it arbitrary.

I would rather just name the method "#{base_method}_#{why_its_dangerous}". For example take ActiveRecord::Base#save and #save!

#save mutates and I would consider that dangerous. #save! can raise an error. I would rather name #save! as #save_or_raise_if_invalid. I know it doesn't look as pretty and takes longer to type but I really don't care. Then again, I'm not a big fan of exceptions so I would never call it.

Original source here, by the way: https://www.ruby-forum.com/t/conventions-in-ruby-and-the-pri...

All of those things are "dangerous" in this sense.

It is arbitrary, but that's how Ruby works; there's a gray area shared understanding of concepts. The "principle of least surprise" is literally about Matz, and Matz alone. Yes, something may be surprising to you, or not, but it's not about you. This shared taste/understandings/whatever is just how convention works. (Or at least, it did when I was involved with Ruby; it's been a couple of years so I'm out of touch!)

I have also strayed away from Ruby so I'm out of touch too. The arbitrariness helped get me into Ruby and helped get me out. It's cool if that's your sort of thing but as I get older I'm starting to dislike arbitrary things more and more.

Anyway, I didn't realize who I was replying to when I replied to your first comment. I've seen a few of your presentations and read a lot of your work and I'm a fan.

I think we followed similar paths; I still love Ruby but my tastes have changed. Rails is still really hard to beat in its area though.

Thank you!

I think we're all really great in cherry-picking something lacking in a language and then describing the whole eco-system as bad. What language are you using now? Were there seriously no bad design decisions made in said language?

If you like dynamic languages I find it hard to pick out poor design decisions in Clojure.

Yes Clojure is the only language which surpasses Ruby in composability.

I haven't watched this since I'm not into Clojure https://www.reddit.com/r/Clojure/comments/83j0hm/clojure_the... Just putting it out here to emphasise the point that ALL languages have controversial parts.

I love all that stuff in Ruby to-date (used in it's appropriate place, following convention, etc) but the rightward assignment feels useless to me.

I have no idea why the few languages that allow it do so. I've never wanted it and I can't imagine it makes parsing simpler in a language where you are sometimes compiling code at runtime and where parsing is already pretty wild.

I've said this before and been wrong so let's hope this turns out to have excellent use cases.

Totally agree.Different approaches to the same thing won't add points to the language.

P.S. the 'endless method definition' is meaningless, too.

> def square(x) = x * x

The original reason of this proposal was:

> Ruby syntax is full of “end”s. I’m paranoid that the ends end Ruby. I hope Ruby is endless. --mame (Yusuke Endoh)

It sounds like "let's add a new syntax for lisp because it has too many brackets"

> It sounds like "let's add a new syntax for lisp because it has too many brackets"

You'll find wisp [0] implemented for several of the larger Schemes. Often because the rationale for adding another syntax can be more nuanced and actually benefitial than a quick joke. [1]

Whilst you're right that caution absolutely applies when modifying a language's syntax, there may be a case for it that reduces friction for the programmer. The change might have been proposed with a joke. I doubt the entire rationale ended there, however.

[0] https://srfi.schemers.org/srfi-119/srfi-119.html

[1] https://srfi.schemers.org/srfi-110/srfi-110.html#rationale

This is a feature present in Kotlin, and it's useful for mathematical functions and simple-but-not-trivial getters.

Ruby has been referred to as Smalltalk meets Perl, and the problem of dealing with other people's code is one of the main things that kept me in the past from using Perl on text processing projects. The problem of collaborating in Perl was lessened a lot by adhering to Damian Conway's Perl Best Practices. Is there anything similar for Ruby?

Rubocop and you're done. It's the first thing I'd add to any team project just because life's too short for an inconsistent codebase.

This. Rubocop is first class. I'm just flat out done bikeshedding in code. If I'm writing JS, it's an ESLint + Prettier combo — or whatever your taste is, I just don't care. Let's write code and let the machine deal with making sure it isn't too ugly.

Ruby’s heavier use of key words rather than symbols saves it from the worst of Perl.

Yes, there’s still some symbols, but nowhere near as many.

For what it's worth, non-alphanumeric Ruby is Turing-complete: https://ideone.com/55WtMM

Explanation: https://threeifbywhiskey.github.io/2014/03/05/non-alphanumer...

The "line noise" aspect of Perl never bothered me, because I'm already a heavy user of regexes. The cause of my misery was Perl's "There Is More Than One Way To Do It."

TIMTOWTDI is what I loved about Perl and the reason I found the transition to Ruby so enjoyable.

In a sense Ruby is sort of a cleaned up Perl but maybe not cleaned up enough.

I fell totally in love with it almost 20 years ago but these days I think we have better languages to choose from even if their ecosystems aren't always as rich.

You mean like Dart and Go? For expressivity I'll stick with dirty old Ruby, thanks.

Ruby is expressive and makes for great short demos but becomes a nightmare to maintain in larger codebases with dynamic typing & implicit imports.

>.NET went with non-standard SQL-like names (select/where) […]

Which names do you believe are standard?

Not who you’re responding to but from context I would assume map/filter, as he said.

Arguably, select/where are less familiar than map/filter to many. I'm not saying that either is a standard, but I can imagine the confusion if you come from say, JS background.

To be fair, map/filter wasn't so popular like now when C# 3.0 (released in 2008) was designed.

`where` is intuitive as a synonym for `filter`, but it's the `select` that always threw me as a synonym for `map`.

I get that they're trying to expose an SQL-like API, but yeah, map is always about mutation, but `select`only does mutation sometimes in SQL.

`Where` at least answers the question "does filter _keep_ the things matching the predicate or _remove_ the things matching the predicate" - my pet hate with the .NET naming is `SelectMany` over `flatmap`.

Map doesn't mutate, it returns the result of applying a function to the (possibly immutable) value. I believe you can also, say, `select icolumn * 2 from table`, where `icolumn * 2` provides precisely the same functionality as the function passed to a map.

Happy someone else echoes my sentiment too, especially when Ruby seems to be beloved by everyone around. So many ways of doing the same thing; unnecessary cognitive burden for both reading and writing.

Best practices are extremely common in Ruby. Something I long missed writing JS which only came about as the language started to really mature with ES5/6. Ruby seemed sufficiently mature and sufficiently best practiced in basic training and widespread usage where it wasn’t a problem.

It’s not anything like C++ or C where the whole coding practice and culture changes depending on your framework (like using Unreal or doing Linux programming). The best practices were the same across the board.

Basically my experience with writing it for a decade doesn’t match these critiques. The quirks in Rails were easily ironed out among intermediate developers. It’s not like it requires advanced programming knowledge to just do what everyone else is doing, which is often share in best practice documents and popular libraries/tutorials/books or (less so) rubocop style plugins.

Reply on news.ycombinator.com