perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Grimm <edgr...@dsblade00.wat.us.ray.com>
Subject Re: Some philosophical questions
Date Tue, 26 Jul 2005 18:35:39 GMT
On Tue, 26 Jul 2005, Neil Gunton wrote:

> Perl 6 looks to me like a huge white elephant. It may work,
> eventually. In fact, when it does, it may be a beautiful, finely
> crafted virtual machine (Parrot?) that can run multiple languages with
> aplomb. However, it will likely do all this to a largely empty room -
> everyone will have left already to go do stuff using other languages
> such as Ruby. The big bet is that people will use things like Ruby
> under Parrot. Maybe, maybe not. Don't know yet. All I know is that
> right now, my experience (and resume) seems to be getting more and
> more marginalized. The geeks in charge seem to have rewrite mania,
> with no regard for the huge pre-existing user base that is left
> wondering where to turn while the new version is getting stable. Do
> you use the old version, which is, well, old? Or do you use the new
> version, which doesn't really work yet? Over the last few years,
> people started using this stuff for *real* projects, which have *real*
> users. It's not just for hobby use any more.  I certainly don't want
> to put this experimental code on my production server.

You remind me of what I feel is the classic problem with perl.  That's
CPAN.pm.  This handy way to keep your system updated has no method for
updating a stable-version system.  The longer you run an old version of
perl, the more likely an update will insist on upgrading all of perl.
It's not that the versions of the modules that run in the version of
perl you have are not available; you can manually download them just
fine from nearly any CPAN mirror.  The issue is that CPAN.pm doesn't
have the capability to consider 'This version of this module requires an
upgrade to other modules, but I'm wanting to upgrade it because of a
dependancy of something else, which would be satisfied with an older
version... is there an older version that would work for that dep that
doesn't require upgrading so much else?'

My ideal solution would allow versions with major bugs to be removed
from the potential install list, yet not require feature updates to
packages that are not specifically being updated.  Further, it would
allow updates to a particular version, instead of just 'the latest'.

> The reason Microsoft was so successful with Windows 3.1 and Windows 95
> was that MS went to great lengths to make them able to run earlier DOS
> programs. They even went so far as to "fake" some memory quirks that
> some popular programs happened to depend on. Nowadays, Microsoft
> appears to have lost that attitude (see: .NET, Longhorn), and I feel
> like the Open Source crowd is doing the same.  It doesn't matter how
> many people were using the old version, this new version is "better"
> and that's all that matters, right? That's a supremely geeky,
> insulated, closed attitude that ignores the real users, and risks
> alienating people wholesale.

I don't think that attitude is particularly geeky.  Geeky is having all
versions work.

In the mid to late '90s, there was a fair amount of deprecating
features.  This annoyed me greatly, because the deprecation warning
never indicated what to do instead, just don't do this.  However, on the
positive side, they left those warnings in for quite some time, to give
people time to adjust.  Now, they seem to be removing features, with
little notice, and even less indication on what to do instead.

I thought the idea was to Evolve, not Devolve.

Ed

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Mime
View raw message