Hacker News Reader

Comment by submeta | Hacker News Reader

What I like in Ruby: Every expression returns a value. In Python my_list.sort() will return `none`. So if I do `sorted_list = my_list.sort()`, my `sorted_list` will be `none`. And I have been shooting a lot in my foot in the beginning. - I love Python now, but not because I find it aesthetically appealing (I prefer Lisps or functional languages) but because it is ubiquitously available, the ecosystem is phantastic, and it gets the job done.

One rant though: Am I the only one being overwhelmed by so many "end" delimiters in Ruby? Feels like visual noise. end end end end...

View on HN

I have, in the past, thought that it might be a good idea to allow `en+d` as a delimiter.

So you'd have

    module A
      module B
        class C
    ennnd

Fortunately, I am no longer suffering from whatever fever-induced hallucination brought on that particular deviation from good taste and decency.

I love it! Obviously not a good idea, but I can see where you're coming from and empathise very much!

The `sorted_list = my_list.sort()` is a bit of an odd case, though, because, as you've written it, `sorted_list` looks like a new list, even though `sort` does an in-place sort. (Javascript has exactly this problem, where `.sort` mutates the existing list, but can be chained in such a way that it looks like just another step, leading to surprises later on when the input data is suddenly different to how it used to be.)

In that regard, separating `sorted` (immutable, returns a new sorted list) and `sort` (mutates, returns nothing) helps a lot in terms of preventing subtle mistakes.

I don't know how Ruby handles this case though.

Ruby conventionally separates methods which modify the object from ones that don't by appending an exclamation mark to the method name. So `sort` returns a new sorted list, whereas `sort!` modifies the original list.

Strictly speaking the exclamation mark convention is for things that are "dangerous", in some sense. Modifying in-place is one sort of dangerous, but there are others, Process.exit! being one notable instance where the "modifying in place" thing is a bit of a stretch, and not really the thing you care about.

!-suffixed being dangerous is a rails convention (throws exception). !-suffixed methods are a ruby convention for instance mutation. Calling mutation dangerous isn't a justification for your argument, as there are intrinsic benefits to using those where justified and contained, such as memory savings.

That's simply not true. matz has said this explicitly in the past:

> The bang (!) does not mean “destructive” nor lack of it mean non destructive either. The bang sign means “the bang version is more dangerous than its non bang counterpart; handle with care”. Since Ruby has a lot of “destructive” methods, if bang signs follow your opinion, every Ruby program would be full of bangs, thus ugly.

(from https://www.ruby-forum.com/t/conventions-in-ruby-and-the-pri..., a quote from 2009)

Thanks for the added information.

I'll argue that `Process.exit!` does modify the state of the program in place (which isn't the typical thing one thinks of when thinking of values). Without the bang, it's just a function call that throws an error, which can be caught and handled, so the logical state machine is unchanged. With the bang, it replaces the set of states the current program can be in to a single exit node.

That's exactly what I meant about the modification of the state in that case not being what you care about. Technically true, actually irrelevant. Mostly.

Python has a `sorted` function which will return a new sorted list. I agree with you about the general inconsistency though.

Python’s weird mix of OOP but also global methods like `sorted` and `filter` is very weird to me. (Not to mention list comprehensions.) In Ruby, control flow pretty much always moves from left to right as you add successive method calls.

I agree. Python is not consistent, probably because features kept being added. Ruby is a little younger though, so its creator could use lessons learned from its predecessors.

> So if I do `sorted_list = my_list.sort()`, my `sorted_list` will be `none`

This is (one of) my biggest gripes with Python. It's utterly inconsistent with its design, and library designers have taken that to mean they also can do anything they want, leaving NumPy vs Pandas to have completely different class vs object stylings for instance. I reach for Python these days only when there's no other option because I'm 100% sure I'll spend 50% more time in the debugger than using Ruby for a similar problem.

This is why you should use type hints and some kind of type checking.

sorted_list: list = my_list.sort()

will raise a red flag with a type checker.

it's a meme (image), so i can't copy it here: https://twitter.com/stylewarning/status/1772795474589987226

That's a good one :) So I'm a non-typical hacker, because I use paredit in Emacs so I don't have any issues with parentheses :D

Old joke from usenet:

> I have reverse engineered secret security algorithms used by the CIA and can break any message they encrypt. As proof, here is the last few lines of an implementation of their encryption function in Lisp

                ))
            )))
        )))
    ))))

The joke misses the mark because Lisp code usually coalesces all the parentheses in the same line at the end of the block. It does make sense for Ruby, though.

Interestingly enough, this type of response ("Lisp parentheses isn't indented like that") was the most usual type of response.

Apparently joke-killers aren't a new thing :-)

It's from here: https://groups.google.com/g/rec.humor.funny/c/HjP_hKi49Ws/m/...

In other archives:

https://www.usenetarchives.com/view.php?id=rec.humor.funny&m...

and

https://www.netfunny.com/rhf/jokes/90q2/lispcode.html

The “end” are better with four spaces of indentation IMO.

As others have said, you can use:

  sorted_list = sorted(my_list)

sorted() also has a reverse option and a key option to specify the keys to sort by.

And the sort is guaranteed to be stable.

https://docs.python.org/3/library/functions.html#sorted

end, curly braces, same same. The deviation is IMHO Python with its intention oriented block creation. Which is a debate on its own ;).

I love the indents now with modern editors being able to deal with them ;) Zen mode. Super clean. No end delimiters.

I personally am more confused without the block delimiters. Having a 4 spaces indent size helps. I wonder if this is purely a matter of getting used to it.

Reply on news.ycombinator.com