
Myths about Perl 6 - lizmat
https://aearnus.github.io/2019/07/06/perl-6-is-cursed
======
jannotti
Oh man. I don't know what to say. In the process of trying to bust myths, this
confirmed every practical concern that the "myths" actually express.

Perhaps the worst was: "Myth: Perl 6 will never be finished"

The author of this actually tried to argue against that "myth" by saying,
"Perl 6 is defined as a set of test cases." and goes on to say that since the
tests were written long ago Perl 6 is done, and has been since like, forever.

If that's the level of "Well, actually..." that this community uses, you can
see why they've become irrelevant.

I LOVED Perl.

~~~
wolfgke
> Oh man. I don't know what to say. In the process of trying to bust myths,
> this confirmed every practical concern that the "myths" actually express.

I think this is part of the joke.

~~~
runn1ng
He replied to me on twitter, it’s not supposed to be a satire

[https://twitter.com/aearnus/status/1147960078680485889?s=21](https://twitter.com/aearnus/status/1147960078680485889?s=21)

~~~
wolfgke
Thanks for the clarification.

This all reminds me of Poe's law

>
> [https://en.wikipedia.org/w/index.php?title=Poe%27s_law&oldid...](https://en.wikipedia.org/w/index.php?title=Poe%27s_law&oldid=905113307)

"[W]ithout a clear indicator of the author's intent, it is impossible to
create a parody of extreme views so obviously exaggerated that it cannot be
mistaken by some readers for a sincere expression of the parodied views."

------
the_duke
This almost seems like satire, but not quite. But then again it really does.

> Perl 6’s lack of a niche is the language’s niche.

> Perl 6’s compilers may not implement the language in its entirety yet, but
> that does not mean the language is incomplete.

> Language is inconsistent. Ideas are inconsistent. Reality is inconsistent.

> It is so dense with information that skipping a single symbol might
> drastically change your interpretation of the entire bit of code.

> That’s why Perl 6 is introduced slowly and softly – using a little subset
> that the community likes to call “baby Perl 6”

> The priority was never speed, it was all-encompassing expressivity.

Also, a page by the same author [1], with a comic awarding Perl 6 with "worlds
worst ML, worst Python, worst C and worst Smalltalk".

\---

I would personally assume that the goal here is to provide a humorous and
intentionally a self-ironic explanation. The message seems to be something
like "Perl 6 has many flaws. There is a reason for them though, and I still
like it."

[1] [https://aearnus.github.io/2019/04/05/perl6-is-the-world-s-
wo...](https://aearnus.github.io/2019/04/05/perl6-is-the-world-s-worst-ml)

~~~
jhanschoo
> Hopefully though this post will convince you to drop that veil of hatred and
> see the intentions behind these design decisions.

I suppose that the article honestly achieved what it said it set out to do.

It's just that those design decisions are more like what one expected from (an
albeit well-thought-out) toy or hobby language rather than a next iteration of
one of the most ubiquitous languages during its heyday.

That's where most of the hate and disappointment comes from, the mismatch of
expectations.

I suppose that the article and that previous linked page were written
deliberately to both seem like a satire to the extent that you viewed it as a
mainstream scripting language, and an useful overview of Perl 6 to the extent
that you are willing to let it be a toy language or an experiment.

From the kind of community and values that Perl advocates has always had,
arguably Perl 6 is a natural evolution from Perl 5. But earlier versions of
Perl were the right language in the right place when the hashes-and-arrays
dynamic interpretable languages started to gain traction over the heavyweight
OOP C-style languages for tasks (web servers, etc.) that would increasingly
becoming more heavyweight, so there was this expectation that Perl would
evolve to serve this community's needs when it didn't, leading to the mismatch
of expectations.

~~~
microtherion
> From the kind of community and values that Perl advocates has always had,
> arguably Perl 6 is a natural evolution from Perl 5.

I think it's fair to say that Perl 6 represents the values of some very
prominent Perl advocates, but not necessarily all of the community.

Perl 5 was (is) both a rather eclectic and an eminently practical language. In
my view, Perl 6 doubled down on the eclecticism when many users had expected
it to double down on the practicality.

~~~
raiph
> In my view, Perl 6 doubled down on the eclecticism when many users had
> expected it to double down on the practicality.

Is your view of its practicality based on using it heavily or have you mostly
or completely left it alone because it's too slow or seems too eclectic or
some other reason?

~~~
jhanschoo
From the linked article, Perl 6 tries to support all kinds of paradigms. This
really detracts from professional development where communicating code and
clear code is necessary.

Every language that supports too many paradigms or gives too much expressive
power to the user eventually has a "the good parts" books that proscribes a
conventional way to program in that language in a professional setting.

~~~
b2gills
Perl 6 supports all kinds of paradigms, this makes it so that you don't have
to write parts of the code in different languages and try to cobble them
together.

So the code can be written using the clearest paradigm for the task at hand
without switching languages.

\---

The only real bad parts of Perl6 that I can see, is the parts that are copied
from elsewhere largely unmodified.

The C-style `for` loop is one such example.

    
    
        loop ( my int $a = 0 ; $a < 10 ; ++$a ) {
            print("hi\n");
        }
    

Why would anyone write that when they could write this instead:

    
    
        print("hi\n") xx 10;
    

Where there isn't a chance for an off-by-one error, or accidently creating an
infinite loop.

You can still use it to intentionally create an infinite loop:

    
    
        my @a = rand xx ∞; # a lazy infinite array of random floating point numbers.
    

\---

After someone would write a “the good parts” book, the next major version of
the language would probably fix many if not all of the not-so-good parts.

If there is a feature that isn't one of “the good parts”, we'll just change it
until it is.

That's one of the great features of being an easily mutable language, you can
mutate it into a better language. (It already has mutated in some small ways.)

\---

Perl6 doesn't have too many paradigms, if anything it has too few. I would
love if it had support for implicit auto currying like Haskell does. (Instead
I have to settle for explicit currying.)

------
ben509
Thinking about the point of Perl6...

I was trying to work out how to best structure a website to explain a
language, so I did a quick survey of existing sites. It's very interesting
what different languages choose to put on that first screen you see.

Many of them have a tagline. "Python is a programming language that lets you
work quickly and integrate systems more effectively." or "Welcome to the Swift
community. Together we are working to build a programming language to empower
everyone to turn their ideas into apps on any platform." or "Ruby is... A
dynamic, open source programming language with a focus on simplicity and
productivity. It has an elegant syntax that is natural to read and easy to
write."

Perl6.org has this opening pitch:

"Hi, my name is Camelia. I'm the spokesbug for Perl 6, the plucky little
sister of Perl 5. Like her world-famous big sister, Perl 6 intends to carry
forward the high ideals of the Perl community. Perl 6 is currently being
developed by a team of dedicated and enthusiastic volunteers. You can help
too. The only requirement is that you know how to be nice to all kinds of
people (and butterflies). Go to #perl6 (irc.freenode.net) and someone will be
glad to help you get started."

It's focused on idealism and community; whereas other language sites are
focused pretty strictly on making a case to users, Perl6 is presented as a fun
hobby where you can meet nice people. It strikes me as a bit of a call back to
the early days of computing when it was more oriented towards the hobbyist
than industry.

If you accept the premise that the language exists primarily for people to
have fun using the language, many of the design decisions make a lot more
sense. Given that Perl5 has largely been supplanted by Python and Ruby, trying
to fill that niche is a bit redundant. While other languages are making
deliberate decisions to make sure a person trying to use their language can
get work done, if someone has to go to a Perl6 forum to ask questions and talk
about it, that's not a problem, that's largely the point.

~~~
lizmat
Being a person who has been able to make a living doing fun things almost all
of her life, I would argue that it is important for any programming language
to be fun when you're working with it. If it not, it is just $work. I feel
that if you do not have fun in what you do for a living, you cannot be
creative in what you do. And if you as a programmer can not be creative in
what you create, you're just a commodity soon to be replaced by a small AI.

~~~
wvh
Perhaps, but at the end of the day, people need to eat; and programming
languages and their ecosystems apparently need a serious effort and even
corporate support to make sure they don't hobble behind the times at risk to
become irrelevant.

I used to code a lot in Perl5, and I thought it was fun in a more creative way
than languages like Python; but it's a hard sell this days. I mostly code in
the Go language nowadays, which is decisively less fun and creative in itself,
but it brings other paradigms like interconnecting services that then allow
you to be creative in a different way than the "poetry" of the language
itself.

~~~
cutler
Try Clojure for both fun and productivity.

------
idlewords
I was a huge fan of Perl from the early 2000's, in large part because the
community around it was eclectic and helpful. Perl was ugly and useful and for
a long time the easiest way to get things done if you were dealing with random
stuff from the web.

My business (Pinboard) runs on a perl5 backend. The over-decade-long
transition to Perl 6 has not only alienated me from wanting to do more
development in the language, but made me look like an idiot back in _2002_
when I championed Perl 6 to my bosses as the wave of the future.

In my opinion, getting rid of the main appeal of the language ("it just
works") was a suicidal move. I admire and respect Larry Wall, but I am not
going near this language again. At this point, it feels more like a religious
cult than a tool to get things done.

~~~
xref
Why is it that Perl (apparently) didn’t survive the transition from 5->6, but
after years of acrimony Python looks like it will survive the 2->3 transition?

~~~
cygx
Perl6 was a reaction to Perl5's loss of mindshare, but it took a very long
time to arrive and still cannot be used as a drop-in replacement for the
latter. It has rather different strengths and weaknesses and thus has to find
a new niche to live in.

~~~
microtherion
> Perl6 was a reaction to Perl5's loss of mindshare

That's not the way I remember it. The Perl 6 effort was announced in 2000, and
(at least by the ever-fickle TIOBE index), Perl marketshare kept growing until
2003 and did not start declining until 2005:

[https://www.tiobe.com/tiobe-index/perl/](https://www.tiobe.com/tiobe-
index/perl/)

~~~
raiph
The GP spoke of mindshare. Marketshare shifts frequently lag shifts in
mindshare by years.

Some Perl fora had started to become hostile by 1999. It had clearly begun to
lose core talent and something needed to be done about that.

~~~
microtherion
There was plenty of hostility in 1996, too. By 2000, certainly some people
decided something needed to be done about the hostility, but I don't recall
"core talent" leaving over it.

~~~
raiph
Maybe I'm wrong. My memory is too hazy on it partly because I was just an
outsider looking in. I know some "important people" quit p5p, but could well
believe they didn't quit the community. [1]

[1]
[https://www.perl.com/pub/2000/05/p5pdigest/THISWEEK-20000507...](https://www.perl.com/pub/2000/05/p5pdigest/THISWEEK-20000507.html/#Moderation_is_Imminent)

------
gtirloni
_> If you don’t know Perl 6, it will fly right over your head. It is so dense
with information that skipping a single symbol might drastically change your
interpretation of the entire bit of code_

How that isn't a problem for the author is beyond me. Different target
audiences I guess (but another point in the article is that there isn't a
target audience, other than existing Perl 5 users, which is pretty vague).

I like to think I'm pretty open-minded to language's choices and I sure have
my own preferences but this article didn't do much to change my image that
Perl 6 isn't going to be even mildly adopted.

I liked that it explained the Rakudo Star, zef and other things about the Perl
6 infrastructure though.

~~~
angrygoat
This stuck out for me too. Sheer information density per character isn't
something I value in a programming language.

Being able to be clear and concise is certainly desirable. But that's not in
any way the same thing; orthogonal high level concepts (iterators jump to
mind) are great ways to hide complexity while keeping code clear, but ten
characters of line noise where every symbol has some subtle meaning will turn
into a nightmare when you've got five hundred lines of noise to make sense out
of.

I'm not a huge fan of Go, but as a counter-example to what's in this post, you
can really see the virtues of the keep-it-simple approach the Go language
designers have taken.

~~~
zzzcpan
Go relies on naming for everything, which pushes information density into
naming where every symbol could have special meaning and special behavior too
[1], but not consistent, universal or shaped and enforced by the compiler. It
means more code to understand and write while less language syntax to learn.
Other approach is to have more syntax, which can be more consistent,
universal, flexible and therefore require less code to understand and write.
Information density doesn't really change it's just syntax is more useful in
more cases so it can replace a lot more specially crafted library functions.

[1] [https://golang.org/pkg/regexp/](https://golang.org/pkg/regexp/)

~~~
nrdvana
I hadn't thought about it that way before, but I like and agree with this
analysis. While method names can contain all the information, it requires more
words and you end up with a Java-style mess
thatContainsTheWholeAlgorithmInTheName. The punctuation is almost like having
a bunch of one-cahracter standard names that everyone understands without
having to agree on standard conventions.

------
geofft
It makes perfect sense to say that the target demographic of English is
English speakers—or more precisely, the target demographic of Modern English
is Middle English speakers who wanted a few simpler rules, some continental
vocabulary, following other contemporaneous European languages in not having þ
and distinguishing i and j, etc. It was a relatively small change and very
intentionally served a community of people who already spoke Middle English
well. It was the Python 2-to-3 of English.

The target demographic of Esperanto, meanwhile, was the whole world: people
who already had a language, people who already had a workable lingua franca in
international contexts (French, later English), and in particular people who
_weren 't_ familiar with the European language patterns that Esperanto was
largely based on. So it had limited success. A Japanese or Indonesian or
Persian or Swahili diplomat not familiar with any European language would be
better served learning French or English than Esperanto, because those
languages are roughly equally foreign, there are many more resources for
learning French or English, there is a larger community and more people to
speak to, there is a larger corpus of works, etc. And an Anglophone or
Francophone diplomat has very little incentive to learn Esperanto, either.

Modern Hebrew, on the other hand, had a well-identified target demographic:
Jews from around the world migrating to the reestablished state of Israel who
lacked a shared everyday language. Some liturgical Hebrew was already familiar
to most of this population, and there was a strong cultural willingness to see
a reestablished Hebrew language. So while it is in many senses a conlang, it
was far more successful than Esperanto and now has a large community of native
speakers.

So the question of whether a programming language—especially one that is so
much like a conlang, not an incremental evolution based on use in practice
(like the C standards committee accepting compiler-specific dialectal
changes)—has a target demographic is a fair one.

------
overgard
The reasoning on #1 is amusing. "It's finished because the test cases are
finished".

Can you imagine going to your boss and saying:

Coder: "The program is finished"

Boss: "Cool, when can I demo it?"

Coder: "Well you can't actually run it, but all the test cases are finished,
someone just needs to fill in an implementation"

(And yes, I get that the implementation is usable. But if the language has
been done "forever" and the implementation is still partial... maybe the
language is a little too complicated?)

Also the argument that it doesn't need a demographic holds no weight to me.
Lets say I read through the Perl docs and go, holy crap, I totally want to use
this at work. I still need to convince others.

"We should use Perl 6 for our next project"

"Why?"

Reasons that might actually be convincing: we can hire for it, it's more
productive/safe/faster than what we use, the tooling is great, Big Company X
is behind it. Reasons I could use for Perl 6: It's uh, slow and the
interpreter isn't really finished and the internet generally regards it as a
joke, but, I can express ideas that usually require words with symbols
instead.

~~~
Spivak
I mean it's not that absurd that Perl 6 _the language_ the defined
independently of any particular implementation of it. Perl 6 seems unique (in
a good way) that the language isn't defined by "whatever the reference
compiler does" but by "this known fixed suite of tests."

~~~
overgard
It's definitely not unique in that regard, C++ is the same way.

The difference though is C++ is old and established. Perl 6 is relatively new,
and it seems crazy to me to say it's "done" if the first iteration of the
language spec hasn't even been fully implemented yet.

Also when the C++ committee says something like "C++ 20 is done", that news is
generally not super useful to me. It's something I tuck away as something I
might use eventually. I'm way more interested in "Clang/VC++ is now C++20
compliant", because then I can actually use it.

~~~
raiph
In P6 culture, the word "spec" is considered an ambiguous word that can mean
several very different things including:

* Specification. The P6 language is specified by a test suite called Roast. There are "release" tags, for example 6.c, 6.c.errata, and 6.d. If a program passes the suite it's "officially" entitled to call itself a P6 compiler for the language versions it passes.

* Speculation. Discussion, ideas, RFCs, a large range of design documents written in English that were once called "specification" documents but were never intended to be a substitute for the binary precision and decision of a test suite, multiple compiler prototypes, etc.

Thus:

> the first iteration of the language spec hasn't even been fully implemented
> yet.

Rakudo fully implemented 6.c, the first iteration of the _electronic_ language
spec, 3 years ago.

> I'm way more interested in "Clang/VC++ is now C++20 compliant", because then
> I can actually use it.

Exactly. P6 has focused on having a digital specification.

If someone wants to know if a compiler is compliant, they can run a test and
know within minutes.

If you prefer a specification written in natural language, and claims of
compliance to be relative to that natural language specification, and consider
tests secondary, well, all I can say is that the P6 view is the other way
around.

If your point is that a couple hundred thousand tests isn't enough, then yes,
you have a very good point, one can never have too few tests, but one has to
start somewhere.

(There's also Toast, which is like Roast, but applied to the entire ecosystem,
running compilers against the test suites of all publicly available modules.
cf cpantesters.)

------
harry8
I'm unclear from this whether perl 6 is finished and usable. The argument that
the language is finished but the compilers may not be seems odd. Is the "main"
perl 6 compiler finished? With a language like perl be it 5 or 6 or python 2
or 3 people will conflate the language with the implementation because the
assumption will be there will be one leading implementation and other niche
implementations of interest to specialists. Saying perl 6 is not finished (is
it?) means it is lacking somehow in its design and/or primary implementation.
So is it?

This sort of looks like a language standardisation committee argument tactic.
We're not responsible for each C compiler, it should be clear which are
standards compliant. Larry used to say he'd be standardised before perl would
be.

~~~
sverige
There has been considerable discussion in the Perl 6 community that they
should have named it something else besides "Perl," like maybe "Rakudo." In
many ways, it's not really a descendant of Perl 5 and prior versions. It's
really an entirely different language.

I wish they'd stop calling it Perl already. Perl 5 is still actively
maintained and developed.

------
ken
> So let me pose a rhetorical question: what is English’s target demographic?
> How do you even answer that? Is it tautological?

I think it's a perfectly valid question, and my answer is: people who live in
English-speaking regions. English has pushed beyond that into business and
technology, but every natural language's first and primary demographic is the
geographic or cultural region in which it's spoken.

The main purpose of a spoken language is to be spoken, and people can't do
that if they aren't around other people who speak it.

> Modern English was constructed from Middle English with various features
> changed to more closely represent the format of colloquial speech.

That's a misleading way to phrase it. "Constructed language" is a linguistic
term, and English isn't one.

All of this is neither here nor there because natural languages and
programming languages are almost completely different beasts. I have still not
seen any examples of where a fact or process or history in one could be used
to draw any valid conclusions about the other.

> To answer the question more directly: Perl 6’s lack of a niche is the
> language’s niche.

That's a _direct_ answer? I feel like this whole FAQ is just an exercise in
twisting the meaning of words.

------
audiometry
Paraphrasing: Myth 1 “Perl is not finished”. Why is it a myth? Because a
language spec is complete, there just aren’t any compilers for the full spec.
“

Come on....

A few myths down it becomes even more confusing when it talks about subsets of
Perl and compilers for those subsets.

I thought for a moment maybe this is satirical but I think the defenses were
honestly given.

Anyway I am not involved in Perl and not attacking it. If it works for you,
then great.

~~~
jannotti
Exactly! After the first two "myths" I truly thought I was being trolled by
some well-crafted geek satire.

~~~
dkarl
My money is on satire.

> Modern English came to be as a solution to the fact that Old and Middle
> English weren’t very good languages – or, at the very least, they didn’t
> represent their usages any longer.

It's either satire or mental illness.

~~~
KirinDave
This comment is not okay, by the rules of the site here or the basic tenants
of civility.

~~~
dkarl
You couldn't include the community standards of HN. We often speculatively
diagnose mental illness based on disorganized reasoning and bizarre arguments.
See for example the recent submission of a mathematics site where a fair
portion of the discussion was about whether the author might suffer from
paranoid schizophrenia.

I don't know why we feel fine publicly speculating about the mental health of
people who seem to be clearly suffering in some way, but in a case where the
odds are in favor of intentional trolling the topic becomes taboo.

~~~
KirinDave
"These arguments aren't well written, therefore this person is mentally ill"
is a terrible argument to defend.

~~~
dkarl
That's not what I said. I don't think the section I quoted is meant to have a
literal meaning any different from what it says, so it's well enough written
as it stands. The bizarre leaps of logic are either a humorous wink to
acknowledge that the author is writing ironically (which, again, is my guess)
or a reflection of an impaired relationship with reality. My guess is that
it's a reflection of how far you have to reach to ensure that people recognize
ironic writing, the phenomenon known online as Poe's Law. I only mentioned
mental illness to force the comparison for context. Really, I think the
question is what relation the face-value writing in this piece has to what the
author believes, which honestly I can't make head nor tail of. Are they a Perl
6 fan humorously acknowledging the difficulty of putting an optimistic spin on
the status quo? Are they expressing disrespect for the criticisms by refusing
to answer them straightforwardly (trolling, essentially?) Or are they trolling
people who still have hope for Perl 6? I never expected to like Perl 6, but I
always hoped for it to be a stimulating presence, so I guess I wonder if I'm
being trolled myself as well.

~~~
nkurz
The author has commented on Twitter that the entire piece is not satire and is
meant to be taken seriously:
[https://twitter.com/aearnus/status/1147960078680485889?s=21](https://twitter.com/aearnus/status/1147960078680485889?s=21)

I don't think you are being trolled. Instead, I think you are jumping somewhat
unkindly to an unfounded conclusion. Rather than satire or mental illness, I
think you are encountering "earnestness" combined with a mind that doesn't
work like yours.

------
cutler
I started with Perl5 around 2001 and loved it, especially its superb regex
handling. I certainly don't "hate" Perl6 but I think a lot of excuses have
been made over the years since its release for its terrible performance. Perl5
distinguished itself with superb regex performance yet Perl6 is still over 9
times slower than Perl5 (and 5 times slower than Ruby) in performing what
Perl5 excelled at - parsing a web server's log file. Until Perl6's performance
at least matches Ruby's for basic parsing (no, not grammars) it's not going to
be taken seriously no matter how many other tricks it has up its sleeve.

~~~
raiph
> Perl6 is still over 9 times slower than Perl5

Any chance you can share what code, data, and compiler version you used to get
those numbers?

> Until Perl6's performance at least matches Ruby's for basic parsing (no, not
> grammars) it's not going to be taken seriously no matter how many other
> tricks it has up its sleeve.

I agree it's still slow but question your prognosis. For example, I think devs
who care about O(1) handling of graphemes will use it when it's fast enough
for them. And its multi prompt continuation control
flow/concurrency/parallel/async design is bearing fruit.

But even if you're right, I see no reason not to think that P6 will keep
getting faster and develop nicely throughout the 2020s.

~~~
cutler
Perl 5.26.3, Ruby 2.6.3, Rakudo Star 2019.03.1 all running on OS X 10.12.6

    
    
        use v6;
        for 'logs1.txt'.IO.lines -> $line {
          say $line if $line ~~ m/<<\w ** 15>>/;
        }

~~~
raiph
Thanks!

One fly in the ointment is that you didn't share anything about the data,
especially its encoding and what sort of multilingual text it contained, nor
the code for the other proglangs.

One upshot is that I'm now wondering if you're comparing apples with oranges.

P6 is optimized for Unicode, making handling of Unicode simple, with O(1)
character (grapheme) indexing.

For example, in P6 regex syntax, << and \w, which are related to the concept
"word character", refer to _graphemes_ ("what a user thinks of as a
character") whose base codepoint has the "word" property. And \w __15 refers
to 15 of these graphemes.

In contrast \w in P5 regex syntax, by default, refers to a _codepoint_ with
the "word" property, not a grapheme. And I'm not sure what support Ruby has
for graphemes.

So I'm wondering if your log text was utf8, and if so, if you took the
codepoint/grapheme distinction into account.

~~~
cutler
The data was a 19Mb web server log file so pretty standard stuff. I've heard
these sort of excuses for Perl 6's sluggishness before. Whatever exalted
abilities Perl 6 may have it's pretty meaningless if that comes at the expense
of performance on more basic tasks. Besides, modern Rubies use utf-8 by
default so the comparison still stands. I'd also be surprised if the latest
Perl 5 wasn't also unicode compatible.

~~~
raiph
> The data was a 19Mb web server log file so pretty standard stuff.

Then it should be treated as likely being Unicode text, likely utf8, and
possibly containing text of any language supported by Unicode, unless you
expressly know otherwise.

In which case, unless you specifically ensured your regexes were written to
process characters as graphemes then they're incorrect.

Of course, if your logs only contain English text or text in other languages
whose alphabets only use one codepoint per character then they'll have worked.
But so what?

> I've heard these sort of excuses for Perl 6's sluggishness before.

Have you understood them?

Are you saying you defend fast, if only English people visited a website, but
incorrect if Indian people did, over sluggish but correct no matter who visits
a website?

> Whatever exalted abilities Perl 6 may have it's pretty meaningless if that
> comes at the expense of performance on more basic tasks.

Caring about performantly doing basic things without caring how badly they're
done is wrong headed.

What I'm speaking of here isn't some exalted thing. It's about absolute basics
and being correct: C=G, Character=Grapheme, per the Unicode standard. Just as
an ASCII byte is no longer the valid character unit of a web server log, so
too a codepoint isn't either.

Apple, and hence Swift, gets this right, because they understood the need to
handle text correctly. In the meantime, most others are using proglangs (and
regex engines) designed before there was widespread awareness of how Unicode
actually works.

(It's incredible but true that the latest Python 3 doc still doesn't even
_mention_ the word "grapheme". This contrasts incredibly sharply with P5 doc
which has included discussion of the impending trainwreck of graphemes for
over 2 decades but unfortunately can't dig out from the sheer complexity of
dealing with it in a backwards compatible way. Hence the infamous
[https://stackoverflow.com/a/6163129/1077672](https://stackoverflow.com/a/6163129/1077672)
Still, I'd rather have P5's honesty and correctness than Python 3's vapid
head-in-sand burying.)

> Besides, modern Rubies use utf-8 by default so the comparison still stands.
> I'd also be surprised if the latest Perl 5 wasn't also unicode compatible.

The issue isn't about being Unicode compatible for an entire string. (Which
for your log files could be one line.) It's about characters and substrings
(and regex pattern matches).

There is no issue if your web server log only contains English. Likewise if it
only contains text in other simple languages for which C=C,
Character=Codepoint. But how do you know your log doesn't contain, say, Indian
text?

Even though P5 and Ruby are Unicode compatible at the level of entire strings,
and P5 has one of the best legacy regex implementations for dealing with
graphemes, it's still the case that if you write regexes without explicitly
taking graphemes into account, then those regexes will fail when applied to
Unicode text that contains C=G text such as Indian text.

------
KirinDave
Honestly, I've considered getting back into Perl 6. Python is so wretchedly
regressive and I'm just not a fan of the decisions made in Ruby (although I
confess whenever I need to slice up a string or something in a way I don't
immediately know in Bash it's a sbcl or irb shell I call out to).

Perl 6's philosophy of _redistributing_ complexity and providing more than one
notation because different notations have different effective use cases has
always deeply appealed to me. Not just because I think it's true (most folks
think their language makes things simply only because a library writer has
done a huge sum of work to make specialists feel awesome rather than actually
face the reality of the library), but because I think that it leads to a more
honest organizational approach to software by allowing different folks to
focus on different areas within the same code-base and share the load more
horizontally as opposed to hierarchically.

On a more personal level, I really miss the days when I was excited about
scripting languages. To some extent, I am less excited because languages like
Haskell and Clojure have come into their own and are so expressive you often
don't need a scripting language to make progress fast in domains they have
good libraries for. But still, the days when I felt like scripting languages
were trying to actually address the machine-cycle-human-effort tradeoff is
past us. Ruby and Javascript have largely stopped innovating radically, with
only incremental changes since 2012 that I see. Python will forever squat on
its 2008-style mentality that all programming is terrible, and Lua is
constrained by its design space to have an extremely minimalist feature set.
Languages like Pike are largely gone, and it sorta feels like only a few Lisps
like PLT Scheme have kept pushing forward on these ideas.

I guess I'm also sad that other folks seem to have such radical double
standards for Perl 6 in the comments here. The only way it seems it _could_
succeed is if it was faster than Lua while being more featureful than Ruby
while also being exactly as regressive as Python. But none of the languages
mentioned here would actually meet any one of those criterion outside of
itself (even if it were possible to mix them).

~~~
overgard
I don't see any double standards. Nobody saying it has to be ALL of things,
but it needs to be at least _some_ of those things. I've yet to hear a single
compelling reason for why I should use Perl 6 over anything else. The blog
post itself is saying "you don't need a why", which just seems untrue. It's
not enough for Perl 6 to exist, for me to invest time I need to know what the
point of that time investment is. Pretty much every popular language has some
reason why you should use it:

c -> it maps to the machine well

perl5 -> C and Bash are bad at string processing

python -> C is too hard to use for a lot of simple problems, perl is
complicated

Haskell -> Side effects cause too many problems

javascript -> It runs in a web browser

java -> C is a loaded footgun

The languages that all become rarely visited niches all have one thing in
common: they don't have a compelling use case. They always say "all use
cases", but frankly, anything that tries to be everything to everyone almost
always ends up not being particularly compelling to any one group.

~~~
KirinDave
> I've yet to hear a single compelling reason for why I should use Perl 6 over
> anything else.

At any point, did someone promise you this?

> The blog post itself is saying "you don't need a why",

A refreshing proposition! It's honest that the decision is arbitrary in most
cases.

> It's not enough for Perl 6 to exist, for me to invest time I need to know
> what the point of that time investment is.

I say this respectfully: within this limited context I don't think anyone
cares about the whats compared to the why.

EDIT: Since you're dramatically editing the content:

> c -> it maps to the machine well

This is _ridiculous_. C doesn't map well to the hardware _at all_. It maps
well to the primitives the OS's interfaces were written in, not the machine.

> The languages that all become rarely visited niches all have one thing in
> common: they don't have a compelling use case.

As I've suggested elsewhere, I think this is a reductive view.

> They always say "all use cases", but frankly, anything that tries to be
> everything to everyone almost always ends up not being particularly
> compelling to any one group.

Why not? Python's strategy seems pretty close to this (only with a promise of
mediocre results).

~~~
overgard
>> I've yet to hear a single compelling reason for why I should use Perl 6
over anything else.

> At any point, did someone promise you this?

Of course not. and I'm not disappointed or betrayed. I'm just, um, not going
to use it. Presumably they would prefer that I (in an impersonal sense) did
use it, and I am unconvinced.

> > The blog post itself is saying "you don't need a why",

> A refreshing proposition! It's honest that the decision is arbitrary in most
> cases.

Huh? On almost any successful project, the choice of something as important as
the language isn't _arbitrary_ at all. The choice between, I don't know, Ruby
and Python might be arbitrary, but it's still bounded by constraints of what
domain they operate in. Nobody in their right mind is saying "whatever lets
just use J and APL for our OS kernel". If their argument is "use Perl 6
because, it doesn't matter anyway and it's 70 degrees outside and the sky is
purple today" I don't think they're going to win many converts.

> This is ridiculous. C doesn't map well to the hardware at all. It maps well
> to the primitives the OS's interfaces were written in, not the machine.

I mean, it originally did when it was invented 40 yearsish ago. It was
colloquially called a "portable assembler" for a reason. It's still a lot
closer to hardware than most other languages.

Even assembler doesn't really map to what hardware does anymore. So it goes.
The point is that there's a reason why you'd use C.

> > The languages that all become rarely visited niches all have one thing in
> common: they don't have a compelling use case.

> As I've suggested elsewhere, I think this is a reductive view.

I mean, ok, but "reductive view" doesn't mean anything to me.

------
tomalpha
I’m an old Perl 5 dev. I haven’t touched it in years apart from the occasional
mega-one-liner (that I find strangely satisfying).

I’d lost touch with Perl 6’s progress way back when. This was an interesting
read for me just finding out how far it’s gotten.

I don’t know if I’ll end up using it, but I’ll definitely take another look.

~~~
totalperspectiv
At this point, I'm more excited about the direction and changes in Perl5. It's
been steadily chugging away through all the drama and keeps getting better.

The following talk covers most of those improvements, as well as some of the
new direction: [https://youtu.be/4wKyNYs7eZw](https://youtu.be/4wKyNYs7eZw)

------
Isamu
I always enjoyed Perl 5 and still do. Never got the point of 6, always seemed
unnecessary and still does.

5 is very pleasant for your own scripting and most heavy lifting tasks,
nothing else has ever been quite as quick and fun.

Maybe not a great choice for a company-wide tooling language, because it is
too easy to write in a way that others find offensive, or else draconian
standards are enforced that turn it into another language, and at that point
why not just use Python?

------
Jach
The quoted bit at the end makes me a bit sad:

> That’s why I devoted two decades of my life to helping ensure that Perl 6
> lets you solve problems in whatever (reasonable) way that suits you…and
> suits your problem! By all means solve the majority of your problem
> functionally, but implement the inherently stateful parts of your program
> with objects, and handle the intrinsically linguistic components with
> declarative grammars. But do it all in the same language and at whatever
> granularity you are most comfortable with.

Why? This could just as well describe Common Lisp. Sure depending on the exact
expressiveness you want you'll have to bootstrap it with some paren-containing
bits, but I suspect you wouldn't need 20 years to do it, and there's a lot
there already...

Perl 6 has long been my "desert island" language. That is, if I'm going to be
stranded on a desert island with certain death in the near future, I'd get the
most kicks in the time left out of discovering all of Perl 6's secrets and
quirks. I don't think I'll ever use it seriously though... I would like if its
built-in grammars system spread to other languages like PCREs did but that
doesn't seem likely.

------
gravitas
_> Myth: Perl 6 is hard to read._

    
    
        [[&g]] (1..100)».&f
    

...OK.

 _> Myth: Perl 6 is too complicated and too hard to learn._

    
    
        C  Chaining infix  != ≠ == < <= ≤ > >= ≥ eq ne lt le gt ge ~~ === eqv !eqv =~= ≅ (elem) (cont) (<) (>) (<=) (>=) (<+) (>+) ∈ ∉ ∋ ∌ ⊂ ⊄ ⊃ ⊅ ⊆ ⊈ ⊇ ⊉ ≼ ≽
    

...OK.

~~~
benj111
"[[&g]] (1..100)».&f"

In all fairness you can construct an obtuse example for any programming
language.

~~~
tyingq
It's verbatim from the blog post. To be fair, the author is trying to make the
point you're making.

~~~
raiph
The OP is making the point that A) it's _extremely_ easy to read if you know
the language and B) it's extremely easy to learn the language and C) it's
extremely easy to think something is hard to read just because you don't know
the language.

Some hints:

    
    
        sub add ($left, $right) { $left + $right }
    
        add 1,2         # call function add as listop; yields 3
        1 [&add] 2      # use function add as infix; yields 3
        [+] 1,2,3       # sticks + between numbers; yields 6
        [[&add]] 1,2,3  # sticks add between numbers; yields 6
    
        1..100          # numeric range between 1 and 100
        (1..100)        # so postfix applies to range, not 100
        
        »           # parallelizable map passing values 1..100
        .           # call a method as the mapped function
        &f          # function f gets called 100 times with
                    # its first arg values 1..100

------
dmitriid
As I grow older, I end up preferring “boring” languages.

They have predictability, discoverability, learnability. And all within the
limits of a person’s life.

A code by programmer A that does X is not significantly different than code
that does the same X by programmer B. Even if that programmer is myself 6
months or 10 years apart.

An algorithm X will loom like X in the standard library, in a third-party
library, or in a random snippet from stack overflow.

A mismatched or ommitted character willnot (usually) alter the bahaviour of a
program in orthogonal ways.

You will not need a magnifying glass to read a mish-mash of ASCII math symbols
to figure out whether someone built a death ray, or just a milk shaker.

~~~
KirinDave
> A code by programmer A that does X is not significantly different than code
> that does the same X by programmer B. Even if that programmer is myself 6
> months or 10 years apart.

Honestly, this reads more like you're burnt out and would prefer not to have
to keep apace of new developments to continue contributing. I can deeply
appreciate that condition, but it seems to me to be an unhealthy place to be
on many levels.

For one, natural language is constantly evolving. Shouldn't the languages we
use to describe the solutions to problems be similarly capable if they want to
keep up with a rapidly changing world?

For two, we can look at what extreme conservatism in this department does to
you. Python 2 has supposed to have started being deprecated, but we're getting
hints that big companies are more inclined to just take over support of Python
2 rather than move forward to Python 3. This problem is the result of the
culture of "a 10 year old line of code being equally useful without other
version controls in place."

Similarly, we see a lot of languages punt on actually making it easy to
prototype and deploy modern data structures and algorithms. That's why a bunch
of mainstream languages still have very slow sorting algorithms in the stdlib
(e.g., O(n²) quicksort instead of O(n) american flag sort; still using
amortized resizing hash tables as opposed to HAMTs, etc); it's just crazy hard
to actually write that code reliably.

> You will not need a magnifying glass to read a mish-mash of ASCII math
> symbols to figure out whether someone built a death ray, or just a milk
> shaker.

No one actually has this problem. Not Perl 6, not Perl 5, and not Haskell or
Ocaml. _Maybe_ APL had that problem, but it's long gone. Holding these
rhetorical points out seriously seems to me to be more evasive than realistic.

~~~
dmitriid
> Honestly, this reads more like you're burnt out and would prefer not to have
> to keep apace of new developments to continue contributing.

New developments don't necessarily mean "let's create new and weird syntaxes
for TMTOWTDI"

> For one, natural language is constantly evolving. Shouldn't the languages we
> use to describe the solutions to problems be similarly capable if they want
> to keep up with a rapidly changing world?

There are many problems with this analogy. But before you read my points, or
even instead of reading my points, I'd recommend you watch "Growing a
Language" by Guy Steele:
[https://www.youtube.com/watch?v=_ahvzDzKdB0](https://www.youtube.com/watch?v=_ahvzDzKdB0)

1\. A programming language is not a natural language. It is a constructed
language

2\. A natural language is not really constrained by anything. It can willy-
nilly invent new words and concepts. It can import words and sentences
wholesale from other languages, adapt, translate or transliterate them. It can
deprecate and get rid of unused words concepts or give entirely new meaning to
words. It can and is ambiguous.

3\. A programming language is constrained and restricted. English has 500,000
headwords in a dictionary. All of those are "built in". Perl has maybe 100
total built-ins (including operators and keywords), plus a couple of hundred
functions in the standard library?

4\. A programming language does not aim to encompass all of human knowledge (a
natural language does).

5\. A programming language hopes to avoid ambiguity (C++ is rightfully
criticised and ridiculed for the amount of ambiguous places in its standard).
It aims to assign one and only one meaning to every word. A natural language
will have thousands of words which have multiple meanings (famously, in
English "set" has _464 definitions_ ).

6\. A programming language over the course of its evolution does not flip
concepts or change meaning of words (except in very rare cases such as
changing operator precedence). There are hundreds if not thousands words in
every natural language that changed meaning (gay, nice, clue, spinster, senile
etc.).

7\. A programming language is usually concerned with backwards compatibility
(even the rapidly evolving Javascript has to take care not to break sites from
15-20 years ago). Natural languages are never concerned with that. There are
tragic stories of huge swaths of history and culture not available to modern
generations in South East Asia after they swapped the commonly used Chinese
hieroglyphics for national alphabets. Meanwhile programming languages like
Clojure boast being able to run old code, and Linux is famously boasting that
"it's usually just enough to recompile old programs".

etc. etc. etc.

> For two, we can look at what extreme conservatism in this department does to
> you. Python 2

That's not conservatism. That's pragmatism. "Don't fix what ain't broke" is a
maxim that is as true today as it was yesterday, and as it will be tomorrow.
There can be decades of institutionalised logic coded in Python 2. And it
works. We should switch to Python 3 because someone said so?

There are 40-year old COBOL codebases that are still doing their job. Should
they have been switched to C in the 80s, only to be switched to Java in the
90s, only to be switched to Python in the 00s, only to be switched to
Javascript in the 2010s?

> Similarly, we see a lot of languages punt on actually making it easy to
> prototype and deploy modern data structures and algorithms.

What you call modern were most likely discovered in 1940s-1960s. All languages
have been slow to adopt those. It still has no bearing on my initial statement
of " A code by programmer A that does X is not significantly different than
code that does the same X by programmer B". A boring language will adopt those
modern structures in a boring way and my statement will remain as valid as it
is now.

> That's why a bunch of mainstream languages still have very slow sorting
> algorithms in the stdlib

So, don't rely on stdlib in these cases.

> No one actually has this problem. Not Perl 6, not Perl 5, and not Haskell or
> Ocaml

Everyone has those problems in any language that adopted TMTOWTDI. It
manifests in difficulty reading other people's code, onboarding of new hires
in organisations etc. etc.

On that note, Rails' popularity (and its clones' popularity) comes from the
fact that it enforced the "there's only one true way to do it" mentality in a
language known for its TMTOWTDI approach. And still, if you take code that
does the same by two different people, you'll have to reverse engineered each
one as they will use and abuse the "let's do it differently" mentality.

~~~
landyacht
> "let's create new and weird syntaxes for TMTOWTDI"

Nothing in Perl 6 is there just for the sake of having it. Usually the options
give you trade-offs between generality and concision/clarity. Like `[+]` vs.
`sum`; sum is clearer (to someone who speaks English, at least), but it's only
that: sum. You can stick any old operator in `[]`, and that happens to include
`+`.

Also, "weird" is entirely subjective.

> There are 40-year old COBOL codebases that are still doing their job...

Absolutely agree here. There's no need to update well-written code just to
keep with the fads. However, when the code is less-than-well-written, or the
newer alternatives really do offer something better, you have a different
story...

> So, don't rely on stdlib in these cases

So we're introducing a new dependency for a common task, adding extra work to
maintenance and setup, because our language's standard library isn't worth a
crap.

And what about the people who either don't want to bring in that dependency or
are blissfully unaware that their stdlib's sort is suboptimal? There's no
excuse for having an objectively inferior default. Third-party libraries
should only have to implement use-case-specific algorithms.

> Everyone has those problems in any language that adopted TMTOWTDI. It
> manifests in difficulty reading other people's code, onboarding of new hires
> in organisations etc. etc.

As for onboarding, I think that has more to do with the "boring" languages
being popular (so it's easy to find experts) than with those languages being
inherently more readable.

I don't know if you've ever tried to get yourself "on board" with a Java
codebase of any significant complexity, but I can tell you from experience
that it's hell. I'm aware Java is an easy target, but it's what I imagine you
mean when you say "boring." Sure, it only takes a competent programmer about a
week to learn fully, but that doesn't make real-world Java code easy to read.
Simplicity and readability aren't the same thing, and in fact too much of the
former hinders the latter. The human brain has a limited amount of short-term
memory and some pretty awesome long-term memory, but committing to it takes
time. When you go about understanding a Java codebase, you're trying to commit
an awful lot to short-term memory, including all the boilerplate and plumbing
needed to build a workable platform up from the feature-bare language itself.
And you repeat this for every new codebase. And people _will_ make different
architecture choices, even if the body of the code ends up looking similar.

However, what if the creator didn't need to write all that boilerplate? What
if the language provided all the common tools? Now, a maintainer can take
their time _once_ committing the language's standard set of tools to long-term
memory and recall that knowledge for every codebase they encounter. When
there's less for creators to re-invent, there's less for maintainers to commit
to short-term memory when they're trying to get in quickly to make a change.
Thus, I think your point about trying to dissect two codebases which serve the
same purpose is moot for Perl 6--it's either provided by the language or it's
something unique enough that you'll only ever need to read one implementation.

Not to mention holding a load of Big Java Nouns© in short-term memory is
exhausting. Ditto on C#, though it's admittedly a bit better. Same for C++
with its type parameterization insanity, or C and its macro insanity... the
common thread here is Larry Wall's old Waterbed Complexity Theory being proven
correct. Give people a limited set of tools with one knife and they'll always
reach for the knife, eventually hurting themselves or someone else.

Perl 6 provides ways to very naturally express concepts, which in fact makes
reading it easier. Plus, the excellent docs and helpful communities on IRC &
StackOverflow make it very easy to learn as you go. I'm not going to sit here
lying to you though--it does take time to get in the right mindset and fully
grasp the language.

------
nxrabl
I respect that Rakudo is still under development, but it's no myth that, as it
is today, Perl 6 is pretty slow. I did some benchmarking [0] comparing the
time for various interpreted languages to start up, print "Hello world", and
quit (or to start up, read from /dev/null, and quit), and Rakudo was about
twice as slow as Node and Ruby, and 100x slower than Perl 5. (I think this is
a decent test of performance if what you mostly run are short scripts but I'm
more than open to improvements.)

[0]
[https://github.com/wilt00/startuptime/blob/master/analysis.i...](https://github.com/wilt00/startuptime/blob/master/analysis.ipynb)

~~~
Ultimatt
$ time perl -E 'say "hello world"' hello world

real 0m0.016s user 0m0.005s sys 0m0.007s

$ time perl6 -e 'say "hello world"' hello world

real 0m0.187s user 0m0.226s sys 0m0.032s

That is not 100x slower, 10x sure. But once its running its faster than Perl 5
in plenty of situations especially for things like heavy OO use or compact
numeric work in tight loops. Anyone who argues Perl 6 is fast is definitely
being disingenuous but the counter is almost certainly more annoying to come
across simply because "startup time" is only important if you expect your
program to execute in less than a tenth of a second. So tight loops in a shell
script for something simple, stick to Perl 5. Large web app that will be
running for the next 5 years who cares about 10x slower startup time? Hardly a
benchmark thats useful.

~~~
futureastronaut
Agreed, "Perl 6 is slow" is a ridiculous takeaway from a benchmark of process
start times.

~~~
lizmat
Especially if you would compare a "Modern Perl 5" startup sequence, which
would involve using the `Moose` module (as Perl 6 has that built in). Then
startup times are basically the same.

~~~
microtherion
So the argument against Perl 6 being slow is "if you use it properly, Perl 5
can be just as slow" ?

~~~
futureastronaut
It's more like saying "the conventional P5 runtime is about as heavy as the
distributed P6 one", seems fair to me.

------
hvs

        Myth: Perl 6 has a bizarre ecosystem.
    

And then goes on to explain that it has a bizarre ecosystem.

~~~
Redoubts
I thought that part was a little overwrought. an equivalent system would be
pointing to PyPy with RPython. I don’t think that ecosystem is terribly
bizarre.

------
foxes
>Alternative reality: You cannot read a language which you do not know.

I think this is probably the only thing I agree with.

>Language is inconsistent.

Programming languages shouldn't be inconsistent. They should conform to a
formal specification that you can use to reason about correctness. A bunch of
test cases seems like a bit of a cop out. It would be nicer if it was a proof
rather than just a test.

>Reality is inconsistent.

I certainly hope reality is not inconsistent otherwise I might wake up as a
potato tomorrow.

~~~
b2gills
In reality Perl6 is strangely consistent.

------
jpswade
I actually really enjoyed Perl.

It forced me to learn regex properly and I learned about parsing mail, amongst
other things.

These days, I just don't see a reason to pick Perl over any other language.

Stuff like this doesn't help, I read "Perl 6 has a bizarre ecosystem", now I'm
under the impression that it's not just bizarre, it's also confusing.

Perl was great because it was simple, easy to get started, great community and
modules, and was ubiquitous.

~~~
tannhaeuser
Careful with Perl-style regexpes (aptly renamed to "Patterns" in Perl 6
AFAICT) being proper. They have higher complexity than standard regexpes [1],
and have been conjectured to recognize (a larger fragment of) context-free
languages [2] rather than just regular languages.

[1]:
[https://swtch.com/~rsc/regexp/regexp1.html](https://swtch.com/~rsc/regexp/regexp1.html)

[2]:
[https://www.perlmonks.org/?node_id=406253](https://www.perlmonks.org/?node_id=406253)

~~~
gbacon
Perl Regular Expression Matching is NP-Hard

[https://perl.plover.com/NPC/](https://perl.plover.com/NPC/)

------
tanilama
I don't buy the major argument a language is completely separate entity with
its implementation, especially there is only very limited choices of
implementations out there.

Other arguments feel a little too convievent to dismiss the concerns as non-
issues. The author is basically saying the language can look like anything and
it doesn't need to be performant, which is a pretty opinionated and not a good
look for selling.

In fact we are in a programming reality that is overwhelmed with choices of
languages, only expressiveness isn't enough to have people onboard.

~~~
ccashell
For many languages, the implementation and spec are completely separate
entities. Many of the biggest ones, actually: \- C \- C++ \- Java \-
JavaScript

------
dkarl
_You can try as hard as you can to shift complexity away from new programmers,
but it’s impossible to stop them from seeking it out. If you show a new Perl 6
programmer this page, they will run away screaming in the other direction.
That’s why Perl 6 is introduced slowly and softly_

This is so out of touch with current fashion, when "once I worked with a guy
who wrote a bunch of code nobody could understand" is an accepted argument
against a language.

Fashion has cycles, and someday people will come back around to the idea that
every language requires taste and restraint, and dull tools present a
different kind of danger than sharp ones. Maybe the plan is that Perl 6 will
still be waiting in the wings when that day comes.

------
smsm42
I loved Perl in the 90s. A lot of my programming back then was done in Perl
(Perl 4/5 of course), and it was good (well, as good as it could be back then
:). But now, 20 years later, I am not sure I can name any reason I would start
a new project in Perl, or try to scale a decidedly-not-flat learning curve of
Perl 6. And looks like the article discussed pretty much recognizes that,
though trying to cleverly dismiss it with koans like "Perl 6’s lack of a niche
is the language’s niche". But somehow this does not seem to be very
enlightening. There's always the classical "because it's there" reason, but is
there any others to get into Perl 6 as it is now?

------
mberning
“Myth: Perl 6 has a bizarre ecosystem.”

Based on the explanation provided I would have to say “myth confirmed”. It’s
not exactly straightforward.

------
smt88
I think (hope?) Poe's law[1] has bitten this comment section. Some of the
points, where the author's busting of the myth seems to be the opposite, sound
very tongue-in-cheek.

Then again, later in the article, it sounds sincere and defensive.

This is a good example of why using the right tone can be as important as
using the right words...

1\.
[https://en.wikipedia.org/wiki/Poe%27s_law](https://en.wikipedia.org/wiki/Poe%27s_law)

------
ricardobeat
> Myth: Perl 6 has a bizarre ecosystem

 _proceeds to describe a bizarre ecosystem_

Jokes aside, I am particularly put off by the attitude alone, which already
exists in the Perl 5 community: if you are not an expert in X, you have no
standing to criticize it - why you would be interested in becoming an expert
in something you don’t appreciate is beyond me.

------
amptorn
If Perl 6, by this essay's own admission, has no target demographic and no
niche, then who is this essay even aimed at? Who are we attempting to
convince?

------
eitland
Found this link in there and it looks interesting:
[https://perl6intro.com/](https://perl6intro.com/)

------
purplezooey
The easy concurrency stuff is cool and very useful.

------
butterisgood
Several times per year I find myself wanting to use Perl 6 for something. Then
I feel like I should be using Rust or working on/with Zig.... help!

It definitely looks interesting. I remember when the “best” Perl 6 was
implemented in Haskell
([https://github.com/perl6/Pugs.hs](https://github.com/perl6/Pugs.hs))

------
dlandis
“Myth: Perl 6 has no target demographic and no niche. Reality: So what?”

Wait, so it’s not a “myth” then, right? Or am I missing the joke?

------
carlsborg
What are the arguments for building the devops part of your system with Perl
6?

Stackoverflow developer survey 2018 lists Perl at 4.2% for “most commonly used
programming language” which surprising to me was close to Scala at 4.6% of
respondents (if I interpreted that correctly) so clearly a lot of people are
still using it.

~~~
cygx
Those are probably mostly Perl5 people, though.

------
xvilka
Perl 6 is a mistake, the same efforts should have been put to improve the Perl
5 evolutionary. See also the Future of Perl 5[1] discussion.

[1]
[https://www.perlmonks.org/?node_id=1220917](https://www.perlmonks.org/?node_id=1220917)

~~~
Ultimatt
You mean like cperl which already exists but was totally shunned by the Perl 5
community? [http://perl11.org/cperl/](http://perl11.org/cperl/)

~~~
ether_at_cpan
That had far more to do with reactions to the person behind cperl, than cperl
itself.

------
mclehman
I don't necessarily want to wade into the discussion on the tone of the
article, but I do want to detail something I've used Perl 6 for that makes me
really enjoy working with the language. I've noticed a trend in threads where
P6 comes up: I rarely see people actually point to specific instances where P6
features have been helpful. This lack of examples certainly doesn't help push
back against the idea that the language isn't usable or, indeed, useful with
anything less than 100% of the spec implemented.

I use P6 for all of my small deployment scripts (as well as a number of small
utilities I've written, like a tmux wrapper). It gets out of my way when I
just need something quick and useful from the start. For example it's
exceedingly easy to wrap other utilities because arguments to MAIN generate a
command line interface automatically.

It also provides features that help me as I move from a useful-but-dirty
prototype to a more maintainable script or piece of a more complex system.
Gradual typing is a big part of this. I tend not to add types for most things,
but it's very easy to use the P6 type system to watch my back when I do want
that help. It's not as good at catching things before runtime as a hardcore
static type system, but it manages to warn me "... will never succeed with
declared signature ..." often enough.

I have a no-frills, no-auth file sharing site I deploy periodically to get a
web front-end to share things with people (usually already on a VPN, sometimes
just on a LAN). At the moment, I use a simple deploy script to do this
manually, but I'm considering setting something up to automatically deploy it
when connecting to a particular network. I almost definitely won't get that
part right on the first try and would _really_ rather not end up accidentally
deploying a no-auth filesystem on my server's public IP address.

Using the P6 type system, I can easily define a subset of IPv4 addresses:

    
    
        my @private-ranges = <10.0.0.0/8 172.16.0.0/12 192.168.0.0/16>;
        subset IPv4::Private of IPv4 where -> $ip { Net::Netmask.new(any @private-ranges).match($ip) };
    

Then simply defining MAIN with a typed (and named, in this case, hence the
colon) argument will handle all the checking at the type level.

    
    
        sub MAIN(IPv4::Private :$ip) { ... }
    

Now I won't be able to deploy this service on a public IP as long as I use
this deploy script as a primitive in whatever eventual solution I end up with,
and the automatically generated usage message even helps communicate why a
call failed (provided you have descriptive type/parameter names).

    
    
        λ |  ./deploy --ip=$(dig +short myip.opendns.com @resolver1.opendns.com) 
        Usage:
          ./deploy.p6 [--ip=<Private>]
        
        λ |  ./deploy --ip=10.0.0.2
        Deploy successful.

~~~
xisukar
Nice example about using the MAIN subroutine. I'd be interested on reading
more about your uses of Perl 6 so should you blog about them, don't hesitate
and share it with the P6 community.

~~~
mclehman
Thanks, I'll definitely keep it in mind.

MAIN is probably what I should point to as P6's killer feature for things of
this scope. I tend to get sidetracked by math/functional features when I demo
things even though stuff like this is a bit more practical and likely to get
traction.

I just got around to cleaning up that tmux wrapper I mentioned above
([https://gitlab.com/0xFORDCOMMA/sessions](https://gitlab.com/0xFORDCOMMA/sessions))
and that might be worth writing something about. It's a miniscule project, but
I think it highlights a lot of useful features.

One result of that clean-up that relates to this is the new usage output. It's
still automatically generated [1], but adding purpose annotations to the
multi-dispatch MAINs in `session` and using a P6 enum as a type constraint in
the MAIN in `sessions` resulted in what I consider quite useful documentation
pretty much for free.

    
    
        λ | -> session --usage
        Usage:
          session -- Create or enter default session 'misc/dev'.
          session <category> <session> -- Create or enter session '<category>/<session>'.
          session <session> -- Search all categories for matching session, switch to result if unique.
    
        λ | -> sessions --usage
        Usage:
          sessions [--style=<Style> (boxed compact)] -- Default display style is boxed.
    

The latter example is generated entirely from these two declarations:

    
    
        enum Style <boxed compact>;
    
        #|(Default display style is boxed.)
        sub MAIN(Style :$style = boxed) { ... }
    

[1] For anyone interested, you can have your cake and eat it too. Defining
your own USAGE routine doesn't mean you have to give up the generated one. The
generated output is available in the $*USAGE variable.

------
agumonkey
As if Larry needed a justification on why making a language. Or anyone for
that matter.

------
jon_kuperman
Is this satire?

------
foobar_
ES6 is an acceptable perl.

1\. It has peg grammar

2\. Reasonably Unicode friendly

3\. Transpilers did what Parrot VM was supposed to do

4\. OOP is flexible enough

5\. Optional type checking and FP libraries

6\. No macros and neither does Perl 6

~~~
b2gills
Rakudo does have macros.

They weren't good enough to be enshrined in the Perl6 language itself.

So there is a project named 007 for exploring how macros should work in Perl6.

------
zzo38computer
Bad programs can and are are written using any programming language.

------
baxtr
I first learnt Basic and Pascal. When I started Perl it felt like pure magic

------
sashavingardt2
Ex-Perl 5 dev. Still use it once in a blue moon b/c of the regexes. Perl 6 was
a joke even 15 years ago )

~~~
lizmat
A well informed opinion.

------
strictfp
TIL that Perl 6 is an APL wannabe

------
antonyme
People still use Perl?

------
kinkora
Myth: Perl 6 has no official "framework"

Reality: Yep.

The biggest issue with Perl 6 IMO is that there are no "official" scaff
holding framework(s) for anything. If I need to spin up a web app? Start from
scratch. Need something like a CMS? Start from scratch. Need a static site
generator? Start from scratch.

Yes, I know there are probably some Github repos out there that may do what I
want and I am nitpicking but it is IMHO that until a programming language
adopts an official framework[1] to help with new entrants or even crusty old
dev guys like me that don't wanna keep reinventing the wheel, that language
will rarely ever get popular.

[1] e.g. rails to ruby, laravel/wordpress to PHP, Django to python, nodejs to
javascript, etc

~~~
hpcjoe
2 minutes of searching found a number[1] of modules implementing frameworks.
Notice the static site generator you mentioned to be one of the lacking
elements[2]. Or the CMS system[3].

But sure, lets just dismiss these, and accept the "but its not
rails/django/...". The comment reads just like the anti-Perl language hate
that it is.

I'm curious though ... WP has been developed over multiple decades, Django
started out a long time ago. Perl6 has been available in usable form for what
... 3 years? And you are seriously asking why the ecosystem is not equivalent?

[1] [https://modules.perl6.org/t/WEB](https://modules.perl6.org/t/WEB)

[2]
[https://modules.perl6.org/dist/Uzu:cpan:SACOMO](https://modules.perl6.org/dist/Uzu:cpan:SACOMO)

[3] [https://perl6.pheix.org/](https://perl6.pheix.org/)

~~~
kinkora
Perhaps I could have better communicated my feedback and I do apologise for
that but I wanted to point out that I _did not say_ there is nothing out there
and in fact, specifically mentioned that I could find those repos:

 _> Yes, I know there are probably some Github repos out there that may do
what I want and I am nitpicking_

Plus I could also say that if you spent 2 minutes searching my comment
history, you will find that I am a Perl enthusiast and also started my sys
admin career with cgi-bin yet you jumped straight into dismissing me as an
anti-Perl person.

I could also add that if you took another 2 minutes to look at the link of
list of modules that you listed, none of them are friendly to new adopters.
E.g. Here are the documentation for the top 4 links:

• Bailador:
[https://github.com/Bailador/Ressources](https://github.com/Bailador/Ressources)
(misspelled link + 404 error to documentation)

• Cro:
[https://cro.services/docs/intro/getstarted](https://cro.services/docs/intro/getstarted)
(taking out the code samples, the whole documentation is 9 lines)

• Uzu:
[https://modules.perl6.org/dist/Uzu:cpan:SACOMO](https://modules.perl6.org/dist/Uzu:cpan:SACOMO)
(this one is actually good. just needs some polishing for new comers)

• Pheix: [https://perl6.pheix.org/doc](https://perl6.pheix.org/doc) (404 error
to documentation)

And compare that to the following:

• Rails:
[https://guides.rubyonrails.org/getting_started.html](https://guides.rubyonrails.org/getting_started.html)

• Django:
[https://www.djangoproject.com/start/](https://www.djangoproject.com/start/)

• Laravel: [https://laravel.com/docs/5.8](https://laravel.com/docs/5.8)

That's just the documentation. I haven't even gone on about the fact that all
of those Perl 6 modules are by independent contributors (Cro being a private
web consulting company) and the worry about it disappearing or losing support
for future releases, bug fixes, etc if I want to adopt Perl 6 for production
systems.

So my point stands.. until Perl 6 has an _official & comprehensive_ framework
to do something to help _beginners_ , it will not be popular. Key word
"official", "comprehensive" and "beginners".

The whole point about this article is that people don't adopt Perl 6 because
of the many myths purported but my feedback is that the reason because any new
language gets popular is due to the official frameworks and community around
it that helps the adoption which also set some standards and will help dispel
some of these myths. All of these makes it much more inviting to someone new
to the language and drives adoption. Without that, even me as a Perl veteran
will find it tough to get myself up and running.

Lastly, I have tried to give constructive feedback to the Perl 6 community and
have always met with these sort of defensive behaviour. We could do with some
more conversations around feedback than simply dismissing comments right away
with a "your language is so filled with anti-perl hate".

~~~
Ultimatt
For Cro the documentation is much more extensive than you suggest
[https://cro.services/docs/intro/spa-with-
cro](https://cro.services/docs/intro/spa-with-cro)

The main issue you're perhaps less aware of is the total size of the Perl 6
user base is about 200ish people who are not commercially oriented for the
majority.

