A meditation on the naming of perl6

[stevieb]

An interesting meditation by zoffix on a potential name tweak to perl6 over on Perl blogs.

[BrowserUk]

My verdict would be: too little, and far too late. The damage -- significant damage -- to both language variants was done and dusted a long time since. Sad to say, but I think recovery at this stage is impossible for both camps.

In part, the marginalisation of Perl(X) has come about because different parts of its once hugely broad domain wanted different things from it.

• The web market wanted a simpler language, substituting built-ins for common patterns of code: They got PHP.

  Server side for 'simple' websites that is. For anything interactive Javascript/JQuery is really the only player in a game that Perl simply had no cards in.

• The math/science/CS people wanted less magic and more rigour: they got Python.
• The embedded market wanted smaller, cleaner, reentrant: they got Lua.
• The corporate IT world wanted "reusable code" -- despite that 95% of reusable code is never reused -- and that means objects: they got Java.

Even without the self-inflicted wounds caused by the naming, delays and infighting, Perl was always going to have a tough time to compete on all fronts. With them, it stood no chance.

Whilst I still use Perl5 for prototyping, I haven't produced a 'production program' in it for over 2 years.

[RonW]

When I was still a university student, the CS department was steeped in Scheme. Meanwhile, in engineering, we were using C and a little assembly language as needed. One of the CS classes I took also used some Pascal (because the professor was steeped in Pascal and still learning Scheme). A few of the engineering libraries were written in FORTRAN, still around because "if it ain't broke, don't replace it". But mostly, we coded in C.

Now, many years later, as a professional developer in the embedded market, still using C. In the testing group, many of the tools they use have various dialects of Lua as scripting languages. Several use Excel spreadsheets as their scripting "language". A few use "Labview" (National Instruments' graphical programming system for their test controllers).

Perl is our data munging and "build script" language. It gets the job done, usually very nicely.

The IT departments of my current and past 2 employers code in Power Shell, C# and SAP Scripting language.

The network admins, though, use Perl and bash.

I don't know what other companies use.

[BrowserUk]

Perl's utility hasn't and won't go away. In 10 years or 20 it will still be as good a language as it ever was; and that's very damn good. The problem will be finding companies that are prepared to accept it's use on their projects & systems.

Eg. For anything that needs to work with AWS until very recently you were totally out of luck. As of 2015, a community effort started to put together a Perl interface to it in the shape of PAWS. By roughly the beginning of this year, they had something that could be seen as reasonably robust; for those AWS services it covers. But that set is only a subset of those available; and the delay between AWS adding new ones and those becoming available via PAWS grows longer.

These problems do not occur for the users of Go, Java, JavaScript, PHP, Python, Ruby, Windows and .NET, C++; for which AWS write and maintain the interfaces and mostly release simultaneously with the announcement of new APIs.

As an in-house perl programmer, you will tend to move between companies that use Perl; as a specialist consultant, the pieces of work I choose from tend to come from a small range of organisations many of whom are now outsourcing the type of workloads I code to AWS/GCP/MAS; none of whom offer Perl support, thus the Perl opportunities in my field have dried up.

I hate to say that the battle is lost; but I see no way back when those 3 cloud vendors cover 9x% of that market place and they -- for pretty sound reasons -- have rejected Perl.

[Anonymous Monk]

The Perl 6 language—to which I shall refer to as Rakudo language, for the rest of the article—is versioned separately from its implementations and is defined by the specification.

(Emphasis is mine.) And I thought Rakudo (and rakudo) was an implementation of Perl 6, not a specification itself. Also, did not think Zoffix Z would be the one to conflate the two. Dang it!

[1nickt]

While it is perhaps a positive sign to see that it's finally dawning on one of the leading "Perl6" advocates that the butterfly language is not actually Perl (as per the globally accepted meaning of that term), it's unfortunately not much help.

The problem is that this particular bandwagon-jumper, er ... advocate, came so much later to the "party" than the other bandwagon-jumpers, er ... advocates, who have been busily staking a claim in the hoped-for "Perl6" gold rush, writing books about a non-production ready language they are learning, running crowd-funding campaigns to underwrite the aforementioned, etc. Those folks all have too much invested in the wrong name, as the blogger acknowledged.

On the other hand his hubris is so enormous that he's apparently unilaterally changing the name in his own writings, and heaven knows that hubris has been the hallmark of the butterfly language so far, so he might just succeed in his quest. Too bad it's only half the job. Perhaps the '6' could be deprecated and phased out over a year or two. 'Rakudo Perl' and 'Perl 7'* -- I could get behind that.

* or 'Perl 28' or even just keep going with 'Perl 5.28 .. Perl 5.99' so long as the damn '6' were dropped)