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