I think 2 pages is not bad :) The point is, Perl is just impossible to formally define, it depends on the implementation to make arbitrary choices. This means multiple implementations are much harder, if possible.
But, yes, Ruby can be parsed independent of being execution, which makes means you can separate the work of a separate implementation into (1) building (or reusing) a parser, and (2) building a system to execute the result of the parsing. Being able to divide the work (and, as a result, to share the first part between different implementations) makes it easier to implement.
I don't think it's as much about ease of implementation as it is about the finality of it and formal verification of completeness of any implementation. But of course, those are very much related :)
"Formal verification" of the completeness of any Ruby implementation has been a problem for some time (even when multiple implementations existed) as Ruby had neither a reasonably-complete specification nor reasonably-complete unit tests (for a while, the closest thing to a "standard" is "does it seem to be able to run Rails") -- the RubySpec effort (which was, IIRC, led by the the Rubinius team though its been accepted generally since) has improved that condition tremendously, though I still wouldn't say that Ruby is exactly in a great condition with regard the ability to have "formal verification" of an alternative implementation.
Though it may be way better than Perl in that regard -- does Perl have anything like RubySpec?
I don't know either Ruby or Perl 5 well enough to be 100% sure of the following answers but my interest in P6 and its spec/test approach has led me to investigate the spec/test framework of several languages and their ecosystems.
> does Perl have anything like RubySpec?
TL;DR It depends on what you count as Perl and how one defines "anything like". I'd say the production Perl 5 (P5) approach is not like RubySpec and the Perl 6 (P6) approach may have been one of the inspirations for RubySpec.
----
The production P5 doesn't have a direct equivalent to RubySpec -- testing isn't tied to a specification document or part thereof.
There are around 50K unit tests for this year's production P5 interpreter, 5.20, and a half million for the core modules shipped with 5.20.
The bundled tests for each "distribution" uploaded to CPAN -- there are around 30K distributions, 100K+ modules, many with numerous versions -- is then automatically tested against various Perls (from the 5.0 of 1994 thru to the in development 5.21) on the various platforms Perl runs on. There have been about 50 million reports, each of which reports on a run of the unit tests for a single distribution on one version of Perl on one platform.
----
P6 has a written "spec". The spec is not "formal" in the normal formal mathematical sense of the word formal. (The same appears to be true for RubySpec.) We're not talking IBM formally verifying Z here!
The P6 spec inlines the "spectests" associated with that section/paragraph/sentence of the spec. About 35K so far.
So, aiui, if one squints a little, the Perl 6 spec/test approach is, perhaps very roughly speaking, equivalent to RubySpec/RSpec.
Aiui there are specific versions of RubySpec corresponding to specific versions of Ruby. (It looked like the latest RubySpec is 2.1, ie not covering the latest Ruby version. But that doesn't sound right. Perhaps I misunderstood what I've seen/read.)
The P6 spec, and its tests, aren't yet structured to serve for multiple versions. (Talk of dealing with this surfaced recently. And of course it's all git backed so spec versions can be correlated with spectest versions with Rakudo versions.) The spec and tests are in some cases years ahead of the latest Rakudo, the main P6 implementation, and in some cases behind. (The word "spec", in regard to the P6 spec, seems to mean both specification and speculation!)
----
P6 ecosystem testing is currently very ad hoc. But P6ers are in the process of integrating P6 distribution (module) management with CPAN, which will mean that user contributed P6 distributions/modules will get the same automated testing that I described above for P5.
----
Finally, to confuse everyone, there are not only multiple implementations of P5 and P6, but also a P5 re-implementation written in... P6.
Tobias Leich is developing "v5", a P5 compiler written in P6. (Well, for now it's written in NQP, a small subset of P6, but he has said he plans to switch to full P6 this year.) The test suite for v5 is a fork of the production P5 test suite.
I think 2 pages is not bad :) The point is, Perl is just impossible to formally define, it depends on the implementation to make arbitrary choices. This means multiple implementations are much harder, if possible.