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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
