Re^2: Back to the __future_

To me, what is remarkable, important and lasting about Perl is not the language itself, but the CPAN library. Many years’ worth of rugged, battle tested software that works. That is what makes Perl different ... as I discovered first hand while briefly consulting for “A Popular Powerful Legendary Enterprise” that wanted for some reason to replace its Perl Software That Works™, with Something In Ruby. Oops! Although Ruby at first blush appeared to have an equivalent package to do many things, it often didn’t provide the functionality that was needed right-now, and furthermore the packages had a rather disagreeable number of flaws. The upshot (at the present day, of course... the Ruby teams are no slouch and I’m not suggesting any such thing) was that while the Ruby language might (?) have been Better,™ the project was not well served by the Ruby system in its present condition. Of course it could happen to anyone, anywhere, in any language system fill-in-the-blank, but ... the Perl library spoils you quick. It is of course the product of many more years of effort than is Perl Itself.

Replies are listed 'Best First'.
Re^3: Back to the __future__ by locked_user sundialsvc4 (Abbot) on Aug 22, 2011 at 12:58 UTC
“The trick,” for the Perl-6 project, is how to make it a different-and-better language while also allowing it to be source-compatible in some way with its important installed-base ... namely, CPAN. There is too much in CPAN to allow all of that stuff to be “rewritten.” So, there is a formidable engineering challenge here. Existing projects such as (specifically...) Moose do show what can be accomplished, even in the context of Perl-5. So, IMHO, “Perl-6 must be more than a forward step. It must be a broader step.” If it were merely to be thought of as “a new and therefore better language,” well, we’ve had all of those things before. We’ve got them right now. Ruby. Haskell. Your Opinion May Vary.™ All of them, nevertheless, different, and all of them rebuilding from scratch a thing that Perl has spent the last X years already doing. So, the engineering problem, as it turns out, is in the existing code. The existing shared code. The easiest approach of course is to “start with none,” but that is throwing away the baby. The language isn’t the baby; it isn’t a thing that can be “improved upon” in isolation. The commercially valuable thing is CPAN, not to mention millions of vital “legacy code” installations that are literally hauling the freight and paying the bills. Hence, my observation that the approach must be a broader approach: one that encompasses what exists now, and which elaborates upon it without repudiating it. We cannot say, “that was then, this is now.” We need, “that was now, and this is also now.” A vastly more complex software-engineering problem . . .

Replies are listed 'Best First'.

Re^3: Back to the __future__
by locked_user sundialsvc4 (Abbot) on Aug 22, 2011 at 12:58 UTC

“The trick,” for the Perl-6 project, is how to make it a different-and-better language while also allowing it to be source-compatible in some way with its important installed-base ... namely, CPAN. There is too much in CPAN to allow all of that stuff to be “rewritten.” So, there is a formidable engineering challenge here. Existing projects such as (specifically...) Moose do show what can be accomplished, even in the context of Perl-5.

So, IMHO, “Perl-6 must be more than a forward step. It must be a broader step.” If it were merely to be thought of as “a new and therefore better language,” well, we’ve had all of those things before. We’ve got them right now. Ruby. Haskell. Your Opinion May Vary.™ All of them, nevertheless, different, and all of them rebuilding from scratch a thing that Perl has spent the last X years already doing. So, the engineering problem, as it turns out, is in the existing code. The existing shared code. The easiest approach of course is to “start with none,” but that is throwing away the baby. The language isn’t the baby; it isn’t a thing that can be “improved upon” in isolation. The commercially valuable thing is CPAN, not to mention millions of vital “legacy code” installations that are literally hauling the freight and paying the bills. Hence, my observation that the approach must be a broader approach: one that encompasses what exists now, and which elaborates upon it without repudiating it. We cannot say, “that was then, this is now.” We need, “that was now, and this is also now.” A vastly more complex software-engineering problem . . .