Esteban Manchado Velázquez wrote:
> And, w.r.t. the reply from James Britt, he said:
>
>
>>Sad, but unless you are paying someone you shouldn't expect
>>developers to be too concerned with writing new code that runs on
>>older versions of Ruby. (And I expect this is true in most developer
>>communities, so nothing scary about Ruby in this regard.)
>
>
> Yes, you're right, you can't "expect" developers to do that, but I think
>Ruby would gain acceptance if more developers tried to remain compatible.
That's, um, crazy. Writing new code and checking that it runs in both
1.6 and 1.8? Then you're basically writing to 1.6.
Yes, that is what I mean. Are there really so much performance-boosting
features in Ruby 1.8 (the language; I guess the libraries should be easy to
upgrade.... if they work in Ruby 1.6) that going to 1.6 for _some_ important
libraries sound crazy? It not telling everyone to not use new lenguage
features (sorry if it sounded like that), I'm simply saying that keeping some
important libraries/applications compatible with Ruby 1.6 would probably make
Ruby stronger in the eyes of many bussinesses.
I don't quite see how new applications that don't take advantage of new
and improved features in a language are really going to win over more
people.
Letting more people use them, reducing maintenance costs, and thus making
more people see Ruby as a viable alternative.
Does anyone expect that new PHP applications will not take advantage of
PHP5? Or when Perl 6 comes out new Perl apps won't leverage things
unique to Perl 6, and require Perl 6?
PHP usually has _many_ (incompatible) changes when they bump the major
version, so I don't think we can compare here. Ditto with Perl 6. I guess that
your comparisons are fine for the Ruby 1.x -> Ruby 2.x transition, but not for
1.6 -> 1.8. I think that we should compare the 1.6 -> 1.8 transition with
Perl's 5.6 -> 5.8 or with Python's 2.2 -> 2.3. But it really is a matter of
opinion.
Overall, Ruby will attract more users as the number of new kickass
applications grows, and that number will grow faster if people aren't
ensuring that their code runs on ruby.previous_version
I wouldn't be so sure. I mean, of course kickass applications make us
having a lot more attention/acceptance, but when trying to push a new,
"obscure" (in the sense of not having gallizion developers out there) language
in your workplace, it's a big plus if you don't have many additional
maintenance costs.
I mean, the compatibility thing is _not_ a problem if you actively want to
use Ruby, or if you are a Ruby shop anyway, because you've already seen the
light 
But if you are in a situation where you need to maintain your own
compiled version of the interpreter separately from the rest of the system,
just to "test" a new language, and (you/your boss) are not even sure if you're
finally going to develop in Ruby, I guess many bussinesses will simply not use
it.
And I'm not saying that if they finally checked out Ruby, the maintenance
thing would surpass the performance/satisfaction/whatever boost... just saying
that easing more people "checking out" Ruby in their workplace would be good.
I guess you think that we're better off taking advantage of new features than
trying to maintain compatibility, but...
(BTW, did you intend to say "Ruby would gain *more* acceptance if more
developers tried to remain compatible"? Because Ruby is clearly gaining
not just acceptance, but active usage, despite any compatibility issues.)
Yes, sorry. Obviously Ruby is gaining a lot of attention, in part thanks to
the great web frameworks written in Ruby.
> And I think other languages (read: Perl and probably Python) care _a lot
>more_ in that regard. Please don't get me started on PHP, for several
>reasons
>;-)
I'm curious how one might quantify this. Maybe look for some sampling of
new applications written after the latest version of P* came out, and
see if they run on an earlier major version?
I'm pretty sure the last time I installed Blender or Zope or something
Python-based they were quite specific about having a current Python.
Perhaps yes. Perhaps I should not have included Python in the list.
But, the only application/library that I recall it had problems with Perl
5.6 is Request Tracker, and then again, it worked, but had some problems with
character set conversion (well, until some version, when they finally dropped
Perl 5.6 support altogether, IIRC). Every Perl application and especially,
library, that I recall installing in the past few years, worked just fine in
Perl 5.6.
So, perhaps the only language/community that maintains that sort of
compatibility is Perl, but is what I use (partly), and I'm used to that, and I
find that a good thing 
Regards,
···
On Sat, Feb 05, 2005 at 10:29:11AM +0900, James Britt wrote:
--
Esteban Manchado Velázquez <zoso@foton.es> - http://www.foton.es
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
For
For