The instructions tell you about the partition method.

This is obviously reading the instructions.

The example even used partition with a block...

Here's the bench mark for both methods.

require "benchmark"

n = 1_000_000
ARR = %w(today is a good day isn't it?)
Benchmark.bmbm do |bm|
  bm.report { n.times { ARR.map(&:capitalize) } }
  bm.report { n.times { ARR.map { |i| i.capitalize } } }
end

Rehearsal ------------------------------------
   1.890000   0.000000   1.890000 (  1.893212)
   1.930000   0.010000   1.940000 (  1.928549)
--------------------------- total: 3.830000sec

       user     system      total        real
   1.900000   0.000000   1.900000 (  1.910439)
   2.050000   0.000000   2.050000 (  2.050394)

I took it as implied that I was recreating zip. Not re-using it.

this is obviouosly cheating

hahahah this one made me laugh

@mortonfox, As I said it's a good solution. I think the comments section is a good place to discuss tradeoffs that may not be obvious to evey user, such as performance issues. That way someone seeing these for the first time can make the best informed decision in the future.

The main thing this is good for is being concise. I never believed it was performant since Ruby has special optimization for blocks.

Clever is the tag chosen by Codewars; this wasn't some kind of slight. It's a good solution, but performance is sub-optimal and the better performing solution is also easier to read.

And to say "As for performance, don't use Ruby", that's just silly. It doesn't matter what language someone is developing in performance should be a consideration. This isn't a case of pre-mature optimization. It's an easy performance gain. I provided the benchmark for anyone that might come along in the future to be helpful as they may not be aware of the performance difference.

It's not 'clever', it's perfectly readable to any Ruby developer. You could argue that so many things in ruby are not readable to 'the average developer'.
Passing just the method is more common in many other languages, be it Python, Scheme, Haskell, Dart, Smalltalk or even C.

As for performance, don't use Ruby, or optimize inner loops. For most Enumerable#map operations the actual operation will cost way more than iterating in whatever way.

This is certainly a clever solution and deserving up the the up votes for that. I'm surprised that this is so heavily upvoted though for "Best Practices", in comparison to the more direct map enumeration version here http://www.codewars.com/kata/reviews/5356b77a2930ee4c010007e6/groups/5397a4c4c20318c06e000ea0

While this technique is certainly clever, I don't believe it is as readable to the average developer and the performance is worse.

The results posted below are from benchmarking this solution against the standard map enumerable. This to_proc version shown here is about 8% slower. So you lose speed and code legibility.

Calculating -------------------------------------
            proc    47.361k i/100ms
             std    52.963k i/100ms
-------------------------------------------------
            proc    980.817k (± 7.3%) i/s -      4.878M
             std      1.060M (± 7.3%) i/s -      5.296M

I wondered the same thing, until I saw everyone else doing it. I am only just learning ruby.

How can you call a function within its own function definition?

Thanks, I did that just now. I chose to keep things simple and explicitly require only symbol support.

Excellent suggestion, I just added this!

There should be a test that requires results to be not in alphabetical order to cut down on all the solutions using #sort for no reason.