Hacker News new | past | comments | ask | show | jobs | submit login
Myths about Perl 6 (aearnus.github.io)
153 points by lizmat 9 days ago | hide | past | web | favorite | 241 comments





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.


The Rakudo compiler targeting MoarVM is also "finished" in the sense I expect it would take you a while to find something not implemented from the spec. More advanced things like concurrency and parallelism features are ready, and there are even nice things built out of them like the Cro microservices framework https://cro.services/. You can also build applications with Cro using full integration with a JetBrains based IDE https://commaide.com/, which feels like a level of maturity and support someone might expect of a finished product? Thats the real myth, is someone can read this article and still not realise Perl 6 is an entirely useful and complete language with a good implementation and nice tooling.

Then the article should say that, not just say that the Platonic ideal of Perl 6 is well-defined in the writings of the prophet Larry.

... but still dog slow. Sorry, it matters.

Ruby is reasonably fast now, but when it became popular it still was very slow. So while speed definitely matters, maybe its lack is not an insurmountable obstacle.

The competition is a lot hotter these days.

Is it? It seems like the scripting language world is incredibly stagnant these days. Can you name an "up-and-coming" scripting language?

Elixir?

Anyway, I'd argue competition is tougher not because there are more competitors (there might be, I don't know) but because they have advanced.

Compared to 15 years ago, Python has gained a lot of stuff, JavaScript has become an ok language with very fast implementations, there's a dozen funcional scripting languages targeting browsers, optional typing has made a comeback, Ruby has native threads and a decent vm and a large ecosystem, Go is a valid solution for things were you might have used a scripting language, lua owns the embedded space and luajit is the state of the art etc.

In 1998 it was enough to have closures and objects to be a potential perl replacement.


In 1998 you would definitely need closures and objects to replace Perl, since Perl has had both since 1994.

I was using closures to great effect in Perl before I even knew what a closure was. (Are closures supposed to be a difficult or extraordinary feature?)

I really find it funny when other languages do things that Perl has already been doing for years.

Go2 is basically copying the way Perl5 has been advancing without breaking backward compatibility. (They don't seem to realize this.) JavaScript copied use strict. PowerShell copied $_. Everybody copied Perl extensions to regular expressions. (I can't wait for them to copy the cleaned-up, easier and more powerful Perl6 regular expression syntax.)

Every feature that I've heard that Python3 changes directly correlates with a similar change that has happened in Perl5. (Only Perl5 has done them in a way to reduce breaking your old code.)

Those are just a few of the the ones I know of.

Perl has been a far more influential language than anyone gives it credit for. Though that is probably because they just use the feature without knowing the history of it. Eventually Perl6 will be just as influential.

---

I agree that optional typing is good, I use it everyday in Perl6. (And have been for nearly ten years.)


You misunderstood me: I mentioned closures and objects as something perl had, which were also one of the selling points of ruby and python at the time, which would be considered competitors to perl.

The example was meant to show the "minimum" needed to be an interesting scripting language.

Edit: I love perl. I love perl6. I hope languages get inspired from it.


Python has gained barely anything at the interpreter and language level, tho?

Mmh, depends on when you start to count. I still consider 1.5.2 the gold standard for Python -- but I am weird. :) Anyway, since then it has gained new-style classes (which gave explicit methods to things like strings, tuples and numbers), list comprehensions, generators (which also gained some changes over time like 'yield from'), generator comprehensions, built-in sets with new syntax, dictionary comprehensions, decorators, descriptors, properties, context managers and the 'with' keyword, absolute vs relative imports (again with new syntax), import hooks, a boolean type, extended slices, a ternary if, ordered dictionaries, async/await, extended tuple/list unpacking, the @ operator, several new ways of string formatting, ... And of course 3.x brought major changes to the way Unicode was handled. Never mind those, um, interesting type hints and the upcoming := operator.

Python as it is now, is a very different language than it was in those days. Even ignoring the whole ecosystem with libraries and package management etc, and standard library changes, it's just a much bigger language.


Red, sort of kind of.

I have been thinking that there might be room nowadays for a new language that is unabashedly a "scripting language"... something you can easily write scripts with, but which doesn't necessarily aspire to scale real far beyond that, so people will not immediately reach for it to write, say, 250K-line web applications. :3 (Then again, if a language is good/useful/flexible enough, people will use it for everything.)

Anyway, I would like to see such a language. The old stalwarts will probably still work just fine for this purpose, but I am curious to see if there's any innovation left/possible in this particular space.


I have one I'd _like_ to see in a very limited domain: Dhall.

Dhall is amazing. But it's domain is very limited.


Scripting languages were to the 200x's what visual 4GL's were to the 1990's, i.e. a whole bunch of them came and went, and only a few gained mass adoption, perhaps 4GL's Visual Basic and Delphi, and scripting languages Javascript and Python. The rest are dead, or slowly dying.

Julia

Is it a scripting language? I suppose so!

Good answer!


Well, it's both really. That's what makes it special.

Maybe that's because scripting languages are a bad idea for anything performance critical anyway - and experience has shown that even if things are not performance critical initially, they might become eventually.

So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place?


> Maybe that's because scripting languages are a bad idea for anything performance critical anyway

This is an example of how programming as a discipline and activity is consistently dismissed by the software community as an unnecessary contrivance. "What about absolute performance?" But the reality is you're making tons of those tradeoffs. You're using a compiler, on an instruction set designed for humans, leaning on network stacks that do work for you in generic but sub-optimal ways, using container systems that introduce huge performance penalties.

Those are socially acceptable to you. They're special in that you think they aren't special.

> So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place?

This assumes they are in fact equally capable. Please don't retort with Turing completeness. That's a copout and we all know you aren't about to go shipping things in BF.


Performance just isn’t the only, or always the most important factor when choosing a language. Sometimes we choose a language and it’s ecosystem for factors we know we value right now, rather than ones we might value later on.

Or they go the other way, after an initial assumption that the task was performance-critical when in fact a scripting language was perfectly capable and took 1/10 the effort to write.

https://opensource.com/article/18/1/my-delorean-runs-perl


Time to market.

All of the popular interpreted languages we use now were dog slow when they originally came out and we still had to deal with many the quirks of low level languages back then but here we are. If you don't like it just don't use it.

This really depends on the task in question and which languages you were comparing it to. Back in the day it was fairly common to have Perl, PHP, Python, etc. outperform languages like C in cases where the task complexity meant that the C programmer had been so busy debugging that they never got around to implementing a better algorithm which required more complex code, or it turned out that the C code behind the Perl regex engine, Python list/dict, etc. already had those optimizations. Java and C++ were compiled but back then the implementations were far less mature and it was easy to find cases where they underperformed in cases which should have been easy on paper. Not having a package manager really favored languages with one or a strong standard library since the alternative was often someone doing a quick naive implementation and never getting around to significant optimizations. The other thing to remember is that in the pre-SSD era it was much easier to be I/O-bound, masking most of the differences.

Someone once posted Perl6 and C/C++ code to #perl6 on freenode.net

According to them, Perl6 was faster.

(The Perl6 code was also a lot shorter, and I could argue it was easier to understand.)

---

My guess is that the reason was that the C/C++ code had to scan for null terminators often, and copy strings around. (Or perhaps more precisely the stdlib had to do that.)

MoarVM doesn't use null terminated strings, and it treats strings as immutable objects. If you do something like create a substring, it creates a substring object that points into the original string. So rather than copying a bunch of data it basically just creates a pointer.

(Strings are technically immutable in Perl6, it is easy to assume otherwise though.)


Compared to Python? They're like, comparable no?

Depends: Some things can still be really (and I mean really) slow. For example, I've been complaining about the speed of the regex/grammar engine for years.

On the upside, the parallelism story is better than Python's or Perl5's.


> 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.


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

https://twitter.com/aearnus/status/1147960078680485889?s=21


Thanks for the clarification.

This all reminds me of Poe's law

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

"[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."


Based on the rest of the blog, I can't actually tell if this is tongue-in-cheek or not...

It's very poorly written satire if so. You can't point out the absurdity of something by repeatedly arguing that it's not absurd. The point about Chinese characters being unfamiliar to readers of Latin alphabets is a good one, for instance. It would be like Dilbert having a week where the pointy-haired boss's apparent nonsense is actually good management practice that Dilbert has been misunderstanding: it would neither be funny nor effectively educational.

My favourite was “Myth: Perl6 is slow” “Reality: Look at all these open performance tickets!”

Many of those are because one way to write the code is slower than another way to write it.

So it is more about the speed not being evenly distributed.


> I LOVED Perl.

Perl isn't going anywhere. It is under active development.

One unfortunate thing about naming the sister language Perl 6 is that it tends to indicate that it is the Next Perl (like Python 2 vs 3). But it is not, Perl 5 is a very different language (and I wonder if at some point Perl 5 will switch to Perl 7.x just for the fun of it).


> One unfortunate thing about naming the sister language Perl 6 is that it tends to indicate that it is the Next Perl...

This is a fair and it's one of the reason why Larry Wall created the alias Raku.

But let's entertain for a moment that there wasn't even an alias for the language. I'm sure we both agree that for a person who comes across the names Perl 5 and Perl 6, the latter seems to indicate that it's the next version of the former. In fact, this is totally excusable. After all, why should the person assume they're different languages and disregard what seems to be a logical conclusion? 6 is immediately after 5 and it suggests some sort of progression. Thus, it was on the community to make it clear and unambiguous to newcomers but I'd daresay it failed at that. Raku is an attempt at correcting that blunder but who can say it will succeed in that area?

Now...

Would it be logical for the same person to rehash the same "assumption" after they already learned about it regardless of the context of the conversation? If you've (you in general) learned that Perl 5 and Perl 6 are different languages, what's the merit behind pointing out the obvious? Again, I'm referring to people who, for one reason or another, already know they're both different languages yet still are set to bring out, whenever the opportunity arises, the same and old "naming" debacle as a reason for people to avoid/bash either Perl 5 and/or Perl 6

When I first heard about C++, I myself was confused on whether it was the next and better version of C. However, it just took me an internet search to realize that C++ and C are two distinct languages. Afterwards, I haven't confused the two anymore. One might certainly argue that version numbers are different to use of operators (specifically, ++) but who decides that? For me, the ++ in front of a language's name implies the same type of progression 6 does over 5.


> "Perl 6 is defined as a set of test cases." ... "Perl 6 is done"

Quoting Larry Wall from 2000:

> [we should] develop the real regression tests into a validation test of what the language actually means and actually go out and explore all the nooks and crannies ... and then we actually have a machine-readable spec. And to me that’s actually a lot more important than what the verbiage on the human readable thing says.

The first implementation of this concept was released in 2016 as version 6.c. Then 6.d in 2018.

P6 will never be "done" but 6.c and a compiler for it was/is done, similarly 6.d, while 6.e is at an early work-in-progress stage.


Quoting Larry Wall from 2000

If you're going to quote Larry Wall from 2000, be honest and also quote him as saying he wanted to release a beta by TPC 2001 and get the final version out by 2002. Don't mislead people by cherry-picking quotes out of context to gaslight them.

That is, assuming you want to be an honest, good faith advocate.


Hi chromatic. I'm not going to engage with you beyond this comment.

----

To all readers,

Imo the issue of a time line (estimated or actual) is immaterial to the original point made up thread (the role of tests in determining a compiler's compliance to a language specification).

But I've decided to reply to chromatic's comment.

With luck chromatic and perhaps others will reply with substance and the result will be a useful HN record about the original P6 time line estimates. I apologize in advance for any further trolling or disconcerting further tangents my comment generates.

Besides quoting chromatic, all text I quote using `>` or "quoting" comes from sources I've linked in footnotes.

----

> If you're going to quote Larry Wall from 2000, be honest and also quote him as saying he wanted to release a beta by TPC 2001 and get the final version out by 2002.

The Perl 6 announcement, which is what I was quoting, doesn't mention these things. [1]

You were, as you tirelessly emphasize, physically in the thick of things, while I was merely reading things online as I found them, roughly contemporaneously with their publication, and then again in recent years. So feel free to provide your own quotes and links.

----

In the meantime, here's what Larry said about time lines in that initial speech:

> We are really jazzed about this. It is our belief that if Perl culture is designed right, Perl will be able to evolve into the language we need 20 years from now. It’s also our belief that only a radical rethinking of both the Perl language and its implementation can energize the community in the long run. In the long run means 10 and 20 years down the road. Finally, it is our belief that Perl 5 will be better supported than it would be if we merely tried to guard what we already have. The best defense is a good offense. Now, this is not going to happen quickly. We expect to have alpha code a year from now, for some definition of alpha. We might even ship it, but we expect it to be well-designed alpha code.

Perhaps mentioning this alpha time line was his first big P6 mistake. [2]

It seems Larry felt comfortable announcing the original one-year-to-alpha estimate. But his comment is clearly about an open source community effort, not something he could assert control over, especially time wise, even if he cared to try. (He had already made it clear, before Perl 6 began, that he did not.) So why did he say such a thing?

Perhaps he was thinking he had pulled off somewhat similar feats on his own before. After all, he wrote the original Perl 5 in about 18 months. And in the new project his anticipated initial role was "merely" thinking up a new language design with a view to keeping what was thought good about Perl 5, dropping what was thought bad, and integrating what he could from the dozen or so RFCs that the design process would supposedly be built around. So perhaps it was on that basis that he felt confident mentioning an alpha time line.

----

Imo, based on what I read at the time and have reread since (some key links are provided in this comment), less than 2 weeks later things were going downhill fast from a project management and time line estimate standpoint: [3]

* An unrealistic draft schedule that got zero feedback ("Nobody had any objections to the draft") was converted into the official one ("so the draft becomes the real one").

* Despite the ominous sign of having no feedback, an alpha millstone (typo intentional) that apparently halved the time from the original estimate Larry had announced ("Vendor liaison begins January 1st 2001 with the alpha release") was added "unilaterally".

* And to wrap up the whole arbitrary schedule "The final release will be on (he picks a date approx. 18 months from the start of the project) 1 January 2002."

While the schedule's overall "long term" time line was clearly a made up fantasy from the start, the short term (weeks) details were no better.

Larry was expected to start work on a language specification on Oct 1st 2000 and deliver it in FINAL form one month later. Imo this was obviously insane even if there were ZERO RFCs.

(Yes, Brendan Eich produced an initial JavaScript design and prototype implementation in 10 days. No, this does not mean it made sense that Larry would produce a new final P6 design in a month.)

Then, by the cut off date of Oct 1st the project had officially accepted not zero, not a dozen, but THREE HUNDRED AND SIXTY ONE RFCs. Many were substantive. Many were good ideas, poorly thought through.

Maybe Larry could just about have hit the Oct 14th draft date if he simply summarily rejected around 97% of them without reading them.

Or maybe he could if he had worked on it all, non-stop, without breaks for food etc., for 45 hours a week, spending FIVE MINUTES reading each RFC, FIVE MINUTES thinking about how to integrate it and FIVE MINUTES writing up a draft specification of that aspect.

Except that wouldn't leave time for the rest of the language that the RFCs didn't address, eg what was already in Perl 5.

And anyway, FIVE MINUTES?!? Imo an estimate of FIVE HOURS WALL CLOCK TIME for these tasks would not be unreasonable. FIVE MINUTES is INSANE. (Imo.)

So, imo, as early as Oct 1st 2000, the schedule's millstones were very clearly INSANE expectations.

----

But it's not just Larry and the RFCs.

The more general point is that the project's management failed to adapt to what had actually happened a few weeks into the project. There had been virtually zero input/help for management. That was an ill omen. In addition the language design task had grown to absolutely monstrous proportions. These ill omens were unexpected and then left unmitigated. [3] [4]

The functional response would have been to reset expectations. But that didn't happen. So instead of P6 being considered a project that was the sort of thing that takes a decade if it's just a mild rewrite (Python 3 arguably took longer) it was instead expected by some to be done in 18 months based on nothing more than wishful thinking. That's not a good start expectations wise.

----

I fully expect chromatic to want to attack me and/or Larry, point out that they're an authority and I'm not, suggest I'm throwing folk under a bus, etc. I won't be responding. Please take what they write with a bucket of salt.

----

[1] https://www.perl.com/pub/2000/10/23/soto2000.html/

[2] Larry has long said P6 would be a journey of mistakes, just like the journey with P5, albeit hopefully new mistakes.

[3] https://www.nntp.perl.org/group/perl.bootstrap/2000/08/msg11...

[4] https://www.nntp.perl.org/group/perl.perl6.meta/2000/09/msg4...

[5] https://www.nntp.perl.org/group/perl.perl6.meta/2000/09/msg1...


Imo the issue of a time line (estimated or actual) is immaterial to the original point made up thread (the role of tests in determining a compiler's compliance to a language specification).

The issue is whether P6 advocates are honest in their advocacy. Pretending that the goal was always to create a sister language or that the intent from the start was always to take 15+ years to release a stable version or that the intent was always to define P6 as a specification and test suite or that a cross-platform VM wasn't a goal from the start is dishonest.


>I LOVED Perl.

5 exists and will always exist. :-)


CPAN also exists, but not as it once did. Perl 5 wasn't just a language, but an ecosystem.

> CPAN also exists, but not as it once did.

Right, it's way better. What makes you ignore all the great improvements the PTS have made?


It will never get a new major version number though.

... if they don’t decide to just name perl 5.100 “perl 7” instead


It's unfortunate, but it has no practical bearing on the fact that the language is still actively maintained and improved upon, with a major release every year in late May -- 5.32.0 being the latest such release.)

It will not, however, always get security updates, performance improvements, and maintenance for its libraries.

The current state of Perl 5 for Python fans:

----

Perl 5: I'm not dead!

TIOBE: 'Ere! 'E says 'e's not dead!

Internet: Yes he is.

Perl 5: I'm not!

TIOBE: 'E isn't?

Internet: Well... he will be soon-- he's very ill...

Perl 5: I'm getting better!

Internet: No you're not, you'll be stone dead in a moment.

TIOBE: I can't take 'im off like that! It's against regulations!

Perl 5: I don't want to go off the chart....

Internet: Oh, don't be such a baby.

TIOBE: I can't take 'im off....

Perl 5: I feel fine!

Internet: Well, do us a favor...

TIOBE: I can't!

Internet: Can you hang around a couple of minutes? He won't be long...

TIOBE: No, gotta get to Reddit, they lost nine today.

Internet: Well, when's your next round?

TIOBE: Next year.

Perl 5: I think I'll go for a walk....

Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?

Perl 5: I feel happy! I feel happy!

----

But seriously, Perl 5.30 just came out in May. It's not dead yet.


I didn't mean to suggest that Perl 5 is dead, only that it's reasonable for people to consider Perl 5 to be deprecated sooner than Perl 6 will be.

I am not so sure.

Perl 5 is more widely used and had much greater historical adoption as the "glue" of the early Internet.

Perl 6 has not displaced Perl 5 and does not appear to be in a position to do so. I believe Perl 5 may out last Perl 6 based on how widely it is used and available.

It is a different situation compared to Python 2 / Python 3. Whereas Python 3 is slowly replacing Python 2, the same cannot be said for Perl 6 slowly replacing Perl 5.


Python2 is EOL as of the end of this year.

Exactly--there is momentum to migrate from Python 2 to Python 3 since support for Python 2 is ending.

I prefer Python 3 to Python 2 and have migrated all my projects that still matter.

Support for Perl 5 is not (to my knowledge) ending anytime soon.


I see no realistic weight behind the notion that P5 will be deprecated in the foreseeable future (decades).

Python 2 or 3 fans?

Both.

It's taken with minor adjustments from this Monty Python scene: https://youtu.be/Jdf5EXo6I68


Perl 5 and Perl 6 are essentially separate languages at this point, so Perl 5 will continue to get features and updates for as long as anyone uses it, which will be a very long time yet.

Wait, what? Is there a reason to believe that indefinite future maintenance of Perl 5 is more in doubt than of, say, Ruby or OCaml? (Of course it has a smaller community than, say, Python or Go, but the community is still existent and AFAIK intends to maintain it indefinitely.)

I don't doubt Perl's longevity, only the maintenance of a specific version. I'd say the same of Python 2, despite its alarmingly long afterlife thus far.

But the Python 2 development community a) has announced a specific date for end of life (January 1 of next year), b) had communicated the intention to sunset Python 2 in favor of Python 3 for years before the specific date was announced, c) is no longer applying anything but critical bugfixes to Python 2, and d) has collectively moved to developing Python 3. None of these are true of Perl 5/6.

Alternatively, if we're going to look for analogies in other languages instead of listening to statements from the Perl 5 community themselves, let's make an analogy to C and C++. Despite C++ having been a mature, usable language for decades, people are still using and developing C compilers and libraries.


You're right Perl 5.18 is no longer being maintained.

But Perl 5.30 is still maintained, and almost all Perl 5.18 code should run on it unaltered.

---

As far as I know, there is no-one who is involved with maintaining both Perl5 and Perl6. There are separate groups for both.

In fact I think there are more people being paid to work on Perl5 than there are being paid to work on Perl6.


Perl 5 and Perl 6 are completely separate languages, they aren't "versions" of the same language.

A rather non-obvious fact, because the language names clearly and misleadingly suggest otherwise.

Can you elaborate on languages that will?

I wasn't commenting on Perl as a language, but rather a specific version of the language.

The thing is, Perl6 as it exists today can not be used as a replacement for Perl5, and in consequence, Perl5 development continues and will continue for the forseeable future. It's better to think of Perl5 and Perl6 as two separate languages in the Perl family, similar to various Lisp dialects.

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...


> 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.


> 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.


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

Perl 6 is, in my view, from a language design PoV extremely practical (it has lots of features, but each has a very clear pragmatic rationale).

From a project management point of view, it was perhaps insufficiently pragmatic, because there weren't the resources to get a production ready, fully productized implementation in a reasonable period of time.


> very prominent Perl advocates, but not necessarily all of the community

I agree, but my suspicion is that the larger mainstream community grew out of Perl being in the right time and place for a scripting language borrowing idioms from sh and C. Whereas the central figures directing Perl were always driven in the direction of eclecticism.


> The central figures directing Perl were always driven in the direction of eclecticism

I don't agree. Larry Wall always had an eclectic streak, but he was also a very practical guy, trying to scratch system administrators' itches with Perl. A lot of Perl 5's eclecticism stems from its predecessors: sed, awk, sh

The other key contributors in Perl 5 in the 90s (The various Perl 5.x pumpkings, Tom Christiansen, Randal Schwarz, etc) were also very practically inclined.

But as far as I recall, apart from Larry, most key contributors to Perl 6 did NOT work on the Perl 5 core prior to 2000 (I'm sure somebody could pull up actual names and statistics to confirm or correct this), though they were certainly active in the community.


> 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?


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.


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.)


> From the linked article, Perl 6 tries to support all kinds of paradigms.

There are two relevant aspects to P6. What P6 supports out of the box. And what P6 can support if someone cares to develop that support.

Out of the box P6 supports a carefully designed combination of the basics including FP, OO, and procedural/imperative.

> This really detracts from professional development where communicating code and clear code is necessary.

Your "This" doesn't validly apply to P6. P6 can easily be extended to support arbitrary integrated DSLs but the standard out-of-the-box P6 does not try to support "all kinds of paradigms".

Communicating code and clear code is necessary for almost all development scenarios, not just professional. Indeed, this is one of the reasons I favor P6.

> 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.

There are about 10 books for P6. None are "the good parts" style books.


I have never used Perl 6, though I have made sporadic efforts to learn it.

The development process certainly did not fill me with confidence about practicality, but I had already come to the conclusion that whatever I wanted from Perl, it could not possibly give me while preserving its original character, so (after some detour through Ruby), I switched to Python.


Thanks for replying.

Now I'm curious about the things you wanted from Perl that it did/does not provide. :)


Primarily a class system as a first class citizen of the language, with uniform object syntax, without sigils or other syntactic contortions.

Being able to pass around open file handles without having to look up 5 kinds of punctuation.

Being able to build up complex data structures without having to use explicit references, where something completely different would auto-vivify itself if I used the wrong sigil.


Makes sense. Thanks for replying. :)

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.


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.

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.


Try Clojure for both fun and productivity.

To me, the fun and creative parts come from solving cool problems. It’s even more satisfy when I can create something readable, maintainable, and reusable.

It’s as if writers were more focused on weird typewriters than writing interesting novels.


The prominent mascot is more of a reflection of the times when Perl 6 marketing materials were written. It was during the heyday of whimsy and _why's Poignant Guide to Ruby. It feels a little forced to me.

Well, at one point the perl community was perhaps one of the most unfriendly and unwelcoming communities I had ever encountered. While some were nice, plenty of the irc residents were pretty quick to just call you a dumbass.

You should ask the Go community if you can have a less repetitive error handling method and see how they treat you, if they talk to you at all after you say that.

To be fair, I've been isolated in the Java community for quite some time now. I couldn't tell you the current friendless scales, I just know that circa 2010ish, the perl community was unfriendly.

The Go community is currently checks the github using democracy to crush helper functions, I guess? Because they seem to think that writing the same if statement over and over again is theraputic and more clear than a helper function named try() that does the same thing more reliably would be.

IDK, they tend to call me names the instant they see I have Haskell and Erlang on my github.


Well, the point of democracy is to resolve disputes. A community could be welcoming and nice and still broadly think an idea is wrong and should not be done. In fairness to the Go people, I read the various "try" proposals and it seems like they gave them serious consideration, which is probably the least worst way to tell someone "no."

Likewise, they shouldn't be so invested in Go that they feel threatened that you like other languages, but feelings are pretty much random. I'm not a fan of the "code of conduct" stuff, but it's certainly addressing a legitimate issue and setting up an expectation that people treat each other decently probably does help with mitigating some of this.


Ugh, I'm all for projects not taking themselves too seriously, but the spokesbug thing feels... a little cringe-worthy? It's also super weird mixed messaging, like it starts off with an overly cutesy thing that seems targeted towards children, and the immediately shows a grammar? Who is this supposed to be for?

Developers of the language not users of it is my guess.

At risk of sounding mean... I think those two demographics might be one in the same at the moment.

Are there any actual systems in production and processing non-toy workloads that are written in Perl6?

I ask this as someone who has several systems written in Perl 5 in production.


Do you mind if I add some of this to the post? These are really good points.

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.


> The over-decade-long transition to Perl 6

Is it really a transition, though? Perl6 looks to me more like an unrelated language bootstrapping from the Perl5 ecosystem. It's certainly more different from Perl5 than something like Ruby.

The biggest mistake with Perl6 was probably to have "Perl" as part of its name. "Rakudo" might have proven more popular from the start. At least it would have gotten rid of all the pointless and altogether predictable discussions.


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?

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.

> 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/


By that time, Amazon for example had already decided that Perl's time had passed.

Another case in point, look at the Google trend for "perl tutorial"[1]. Unfortunately, that only starts at 2004, but you can still see by that metric, Perl popularity already was in sharp decline when Tiobe still had it fluctuating around a peak.

[1] https://trends.google.com/trends/explore?date=all&geo=US&q=p...


It took a while to realize how great the distance would be between perl 5 and perl 6, and how far off into hyperspace the latter would go.

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.


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.

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...


Fairly early in the life of Perl6 it was basically decided there wasn't going to be a transition. Not like the Python one at least.

Also I've heard about projects that transitioned from Python2 right to Go. (The way it sounded, it was easier for them than transitioning to Python3.)

---

Perl6 isn't trying to replace any language. Why does everyone think this has to be a zero-sum game?

C++ didn't replace C. D and C# didn't replace C++ or C. Ruby didn't replace Perl. C didn't even replace Assembly.

There is a long list of languages that didn't replace other languages.

I mean even Cobol is still an actively used language.

---

Also I think it is dumb that Python didn't copy Perl and make all of those changes work in a backward compatible way. (I have yet to see a change in Python3 that isn't reminiscent of one I've seen in Perl5.)


Perl was already dying by the time 6 came around. Python was on the upswing when Python 3 came around.

2to3 works and forward/backward compatibility was handled very well.

It really wasn't, but I suppose it clears the low, low bar of perl 5/6

Data science libraries and adoption by teaching institutions.

> In my opinion, getting rid of the main appeal of the language ("it just works") was a suicidal move.

No one ever got rid of that -- P5 still just works and P6 aims to be as practical -- so I'm quite confused by this aspect of your comment.


One of Larry Wall's nice insights was that a language includes the community around it, just as much as the core features or standard library. So when the charismatic founder of the language and his chief apostles moved on to a different project, that had a real impact on people. Not least, it sent the message that the 'old' perl was a legacy dead end.

I hear that's what many saw, the message they got. And it's clear many still see and hear the same. And that had and continues to have a real impact.

But to do Larry justice it's important to acknowledge that he specifically did not move onto a different project. He was pushed by the Perl community to start on a new version of Perl and he did so. He then dedicated a large chunk of the next two decades of his life to it, to Perl, and continues to do so, despite misunderstandings like the ones you're expressing and outright hostility from some in the Perl community. And all this while arguably he's done the best thing that could be done for Perl.

In 2000 he said:

> We have to be better, not just get there faster. ... We are determined to do the right thing by everyone. To this we pledge our lives

When asked in 2018 "Why didn't you pick something different?" he said: [2]

> Because I wanted to go to a Perl conference. I didn't want to go to a Perl and something else conference.

> You guys are Perl people. All of you.

> You know at the beginning we thought that [Perl 5 and Perl 6] might be a little closer together and they did diverge a little more than than we thought they would but by and large you know I think of Perl not as a particular syntax or engine but as a a set of philosophies of language design that you don't find any anywhere else in any other language. And both Perl 5 and Perl 6 follow those philosophies so on that level they are very closely related languages. They're both how I think.

> And the third leg of that is you know one can look back and say well you know maybe it would have helped the marketing of Perl 6 if it had had a different name but I'm not sure that it would have helped the marketing of Perl 5 to have a different name from Perl 6. I don't think that Perl 6 really stole any mindshare from Perl 5 at all.

[1] https://www.perl.com/pub/2000/10/23/soto2000.html/

[2] https://www.youtube.com/watch?v=_wJNPOs-Q20&t=44m


> 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.


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.


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/


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.

> Sheer information density per character isn't something I value in a programming language

Not that extreme but I find it undervalued in most mainstream languages; I value easy to understand and and descriptive for stuff I rarely use or need, but for things I use all the time, like map, fold, etcetc; why are those constructs not 1 char; it is not like I will forget the use or when someone reads it will not know the use of those functions.


> Sheer information density per character isn't something I value in a programming language.

That's a strawman.

> Being able to be clear and concise is certainly desirable.

That's obviously what the OP meant. Anything else would be silly.

> orthogonal high level concepts

Everything in the line the OP quoted as being an exemplar of flying over folks' heads if they don't know P6, and that "skipping a single symbol might drastically change your interpretation", is also an exemplar of clarity and concision of orthogonal high level concepts.

> 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.

Where did "line noise" and "subtle meaning" suddenly come from other than prejudice?

Perhaps you don't know that [op] means a prefix reduction in P6. But if I tell you that in the following it means "sum", and the result is 6, do you now understand?

    [+] 1, 2, 3
Boom, now you understand how to turn any infix operator into a reduction in P6. That's an orthogonal high level concept (any infix operator can be used inside the [op]) expressed in a clear and concise manner.

All the rest of that line is equally simple. But it will fly over your head until you learn it. Your assumption that it's line noise and subtle based purely on not knowing the language is indistinguishable from ignorance and prejudice and coupled with the fact that the OP was making that precise point means your comments are indistinguishable from sheer bloody mindedness.

> 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.

You can see the virtues of the keep-it-simple approach of English as a counter-example to what's in Devanagari if you can read English and can't read Devanagari. What does that tell us about a world in which there'll be more Indian devs than US devs in a few years?


Yup. This is not how you bust "myths".

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.


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.


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."

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.


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.)


> Can you imagine going to your boss and saying:

> Coder: "The program is finished"

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

Yes. Absolutely.

If I had a design worked out over a decade, multiple substantial prototypes, including one written in Haskell by a hundred lambdacamels, an acceptance test suite designed over a decade with over a hundred thousand tests, a production compiler written by top notch devs, field testing of thousands of modules, toasting of the compiler over the test suites of those modules, and the compiler passing the formal acceptance test, then yes, I can not only imagine it but would look forward to it.

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

That's bullshit.

> (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?)

What the heck? So the `leave` keyword is not yet implemented. Big whoop. It was designed so it could be left out. So you just leave the key word out and code works correctly anyway. Can you name a single other language feature that's not implemented? I thought not.

Why are folk here all assuming the absolute absurd worst case scenario twisted interpretation of the OP's words?

Have you noticed that Rust 5 isn't done? Haskell 2030? Swift 10?

Or, forgetting the fact that the P6 design was deliberately forward looking, so has `leave` as not yet implemented rather than just having never damn well mentioned it in the first place, what about just current versions of languages? Is C# "done"? Python? Racket? Idris? No bugs? No feature requests? No new versions?

In fact, how about you name any language that's done?

> Also the argument that it doesn't need a demographic holds no weight to me.

Who cares? The OP wasn't saying it matters whether you think the truth holds weight. They were just saying that some folk are getting into P6 despite P6 not targeting a demographic.

And what the heck is it with folk just assuming the worst?


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.


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.


Perl6 has had two proper language releases (v6.c in Dec 2015 and v6.d in Nov 2018), and there's a compiler that implements them (namely Rakudo).

The language is not 'finished' insofar that parts of the original design have yet to be realized (eg macros), and as any language that isn't dead, it continues to evolve to meet developers' needs.


> 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.


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.


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

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.


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

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.


Internet psychiatric diagnosis is not ok on HN.

https://hn.algolia.com/?query=by:dang%20psychiatric&sort=byD...

If anyone sees that happening and we haven't replied, it's most likely that we didn't see it. Users can help in a case like that by flagging the comment (https://news.ycombinator.com/newsfaq.html) or by emailing hn@ycombinator.com in egregious cases, which guarantees we'll see it.


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

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.

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

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.


Tenet and tenant have the same Latin root. A tenet is a principle to hold. A tenant is the person who does the holding.

You are correct. I blame my phone and upvoted your post.

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.

> 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.


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>>/;
    }

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.


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.

> 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 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.


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).


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.


> 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).


>> 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.


Why does it have to be any of those things?

Can't it just be its own thing for the sake of being itself?

---

If you want a compelling reason to be Perl6, how about one of these:

It brings together many features from many different languages and makes them feel as if they have always belonged together.

It fundamentally breaks with the traditional design of what a language can be. The way in which this was done also allows mutating it to be whatever you desire in a language. (It doesn't even have keywords in the traditional meaning of the word.)

It has been said that the best way to solve a problem is to create a language in which solving the problem is easy. You can make Perl6 into that language.

Perl6 has a motto that easy things should be easy and hard things possible. It actually went too far with this motto. Some hard things are actually easy in Perl6. (There may even be some things which you might have thought of as impossible, that are merely difficult.)

It is very strangely consistent.

You can load and use multiple versions of a module in the same process.

Nothing in the language is any more special than user code.

It is possible to use modules written in other languages as if they were really written in Perl6.

---

If you want a reason to stay away from Perl6:

After getting used to writing code in Perl6, going back to another language may feel overly restrictive.

If you don't want to improve as a programmer by trying languages with a different design ethos to ones you are already proficient in. (There is no other language with a similar design ethos.)


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.


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


Same, and that's why this one isn't a myth:

"Myth: Perl 6 has no target demographic..."

The easiest target demographic was active Perl5 users. We mostly all moved on to some other language after waiting a reasonable amount of time.


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?


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.


> 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.

Yeah, as the author implied: languages you don't know are hard to read. Let's just pause for a moment and reflect on how Haskell is also beat up over this, but as one twitter user recently pointed out[0], we pretend that stuff like this:

    concatMap :: [a] -> (a -> [b]) -> [b]
is somehow less readable and "harder to learn" than common expressions in more mainstream languages where we see absolutely inscrutable equivalent constructions:

    SelectMany<TSource,TCollection,TResult> IEnumerable<TSource>, Func<TSource,IEnumerable<TCollection>>, Func<TSource,TCollection,TResult>)

The sin of these languages is not that they're hard to read, it's that you're irritated with unicode syntax. But languages that support dense constructs will always need to appeal to symbolic artifice to not end up being totally unreadable strings of useless syllables, as above.

You might argue in the Pythonic tradition that such code shouldn't be allowed to exist. But that's a bit of a lie from Python. They just want to push it up and up the library chain to where someone anointed as "sufficiently smart" eventually just has to write a dozen lines to do the same thing we could have taught everyone to do with the conveniences of notation that lean on natural language.

[0]: https://twitter.com/MxLambda/status/1147150220876308480


The latter looks gross, but has something the former doesnt: words and names. Even if it's verbose and ugly, I can at least puzzle it out just based on the information at hand (I can figure out that <> is similar to (), and Enumerable/Select/Func/Collection/Result are all words I can figure out). I wouldn't be able to write that expression without knowing the language, but, I can read it, even if it's gross. It's also much easier to lookup. I can google IEnumerable a lot more easily than "what is -> after ::".

The haskell version on the other hand is undeniably more elegant, but if I don't know those symbols I'm ENTIRELY lost. There's nothing about :: that means anything to me if I don't look it up. Likewise -> only implies... a transform of some sort? And [a] might mean a list, or, it might mean optional, or it might mean... lots of things.

To be clear, I like the haskell version better, but it is more opaque to a beginner.


> Even if it's verbose and ugly, I can at least puzzle it out just based on the information at hand (I can figure out that <> is similar to ()

But you can't make similar inferences about [] and ->? I mean... it's an arrow. People generally get what arrows imply about processes, right? Most kids are exposed to a flow chart somewhere in their lives.

> Enumerable/Select/Func/Collection/Result are all words I can figure out

Only because of extensive exposure to a world where that works. And I submit SOME of those words are quite sketchy. For example, what exactly is a "Select" and what on earth does "Result" mean on this? Why do we need such a special type? And what's the semantics significance of "T" vs "I"?

I think you're ignoring what you know. In terms of the number of symbols at play that you'd need to know, the Haskell is more familiar because you need far fewer symbols AND fewer words AND it actually constrains the implementation much less!

> There's nothing about :: that means anything to me if I don't look it up.

But you can just work out what <> means? Especially given that this code could easily be in one of 3 languages that all have significantly different semantics for <>?

> Likewise -> only implies... a transform of some sort? nd [a] might mean a list, or, it might mean optional, or it might mean... lots of things.

That's probably a less opaque concept than "IEnumerable".

> To be clear, I like the haskell version better, but it is more opaque to a beginner.

This fictive beginner who doesn't know what a function is but naturally can work out what "Select", "Func" and "Enumerable" are is a very strange story to me. If you're expecting me to just accept this person exists, I'm afraid I'm going to disappoint you by saying it sounds unlikely.


> But you can't make similar inferences about [] and ->?

Words are WAY less ambiguous. -> means pointer dereference, or function call, or an associative mapping in other languages I know. [] is often an indexer, or an indication of a fixed allocation, or an indicator in documentation that a value is optional...

Both of those symbols have very overloaded meanings.

> For example, what exactly is a "Select" and what on earth does "Result" mean on this?

I mean, Result is pretty straightforward. Especially in the context of "Func" which is already there. Select is a common phrase used in, well, english, but also sql, smalltalk, C#, ruby ... and a bunch of others. If I know any of those it's a pretty big hint. It's also a common word for anyone that uses computers. If I say "select a group of files" you know that I mean, grab some files based on some criteria. If I tell you to concat map a group of files, you would probably have no idea what the hell I'm talking about.

> But you can just work out what <> means?

It's roughly the same shape as () and [] and I already know it from html.

> That's probably a less opaque concept than "IEnumerable".

Subjective really. Enumerable means a thing that can be numbered. That's pretty unambiguous. [a] in unix docs often means "optional". Or it's an indexer. Or it's.. it's used in a lot of different ways.

> This fictive beginner who doesn't know what a function is but naturally can work out what "Select", "Func" and "Enumerable" are is a very strange creature to me.

To most programmers, a function looks like:

f(a,b,c)

The alternative:

a -> b -> c

Is REALLY unfamiliar to most programmers that have never been exposed to a functional language like haskell or F# (which is to say, most programmers). Select and enumerable are commonly used vocabulary (well, maybe the former more than the latter, but enumerable is an easy word to lookup). Func is a very common abbrev.

I've read some intro to haskell docs, and even I don't remember what :: means. There's nothing implicitly about :: that means anything at all. In C++ it's a namespace separator. In other languages it apparently just gets used because a single ":" just doesn't quite get the point across well enough.


> I mean, Result is pretty straightforward. Especially in the context of "Func" which is already there. Select is a common phrase used in, well, english, but also sql, smalltalk, C#, ruby ... and a bunch of others. If I know any of those it's a pretty big hint.

> It's roughly the same shape as () and [] and I already know it from html.

The entire point of this is that folks who are educated in a language forget how much they had to learn to render a piece of code obvious, instead appealing to "simplicity" and imaginary beginners.

I think these quotes demonstrate that's how you're thinking here too.


My point, which you seem to be avoiding, is that words are a lot less ambiguous than symbols.

EDIT for additional point: also, since your examples are haskell and C#, let me point out that reality seems to agree with me here, since C# is vastly more popular than haskell. If you're learning something, learning something with less ambiguity is usually easier. Considering that F# is similar(ish) to haskell and has the full power of the .NET platform and is still vastly less popular than C#, I think it's clear which option people think is easier. Easy may not be better, but that's a separate discussion.


> My point, which you seem to be avoiding, is that words are a lot less ambiguous than symbols.

Sorry, I don't accept this and you haven't demonstrated it except to say "well we can use an appeal to other things for words, but not for symbols." That really dosn't fly at all, for me.

> let me point out that reality seems to agree with me here, since C# is vastly more popular than haskell. If you're learning something, learning something with less ambiguity is usually easier.

This isn't actually an argument. It's a hope.

Besides, many of the folks in industry learned to program in other languages than the ones they use today in industry, but not languages that didn't exist at all.

> Considering that F# is similar(ish) to haskell and has the full power of the .NET platform and is still vastly less popular than C#,

Imagine, if you please, a world where people in industry and on Hacker News repea an untrue mantra that one language is "simpler" from first principles, confusing familiarity with simplicity? In such a world, educators would look to what the industry demands and feel that in good faith, they should give those languages some treatment in courses over time. We might also see these universities (under pressure from an increasingly competitive market for the bulk of undergrad education), start to set aside time-tested teaching languages and regretfully move to courseware that prepares people for these industry jobs.

I feel like maybe my story matches reality at least as well as yours. It also explains why a simpleton like me might be able to learn these supposedly unapproachable languages like Forth, Lisp, F# and Haskell without appealing to me being a genius.


> > My point, which you seem to be avoiding, is that words are a lot less ambiguous than symbols.

> Sorry, I don't accept this and you haven't demonstrated it except to say "well we can use an appeal to other things for words, but not for symbols." That really dosn't fly at all, for me.

Nobody is a blank slate. When we learn things we associate with what we already know. The power of symbols is that they are inherently abstract and are not associated with what we previously knew, but when we're learning things that makes symbols harder to understand, not easier. "Sum" is a lot clearer than "Σ" if you're starting out. Quick, what do you think this means?

    {↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
(That's an actual program, btw, I didn't mash my keyboard). If you don't know any of those symbols, where would you even START?

But wait, let me make it easier on you:

    life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
Now what do you think it means? Does it give you a place to start, at least? (That's the APL version of the game of life)

That version of the game of life is much simpler than if I were to write it in C#, which would be hundreds of lines longer. But is it easier? Of course not. It's absolutely baffling.

> Imagine, if you please, a world where people in industry and on Hacker News repea an untrue mantra that one language is "simpler" from first principles, confusing familiarity with simplicity?

Simple and easy are not the same things. Familiar IS easier, even if it's not simpler. I can imagine that world, but I also live in this world, where people have a current set of knowledge and it's easier to bridge the gap between what they don't know and what they do know by using what they already know.


Sure you know what `sum` means, and maybe even what `product` means.

`sum` is applying `add` repeatedly to a list. `product` is applying `multiply` repeatedly to a list.

The thing is most people use `+` instead of `add`.

Also why use two different things for `add` and `sum`?

How about we use `+` for both `add` and `sum`, since they are basically the same thing:

    1 + 2 + 3
    [+] 1, 2, 3
While we are at it, let's make it so you can also do the same for `multiply` and `product`:

    1 * 2 * 3
    [*] 1, 2, 3
Or perhaps even make it so that you can use any associative infix operator:

    1 ** 2 ** 3
    [**] 1, 2, 3

    1 < 2 < 3
    [<] 1, 2, 3

    (1,2) ⊆ (1,2,3) ⊆ (1,2,3,4,5)
    [⊆] (1,2), (1,2,3), (1,2,3,4,5)

    0 || 0e0 || Nil || 1
    [||] 0, 0e0, Nil, 1
I'm sure you know what exponentiation means, but do you know what word you would use to mean repeatedly applying it to a list? (If you know please tell me, because I sure don't.)

---

After you learn what `sum` means, you still have to learn what `product` means.

However once you learn that you can put any associative infix operator between `[]` and have it apply to a list, you've just learned one thing that is really both of the above, and also many more things.

This makes it quick to learn Perl6. You learn about one thing in one place, and that knowledge applies to everything everywhere. (This is true about almost every feature of Perl6.)

---

If you really don't like the syntax, you don't have to use it.

    # alias the `+` infix operator to a subroutine named `add`
    my &add = &infix:<+>;

    reduce( &add, 1, 2, 3 );
---

I would like to point out that this higher-order feature is basically the same one that allows `+=`.

    my $a = 1;
    $a += 2;
That is because `=` is a meta operator. Meaning it can take an infix operator as a sort-of argument.

    sub infix:<IOP> ( $l, $r ){
        $l + $r
    }

    my $a = 1;
    $a IOP= 2;


    $a *= 1;
    $a /= 2;
    $a max= 10;
I just taught you a second thing that you can now use for most infix operators.

What's more, is that you might have figured out that infix operators are just subroutines with a special name. I didn't even really mean to teach you that.

---

I mean sure a novice is more likely to know what `sum` means. But they have only to read this comment to learn a much larger chunk of Perl6.

Frankly I want newcomers to Perl6 to be confused about `[+]`, because then they are more likely to come to a place where I can quickly teach them everything above.

(Teach a man to fish and he eats for a lifetime. Teach a man to use a net and he can feed his family.)


> {↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

This is such a contrived argument. Firstly, I'd argue that it's only because of extensive exposure to a C#-ish language that you have a mental dictionary capable of fully describing IEnumerable. To most novices, both this and my prior example would be equally impermeable.

> Now what do you think it means? Does it give you a place to start, at least? (That's the APL version of the game of life)

I actually do know this program. It's part of Conway's Game of Life in APL. I know this not because I know APL, but because I copied part of the code into Google. Which is how most folks these days solve programming problems anyways.

And once I know that, I can type "APL ↑ documentation" and tada, I found a wikipedia page! "Select the first (or last) A elements of B according to ×A"

Feels roughly about the same amount of effort as trying to coerce some meaning out of obscure Python library errors, if I'm honest.

> Simple and easy are not the same things.

Thanks for that. Why are you so eager to take the eas yway out?

> but I also live in this world, where people have a current set of knowledge and it's easier to bridge the gap between what they don't know and what they do know by using what they already know.

A world where you're actively discouraging anyone from learning anything new by writing hundreds of words on websites about how they shouldn't do it because it's simpler and not easier, for what it's worth.


>Sorry, I don't accept this and you haven't demonstrated it except to say "well we can use an appeal to other things for words, but not for symbols." That really dosn't fly at all, for me.

Words are easier to lookup than symbols. Symbols can be easy to reference when you know where to look, but unless you know what other words to stick into Google (especially if you don't know what language a particular snippet is), ":: programming" will be utterly useless, while searching IEnumerable will return results for C# immediately. When you are new to programming, the ease of finding relevant documentation can make things a lot less ambiguous.

>In such a world, educators would look to what the industry demands and feel that in good faith, they should give those languages some treatment in courses over time. We might also see these universities (under pressure from an increasingly competitive market for the bulk of undergrad education), start to set aside time-tested teaching languages and regretfully move to courseware that prepares people for these industry jobs.

You mean like Java? It's time-tested and the bulk of the developer positions in my area want Java experience. Coincidentally, it's also a common language to teach in undergrad. I've only seen functional languages listed by companies that list every language under the sun, and research positions.


> Words are easier to lookup than symbols. Symbols can be easy to reference when you know where to look, but unless you know what other words to stick into Google (especially if you don't know what language a particular snippet is), ":: programming" will be utterly useless, while searching IEnumerable will return results for C# immediately. When you are new to programming, the ease of finding relevant documentation can make things a lot less ambiguous

Weird because the other poster posted an APL snippet and I worked it out with a search engine without content.

> You mean like Java? It's time-tested and the bulk of the developer positions in my area want Java experience. Coincidentally, it's also a common language to teach in undergrad. I've only seen functional languages listed by companies that list every language under the sun, and research positions

I was there when Java started appearing in Universities. They didn't choose it because it was easier than scheme. They chose it in hopes of making it easier for graduates to find work with employers increasingly not giving a shit about training and graduates increasingly being reluctant when askedd to learn new things outside of school.


It's a trade-off, though: Compactness and visual variety can help readability. There's a reason why symbolic math notation won out, and why the most regular and/or verbal languages (eg Lisp, Cobol) haven't won over everyone's hearts and minds.

> I can google IEnumerable a lot more easily than "what is -> after ::"

That's not really a fair comparison. You're comparing an identifier in one language with the basic syntax of the other. The correct comparison would be whether : {} <> [] , ++ ; & * and other syntax structures of the C-like counterpart are more easily searchable or understandable than those of Haskell, which I don't think is the case.


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

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


For the record, this could also be written as

    (1..100).hyper.map(&f).reduce(&g)
Syntactic sugar can make a mess when overused, but also improve readabiliy tremendously when used judiciously.

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

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

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.


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

Are you implying that Perl 6 is the only language in which adding / removing a `!` or a `not` does not alter the behaviour of a program in orthogonal ways???


I'm not implying anything. I'm directly referring to points made in the post (emphasis mine):

--- start quote ---

It is so dense with information that skipping a single symbol might drastically change your interpretation of the entire bit of code. Want to see how dense Perl 6 can be?

  [[&g]] (1..100)».&f
Every single symbol in that line of code carries a significance, and the code would be drastically different should any of the symbols be missing or different.

--- end quote ---

Couple that with an insane amount of operators and the "there's more than one way to do it" philosophy, and you'll see what I'm against.


You hear such complaints a lot, but frankly, this has never been an issue for me in practice.

> 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.


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

Do you think that the patronising and confrontational tone of this comment and others here are effective at getting your points across, because I'm not finding any positive reasons to be interested in Perl 6 and its community in what you've said... or maybe in how you've said it.


Firstly: do you think this is particularly patronizing? I don't think that discussing burn-out and how people come across in that state is so.

Secondly: the GP is, by any reasonable standard, pretty dang patronizing in and of itself. Stuff like:

>> 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.

Is that elevating the discourse? I think the reason folks are willing to overlook this is because they think it's socially acceptable to hurl insults when they dislike the flavor of the syntax rather than actually offering concrete complaints. Folks in the various responses have mocked perk, its users, and diagnosed the author with various illnesses.

> or maybe in how you've said it.

I don't have much of a stake in Perl 6. I think it's interesting. What I am invested in is reminding folks that good notations require investment of time to read. That's the case for every other applied science, but because of the pervasive scorn directed by the world at computer science, folks view any effort put into programming as wasted.

I'm not trying to give you a reason to use Perl 6, so there is no surprise you didn't find it. I'm trying to reflect back these learned behaviors and show how arbitrary and thoughtless they are.


> 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

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.


> "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.


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

Conlangs can be universal. Certainly Toki Pona and Esperanto punch above their weight when given an opportunity to do so.

> 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?

Programming languages that lack these constraints not only exist, they're quite famous. You may have heard of Lisp. Similarly, the vocabulary that is the union of every C library in existence is surely more than half a million distinct tokens!

Both natural languages and constructed programming languages can constrain themselves to subsets of the total vocabulary, and then extend or contract that context.

> . 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.).

Programming has tons of these as well. Many concepts are overloaded right now! The semantics under the symbols are constantly evolving. Heck, even things you might not believe have changed at lot have altered in subtle but important ways, like "new" and "delete" and "malloc" and "fopen." One of the most dramatically changed is "map."

> What you call modern were most likely discovered in 1940s-1960s.

No. 1990 onwards. People still spout absurdities like, "the fastest you can sort an array is O(n log n) time." But another important example is Bagwell's Hash Array Mapped Tries, which dramatically improve the performance of well-ordered key-value stores dramatically on modern hardware.

Outside of some interesting index techniques, I can't think of many worthy algorithms from the 60's lingering in obscurity. Can you?

> 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?

If you don't change your methodologies at all over the course of a decade as the entire world of computer science revolutionizes itself and we even start rethink how we're organizing operating systems?

> 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?

Are there? I know a few banks deeply regretting their decision to keep their system of record on outdated cold-war-era technology as they struggle with hard complexity caps they can't address. But sure, I'm sure somewhere somehow this is true. It's just not actually an argument.

> 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.

This is a just-so story. There is no magical solution that makes all code permeable. It's misguided to assume code can exist without good documentation.

> 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.

Hi, I actually know a lot about this and there is no such notion in Rails. In fact, you have it exactly wrong. Rails is deeply committed to a "good default behavior" that is always subject to modification. And people do in fact modify it extensively to suit their needs. The idea that Rails's defaults are constraining as opposed to a rational starting point fundamentally misses the point.


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...


$ 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.


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

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.

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

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

Startup time is only relevant in specific cases, and doesn’t really reflect what most people think of as the language speed. It’s most important in serverless apps or similar cases where a small script is going to be called very frequently and the results are time critical, in most other cases it is very quickly made irrelevant by the duration of the task itself. For example, Java and C# start up slower than many interpreted languages, but can be significantly faster once they get going. I suggest a more accurate benchmark to be something that include some file io, string processing, arithmetic, and some basic data structure operations. I have an idea I might code up later.

One of the key use-cases for Perl 5 in scripts was as a replacement for sed/grep/awk. In a makefile or batch processing script, these can get called hundreds to thousands of times per second effortlessly. With a startup time of .2s, you could only start a Perl 6 interpreter 5 times per second, which is a major slowdown and eliminates it from this class of use-cases.

If you're doing some sort of processing where you're calling an external script hundreds or thousands of times, you're probably doing it wrong. You should be writing it to get called once and process your input as it comes in.

That goes regardless of language. If you're calling an external "thing" thousands of times to process something, you're going to have issues with performance because the approach to processing the data is bad.

You can get away with it to a point by using only the most simple and basic of tools (cat/cut/tr/echo/grep/etc), but one of the common reasons that shell scripts get rewritten in Perl/Python/etc is to process data without making hundreds of thousands of calls to spawn external processes.


    Myth: Perl 6 has a bizarre ecosystem.
And then goes on to explain that it has a bizarre ecosystem.

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.

>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.


In reality Perl6 is strangely consistent.

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.


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

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


Perl Regular Expression Matching is NP-Hard

https://perl.plover.com/NPC/


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.


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

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?

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.


“Myth: Perl 6 has a bizarre ecosystem.”

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


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


> 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.


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?

Found this link in there and it looks interesting: https://perl6intro.com/

The easy concurrency stuff is cool and very useful.

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)


“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?


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.


Those are probably mostly Perl5 people, though.

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


You mean like cperl which already exists but was totally shunned by the Perl 5 community? http://perl11.org/cperl/

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

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.

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.

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) 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.

Nice summary! I'd enjoy reading more of your success stories rather than more mindless hurr hurr! Perl bashing.

Thanks! I'll see what I can do about writing things up and posting them somewhere. My site is a mess at the moment (always has been), but maybe this will motivate me to do something about that.

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

Is this satire?

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

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


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.


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

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 )

A well informed opinion.

TIL that Perl 6 is an APL wannabe

People still use Perl?

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


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

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

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


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 (misspelled link + 404 error to documentation)

• Cro: 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 (this one is actually good. just needs some polishing for new comers)

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

And compare that to the following:

• Rails: https://guides.rubyonrails.org/getting_started.html

• Django: https://www.djangoproject.com/start/

• Laravel: 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".


For Cro the documentation is much more extensive than you suggest 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.


As far as I'm aware, there's nothing "official" about any of the three examples you linked. They've just gained unanimity.

You're looking for Cro

https://cro.services


Ho doesn't have a framework either but it's quite easy to start a webserver/develop a web app.



Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: