Myths about Perl 6
aearnus.github.io
aearnus.github.io
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.
I think this is part of the joke.
So it is more about the speed not being evenly distributed.
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."
5 exists and will always exist. :-)
----
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.
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.
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.
It's taken with minor adjustments from this Monty Python scene: https://youtu.be/Jdf5EXo6I68
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.
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.
... if they don’t decide to just name perl 5.100 “perl 7” instead
Right, it's way better. What makes you ignore all the great improvements the PTS have made?
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 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.
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.
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.
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.)
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.
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.
Dhall is amazing. But it's domain is very limited.
Good answer!
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.)
On the upside, the parallelism story is better than Python's or Perl5's.
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).
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.
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.
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.
----
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...
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.
> 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...
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.
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.
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?
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.
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");
}
print("hi\n") xx 10;
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.)
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.
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.
Now I'm curious about the things you wanted from Perl that it did/does not provide. :)
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.
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.
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.
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.
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.
It’s as if writers were more focused on weird typewriters than writing interesting novels.
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.
IDK, they tend to call me names the instant they see I have Haskell and Erlang on my github.
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.
I ask this as someone who has several systems written in Perl 5 in production.
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.
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:
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.
[1] https://www.perl.com/pub/2000/05/p5pdigest/THISWEEK-20000507...
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...
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.)
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
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.
* 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.)
> 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 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.
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.
I wish they'd stop calling it Perl already. Perl 5 is still actively maintained and developed.
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.
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.
> 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.
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.
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.
https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
If anyone sees that happening and we haven't moderated it, the likeliest explanation is 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.
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.
use v6;
for 'logs1.txt'.IO.lines -> $line {
say $line if $line ~~ m/<<\w ** 15>>/;
}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.
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.
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).
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.
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).
> 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.
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’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.
"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.
The following talk covers most of those improvements, as well as some of the new direction: https://youtu.be/4wKyNYs7eZw
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?
> 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.
[[&g]] (1..100)».&f
> Myth: Perl 6 is too complicated and too hard to learn.
C Chaining infix != ≠ == < <= ≤ > >= ≥ eq ne lt le gt ge ~~ === eqv !eqv =~= ≅ (elem) (cont) (<) (>) (<=) (>=) (<+) (>+) ∈ ∉ ∋ ∌ ⊂ ⊄ ⊃ ⊅ ⊆ ⊈ ⊇ ⊉ ≼ ≽
In all fairness you can construct an obtuse example for any programming 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 (1..100).hyper.map(&f).reduce(&g)
concatMap :: [a] -> (a -> [b]) -> [b]
SelectMany<TSource,TCollection,TResult> IEnumerable<TSource>, Func<TSource,IEnumerable<TCollection>>, Func<TSource,TCollection,TResult>)
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 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.
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.
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.
> 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.
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.
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.
> 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∘.⌽⊂⍵}
But wait, let me make it easier on you:
life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
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.
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.
`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
1 * 2 * 3
[*] 1, 2, 3
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
---
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;
sub infix:<IOP> ( $l, $r ){
$l + $r
}
my $a = 1;
$a IOP= 2;
$a *= 1;
$a /= 2;
$a max= 10;
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.)
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.
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.
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.
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.
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???
--- 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
--- 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.
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.
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.
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.
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.
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.
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.
[0] https://github.com/wilt00/startuptime/blob/master/analysis.i...
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.
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.
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.
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.
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.
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.
Based on the explanation provided I would have to say “myth confirmed”. It’s not exactly straightforward.
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...
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.
It definitely looks interesting. I remember when the “best” Perl 6 was implemented in Haskell (https://github.com/perl6/Pugs.hs)
Wait, so it’s not a “myth” then, right? Or am I missing the joke?
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.
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) };
sub MAIN(IPv4::Private :$ip) { ... }
λ | ./deploy --ip=$(dig +short myip.opendns.com @resolver1.opendns.com)
Usage:
./deploy.p6 [--ip=<Private>]
λ | ./deploy --ip=10.0.0.2
Deploy successful.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.
enum Style <boxed compact>;
#|(Default display style is boxed.)
sub MAIN(Style :$style = boxed) { ... }
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
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.
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
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
> 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".
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.