Having read the long discussion on the advantages and disadvantages of
language evolution, I have to agree with the original poster.
If there is significant change in the language, yes there will be a
cost to upgrade the source code to the new standards.
So why shouldn’t the Ruby community create the same tool the Perl
community is apparently working on: an automatic CODE CONVERTOR or
“upgrader” from 1.8 to 2.x?
It is a great idea, they have even thrown in a “compatibility mode” to
their plans!
Although I am no fan of PERL, we have to recognize folks, THIS is a
great idea, here’s what they say at Perl 6 FAQ:
"Will I be able to convert my Perl 5 programs to Perl 6?
Yes. Larry Wall and others are already working on a Perl 5 to Perl 6
translator, which will be able to translate (most) Perl 5 source code
to the equivalent Perl 6 syntax.
‘In addition, Perl 6 will provide a “Perl 5 compatibility mode”,
allowing the compiler to directly execute any code that it recognizes
as being written in Perl 5.’
Source: Perl 6 FAQ
This sounds to me like a perfect open source tool that would benefit
all Ruby developers… easing the transition, especially of
applications with a lot of Ruby code.
Having read the long discussion on the advantages and disadvantages of
language evolution, I have to agree with the original poster.
If there is significant change in the language, yes there will be a
cost to upgrade the source code to the new standards.
So why shouldn’t the Ruby community create the same tool the Perl
community is apparently working on: an automatic CODE CONVERTOR or
“upgrader” from 1.8 to 2.x?
[snip]
We may in fact do something like this. No one has ruled it out.
The fact is that 2.0 is still an indefinite amount of time in the
future.
Since 1.8 (and 1.9, and 1.6 even) can be installed at the same time as
2.0, a better option, imo, would be to add a built-in keyword or
Kernel-method whereby you can specify what version of the interpreter a
given script is meant for, and issue a warning if that is not the
version being used to execute the script. Something like:
use 1.8
… the rest of the script
A simple implementation could be:
module Kernel
def use(version)
unless RUBY_VERSION.include?(version.to_s)
warn “Warning: Wrong ruby version:\n”
“Expected #{version}, but got #{RUBY_VERSION}”
end
end
end
Many programming platforms go through major, incompatible changes every
now and then (e.g., gcc3 vs. gcc4), but the world hasn’t imploded yet
with productivity grinding to a halt; people either use the legacy
version with their legacy code, or else update their code and use the
new version.
I think what should not be overlooked is that perl 6 is still not out,
nor is ruby 2.x. I think its way too early to worry too much about
it. Better try out the latest 1.9’s regularly!
One thing that can help to test your code against miltiple ruby
versions at once is with ZenTest’s multiruby. It allows you to set up
a test harness that will run all your unit tests on whichever
versions of the ruby interpreter you are targeting.
We may in fact do something like this. No one has ruled it out.
The fact is that 2.0 is still an indefinite amount of time in the
future.
As is PERL 6. They may never come to be.
Indeed, if memory serves LW predictated perl versions to approach 2*pi
assymptotically,
maybe it will be pi+e :(, but I hope not, perl6 will be a wounderful
beast
even if one might not want to use it.
Robert
assymptotically,
maybe it will be pi+e :(, but I hope not, perl6 will be a wounderful beast
even if one might not want to use it.
Robert
So the Perl version number approaches 8*atan(1) the Python version
number approaches exp(1), and the Ruby version number approaches sqrt(4)
as t approaches infinity?
Seriously, though, I wonder what the bottleneck is? Is it Parrot – are
the Parrot folks trying to be too many things by supporting both Python
and Ruby in addition to Perl, especially given that the Ruby community
appears to be more interested in YARV and JRuby than “waiting for
Parrot/Cardinal?”
Seriously, though, I wonder what the bottleneck is? Is it Parrot – are
the Parrot folks trying to be too many things by supporting both Python
and Ruby in addition to Perl, especially given that the Ruby community
appears to be more interested in YARV and JRuby than “waiting for
Parrot/Cardinal?”
I almost wanted to suggest Parrot one day and than I thaught twice and
thrice and concluded that (a) I was not educated enough in the stuff
(although I still believe that a register based VM should outperform a
stack
based nowadays) and (b) I did not follow Parrot closley enough.
I stopped steeping by the perl6 site about a year ago as there was
nothing
going on, time to have a look for sure. http://perl6.org/
Edward can we do a Ruby Q.:
Write a Perl6 interpreter in Ruby, it has to be faster than Ruby of
course
Cheers
Robert
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
Having read the long discussion on the advantages and disadvantages of
language evolution, I have to agree with the original poster.
If there is significant change in the language, yes there will be a
cost to upgrade the source code to the new standards.
So why shouldn’t the Ruby community create the same tool the Perl
community is apparently working on: an automatic CODE CONVERTOR or
“upgrader” from 1.8 to 2.x?
For 1.6 → 1.8 there was a shim library that added 1.8 features to
1.6. (Which is the opposite of what you’re asking for, but much
easier to write.) I’m pretty sure such a thing will exist once 2.0
begins to become something real.
If you want to shorten my name, JEG2
