I just came across today's LXer page-link about "the language euphemistically known as 'Perl 6.'" There is a lesson to be learned here for all language developers . . .

Language developers love nothing more than to add "new and improved" features to their "new release" language, cheerfully adding "+1" to the version number while introducing "breaking changes." The new language is not backward-compatible with the old. You're supposed to re-write your applications to take advantage of all these cool new features. You're supposed to want to. You're supposed to be able to afford(!) to.

Furthermore: developers conveniently forget about the vast contributed libraries ... Perl's CPAN, PHP's Pear, Ruby's Gems, etc. ... which are a critical and indispensable part of every application that is built using their language. These libraries either become "deprecated," or they get "re-implemented," also doing so in a way that breaks backward compatibility.

I vividly remember participating in a project that attempted such a conversion ... at a Northern California Computer Company That Everyone Knows About, of all places that should have known better. They were stunned when the new contributed-library that they attempted to use (having "assumed" that the new one would work as the old one did) was spewing out #FIXME# and #TODO# messages! The project in question sits squarely in the mission-critical business path for this corporation, and at that moment it was sunk.

There are millions of dollars' worth of human labor and troubleshooting incorporated in those libraries which we are free to use at no cost.

There are also millions of dollars invested in the end-user applications which we build and which we are then tasked to maintain. (In my present engagement, the application in question also books more than a million dollars a week in gross revenue, and is responsible for essentially 100% of the orders that the company takes in.)

So, please don't look at your "cool new language" in isolation. Don't create breaking changes. Don't become incompatible with your vast contributed-code library. Don't make changes for change's sake. The companies who use your product must consider business risk above all other business considerations, and the risk of making the conversion that you contemplate is incalculable.

Perl-6 is a dead dodo for these reasons, stillborn in its birth-pangs which have been stretching on for a half-dozen years now, and it will remain so forever.

Just like we have python and python3, now we have perl and perl6... (Also php7 isn't entirely compatible)

I love this. Releases like this are typically preceded by a *decade* of open development, documentation, blog posts about transitions, etc. And then once the release finally happens, everyone acts like it was sprung on them with no warning.

The thing is nobody likes to rewrite a program when the only reason to do it is that the interpreter that runs the program has had an incompatible change. Also nobody likes to pay for such a rewrite of a program.

Yes – my point is that the years of effort (in each case, actually) was [IMHO ...] mostly a waste of time.

The application in my case is over 250,000 lines of source code. (I have worked with Perl applications that were far larger.) There is no "improvement to the language" that would justify the massive and impossibly-risky changes to this source code that would be incurred with no business benefit to the customer, who is perfectly happy as he is and obviously unwilling to incur business risk.

sundialsvcs wrote:

> I just came across today's LXer page-link about "the language euphemistically known as 'Perl 6.'"

Do you mean https://opensource.com/life/16/9/perl-6-features? (A google for "the language euphemistically known as 'Perl 6.'" matches just your comment.)


> You're supposed to re-write your applications

No, you're really not. Why would anyone rewrite when they can just continue to use what they've already got?

The article begins with the question "What's something about Perl 6 you wish everyone knew?". Part of the answer is "Lets you run all 170,000+ Perl 5 modules". Perhaps you missed that bit or didn't understand it or don't believe it?


> the vast contributed libraries ... Perl's CPAN

You can use CPAN modules with Perl 6. For example: http://perl6.party/post/IRC-Client-P...ule#dontwaitup

A similar story applies for Python modules, Ruby, Lua, etc. See http://modules.perl6.org/#q=inline

Off: yasql-1.83, for example, doesn't work without modification with newer Perl5 versions. Haven't tested with Perl6 yet.

There have been so many versions of Perl-6, in particular, so many conflicting implementations and so many stories about it, that no, quite frankly, I don't believe them anymore.

Perl works OK as it is, if you can speak it you can get things done.
It's not perfect, lots hate it, but no contrivance built of man ever will be perfect or universally loved.

I have never got the point of Perl 6.

sundialsvcs wrote:

> There have been so many versions of Perl-6, in particular, so many conflicting implementations and so many stories about it, that no, quite frankly, I don't believe them anymore.

Fwiw I don't believe Rakudo "lets you run all 170,000+ Perl 5 modules" either.

But when I have used Perl 5 CPAN modules in Perl 6 code I have found it works as simply as Zoffix describes in the blog post I linked in my earlier comment:

> For page fetching needs, I chose Perl 5's Mojo::UserAgent, since it has an HTML parser built-in. The :from<Perl5> adverb indicates to the compiler that we want to load a Perl 5, not Perl 6, module.

The Perl(-5) language is quite interesting because it is actually tiny. Unlike both PHP and Python, the "core language interpreter" is small because there is virtually nothing in it. Instead, a simple statement such as use DBI; brings in both Perl source-code and related binary drivers.

Therefore, from an entirely pragmatic viewpoint, "changes to 'the language itself'" don't really matter so much, because the real meat-and-potatoes work comes almost-exclusively from these "contributed" (sic ...) modules.

However, the implementation of "the language, itself," does thereby become quite important indeed. Sometimes, these venerable modules delve quite deeply into the so-called perlguts, but "it just works" because those authors knew precisely what they were doing at the time.

But the Perl-6 implementors (and, there have been quite a few of them ...) never quite seemed to reach any sort of consensus. For instance, some of them decided to abandon the Perl-5 runtime system altogether and to produce a compiler that produced object-code for (of all things ...) JVM. (Go ahead ... "Google It yourself.")

Yes, there were plenty of different groups of "very-earnest language implementors" out there, eagerly talking about a Brave New World™ for their beloved language, as though it could blissfully disconnect itself from its own multi-billion-line installed-systems past in a singular pursuit of language-purity nirvana.

Unfortunately: "success comes at a price." Companies build systems, using version X.Y of your language, that suddenly start producing millions of dollars of revenue each and every month. Therefore, all of the sudden, "non-nirvana issues" such as bu$ine$$ ri$k start to become deal-makers and deal-breakers.

In recent times, all three(!) of the "Big Three™" language systems ... Perl, PHP, and Python ... have (IMHO™...) run headlong into this concern, at the hands of their own respective inventors, who seem to be "ivory-tower unware."

It seems few of you were in on the threads when Perl-6 was first conceived. I was far out on the edge, but remember parts of it well, please let me add some history.

Perl-6 was not, and is not, supposed to be a 'Newer better Perl-5" the way Perl-5 was an improvement on Perl-4. Perl-5 is still alive and well. Perl-6 is a 'standard' and concept that looks at language in a whole new way. The idea was that it WOULD be a 'standard' rather than an implementation, and there would be many ways to implement that standard for different engines: both interpreted, compiled, and (as with Perl-5) a combination. Perl-6 should be able to generate like gcc, jdk, or any other translation engine by using them in the back end. The final compile should not have to change the way you build the SOURCE of your Perl-6 program. The idea was to make the language fit the people, rather than make the people conform to the language.

The concept is elegant. The execution seriously problematic. Some of the implementations are incredibly impressive, once you understand what they were attempting. When this fully works, it is a little bit like software magic with fireworks and rock and roll for developers!

Not quite there yet, but it has only been about 16 years. Considering the goal and how it has progressed, I am not at all upset with that. It can keep getting better for as long as it takes.

Meanwhile, I am still getting mileage from C, Pascal, Perl-5, Python, PHP, BASH, BASIC, COBOL (and Object Oriented COBOL), FORTRAN, and Forth.

While it might "look at language in a whole new way," the core fallacy of it is the literally-billions of lines of installed Perl source code that don't (and, can't) work that way. Languages of this type are extremely dynamic. They eval and do lots of other messy things that only an interpreted language can do. The collected source-code that does these things is responsible for billions of dollars of commerce, every day.

We already have so-called "transpilers," which produce source-code as output. (Haxe and OpenFL immediately come to my mind, because I use them a lot.)

If they wanted to do such a thing, they could do so, but, "that's not Perl." Call it Rakudo. (Or, call it Ruby, which basically trekked over the selfsame ground.)

They also made a critical error by "hijacking" the JVM runtime engine. Not only is JVM an insufferable pig(!), but it exists to support the Java language system, not Perl. (Well, some of the implementations did this. Others picked different implementations.)

So, we have a 16-year-old project that has produced several incompatible flavors of ... pure irrelevance.

Academically interesting "perhaps," if you are a language nerd. But, commercially irrelevant.

JM2CW™ ...

One of the first Linux conferences I went to had a perl developer speaking. At the q&a after I asked if I should learn perl now or wait for 6. Large discussion followed as things were still in a state of flux - I decided not to wait.

That was over a decade ago.

And, again you miss my point. Perhaps I made it badly, so let me try again. PERL6 DOES NOT REPLACE PERL5! And, it is not ONE implementation, there have already been several TOTALLY DIFFERENT implementations of some or all of the PERL6 standard. (I think PARROT was the first, but my memory is a bit fuzzy as I was getting married about that time.)

Despite the plan to make a nearly clean break with PERL5, there are things that carry over. That is no more relevant than that some code fits nicely into standard C or standard PASCAL (Or MODULA-3) if carefully written. It would be almost totally coincidental, except that in this case the developers REALLY LOVE both language PERL5 and PERL6 standards and LIKE it this way. Treat them as totally different engines that are good for totally different purposes (and some of the same purposes) and you will be a bit more on track. Another way to look at it: NO ONE IS FORCING, OR EVEN SUGGESTING, THAT THE RIGHT WAY TO TREAT PERL IS TO START USING PERL6 AND STOP USING PERL5! It is not an upgrade progression, rather an almost but not quite totally different language BY DESIGN.

Use both, use either, use something else: there is no basis for complaint here.

Perhaps they should have named the standard something else to avoid confusion.

About the JVM: I agree with your opinion. The PERL6 concept allows it to hyjack almost any backend runtime, and I hope that gets some general implementations that are more elegant than JVM sometime soon. At least it is not generating against the UCSD P-code runtime!