Some of these are pretty amazing, like the `digits` method and the new OptionParser functionality (which seems to be a sort of standard library equivalent to doctopt!).
That being said, I can't help but shake my head at the section about "multiple assignment of conditionals:
"You can now assign multiple variables within a conditional...You probably shouldn’t do that though."
Am I alone and thinking that it's a little bit hypocritical to specifically add functionality to your language if you don't want people to use it? Or is this just a joke that's gone over my head?
> Am I alone and thinking that it's a little bit hypocritical to specifically add functionality to your language if you don't want people to use it?
It's just a change to make the language more consistent. `a, b = something` already worked as an expression in most places, so it makes sense that it should be allowed on `if` conditions too. Before 2.4:
> if (a, b = nil) then :foo else :bar end
SyntaxError: (eval):2: multiple assignment in conditional
So instead of having that special syntax error, and probably needing a justification for it, Ruby 2.4 makes `a, b = something` a valid expression there and removes an edge case.
That you probably shouldn't use multiple assignment on an `if` condition is a separate issue. It's just a preference, and it follows the same logic of avoiding assignments on conditional expressions in general.
Ah well "You probably shouldn’t do that though" is just my opinion as the author. I didn't play a part in these changes. I just like Ruby enough to dig into their changelog :)
Interestingly, assignment inside conditionals is usually avoided because it is easy to accidentally do an assignment (=) rather than a comparison (==). Note that for multiple assignment this mistake can no longer happen:
irb(main): a, b == 3
SyntaxError: syntax error, unexpected ==, expecting '='
First of all that is an interesting point. Given that it isn't as potentially dangerous I'll agree that it is less bad than I initially thought.
I'll respond to your question by asking you a question. Which of the following expressions evaluate to "truthy"?
'truthy' if (a, b = []) # =>
'truthy' if (a, b = nil) # =>
'truthy' if (a, b = [nil]) # =>
'truthy' if (a, b = [nil, nil]) # =>
'truthy' if (a, b = [false]) # =>
'truthy' if (a, b = [false, false]) # =>
'truthy' if (a, b = [true, false]) # =>
'truthy' if (a, b = [false, true]) # =>
'truthy' if (a, b = *[]) # =>
'truthy' if (a, b = *nil) # =>
'truthy' if (a, b = *[nil]) # =>
'truthy' if (a, b = *[nil, nil]) # =>
'truthy' if (a, b = *[false]) # =>
'truthy' if (a, b = *[false, false]) # =>
'truthy' if (a, b = *[true, false]) # =>
'truthy' if (a, b = *[false, true]) # =>
It is usually not a great idea, but there are some patterns where it produces code that is a lot nicer than not. In practice, this will allow stuff like
while x, y = foo.pop
..
end
which without the mass assignment will require duplication of the assignment line.
Haven't tried it, but the assignment semantics is that the return of the assignment expression is always the right hand side of the operator. They probably kept that semantic. So
foo, bar = ['foo', nil]
evaluates to
['foo', nil]
which is truthy.
If the code was:
if (foo, bar = [nil, nil])
'truthy'
else
'falsey'
end
It'd still be truthy even if no variables were "set" (they were actually set, explicitly to nil, but you get the idea) because [nil, nil] is truthy. It doesn't have anything to do with the values of the variables after the assignment, just what's on the right hand side.
Just gotta remember there's nothing special about there being an assignment there, it's just another expression. `if` is another expression and it doesn't care about the status of assignments or whatever is in the conditional clause, only what the expression inside evaluates to.
As far as the assignment operator evaluating to the right hand side, it'd be more difficult to understand if that wasn't the case. There are more scenarios to destructuring on the left hand side than the right.
Also keep in mind there's no such thing as a "failed" assignment. They always work, sometimes things are just assigned to nil explicitly or implicitly.
This case is somewhat hard to get because it brings together a few things of Ruby in way that can get weird. Those things separately are actually pretty good, but bunched up makes it a bit more dense semantically. Which is why it's best to avoid getting too clever with assignments in conditionals.
To summarize* and elaborate: Originally in Ruby, multiple assignment inside a conditional caused a parse error. Why? Because multiple assignment originally always returned an array:
irb(main): a, b = nil
=> [nil]
In Ruby, non-empty arrays always evaluate to truthy. (The array above has one element, nil.) Hence, multiple assignment inside a conditional would have been meaningless. For this reason, Ruby threw a parse error.
As of Ruby 1.9, multiple assignment in a conditional now returns whatever the right-hand side of the assignment operator evaluates to. So, it makes sense to re-allow multiple assignment inside conditionals and remove the parse error.
Here are some examples illustrating the return value of multiple assignment. The first two are truthy while the third is falsey:
irb(main): a, b = 8, 7
=> [8, 7]
irb(main): a, b = 8
=> 8
(a = 8, b = nil)
irb(main): a, b = nil
=> nil
(a = nil, b = nil)
Ruby is the first language I really like. The core concept of the language is small, just not easy to get, but the change on how to programming is significant.
Sadly, Ruby is not the language for the multi-core world, and many advantages of using it is disappearing.
Although Ruby is changing, 2.3, 2.4, maybe 3.0, but what's the difference?
First of all, Ruby has a very ambitious goal for version 3.0, which most likely involves some kind of thread parallelisation.
Second, I would not say Ruby is not a language for the multi-core world. There are tens of thousands Ruby production environments over the world that make excellent use of multi-core machines. They run Ruby on problems that are embarassingly parallel such as web applications using process managing application servers such as Phusion Passenger or Unicorn. This is the way many modern web application platforms parallelize, including Node.JS and Python.
Third lack of paralellization is not a language feature. Both JRuby and Rubininus support threads without a GIL. Projects like Celluloid and Concurrent-Ruby make use of this.
1. Ruby will support parallelization, it’s just a matter of time.
2.Passenger and Unicorn are multi-process, which due to developers can make use of nearly nothing in Ruby, and that's why gems like https://github.com/grosser/parallel come out.
3. The language implementation detail matters a lot. Too many gems are not thread-safe. JRuby is an option, but not that good, as there're too many other options under JVM platform. Rubininus is awesome, I wish it comes out earlier.
> Sadly, Ruby is not the language for the multi-core world
MRI isn't the implementation for the multi-core world, but MRI isn't the only Ruby implementation; on language features, JRuby, particularly, isn't particularly far behind (the current version runs Ruby 2.3 code; I wouldn't expect 2.4 support to be that far behind), and fully supports thread-based parallelism.
Yes, from the beginning, and there exists celluloid which try to implement actor model.
The fact that concurrent-ruby cannot be truly parallelized just disappoints me. The same idea of Future,Promise applied to Ruby doesn't gain the benefit. At last, it's just a method of writing 'better' code, not getting better solution.
I assume (but don't know) that this is an attempt to avoid returning `nil` for empty collections: `[].inject(:+)` is `nil`, but `[].sum` is `0`.
Forcing the use of the additive identity every time, rather than starting with the first element of the collection, is a good way of setting people up to get the correct behaviour on empty collections, even if they don't test for that case.
As a golfer, that code would have already been golfed down to:
num.to_s.chars.map &:hex
So digits only saves 14 characters (22 if reverse is really necessary). But usually we would actually be doing something with the digits instead of just getting them, so the method may save even less.
For example, for finding digit sums, the new digits and sum methods give us the efficient:
num.digits.sum
But for numbers up to 5 digits (or digit sums up to 47) we can already do:
Great to see my favorite language evolving! I also use various lisps, Java, Haskell, Typescript, JavaScript, Python, etc., but I am happiest when coding in Ruby.
Unfortunately, most of what I do now is machine learning, and Python wrappers for underlying C++ code have by far more support than Ruby. (Ruby does have some great ML projects and libraries though).
It's a Ruby wrapper for the popular Google TensorFlow ML library. It will probably be completed before this autumn because it was originally a GSOC project (and couldn't be admitted because it was found to be missing some Google requirements at the last moment). It's now crowdfunded but it seems that Google is still offering some degree of support to interested developers [1].
In the meanwhile also check this out https://gist.github.com/gbuesing/865b814d312f46775cda "Resources for Machine Learning in Ruby", some of which are again wrappers around popular ML C libraries, thus removing the problem about sheer speed.
I'm on a similar boat, and am eagerly awaiting production-ready releases (and wider adoption) of both Crystal[1] and Julia[2] languages. Crystal for the Ruby-ish syntax, and Julia because it seems to be shaping up into a language I like even more than Ruby.
Why do the old match operators now implicitly set a global variable? I feel like in a year I'm going to be debugging some really weird race conditions because of that change and I can't see any value in it...if I want to use the value of a match operator I'll _always_ save it to a local variable.
Can anyone shed any light on this, because my first attempts at grok'ing this change have me really blown away.
Ahh, thanks for the clarification I had no idea this was old behavior but it looks like the new method might allow them to deprecate what I would consider an anti-feature later.
This is the kind of stuff that is great for shell scripting / one liners. I doubt they are ever going deprecate it. Maybe the best thing is to rewind your mind 30 minutes and pretend you never read about it : )
Example
ruby -ne 'puts $1 if $_ =~ /^(([\d\.])+)/' < /etc/hosts
Ruby has ALWAYS set certain $global_vars based on a match. This borrowed (directly) something that Perl did/does, as well. This is not a new behavior. See docs: http://ruby-doc.org/core-2.2.3/doc/globals_rdoc.html for "global", "predefined" or "magic" variables. That documentation has existed for many, many versions (not just 2.2.3, per the URL).
If you have issue with this sort of thing, you should go to Elixir. ;)
These globals are thread local and method local, so these are safe from race conditions.
Though, I too had to dig into it the first time I saw use of these special vars to gain confidence that I wasn't introducing a world of pain when we hit load.
Usually when I've seen digits indexed in a number it occurs from right to left (certainly in binary contexts--bit 0 is the least significant bit and bit 31 is the the most significant bit in a 32 bit integer). So, 123.digits[0] means the least significant digit, 3, whereas 123.digits[2] would give you 1, the most significant digit.
These are all great but when are we getting optional typing? If the js ecosystem wasn't a clown operation my language of choice would be typescript instead of ruby.
I like optional types as well, but more because I'm lazy. The Elm and Haskell people are not complaining about types, and given that every function takes SOMEthing (of some implicit type) and usually spits out SOMEthing (of some implicit type), I can hardly see how it will "dictate the design" more than create a bit more validation code.
Not having this flame war. I have my reasons, you have yours. We will continue writing code using our separate ways. Certain patterns are awkward or even impossible in statically typed languages and you need to bypass the type system to get things done so implicit or not, static type systems have a cost. There is a benefit as well but the kinds of systems I work on I don't need the extra validation. I need the ability to quickly prototype and ship and then layer on the validation, hence the need for optional types.
Didn't think I was starting a flame war, I thought we were having a stimulating discussion, actually, but the two are often confused online unfortunately. I don't use any statically typed languages myself, so there is no reason for me to advocate for them from a personal bias standpoint, I was just saying that the people who DO use them seem to be pretty sold on them. Your criticisms are valid of course!
That being said, I can't help but shake my head at the section about "multiple assignment of conditionals:
"You can now assign multiple variables within a conditional...You probably shouldn’t do that though."
Am I alone and thinking that it's a little bit hypocritical to specifically add functionality to your language if you don't want people to use it? Or is this just a joke that's gone over my head?