Subtraction accumulator

I'm currently following the tutorials over at RubyMonk, and one of the problems I need to solve is to write a subtract function that would meet these conditions:

• invoking subtract(4, 5) should return -1

• invoking subtract(-10, 2, 3) should return -15

• invoking subtract(0, 0, 0, 0, -10) should return 10

Coming from a traditional imperative programming background (C, Lua, Java, etc.), my first attempt would have been something like this:

def subtract *numbers
  start = numbers[0]
  tail  = numbers.drop(1) 

  for i in tail do
    start -= i
  end

  return start
end

But, this just felt wrong in Ruby, and I don't doubt that it is. Trying to use a more Ruby-esque style, I thought it would be better to use some of Array's methods.

Here is my latest version:

def subtract *numbers
  (numbers.drop 1).inject(numbers[0]) { |x, y| x-y}
end

One thing to note is that this is essentially the same thing as above, I just moved most of the looping into Array#inject. To me, simply moving logic isn't a new style per se, and so conceptually this is nothing new to me.

Therefore my questions are:

• Is this true Ruby style? If not, how could I make it so, and how would that new style differ from the current?

• Is there any way to improve readability? ('Cause honestly the current version lacks quite a bit).

Some notes:

-
def subtract *numbers: While Ruby allows to omit parens, the community consensus is that it makes signatures harder to read.

-
(numbers.drop 1): When you have to write parens like this, it's a signal that you should just write them in the method call. It looks like Scala or Haskell, not Ruby.

-
As @Nakilon pointed out, you can drop the drop/first, a fold without an initial value takes the first one.

-
The identity value for subtraction is 0, let's use it for empty inputs.

-
xs.inject(initial) { |acc, x| acc.method(x) } -> xs.inject(initial, :method)

We can now write:

def subtract(*numbers)
  numbers.inject(0, :-)
end

For me, simply moving logic isn't a new style per se, and so conceptually this is nothing new to me.

I don't agree. The steps followed are conceptually the same, yes, but the use of a widely known generic abstraction like reduce/inject has reduced the overall complexity. Of course, one abstraction does not make much difference, but dozens of them change the way a whole program describes what it's doing. And that's what programing is about: building abstractions to reduce complexity.

StackExchange Code Review Q#25394, answer score: 4