
Is Perl 6 Being Renamed? - mtmail
http://blogs.perl.org/users/ovid/2019/08/is-perl-6-being-renamed.html
======
mkozlows
To my mind, the blockers for Perl 6 adoption in order of importance have been:

1\. The name, saddling it with the legacy of Perl. (I say this as someone who
really liked working with Perl back in the waning years of the old millennium,
and believes that Perl was visionary in pointing the way to the state of
modern programming... but also that it had some limitations that have only
become more glaring over the years.)

2\. The coyness around whether it's "done" or not. Right now today, as someone
who has paid attention to Perl 6 and even written some toy code with it, I do
not understand its release status at all. That's absurd.

3\. The insistence on branding sub-components of it and exposing that
branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk
about ParrotVM and Rakudo as if they're different things? Java has a compiler
and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the
standard, the software you're running is Rakudo and Parrot" distinction is
totally irrelevant to anyone actually wanting to write code, and weirdly
confusing.

4\. In a distant, distant last place: any actual functional stuff about the
language.

~~~
dragontamer
> But why do people talk about ParrotVM and Rakudo as if they're different
> things? Java has a compiler and a VM, they're called "javac" and "jvm."

Bad example: Java actually has many VMs available for it: Oracle, OpenJDK,
Zing, and IBM come to mind. (EDIT: And "Dalvik", for all the Android fans).
I'm unsure if Java has multiple compilers, but its quite possible.

Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few
others.

When Perl 5 was huge, there were multiple VMs and interpreters: IronPerl comes
to mind as a Windows implementation back in the day that had different quirks
than the canonical Perl interpreter.

~~~
mkozlows
Sure, but most people don't know or care. They just type "python" and Python
happens. If they need to find another implementation, it's possible, but
there's no question about what the default implementation is.

~~~
dragontamer
> Sure, but most people don't know or care.

A lot of people care. It costs $3500 per server to run Zing Java. Every user
of Zing cares enough to pay $3500. Everyone who has written an Android app
cares about the distinction too. Dalvik has different quirks than regular
Java. (EDIT: Oh boy, that shows how out of date I am. Apparently Android is
now using Android Runtime instead of Dalvik....)

> If they need to find another implementation, it's possible, but there's no
> question about what the default implementation is.

The implementation can, and does, change without the language changing. That's
the unfortunate truth about real world deployments. As such, you need a unique
name for the interpreter.

~~~
ben509
>> Sure, but most people don't know or care.

> A lot of people care.

Both of these claims are true, but yours is missing the point.

You grow a userbase by appealing to people who _don 't_ use or understand your
product. People who are already invested to the point of spending $3500 for a
custom VM aren't the ones you're trying to clarify things for by using
consistent branding.

------
dkarl
_Routinely I see in numerous online discussions that people refuse to even
consider Perl 6 because they hate Perl. Or there are younger people who think
of Perl as "their grandfather's language" (in much the same way people in my
generation view COBOL)._

I am not a fan of Perl, but this feels tragic to me. Perl was so radically
different. I remember being on Perlmonks way back in the day, and someone
would post a question about why their code didn't work, and there would be
dozens of people who could instantly, intuitively post a corrected version of
the code, but then the poster would say "oh, shit, what was _my_ code doing?
and why does the correct code do something different?" and you'd be lucky if
there was a single person ( _cough_ chromatic) who could explain it. And none
of the Perl fans cared, because Perl made them extremely powerful and
productive, and they could (almost always) confidently produce a line of Perl
code that did what they wanted. The analogy to natural language carried
further into practice than Larry Wall could have dreamed. Nobody worries that
the difficulty of resolving linguistic conundrums impairs their ability to
have a conversation, and the Perl ninjas in my company enjoyed a very close
and chatty relationship with the systems they worked on.

I'm the opposite kind of person, who got sick to his stomach looking at a line
of code like !#$foo->%_[] (note: not real Perl) not knowing why it worked,
even if I wrote it and knew that it would work. Even now, I have a nagging
fear that if I executed "!#$foo->%_[] (note: not real Perl)" it would print
"Yes it is! Ha ha. Love, Larry" to the console. I can't stand that, so Perl
was never for me, but I still hope that against all odds this long, drawn-out
apparent deathbed scene turns out to be the middle of a successful
convalescence.

~~~
spiralx
> The analogy to natural language carried further into practice than Larry
> Wall could have dreamed.

Over the years I've seen this mantra repeated a million times but I've yet to
have anyone actually explain what it means beyond a piece of marketing fluff.
What actually is this analogy in concrete terms?

~~~
Qcombinator
A lot of languages — in fact, a lot of software in general — is designed to
make things easy for the computer/programmer: "This is how it works and you
just have to adapt, deal with it." Larry Wall put a lot of effort into making
Perl try to adapt to the way the user already thinks instead, including taking
advantage of having studied linguistics to figure out how the "language" part
of a computer language fits (or doesn't fit) the way our brains process
languages.

The result was a language that has a lot of power and flexibility. People who
like Perl tend to love it, because it fits like a tailor-made suit instead of
all those off-the-rack languages. People who dislike Perl tend to hate it,
because all that power and flexibility can be easily abused (even when you're
trying not to — there's a reason so many people buy off the rack instead of
making DIY suits).

•[https://bigthink.com/videos/why-perl-is-like-a-human-
languag...](https://bigthink.com/videos/why-perl-is-like-a-human-language)

•[https://www.perl.com/pub/1999/03/pm.html/](https://www.perl.com/pub/1999/03/pm.html/)

•[https://www.perl.com/pub/2007/12/06/soto-11.html/](https://www.perl.com/pub/2007/12/06/soto-11.html/)

~~~
thaumaturgy
I think there's a greater underlying dichotomy here that's relevant to your
tailor-made suit analogy: the people who love Perl tend to be the people who
are building and maintaining mostly only their own tooling and (usually small)
codebases, and the people who don't love Perl tend to be the ones that are
responsible for maintaining large piles of other people's code.

A language that's "tailor-made" for the individual is _fantastic_ when you
only have to deal with your own code. You get to write stuff that makes sense
to you. It doesn't matter if it's unconventional or doesn't make sense to
anyone else -- it fits the way that your brain works.

But when cooperating on larger projects with lots of other people involved,
this backfires remarkably. You now need to understand the way that half a
dozen or more other brains work.

As software development has gradually shifted away from the published efforts
of lone hackers and towards the collaborative efforts of teams of specialized
people, Perl's "TMTOWTDI" approach has made it a far more expensive language
to develop software in than all of the alternatives.

~~~
Jeema101
Do you have any data to back up the claim that it's "a far more expensive
language to develop software in than all of the alternatives"?

I feel like most scripting languages are pretty similar in terms of
productivity based on my own experiences anyway...

~~~
thaumaturgy
I was stating a syllogism there: understanding and working with different
coding styles is difficult, increased difficulty adds increased expense, and
Perl supports many different coding styles.

As far as I know, nobody's done a comprehensive cost analysis of similar
software built using different languages, methodologies, or architectures.
Certainly nothing recent. I've harped on this before quite loudly and I think
it's one of the reasons our industry can't be called "engineering".

People's individual experiences just don't make for good enough data because
there are too many confounding variables.

------
roryrjb
Perl 6 is probably a great language, I'm not very interested in it, for the
reasons someone might pick it, I'd probably pick a different language; of
course not for any logical reasons, but still. Perl 5 on the other hand is
still a great language for lots of reasons. I hope Perl 6 is renamed and Perl
5 will become Perl again and it will be reinvigorated and more people will
consider it again. Don't get me wrong, I don't use Perl day to day because of
the type of work I'm doing at $DAYJOB, but people like to dump on it for all
the wrong reasons or outdated reasons, but I still believe in it, and I think
a lot of people still do but there just isn't the mindshare and no matter what
we think about our industry and how it works, that ultimately means new
developers won't use it.

~~~
_pmf_
> Perl 6 is probably a great language,

Does it also have the unparseability problem[0] of Perl 5? That's a deal
breaker for a lot of tooling.

[0]
[https://perlmonks.org/?node_id=663393](https://perlmonks.org/?node_id=663393)

~~~
viraptor
This specific problem is not a deal breaker in practice. You solve the problem
by adding to the readme of the tool "If the arity of a function cannot be
established, we assume no arguments and print an warning. Add {foobar} before
the function to assume arguments. Sorry for inconvenience."

No language tooling is perfect. We shouldn't expect that from Perl tooling
either.

~~~
_pmf_
> No language tooling is perfect.

Java and C# tools are pretty close. But yeah, it's generally hard for dynamic
languages.

------
mmaunder
I'm sorry but Perl 6 isnt relevant IMO. It took too long. I was a Perl
developer at etoys.com in 2000 and BBC in 2001. I wrote OneMusic for Radio1
and even convinced the BBCs uptight ops team to run it with modperl so it
could handle the high traffic it did. I also created the job search engine
WorkZoo in modperl, one of Time Magazines top 50 sites of 2005 and Indeed's
main competitor at the time.

Perl6 was promised. Then it never happened. It's now an almost quarter century
later. The world has moved on. Taking that long for a single version update in
a language is not reasonable. I loved Perl. I still love Perl5. But I've moved
on and have 100% blocked Perl6 from my psyche and list of expectations. No one
I know uses it. I am not excited by it. I dont need it. And I don't care to
hear these discussions about minutia related to it. It's a debacle and a case
study in the failure of what was a beautifully ugly practical performant
language.

~~~
6thaccount2
If Perl6 is ever performant, I'll be dropping Python for a lot of Scripting
uses.

Perl6 is a big language, but has a lot of power and beauty.

~~~
petre
Yeah too bad it's slow. I write Perl 5 code at work on a daily basis and
really wanted to like Perl6. Too late, too slow.

~~~
6thaccount2
Lizormato and some other folks have put in hundreds of performance fixes...I
think these things just take time. The language might have been in development
and design since the 90's, but it only just got to 1.0 or a "stable release"
in 2017 I think. I'm surprised Larry Wall hasn't written a Perl6 book yet.
Plenty of other authors have, but I was really looking forward to something
from him or Damien Conway.

~~~
petre
I've installed just about every release since 2017. It's a nice language but
still slow and lacking library support. The best thing about it is probably
the rational math.

~~~
6thaccount2
Thanks for the information!

Yea... libraries are always good (especially for math and analysis), but I
find that powerful languages need far fewer libraries to get things done. APL
can do something with a few characters that might commonly be implemented as a
lengthy function or library in some languages.

Windows Powershell can surprisingly do a lot of what Perl 6 can do and people
mostly understand the limitations. You can automate processes, build your own
DSL, have full OO support, full .NET interop, concurrency, you can pipe data
around kind of like with FP...etc. It doesn't have some of the more perlish
features though.

------
DangerousPie
As an outsider who hasn't written perl code in more than a decade this all
makes a lot of sense to me.

I think of Perl 5 as something "outdated" because I know that there is a
language called Perl 6. When I think of Perl 6 I am not particularly
interested in it because I assume it's more or less the same as the "old"
Perl, which I don't use and didn't really like back in the day.

Renaming Perl 6 to something else would help with both of these problems.

That said, I wonder how much damage has already been done at this point and
whether renaming it now will still be very useful. There are a lot of
references to Perl 6 out there already, so convincing people that Perl 5 is
the latest version of Perl again will be tough.

~~~
goto11
If Perl 6 is renamed, Perl 5 could skip to Perl 7 in the next version to avoid
confusion.

~~~
wott
Yes for Perl 5->7, but it would be good to have a solid-ish feature change or
addition to justify the jump and promote it.

When I see that we still don't have a simple "is item 'in' set" operator, 12
(?) years after the introduction of smartmatch and 5 or 6 years after its
half-retraction...

(Well, we still have no sets either :-), let's talk about lists/arrays...)

When I see we still don't have a clean function parameters declaration system
(better than the mess with prototypes and signatures)...

When I see that constants, enums, simple structured data (C-like-ish structs)
still have to be simulated with functions and/or objects and the weight which
comes together...

...On one hand, it gives a set of features that could be used to justify a
jump. On the other hand, if these basic features has never been deemed useful
by the language leaders until now (that is, during a couple of decades), I
have little hope they will change their minds.

~~~
bmn__
There is little strain on the "language leaders" (that would be barking up the
wrong tree, anyway) as the features you named with one exception are already
done and have been available for years.

• "is item 'in' set" operator:
[https://metacpan.org/pod/Syntax::Feature::In](https://metacpan.org/pod/Syntax::Feature::In)

• sets:
[https://metacpan.org/pod/Set::Object](https://metacpan.org/pod/Set::Object)

• clean function parameters declaration system:
[https://metacpan.org/pod/Kavorka::Manual::Signatures](https://metacpan.org/pod/Kavorka::Manual::Signatures)

• constants that are not functions/objects:
[https://metacpan.org/pod/Const::Fast](https://metacpan.org/pod/Const::Fast)

• enums that are not functions/objects: ?

• structs that are not functions/objects: pack/unpack, for explanation see
[https://metacpan.org/pod/Convert::Binary::C](https://metacpan.org/pod/Convert::Binary::C)

------
nneonneo
> Perl 6 performance has now gotten to the point where it's often comparable
> to Perl 5 or surpasses it. It still needs some work in this area, but the
> work is clear, the goals are straightforward, and Perl 6 is going to easily
> oustrip Perl 5 in terms of performance. If the Perl 6 community wants to
> rename, it's perhaps the perfect time to do so. It doesn't look like a bad
> choice if performance is a primary concern.

Perl6 has been under development for over a decade at this point, and this
equivocating statement is the best that can be said about performance? If the
"work is clear, the goals are straightforward" and Perl 6 should easily
outstrip Perl 5 on performance, then by gosh they should demonstrate that.
Plenty of comments are mentioning slow performance. Not having used Perl 6
myself, I can't comment on it, but the fact that this seems to crop up a lot
is really worrying. I've heard varying things - regex/grammar are slower than
Perl5, startup time is really slow, etc.

And yes - I realize that technically the most popular compiler/VM combination
Rakudo+MoarVM hasn't had that full decade of development, and that the spec is
"in theory" performant. None of that matters to developers who just want to
use the language...

If performance is a major blocker to adoption and it's as straightforward to
fix as suggested - it should get done. Otherwise, the empty promises will
continue to hurt adoption.

~~~
Ovid
> Perl6 has been under development for over a decade at this point, and this
> equivocating statement is the best that can be said about performance? If
> the "work is clear, the goals are straightforward" and Perl 6 should easily
> outstrip Perl 5 on performance, then by gosh they should demonstrate that.

As the other of the post in question, I refer you to this presentation:
[https://www.youtube.com/watch?v=QNeu0wK92NE](https://www.youtube.com/watch?v=QNeu0wK92NE)

It's fairly decent, but there's still a huge amount of backstory left out of
it. In short: in many areas Perl 6 is pretty close to on par with most dynamic
languages today. In other areas, performance is still an issue.

> If performance is a major blocker to adoption and it's as straightforward to
> fix as suggested - it should get done.

(Disclaimer: I'm not the one doing the work mentioned below)

It's being done, but there's a lot of work. There's compile-time analysis with
constant folding, eliminating unnecessary scopes, inlining native ops, code
rewriting to faster equivalents, etc. But that can only take you so far.

The run time optimizer is hard work, but that's where the good stuff is at.
There's a very lightweight optimizer that builds a statistical model of the
program and that's very helpful. For example, we can tell if a codepath is hot
or not and that model than lets us do all sorts interesting stuff, such as
realizing that a hot method is always getting called with an int, so we can
skip multi-dispatch lookups, assume an int, and just have a fast guard in
place.

We can inline code where appropriate. We can do more escape analysis. We can
reoptimize code that's inlined at runtime. We can see an int->int and realize
that we might not need to box and unbox those as objects. See also:
[https://jnthn.net/papers/2019-gpw-ea.pdf](https://jnthn.net/papers/2019-gpw-
ea.pdf)

In short, there's a ton of stuff to do and it's being done.

~~~
Ovid
"author of the post in question"

God, what a horrible typo :)

------
jefftk
This makes a lot of sense. Renaming Perl 6 means:

* Perl 5 can continue being "perl" and have a future. People with existing perl codebases won't think they're going to need to upgrade.

* Camilia/Raku/etc can be considered on its own merits.

The C/C++ analogy is a good one: when things are different enough you stop
expecting everyone to "upgrade" and instead are making a different language.

~~~
derriz
I don't see any future for Perl5. Through a type of Osborne Effect -
[https://en.wikipedia.org/wiki/Osborne_effect](https://en.wikipedia.org/wiki/Osborne_effect)
\- the development of Perl 6 has also killed Perl 5. Few or none will reach
for Perl5 these days for new development - Python or Node.js have obliterated
Perl as contender in the space it used to dominate and I don't see Perl5 ever
muscling it's way back. Fairly or unfairly, Perl5 is viewed as a legacy tool
these days.

------
Grue3
Raku is a good name (can be abbreviated to 楽 as a bonus). Camelia is too long
and is already the name of the mascot. Ofun is terrible (nothing like a
product implying it's "fun" by literally including "fun" in the name).

~~~
tomlong
Especially when it can readily be pronounced "Zero Fun"

~~~
jmilloy
Just like how people readily pronounce your user name "Tzerom Lzerong"?

~~~
tomlong
Exactly

------
wombatpm
I learned Perl4 in grad school and it was a life changing tool to automate my
analysis workflow. With it I was able to script complex solutions that drove
stepper drivers and CCD cameras on a microscope for data and image collection.

I stayed through the Perl5 change over and thought it was good. Then I tried
OO programming. And cried. And read that Perl 6 would make it better. But I
needed something now, on a windows box, and free. That was 2003.

I tried Python and loved it.

Higher Order Perl made me appreciate what Perl could do, but the state of Perl
6 and lack of progress kept me away, as the features I most wanted were always
fixes coming real soon now.

I STILL program python. Perl had me and lost me. Perl might not be dead, but
it is dead to me.

~~~
aduitsis
What I got from mingling with the Perl community: The single most repeated
advice (indeed Larry Wall himself has said it repeatedly), is that one should
use whatever tool will allow one to carry out the task at hand and generally
get things done.

In that sense, Perl never had you because Perl probably isn't interested in
"having" anyone. Maybe helping out people carry out their work, but not having
them. It is about getting things done, without trying to be the next big thing
in CS. At least that's what I'd like to believe.

If Python helps you carry out your work better, you should most assuredly and
definitely use Python. Ditto with PHP, Go, and all the rest. And Perl.

------
AlexanderDhoore
Serious question: what does Perl 6 bring to the table? What advantage does it
provide over Perl 5, Python 2/3 or Ruby?

I could google this (which I will), but give me the HN summary. What do you
think is a good reason to use Perl 6?

~~~
patrickas
Off the top of my head: Concurrency and parallelism using high level and low
level APIs. There is no GIL.

Grammars which are like regular expressions on steroids for parsing. (
admittedly still not optimized for speed)

Gradual typing, you can go from no types at all for short one liners, to using
built in types, to defining your own complex types for big programs.

    
    
      subset Positive of Int where { $^number > 0; } #create a new type called Positive 
      multi factorial(1) { 1 } #multi subroutines that dispatch on type
      multi factorial(Positive \n) { n * factorial(n-1) } 
    
    
      #say factorial(0); #Error type mismatch
      #say factorial(5.5); #Error type mismatch
      say factorial(5); #120
    
      hyper for (1 .. 1000) -> $n { #use hyper indicate for loop can be run in parallel on all available CPUs
        say "Factorial of $n is { factorial($n) }"; #Gives correct results by automatically upgrading to big int when needed
      }

------
cutler
I don't get all this "Perl 6 is a different language" nonsense. It was created
by Larry Wall and retains all the characteristics of Perl 5 whilst adding a
lot of great stuff from other languages. Sadly, performance prevents it being
taken seriously in production.

~~~
pjc50
It's a different language because you can't run Perl5 programs unmodified in
Perl6. The same is also true of Python2/Python3, which is why that transition
has also taken so long. The difference is they managed to do it without
everyone abandoning Python2 for something else.

~~~
empath75
It’s pretty easy to upgrade most code from python 2 to 3 and a lot of code
just runs as is. The reason the upgrade path was so slow, imo, is that even a
reasonably small amount of work is still work, and for a lot of people, the
benefits didn’t justify spending any time at all rewriting software that
already worked.

~~~
chucksmash
After the initial round of "useful PyPI packages don't support Python 3
though, I can't migrate", that "I know 3.x is different and I'll have to read
up on the differences....later" was absolutely the biggest blocker for
adoption imo.

I know proficient Python programmers who were starting projects from scratch
in 2017 and didn't want to use Python 3.x because they were in a hurry,
worried that they didn't know how to write Python 3.x in a timely manner
because they hadn't invested the time to learn it. Lots and lots of people
just knew it was a known unknown for them, had no idea of the magnitude of the
effort required to switch (tiny for new projects! tiiiny) and just put "look
into this" somewhere deep on their backlog.

------
pavon
I think this is a great idea that is two decades too late. Many people say
that python killed perl, and that is true for those who disliked perl.
However, I think perl 6 killed perl for those who liked it, or could have
liked it if they learned it. The knowledge that there was a new version on the
way that would have all power of perl, but fixed many of its problems took the
wind out of perl's sail, especially once it became clear how different it was
going to be. Why invest time into learning perl 5, when perl 6 was just around
the corner? How do I defend my use of perl 5 in production, when its own
creators have moved on? Best to just concede the battle, and regroup for the
war when perl 6 is ready ... and then it never was.

I really think that both languages would be stronger today if Larry Wall et.
al. had "marketed" perl 6 as a research sandbox for new ideas for language
design, and then depending on where those ideas led them, pronounced it as
either a successor to perl, or a new language when it was closer to ready.

------
jpm_sd
I suggest "Perl Nukem Forever"

~~~
DonHopkins
Perhaps something onomatopoeic like "$#_@;\>&%}`[*~!^)"

~~~
coldpie
As a non-perl programmer, the mnemonic descriptions in the perlvar manpage
crack me up. They probably are useful and make sense to perl programmers, but
from the outside, they look like parody.

~~~
nocman
I don't think you should place too much emphasis/concern/whatever on most of
the special variables available in Perl 5. I would wager that most Perl
programmers never use about 95% of them (that is, the short 2-3 character ones
listed on that man page).

At the very least, I would guess, most Perl programmers _almost_ never use 95%
of them -- and many would choose (as the perlvar man page says) to 'use
English;' \-- and thus use the readable version. An example would be using
$LIST_SEPARATOR instead of $" (which is what I would do).

I write Perl 5 code frequently, and that man page is chock full of short
variable names I never use.

~~~
DonHopkins
Yet you have to know both versions of them all, and be able to recognize and
understand both kinds when reading other people's code.

How does it improve the language to be so top-heavy and chock-full of obscure
unreadable arbitrary syntax, 95% of which nobody every uses, but that everyone
still needs to memorize and understand in order to read?

That's exactly why Perl's philosophy of TMTOWTDI is intellectually bankrupt,
and encourages write-only "creative snowflake" Perl code that's an
inscrutable, unreadable, unmaintainable nightmare.

The language isn't any better for having $" as a shortcut for $LIST_SEPARATOR
(or $LIST_SEPARATOR as a mnemonic for $", depending on how you look at it),
because now you have to learn twice as many things, and all that duplicated
effort and mental stress and syntactic surface area doesn't make it any more
powerful or easy to use, has absolutely no tangible benefits, only pointless
costs, and makes it twice as hard to learn and read and maintain Perl code.

~~~
perigrin
> Yet you have to know both versions of them all, and be able to recognize and
> understand both kinds when reading other people's code.

You have to be able to understand that if it's a two character variable of all
punctuation you may need to look it up to figure out what it is. Typing
`!perldoc $"` into duck duck go sent me to
[https://perldoc.pl/variables/$%22](https://perldoc.pl/variables/$%22) ...
which is roughly equivalent to `!g [docker error]` which I already do all day
long.

~~~
marcosdumay

        $ perldoc '$'
        No documentation found for "$"
    

I hope perldoc search improved on Perl6, because it only used to match section
titles, and none of the line noise vars are there.

(Yes, after a while one should learn yo search for the section that explains
all the vars, at least if he's coding Perl all day. But it's a ton of useless
trivia to keep in mind anyway.)

~~~
Grinnz
The correct invocation to search for a variable named $" (not $) is perldoc -v
'$"', which the variable search on perldoc.pl was modeled after.

A glance at "man perldoc" (or "perldoc perldoc") will tell you of the very
useful other switches, such as -f and -q.

------
mcdermott
Perl 6 was a huge mistake; it's a different language and should have never had
the same name. I support renaming it so we can all forget about it and have
Perl 7 be a direct, mostly backwards compatible descendant of Perl 5 with
feature enhancements. This whole Perl 6 nonsense was the reason I jumped to
Python many years ago.

~~~
cestith
I don't think the language was a mistake, but it looks like the naming was.

------
hyperpape
I think this is a good idea, but there's a decent chance that some people will
mishear the change as "Perl 6 is cancelled, Perl is dead".

To be honest, I'm not sure anything can change the decline of Perl. There will
continue to be Perl projects and Perl shops for a long time, just as there are
COBOL projects, and COBOL shops. There will even be some new projects. But
many projects will die, some companies will go out of business or migrate, and
the ecosystem will continue to ossify.

------
meijer
As a German, I don't like the name "Camelia" very much because it is
associated with hygiene products here (brand name).

"Raku" sounds nicer for me.

~~~
cestith
Anecdotally, "Meijer" is one of my favorite retail chains in the US.

------
gmiller123456
I think it was CPAN that killed Perl, at least that was a major nail in the
coffin for me. I have no idea what the CPAN of today is like, but back in the
mid-late 90's it was horribly unreliable. There were dozens, if not hundreds
of modules that did the same thing, and a lot of them had major bugs. But
installing one was the big issue, as it would always choose the latest release
of any module in the dependency chain, including the perl interpreter itself.
And this was done without any hint as to whether the module actually worked
with the latest versions of those modules. So, you'd end up upgrading a bunch
of modules, very likely breaking things that worked. And at the end, it'd
"upgrade" the perl interpreter. And by "upgrade" I mean install a new copy,
replace all OS references to the new version, but not include any of those
modules you just installed. So you had to re-install everything again.

Perl's main use at the time was developing CGI scripts. It had big
disadvantages over things like PHP and Netscape Commerce at the time, but
people still seemed to like Perl. As complex web side code grew more complex,
requiring a lot of 3rd party components to get Perl to do anything, people
seemed to abandoned it pretty quickly.

I still use Perl today, version 5. Mostly just to process text files, but I
still don't use any 3rd party libs.

~~~
ether_at_cpan
> But installing one was the big issue, as it would always choose the latest
> release of any module in the dependency chain, including the perl
> interpreter itself.

You are mistaken. No cpan client is capable of upgrading perl itself. If a
cpan module declares a dependency on a perl version later than what you are
currently running, the installation simply fails (as what would happen if
there is a dependency declaration on a module that is shipped with core and is
not upgradable separately, e.g. 'strict' or 'POSIX').

~~~
peteretep
This is true now, but was not true many years ago.

~~~
Grinnz
To put some numbers in this thread, it was fixed in CPAN.pm version 1.90 in
2007, which first came with Perls 5.8.9 and 5.10.0 (but can be updated on
older Perls).

------
pvaldes
Maybe Perl 5 should be renamed to Perl 7...

~~~
AlexanderDhoore
You say this as a joke, but that might actually be a good idea.

~~~
DonHopkins
Then what's the next version of Perl 6 supposed to be, Perl 8? And the next
version of Perl 7 will be Perl 9... From then on their version numbers will
leapfrog each other to keep Even Perl and Odd Perl in parity.

~~~
beefhash
> Then what's the next version of Perl 6 supposed to be

raku 2? Perl 5 gets the Perl name back and gets a version number leap to show
it's not dead yet and raku is off doing its own thing with its own version
numbers, probably hitting 1.0 barely before GNU Hurd.

~~~
DonHopkins
Rakuier

PINP: PINP Is Not Perl

------
harry8
perl5 needed a single switch to make it loosey-goosey anything goes otherwise
have use strict and -w by default.

That one decision cost the language so very much. I miss Perl. Python is what
was pushed on me by employers and it's fine, it's perfectly acceptable. As is
ruby and many others but I just miss Perl.

I hope the Perl6/Raku folks get things happening in their tech and perception
of it the way they might like. I think they deserve a break.

------
dragonsh
I think the name Camelia or Raku is fine, no need to argue over it forever.
During this renaissance period of computer languages in history, it will be
nice to get this out and iterate. Given there are plethora of choices today
like go, rust, Nim, elm, elixir, Scala, julia, crystal, F#, D etc. trying for
developer mindshare which is a limited resource speed is of essence.

Indeed with parrot VM besides perl 6 developers can be truly polyglot with
same toolchain. So move forward, it's still a great addition. I feel parrot is
truly open source, better than Graal no Oracle involvement.

~~~
riffraff
parrot (as a multi language vm) has been dead for a long time, the GraalVM is
probably the current best bet for a polyglot platform.

~~~
dragonsh
Yeah that's sad Perl 6 moved to moarvm[1]. I guess necessary evil to have
performance which they can't get out of parrot.

Hopefully someone pick up Moar with Rakudo and make it multi-lingual. Given
Oracle involvement in GraalVM, it will always be a risk for open source
development.

[1] [http://www.moarvm.org/](http://www.moarvm.org/)

------
thesuperbigfrog
Perl 6 should definitely be renamed so that Perl 5 can just be Perl.

An easy way to see this is to simply look at the mascot for each language.

Perl_5 => Humphrey the Camel (See
[https://www.perl.org/](https://www.perl.org/)) (I am not sure if the camel
actually has a name, so Humphrey seems like a good name for a camel mascot.)

Perl_6 => Camelia the Butterfly (See [https://perl6.org/](https://perl6.org/))

They are very different and the languages are too, so why should the languages
both be called "Perl X" ?

------
peterwwillis
I wish Perl 5 was being renamed. As a language, it's annoying, but as a tool,
it's possibly the best programmable tool ever made.

------
mark_l_watson
Jeremy Howard (co-founder of Fastmail (Perl used for everything), co-founder
of fast.ai, etc.) in his Lex Firdman interview this week, made some
interesting comments on Perl and Larry Wall no longer taking enough interest
in the language. I don't use Perl, but the comments were interesting anyway.

~~~
sundarurfriend
Link: [https://lexfridman.com/jeremy-howard/](https://lexfridman.com/jeremy-
howard/) to the podcast episode that I guess you're referring to. Thanks for
mentioning it, will check it out.

------
cannedslime
I rarely see Perl in the wild today. Only companies that are too big too fail
and too cheap to move on still clings on to Perl, the big "index" sites of the
late 90'ies that somehow haven't been completely run into the ground by
silicon valley giants like monster, facebook, linkedin etc.

------
amptorn
They renamed Perl 6 to "Raku" last year!! Am I losing my mind? This is a done
deal!
[https://marketing.perl6.org/id/1541379592/pdf_digital](https://marketing.perl6.org/id/1541379592/pdf_digital)

~~~
Grinnz
That announced that it could be used as a second name, but provided no further
guidance, so Perl 6 is still used by many thus its problems are still just as
present. This proposal would be to actually consistently use Raku as the name
of the language.

~~~
amptorn
Wouldn't it have made more sense to hold off on the first announcement until
there was consensus on a single new name, instead of having two or three
inconsistent namesoperating simultaneously for a year? Neither of which might
be the final one?

~~~
Grinnz
A lot of things would have made more sense in hindsight, but it's not where
the community was at the time, and ultimately Larry said no to a straight
rename. He is taking less of a role now so it can be revisited.

------
mojuba
I think an interesting question is, if the developers of Perl 6 knew from the
beginning that they are essentially designing a new language with a new
identity, would their new language be different and to what extent?

~~~
de_watcher
Developers now want to grab old folks by using old name and new ones by using
new name. Politically they can do that because there is a Perl 5 faction
existing because of the big differences between 5 and 6.

------
ThomWilhelm3
This is a bit like people arguing over the what noise should be made when the
"tree falls in the woods and no one hears it".

------
zests
I want to write some scripts that are _slightly_ too complicated for bash.
Basically just implementing some simple scripts that have a couple
options/args and I want to use another tool.

How good would perl 5/6 be for this?

If not perl, anything similar that's not python? I want to learn something
new.

~~~
daotoad
As I said elsewhere in this thread, check out my article for the 2018 Perl6
Advent Calendar.

[https://perl6advent.wordpress.com/2018/12/16/day-17-checking...](https://perl6advent.wordpress.com/2018/12/16/day-17-checking-
your-list-twice/)

I walk through the development of a utility for auditing Santa's Naughty and
Nice lists. Along the way, I introduce literate programming, multiple
dispatch, types, type subsets, links to documentation, perl6 collections, and
File IO. And, I've been told I managed to do all this without making the
reader they've been dragged over rough ground behind a certain festive sleigh.

The key thing to remember when you start learning a Larry Wall Language is
that you only need to worry about the parts you need to worry about. It's more
like learning a natural language than a programming language. Learn how to say
the things that are important to you, and it will serve you well even if you
speak with an accent.

------
cryptozeus
“Perl 6 is a sister language, part of the Perl family, not intended as a
replacement for Perl 5, but as its own thing - libraries exist to allow you to
call Perl 5 code from Perl 6 programs and vice versa.”

Umm.

~~~
daotoad
You can also call Python from both languages. It doesn't mean they are the
same.

[https://metacpan.org/pod/distribution/Inline-
Python/Python.p...](https://metacpan.org/pod/distribution/Inline-
Python/Python.pod)

[https://github.com/niner/Inline-Python](https://github.com/niner/Inline-
Python)

------
nvr219
I love open source drama

------
lelf
> _s /Perl/$other_language/g_

I’m somehow not sure Perl6 has anything to do with that.

> _because they 're tired of waiting for Perl 6_

But…for what exactly? It’s already stable enough for use.

~~~
tyingq
Reasonable performance

~~~
lelf
It is.

Ref:
[https://www.youtube.com/watch?v=S5iVBlk7pdg&t=279m33s](https://www.youtube.com/watch?v=S5iVBlk7pdg&t=279m33s)
“Perl 6 Performance Update”

~~~
tyingq
Do perl5 vs perl6 benchmarks exist somewhere? Google produced nothing
recent/relevant.

------
kazinator
Although the "Perl" name in "Perl 6" is basically wrong and misleading, it's
also the only reason Perl 6 is a blip on anyone's radar.

------
mikl
Until Perl6 is actually released, it doesn’t really matter what they call it.

(yes, I know they have functional snapshot builds, but as long as there’s not
a final "6.0" (or "1.0") release, expect most devs to steer clear of it. Few
people (masochists, mostly) want to use an ‘experimental’ programming language
for important work).

~~~
dragonwriter
> Until Perl6 is actually released, it doesn’t really matter what they call
> it.

> (yes, I know they have functional snapshot builds, but as long as there’s
> not a final "6.0" (or "1.0") release, expect most devs to steer clear of it.
> Few people (masochists, mostly) want to use an ‘experimental’ programming
> language for important work).

The “1.0” for the Perl 6 spec (6.c, because reasons) was released in 2015; the
stable implementation in Rakudo was a little later but years ago. Current
Rakudo has a stable, production-ready implementation of last year's 6.d
version of the language spec. So we’re _well_ past the threshold you suggest.

~~~
Qcombinator
Then it should have been called "1.0". Calling it "DEFINITELY NOT 1.0" while
deciding that that is secret P6 code for "really means 1.0" is awfully bad
marketing.

(More seriously, slow performance, missing features, bugs, etc. were part of
the reason for not calling it "1.0", but I would agree that to be really
successful, the language needs a release that is called 1.0 and acts like it.)

~~~
dragonwriter
> Then it should have been called "1.0".

6.c was described, both before and after its release, as being the “1.0”
release of the Perl 6 language.

> More seriously, slow performance, missing features, bugs, etc. were part of
> the reason for not calling it "1.0"

No, they weren't.

The first “production-ready” release of Rakudo Star release was shortly after
the 6.c spec release, in version 2016.01 (Rakudo Star uses date-based versions
numbers.) If they were using semver-ish numbering for Star releases rather
than dates, this would have been the 1.0 implementation (as opposed to spec)
release.

------
dmix
I've got to agree Raku is way better than Cameila.

Although I understand why the female developer couple would want a female
name. It just doesn't sound like a programming language and shorter the better
(nothing beats Ruby).

~~~
cestith
Camelia is the name of the butterfly mascot, hence the suggestion to use it as
the name of the language.

rakudo, the language tool, basically translates as "way of the camel" playing
on the use of the camel as Perl's O'Reilly book mascot. "Raku" or "raku",
would basically be calling the language "camel" and the tool "way of the
camel" which has a certain appeal as well. However, the camel has never been
really directly associated specifically with the new language except in the
names rakudo and raku.

So as I see it, there are good arguments for either side of this. Knowing Liz
and Wendy I doubt their suggestion has much more to do with being girly than
my feelings on the matter. I think it has more to do with making the clean
break really, really clean.

Unfortunately all this furor within the community and even from without has
nearly convinced both ladies to leave the community they've been pillars of
for two and a half decades. They've suffered personal attacks over this and
their participation in anything Perl related is likely to be curtailed if not
ended. It's a sad, sad day because Wendy's one of my favorite people at the
conferences.

~~~
dmix
Oh apologies I made an assumption there I probably shouldn’t have.

To me naming is was mostly how it rolls off the tounge so I’m not a fan of
multi syllable words that aren’t super common.

I’m also not a fan of ‘clever’ words that have dual meaning, like tattoos it
should mostly be an aesthetic thing.

But I’m not surprised when I hear communities responding to change poorly. Any
large community has this problem and it’s best to ignore the rancour. Not
everyone should have an opinion and there’s nothing that attracts more than a
name. So it will come down to personal taste.

I’d 100% defer to the primary devs on this one.

------
k__
What did Perl do better than others when it came out?

~~~
marcosdumay
It was shell scripting with reasonable arithmetic and an incredibly good
support for text consumption and regular expressions. Everything you'd miss on
a normal shell.

But it scales only slightly better than sh into large programs.

~~~
k__
I see.

Would you consider Bash on-par with Perl?

~~~
marcosdumay
No, I wouldn't. Perl 5 is much more powerful.

But I wouldn't choose either for a moderately large script.

~~~
k__
Ah okay.

But back in the days? Bash seems to be released a year or so after Perl.

~~~
marcosdumay
Bash is a much better shell, mostly because you don't have to quote shell
commands. Perl 5 is a much better scripting language.

If it was not for Python and Ruby, Perl would still be the language to go for
scripts. But I don't think anybody ever used it interactively.

------
foobar_
Raku, Camelia and Rakudo are stupid names.

Perl++ is a good name. C and C++ are different enough and live alongside each
other.

~~~
cat199
but this brings up C++, if in name only, which wouldn't always win you fans..

~~~
foobar_
The cool part about old 90s Perl5 was ... it was doing its own thing. The best
part about everyone hating you ... gives you the freedom to do precisely that.

I don't like the proposed names because they seem to imply a new language. You
need Perl in the goddamn name.

I honestly think the biggest mistake that Perl5 made was going the OOP garbage
way, which complicated the language as it was implemented as a hack. And
everyone just said ... look Perl, ha ha ... can't do OOP!

OOP in all its forms is a mistake. Small talk OOP, CLOS, Java OOP .... sheesh
it's just a hash with sub refs. C gives you function pointers and structs. OOP
should have been limited to just fucking that.

Encapsulation is a mistake. Inheritance is a mistake. Polymorphism is useless
in a dynamic language.

------
vincent-toups
If I ever wanted to program in Perl, I'd program in J.

------
xweb
I haven't worked with Perl in 20 years, but obviously totes:

Perl++

amirite?

 _joking_

------
markstos
Rebrand.

------
cyrc
Suggestion for rename: Pearl 1

------
adamnemecek
I'm not surprised that the language is dying. They seem to be spending time on
things no one cares about and things that are inconsequential.

~~~
jerf
This is by far the most important thing they could be doing right now. It
should have been done 10-15 years ago, and is arguably the dominant remaining
reason for why the work done on both Perls since Perl 6 has failed to payoff
the way it should have.

There is a certain contingent of developers who _should_ have been all over
Perl 6 and very excited about it. We should have been seeing the stream of
"$COMMON_LIBRARY but in Perl 6!" postings on HN for a couple of years, along
with the blog posts of "look how crap this is to write in $OTHER_LANGUAGE but
with this bit here and there look at how slick the Perl 6 solution is!" every
couple of weeks. We should be seeing blog posts about the joys of working in a
language with built-in grammar support replacing the old ad-hoc regex support,
and how well it integrates with the rest of the features. We should have even
eventually seen the contrarian backlash posts about how much of a mess you can
make if you overload all your operators and grammar constructs and use all the
features at once in an ill-advised manner, followed by comment thread semi-
flamewars about whether bad code is the fault of the programmer or the
language.

But we didn't.

Bias disclosure: I actually have no interest in Perl 6, so this isn't
advocacy. Anything I've ever seen that Perl 6 looks interesting _to me_
(emphasis) for, I'd rather just use Haskell, which I've already learned and
actually does quite a lot of what Perl 6 does. But Perl 6 does it without
being a immutable functional programming language, making this all a lot more
accessible to a lot of programmers. I'm not saying _I 'm_ interested in Perl
6; I'm saying, there is definitely a chunk of programmers who _should have
been_ interested in it who are not.

And from what I can see, this naming confusion is one of the major reasons.

(One other one I would point to is the Perl 6 community's multi-year "joke"
that Perl 6 would be released "next Christmas", which nobody outside of the
Perl 6 community found even slightly funny, instead creating a reputation for
the community that overpromises and underdelivers; that a few people would
swoop in to those conversations to actually mock people who weren't insiders
enough to know it was a joke and not a real promise, which is to say,
99.9999999% of humanity (that is not random nines; that is all but ~700
people; take one off if you like), really didn't help. I put "remaining
reason" in my first paragraph because this has been resolved for many years
now. But I can tell you that this significantly diminished my own personal
interest, and I'm sure I'm not alone.

Finally, I'd point to it just never being done, but, arguably, that alone
couldn't have killed it. There's plenty of languages that grow quite
substantially over time; the Python of when Python first really got popular
and the Python of today are _very_ different, for instance. Had more people
been interested and pushing for something usable $TODAY, with more work being
done later, this probably wouldn't have been as big a deal.)

~~~
DonHopkins
I believe Perl 5's decline and Perl 6's failure to catch on is evidence of the
failure of their common underlying TMTOWTDI philosophy, which encourages
write-only "creative snowflake" Perl code that's an inscrutable, unreadable,
unmaintainable nightmare. (The sigil-heavy line-noise syntax sure doesn't
help, either.)

[https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...](https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it)

[http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt](http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt)

While I believe Python's continuing success is evidence supporting the truth
of its Zen of Python philosophy: "There should be one — and preferably only
one — obvious way to do it."

[https://www.python.org/dev/peps/pep-0020/](https://www.python.org/dev/peps/pep-0020/)

~~~
jerf
So I basically agree with you & jschwartzi. But to expand or reinforce my
original point, it is very clear there is a substantial contingent of
programmers who do not. While of course in my own opinion, my own opinion is
correct (duh), at a more global level, or maybe in a more academic sense, I'm
open to the possibility that I'm wrong. I've already flopped on that matter
once in my career and I reserve the right to be convinced by another language
that I'm wrong now, too.

~~~
Qcombinator
You don't have to be "wrong". You just have to be not exactly the same as
everybody else. And of course, nobody is exactly the same as everybody else,
therefore there is not possible for there to be such a thing as The One
Perfect Language. The right tool for the job; but also the right tool for the
workman.

------
Stubb
I haven't looked at Perl in years, having long ago switched to Python/SciPy,
but now I see that Perl 6 doesn't have GIL, something that Python has been
unable to shed. So now a language that nobody cares about anymore solves the
#1 problem that I have with Python. We are truly blessed to have so many
shitty implementations of dumb programming languages to choose from these
days!

~~~
Grinnz
I am a Perl user not Raku, and Perl had almost the opposite problem where its
threads _are_ concurrent but too badly designed to be useful. But from what I
have seen, Raku is second to none in this capability.

~~~
Stubb
Being able to do a multi-threaded map() would be divine. In Python, you're
creating/destroying a new process and using IPC to seed the state info and
return the results for each element in the iterable arg. If the function in
question runs quickly, it ends up being faster to do it single threaded.

~~~
Grinnz
It's not going to be efficiently threaded like in Raku, but this is also
possible in Perl 5 with a few modules from CPAN.
[https://metacpan.org/pod/IO::Async::Function](https://metacpan.org/pod/IO::Async::Function)
will maintain a preforked pool of processes (on Unix) or threads (on Windows),
and return Futures, which can be used by fmap_concat from
[https://metacpan.org/pod/Future::Utils](https://metacpan.org/pod/Future::Utils)
to make a very map-looking iteration. The experimental
[https://metacpan.org/pod/Future::AsyncAwait](https://metacpan.org/pod/Future::AsyncAwait)
will make this even more natural in the future.

~~~
Stubb
I'm continually astounded that threading involves jumping through so many
hoops in 2019. If you want a language that provides a REPL and easy threading,
your choices are few and far between.

------
veidr
whorl

EDIT: no, I'm serious and that's a cool (enough) and available name with the
right amount of historical correlation

EDIT 2: plus it already has an emoji icon on most platforms:
[https://emojipedia.org/fish-cake-with-swirl-
design/](https://emojipedia.org/fish-cake-with-swirl-design/)

