I think 6lang naming proposal is Good
6lang: The Naming Discussion Update
I'm Perl programmer, not Perl 6 programmer. People seem to think Perl 6 is successor of Current Perl at first time.
It is strange that Version Number is contained in Language Name. We should admit this idea is wrong.
Perl 5 vs Perl 6 never produce any values. Many misleading occur and it damage Marketing of both Perl 5 and Perl 6.
…Read this article on 6lang.Party
When a couple months ago I rekindled the naming debate—the discussion on whether "Perl 6" should be renamed—I didn't expect anything more than a collective groan. That wasn't the case and today, I figured, I'd post a progress report and list the salient happenings, all the way to my currently being the proud owner of 6lang.party domain name.
The "new" name I mentioned in my original post was Rakudo. As many quickly pointed out, it wasn't the greatest of names because it was the name of an implementation. Yes, I agree, but originally I thought few, if any, would be on board with a new name, or extended name, and Rakudo was basically the only name people already were using, so it stood out as something that could be "hijacked."
There was quite a bit of discussion on r/perl, r/perl6, and blogs.perl.org. The general mood among the Perl community members who aren't avid 6lang users was that the entirely new name was a good idea. However, the 6lang users, and especially core devs, overall, argued "Perl 6" still had some recognition benefits and should not be removed entirely.
The middle ground was aimed at then: extend the language name. The "official" name would be among the lines of "Blah Perl 6" and users opposed to the 4-letter swear word would just use the name extension on its own, while those who feel the original name has benefits can still reap them.
The decision on the naming extension was placed on the 6.d language release agenda, with the final call on whether and with what the name should to be extended to be done by Larry, when we cut the 6.d language release.
Fast-forward two months. A kind soul (thank you, by the way!) asked Larry what he thought about the naming debate during the last Perl Conference:
Larry opined that we could have other terms by which Perl versions or Perl distributions are marketed as. So that gives us an option to pick an alternative name to be the second name with any "official" standing. Personally, I really like this idea; even more than name extension, because should there indeed be more benefit to the name without "Perl" in it, the alternative name will naturally become the most-used one.
Another core dev, AlexDaniel++, coined an alternative name: spelt 6lang; can be pronounced as slang, if you want to be fancy. I really liked the name, so I jumped in and registered 6lang.party
<AlexDaniel> Zoffix++ for making me recognize the need for
alternative name. For a long time I was against
<AlexDaniel> and honestly, I can start using something like 6lang
right away. “Rakudo Perl 6” is infringing on
language/compiler distinction so I'm feeling reluctant
<Zoffix> OK, I'll too start using 6lang
* Zoffix is now a proud owner of 6lang.party :D
<timotimo> wow
<AlexDaniel> that was quick
And a couple of hours later, our Marketing Department churned out a new poster:
The drawback is that the name can't be used as an identifier… and Larry doesn't think it's a terribly sexy name.
* TimToady notes that 6lang isn't gonna work anywhere an identifier
needs a leading alpha
<TimToady> it's also not a terribly sexy name
<TimToady> I could go for something more like psix, "where the p is silent
if you want it to be" :)
Although, on the plus side, the name has the benefit that alphabetically it sorts earlier than pretty much any other language.
<AlexDaniel> If we see “6lang” as a more marketable alternative, then
the fact that some things may not parse it as an identifier
practically does not matter. However, this little bit is quite useful:
<AlexDaniel> m: <perl5 golang c# 6lang ruby>.sort.say
<camelia> rakudo-moar 39a4b7: OUTPUT: «(6lang c# golang perl5 ruby)»
<AlexDaniel> :)
<AlexDaniel> .oO( AAAlang – batteries included )
So that's where things progressed to so far. No official decisions have been made yet, but we're thinking about it and playing with the idea. The decision on the naming debate is to be made during 6.d release.
Having learned a painful lesson from The Christmas release, we're reluctant to put down any dates for 6.d release, but I suspect it'll be somewhere between the upcoming New Year's and It's-Ready-When-It's-Ready.
See you then \o
This article represents my own thoughts on the matter alone and is not an official statement on behalf of the Rakudo team or, perhaps, is not even representative of the majority opinion.
When I came to Perl 6 around its first stable Christmas 2015 release, "The Name Issue" was in hot debate. Put simply: Perl 6 is not a replacement to Perl; Perl 6 is not the "next" Perl; Perl 6 is a very different language to Perl; so why does it still have 'Perl' in its name?
From what I understand, the debate raged on for years prior to my arrival, so the topic always felt taboo to talk about, because it always ended up in a heated discussion, without a solution at end. However, we do need that solution.
The major argument I heard (and often peddled myself) for why Perl 6 had 'Perl' in the name was because of brand recognition. The hypothesis was that fewer people would bother to use an unknown language "Foo" than a recognizable language "Perl". Now, two years later, we can examine whether that hypothesis was true and beneficial and act accordingly.
The Perl 6 language—to which I shall refer to as Rakudo language, for the rest of the article—is versioned separately from its implementations and is defined by the specification. The current version is 6.c "Christmas" and the upcoming version is 6.d "Diwali"
As some know, despite slinging a lot of code in my spare time, I earn my bread under the banner of Multi-Media Designer. While one of the "media" I work with is Web and so I do get to write some code once in a while, my office for the past 8-ish years has been located squarely in the Marketing Department, not I.T.
As the Rakudo core team was recently penning down the dates for 6.d release, I got excited to have the opportunity to do some design and marketing for something quite different than products at my job. However, I very quickly hit a roadblock. The name "Perl 6" isn't quite marketable.
Ignoring trolls and people whose knowledge of Perl ends with the line-noise quips, Perl is the Grandfather of Web, the Queen of Backwards Compatibility, and Gluest language of all the Glues. Perl is installed by default on many systems, and if you're worthy enough to wield its arcane magic, it's quite damn performant.
Rakudo language, on the other hand, is none of those things. It's a young and hip teenager who doesn't mind breaking long held status quo. Rakudo is the King of Unicode and Queen of Concurrency. It's a "4th generation" language, and if you take the time to learn its many features, it's quite damn concise.
Trying to market Rakudo language as a "Perl 6" language is like holding a great Poker hand while playing Blackjack—even with a Royal Flush, you still lost the game that's actually being played. The truly distinguishing features of Rakudo don't get any attention, while at the same time people get disappointed when a "Perl" language no longer does things Perl used to do.
So did the hypothesis about Perl brand name recognition hold true? Yes, but Rakudo language has very different strengths than those that brand represents. Which leads to a lot of confusion, disappointment, and annoyance.
As the 6.d language release nears, and with it the ability to make large changes, I think it would benefit us to reflect on the issues of the past two years and improve.
Even if the entire Rakudo community would decide a different name is good, there's a teenie-tiny problem of existing infrastructure. Need documentation? You go to perl6.org, not rakudo.org. Need a live, squishy human to help you out? You go to #perl6 IRC channel, not #rakudo. Need a Rakudo book? Why, then go to perl6book.com and pick any of the books with "Perl 6" in their titles.
This is one of the major things that derailed my thinking on the subject
in the past: people saying "just rename it," when clearly it's no easy task.
Domain names, email addresses, bug trackers, Reddit subreddits, Facebook
groups, Twitter feeds, GitHub orgs, IRC channels, presentations, books, blog
posts, videos, hell, even names of some variables ($*PERL) and env
vars (PERL6_TEST_DIE_ON_FAIL) would all need to change for a thorough rename
job.
Not only would all those things need a rename, the old versions in many cases would need to be able to redirect to the new name. "Just renaming" perl6.party website and its contents will take me some effort and already incurred a minor expense for a new domain name. The effort required to do the same everywhere would be monumental and in the end we'd still go to The Perl Conference and get sponsored by grants from The Perl Foundation.
I think the ship for "just renaming" it has sailed a few years before first stable language release. However, we don't have to be at the mercy of all-or-nothing tactics, when there are clear benefits to reap from a name tweak.
Rakudo is the name of a mature—and to date, the only one that's usable—implementation of the language. If Wikipedia is to be believed, the name means "The Way of The Camel" or "Paradise."
It's also the name that's ripe for the picking to be the name of the language: those who use the language
already have heard the name, so it's familiar; the compiler's repo
is rakudo/rakudo, not perl6/rakudo;
newcomers are told to install "Rakudo Star," not "Perl 6 Star"; and having
an already bikesheded name can cut down on irrelevant
discussions when the need for change itself is controversial.
While it's true that re-using the compiler's name for the language creates an
ambiguity, it can be resolved by using all-lowercase
letters for the compiler and title case for the language—Perl 5 has been doing
that for years. In addition, if the executable were to be renamed
from perl6 to rakudo, there'd be fewer accidents of running Rakudo scripts
with perl command, which is currently is actually actively fought against by
the recommendation to put use v6 in all of the programs.
The "Rakudo Perl 6" name for the language was suggested by lizmat++, so I assume there's at least one other core team member who's open to the language name tweak. And I do precicely mean tweak, not change. While change would be more preferable, it stands opposed by existing infrastructure naming and, of course, those who believe Perl 6 is a fine name and should be kept unchanged. So by tweaking the language name to be "Rakudo Perl 6," we get the benefit of marketing a new release of a hot new language "Rakudo 6.d" instead of a new release of same-name-but-totally-not-Perl-5 "Perl 6.d"; we get to keep using "perl6" ticket queue on RT, without raising too many confused eyebrows; we get to publish Rakudo blog posts that don't get knee-jerk reactions form non-Perl users; we get to attend The Perl Conference without feeling we don't belong; we get to mention how awesome Rakudo is to our peers without fearing yet-another pointless "Perl is dead" discussion; we save the trees by not reprinting all of the existing "Perl 6" books"; yet we get to... start anew.
Humans are funny creatures. We don't like to change our minds, lest we appear to not have a clue. We cling to past decisions and things said because abandoning them is admitting you were wrong. However, looking at the past two years, it's very clear to me the name of "Perl 6" has been detrimental to the language. I'm not afraid to admit I was wrong in defending the "Perl 6" name.
It's an indicator that something's wrong, when you spent days writing an amazing technical post but have anxiety posting it to r/programming because it'll inevitably end up with quips and jokes about Perl being late to the party. It's an indicator that something's wrong, when you're apprehensive joining a tech discussion to mention how easy the task is to do in "Perl 6," because even well-meaning people have a hard time realizing Perl 6 is an entirely new language.
I'm under no delusion that merely changing the name would instantly make everyone love the language. There are still performance problems to tackle. More bugs to fix. More documentation and tests to write. All these things need humans to work on them and humans care about perception. The assumption that many humans will start using Rakudo simply because it's a better product just does not match reality.
It would be beneficial to change the perception of the Rakudo language. Ignoring the problem won't do that. Including boiler plate text about Perl 6 being new language that's totally different from Perl 5 at the start of every conversation won't do it. Tweaking the language name to be unique will. It doesn't have to be a dramatic event, but...
Last night I registered rakudo.party and changed my Twitter bio to no longer refer to the language as "Perl." In the coming days, I'll update all mentions of "Perl 6" on rakudo.party to read "Rakudo" or "Rakudo language" where it's ambiguous with the rakudo compiler. My IRC hostmask and module descriptions on GitHub will follow suit. My conversations, Twitter hashtags, Facebook posts... all will refer to Rakudo instead of Perl 6, just as I've been doing in this post.
However, that is about the end of my unilateral control of the whole thing. I can't change docs.perl6.org or the next blog post you'll write, which is why I strongly encourage those who care about The Name Issue and especially those who care about success of the Rakudo language to do the same active language name tweak I'm doing.
Acknowledge that language's full name is "Rakudo Perl 6". Yes, there's a compiler with a similar name, but it's the next best thing after nothing. Shorten the full name of the language to just "Rakudo," to differentiate it from THE Perl; you don't even have to worry about spacing issues if you do! Tell people about Rakudo's unique features, not about how it's trying to catch up to the things Perl 5 does well.
Rakudo has many strengths but they get muted when we call it "Perl 6". Perl is a brand name for a product with different strengths and attempting to pretend Rakudo has the same strengths for the past 2 years proved to be a failed strategy. I believe a name tweak can help these issues and start us on a path with a more solid footing. A path that invites newcomers, not scares them with knee-jerk reactions and fear of using an outmoded product.
I may be wrong about it. I may be the only fucking idiot on the planet with a "#Rakudo" hashtag in their Twitter bio. But... I think I'm right about it, and I hope you'll join me and use the tweaked language name.
-Ofun
The Perl Toolchain Summit (PTS) started yesterday (Thursday 11th May) in Lyon, France. 35 dedicated toolchain developers have assembled for four days of intensive discussions and co-working. Not only does a lot get done in these four days, but we send everyone home with longer todo lists, fired up to keep working on them.
The developers come from around the world, and we're only available to do this with the generous support of all of our sponsors. You've seen individual posts for our Platinum and Gold sponsors, but in this post we'd like to tell you about our other sponsors. If you get the chance, please thank them: all Perl developers benefit from this summit.
This year the Perl QA Hackathon has been rebranded as the Perl Toolchain Summit on the advice of the marketing team. This is the tenth year that the event has been held and, after missing the first few due to scheduling conflicts with my (then young) children's birthdays, I suppose I have now become something of a regular. This year the event is being held in sunny^W rainy Lyon - a shortish train and car (thanks Lee) ride for me.
The Perl Toolchain Summit (hereafter PTS) has become the most important Perl event of the year for me. It's a chance to get together in one room (two actually) as many of the people as possible who work on the Perl infrastructure. This is not the perl core, but the entire toolchain that fits around the core - primarily focussed on CPAN, the archive of Perl modules. CPAN was one of the first such archives, and the infrastructure around it - especially with regard to CPAN Testers and the MetaCPAN architecture, is generally regarded as without peer.
PTS brings together about 35 Perl developers from around the globe to work on this infrastructure together, and to thrash out the sort of problem in which five or six people can sit together and find a good solution which might otherwise have taken months of discussion to reach.
These discussions often mean that people leave with longer TODO lists than when they arrive, which is probably as it should be. But apart from the discussions, there's also a lot of hacking work that takes place, and it's remarkably efficient, when working on code that uses someone else's module, to be able to lean over and ask them a specific question about that module.
In short, if you or your company cares about Perl, you should probably care about PTS.
PTS started on Wednesday afternoon for me. On the train I was able to merge a pull request for Devel::Cover that I had been putting off for too long. I carried on merging pull requests on Thursday, the first full day of the PTS, and fixed various problems and closed a number of tickets. Then I released Devel::Cover 1.25. I also had a number of interesting discussions about thorny Devel::Cover problems, and the future of cpancover.
In the evening we had a joint meal at an Ethiopian restaurant, sponsored by cPanel (thanks!) and Lyon almost beat Ajax by enough to get to the Europa League final, but just missed out.
Looking forward to day 2 being as productive.
Many thanks to all the sponsors without whom this event would simply not be possible: Booking.com, ActiveState, cPanel, FastMail, MaxMind, Perl Careers, MongoDB, SureVoIP, Campus Explorer, Bytemark, CAPSiDE, Charlie Gonzalez, Elastic, OpusVL, Perl Services, Procura, Oetiker+Partner.
In my $dayjob at GetResponse I have to deal constantly with time dependent features. For example this email marketing platform allows you to use something called 'Time Travel', which is sending messages to your contacts at desired hour in their time zones. So people around the world can get email at 8:00, when they start their work and chance for those messages message being read are highest. No matter where they live.
But even such simple feature has more pitfalls that you can imagine. For example use…
Read this article on Perl6.Party
Recently, I decided to undertake a quick little journey down to the Perl 6's Bug Queue. A quest for fame and profit—some easy game to hunt for sport. There's plenty of tickets, so how hard can it be? The quick little journey turned out to be long and large, but I've learned a lot of good lessons in the process.
Right away, I hit a snag. Some tickets looked hard. On some, it wasn't clear what the correct goal was. And some looked easy, but I wasn't sure whether I wanted to work on them just yet. While the ticket queue has the tag system, I needed some personal tags. Something special just for me....
So I wrote a nice little helper app—Ticket Trakr. It fetches all the tickets from the bug queue onto one page and lets me tag each of them with any combination of:
The app worked great! I quickly started going through the queue, looking over the tickets, testing if the bugs were still there, and estimating whether I could and wanted to fix them. And after a full weekend of clicking, tagging, testing, closing, taking an occasional break to hunt bears with a mortar, more closing, testing, tagging, and clicking, I... was through just 200 tickets, which is only 15% of the queue:
And so I've learned the first lesson.
Whenever I see someone ask how they can contribute, the basket of offers they receive generally contains: docs, marketing, modules and libraries, or bug fixing. Going through the ticket queue doesn't seem to be considered a task on itself. The ticket queue is just a place where you find the bugs to fix, right?
What may not be obvious is the bug queue contains an extraordinary amount of work that can be performed by less skilled contributors to make it easier for highly-skilled—and by extension much scarcer—contributors to fix bugs. Let's see what those are:
Just because you have 1,000 tickets in your bug queue doesn't mean you have 1,000 bugs. Here are some things that might end up as a ticket and how you can help:
This is a lot of work, but this is just the basics. What else can a person new to the project can contribute?
So we've cleaned up our queue and now we have a few reports that appear to have at least some sort of a six-legged quality to them. Sure, we're new to the project and don't even know where to begin fixing them, but that doesn't mean we can't play around with code to narrow down the problem.
Merely being able to reproduce the bug shows it's likely is indeed a bug and not just a quirk of the reporter's system. Speaking of systems: test the bug on several, especially if you have access to esoteric ones.
Test different versions of the project to see where the bug appeared. If
possible, try to narrow down the commit that introduced the bug. For Rakudo
Perl 6 compiler, you can use bisectable bot on IRC:
<Zoffix> bisect: say ^10 .grep: { last if * > 2 }
<bisectable> Zoffix: exit code is 0 on both starting points, bisecting by using the output
<bisectable> Zoffix: (2016-03-18) https://github.com/rakudo/rakudo/commit/6d120ca
Even if you can't fix the bug, all this extra information can help a more knowledgeable contributor. Especially if they are the author of the commit that introduced the bug.
I've seen a disturbing amount of people playing code golf. Here is the perfect place to put those skills to good use: reproduce the bug with less code. This narrows down the areas where the bug is hiding.
For example, here's the original [actual] reported code, along with the bug report title:
# You can't catch Proc::Async failing because the external program
# doesn't exist if you open it for writing:
perl6 -e 'my $p; try {$p = Proc::Async.new(:w, "asdfcat"); CATCH {die "in
new"}}; my $pr; try {$pr = $p.start; CATCH {die "in start"}}; try
{await($p.write("hi\n".encode)); CATCH {die "in write"}}; try
{$p.close-stdin; CATCH {die "in close"}}; try {await($pr); CATCH
{die "in await"}}'
That code is a bitch to read, let's pop open an editor and format it properly:
my ( $p, $pr );
try { CATCH { die "in new" }; $p = Proc::Async.new: :w, "asdfcat" }
try { CATCH { die "in start" }; $pr = $p.start }
try { CATCH { die "in write" }; await $p.write: "hi\n".encode }
try { CATCH { die "in close" }; $p.close-stdin }
try { CATCH { die "in await" }; await $pr }
# Outputs nothing when run
That's much better! So the report claims we can't catch things and we've
got five try blocks and no output. Hmmm... Let's get rid of all the
tries and catching and see what error the write throws:
given Proc::Async.new: :w, "asdfcat" {
.start;
await .write: "hi\n".encode;
}
# Outputs nothing when run
And the error is... nothing?! There's no output from the program, so maybe it
"succeeds" in writing things and there's nothing to throw? Let's toss in a
couple of say calls:
given Proc::Async.new: :w, "asdfcat" {
say 'Starting';
.start;
say 'Writing';
await .write: "hi\n".encode;
say 'Wrote';
}
# OUTPUT:
# Starting
# Writing
The Wrote is missing from the output. The original report is incorrect in
its assumptions that the issue is with the CATCH block! There's nothing
to catch in the first place and the .write
Promise seems to exit the program.
Perhaps, CATCH blocks were scary to you, but fixing a bug in a .write
call is less so. And there you go: we found a contributor to fix the bug!
So you've found out that it is a bug for sure and you've played around with code and maybe even found the commit that broke it. You don't know how to fix the bug, so are we done with this ticket then? How about we write tests!
After the bug is fixed, the project's test suite should contain a test checking regression of that bug. Perl's TAP supports TODO and SKIP features. TODO expects the test to fail and will alert you when it starts to pass. SKIP marks the needed number of tests as skipped and your test logic can avoid running them. So even if the bug is not yet fixed, we can still add tests for it—we'll just TODO or SKIP them, depending on how severe the bug is.
Perl 6's test suite has a fudging mechanism that lets you mark tests as skip or todo, depending on the compiler and virtual machine being tested:
#?rakudo.moar 2 todo 'Waiting fix for RT128526'
ok $fixed, 'stuff is fixed';
ok $also-fixed, 'other stuff is also fixed';
The test suite will expect the above two tests to fail for Rakudo compiler running on the MoarVM virtual machine and it will complain when they start to pass. If someone fixed the bug and wasn't aware of the open ticket, running the test suite alerts them of the ticket automatically. Magic!
As a bonus, the tests are the best description of the bug and they also can expose alternate failure modes that aren't apparent from the bug report itself:
<lizmat> .tell Zoffix the tests you added to S29-os/system.t yesterday hang on OSX :-(
There's lots to do in the bug queue, but it's not as dull and boring at it appears at the first sight. And so, the bug queue taught me another lesson...
If you're a new contributor and you want to get up to speed, the bug queue isn't a bad place to start your learning. And there's a lot to learn from it!
You get to see real world code that uses the project you want to learn. Not the out-of-context code in the documentation. Not the polished code in the pre-made examples, but real-life, less-than-perfect, hacked-from-the-hip code. You also get to see code from multiple, vastly different people who use different style guidelines. Being able to easily read code regardless of the style used is a valuable skill.
Everyone and their brother knows about and and what it's for, but did you
know about andthen? I get
flashbacks whenever I see it,
but it's a useful chaining operator
in Perl 6! And I learned about it from a bug report.
You can get very far with language primitives, but knowing more powerful and more appropriate contructs and features will let you write more concise and eloquent code. The bug queue can teach them to you.
Writing tests can teach you the language you're writing them in. Writing tests for the Perl 6 compiler can teach you Perl 6. How much will you need to think when writing a program that runs a piece of code that might hang and in a set amount of time tells you whether the code resulted in success and kills the thread if it hung? I can do it with my eyes closed now.
Writing tests is a skill in itself and the bug queue gives you lots of opportunity for practice.
Going through the bug queue has a large social aspect to it as well:
Also, going through the ticket queue is not the favourite of the people, and the person who does it isn't exactly hated.
The bug queue is a much more complex beast than people may suspect. It has a lot to offer and a lot to teach. From language use, to the quirks of squishy humans. Today, we've examined the vast potential for contribution the ticket queue offers to people new to the project. Helping sift out actual bugs from false reports. Helping with debugging. Helping with tests.
That's not the only thing the bug queue has on the menu. In the next post, we'll examine what it has to teach more experienced regulars and core members of the project! How can you get more bugs fixed? Maybe the bug queue knows the answer.
Hello YAPC-ers,
Deadline seems to be quickly approaching, the Call for Speakers closes July 15th, 2016. But the good news is that you've got plenty of time to submit, prepare your talk && join us in Transylvania,
So come on, share your experience, amaze us with incredible ideas && practices. We want to have our minds blown about what we had never thought could…
A person's experience with a programming language involves many aspects: how a user first learns that a language exists, their first steps in that language, their process of learning more about it, developing in it, contributing to it, and spreading the word about it are all part of that experience. In short, it's a huge swath of elements, which is why it's important to have a means to efficiently identify any issues in that experience, so that it can be improved.
I'd like to announce the creation of The Perl 6 User Experience Repository. Its main page enumerates various aspects of the Perl 6 User Experience and the sub-pages will outline plans to overcome any of the identified problems, or perhaps serve as a documentation repository for protocols, lists of contacts, or other additional files.
A valuable aspect of that repository is the Issues tab where anyone can bring up an issue with any aspect of the Perl 6 User Experience, for possible consideration and improvement. A set of Issue labels corresponding to main sections listed on the main page has been created, so the Issues can be tagged approprietly.
Having a centralized place to raise such issues should prove more useful than an occasional grumble on an IRC channel, a blog post, or a Reddit comment. Those things tend to slip through the cracks and get forgotten.
Here are the main sections currently available. At the moment, they're the result of one mind's work, and thus I fully expect changes: more sections added, sections removed, changed, or expanded. PRs are welcome.
The rest of the User Experience can never exist if no one knows Perl 6 exists. Are there any issues that need to be addressed when it comes to people finding out Perl 6 is a thing? Do the marketing materials deliver their point? Do blog articles, social media posts, and news items about Perl 6 ever reach the ears and eyeballs of those who aren't familar with Perl 6?
Once interest sparks up, how does a person get to the point where they can run some Perl 6 code and have it work? If they care, can the person understand the difference between, say, Perl 6.c the language, Rakudo 2015.12 the compiler, and Rakudo Star the distribution? And if they don't care, is it still easy for them to "install Perl 6"?
At the time of this writing, this is a section where a definite problem has been identified and a plan of action has been put in place.
Installation is just one step. How easy is it for a user to run a Perl 6 program? Such a program may require the functionality offered by a module in the Ecosystem. Is the search feature functional enough to find such a module? Is the toolchain usable enough to correctly install that module?
A Perl 6 programmer produces modules and programs. Is there a toolset available to simplify that process (e.g. a dist-minting toolkit like Dist::Zilla in Perl 5)? Is it easy to package a Perl 6 program so that it can be sold to a customer or deployed by someone not knowledgeable about Perl 6?
Efficiently programming in Perl 6 is tough if you can't get help when you run into issues or don't receive proper training. Do Perl 6 and its ecosystem modules offer useful and complete documentation? Do Perl 6 users know where to ask for help? Can they easily access those channels, even if they don't have experience with things like, say, IRC? Is it easy for them to find out about and attend Perl 6 conferences and workshops?
If a user has any issues with Perl 6 or its compilers or modules, or even something else, how easy is it for them to report those problems? Will they get notified when the reported problems get resolved?
This is an area where The Perl 6 User Experience Repository itself falls under and can itself have issues to be addressed.
Should a user wish to give back to the Perl 6 community, how easy is it for them to find out what needs to be done and to contribute their work? Is it easy for them to get commit bits, if their work is of stellar quality? Do contributors get proper recognition?
A strong community doesn't just talk code all the time. They chat about other things and go out for a drink. Is that available in a Perl 6 community?
Are there any community participation barriers—whether deliberate or accidental—for persons of a particular gender, sexual orientation, race, age, creed, nationality, or physical, mental, or technical abilities?
Is there a Standard of Conduct that sets the bar for the expected way the members of the Perl 6 Community treat others? Is there a particular person one can safely contact in private, when that Standard of Conduct is violated, or when other members of the community are being abusive?
The last section completes the circle the first section started. A Perl 6 Programmer exists in a larger world and tells that world about Perl 6; whether it is by working at a job that involves Perl 6, by interacting with communities of other languages, or by simply spreading the word about Perl 6 on blogs, social media, and conferences.
Are there resources allowing to post or search for Perl 6 job offerings? Are there any issues with other communities? Do Perl 6 markerting materials—like printable brochures or a well-written "sales pitch"—exist and is it easy to obtain them? Is there Perl 6-styled merchandize, like mugs, pens, or shirts, one could either get to keep for themselves or to hand out at some event? Are there places someone can blog about Perl 6, if they don't have a blog space of their own?
The nature of what this repository wishes to address begs an obvious question: won't we end up with a whole bunch of low-quality Issues created by frustrated users banging on their keyboards while foaming at the mouth?
Well, we probably will. If I spent "three f#$(!ng hours" trying to install a Perl 6 compiler just to get "this stupid script" to run, I'll be quite angry, I'll use colourful terms in the Issue I create, and I'll likely blame the creators of whatever I tried to use for my frustration. Those responding to such Issues must be aware of where The Frustrated Reporter is coming from. Something made that user this aggravated and it's possible that something can be improved.
The Perl 6 User Experience covers a lot of things. Big things. Huge things! I suspect most Issues won't be closed with a simple and quick one-line fix. Some will require an extra army of Volunteers. This is what this blog post—and, indeed, the repository itself—is all about: inviting people to pitch in. Not only to report the issues, but to attempt to resolve them, and... to become a part of The Perl 6 User Experience itself.
I mean, can you get it any more WRONG?! The juvenile logo and awful color scheme of the website. The Christmas release that isn't all release-like. Version 6.c? Why not 6.0? What's with the whole "language" and "compiler" distinctions no one cares about? Why is the first stable release of the compiler not optimized to the max? And why is it called "Perl" in the first place? They should rename it!!
Too little, too late. Is there a need for a new Perl? No, of course not. What is it good for? Nothing. What is its business case? None! What's Perl 6's "Killer App"? Non-existent. Why in the world would anyone use Perl 6?!
In the three short months since I joined the Perl 6 community, those are some of the criticisms and attacks I had to endure—and sometimes respond to—on blogs, HackerNews, IRC, and Twitter.... I don't mind it at all, since there's little substance in those attacks. At the end of the day, I'm just writing my Perl 6 code. Enjoying it a lot, too.
Am I not meant to?
Must I look for logos tailored to the 50-something CIOs and not logos aiming to discourage misogyny in the community, before I even try the language? Must I demand the first stable release of something to perform better than other things that had a couple of decades of optimization? Must I demand from volunteers they spend the Holidays making a picture-perfect release instead of enjoying rest with their families? Must I hold every open-source tool I use to such standards? A solid, clear business case or GTFO?
English isn't my native language. That language is something else and I can barely speak it now. Don't have much use for it. In fact, I dislike it. It's nothing major—some of the most famous literature in the world is written in that language, after all—but... well... it's the little things.
Maybe it's having too many letters or weird letters that aren't usually present on a keyboard. Maybe there are too many rules and too many special cases for them too! Maybe... Ugh, the language is just ugly, you know? I want results and not a language.
Of course, the same applies to programming languages too. It's the little
things. Like having to write foo(1, 2, 3) instead of foo 1, 2, 3; or writing
some_var instead of some-var; importing
a lot of functionality instead of having it available from the get-go;
perhaps writing if 5 < x and x < 100 instead of the much clearer if 5 < $x < 100; or how
about checking a set contains only valid elements? In Perl 6, it's
just a set operator away: if @given ⊆ @valid; or use subsets and junctions!
I want results and not a language.
Omited parentheses and fancy operators are little things, I know. But they add up. Some programs that I converted to Perl 6 are nearly half the original size. In a 100,000-line program, that's 50,000 lines you don't have to write, and, especially, read later.
And it's things like these that make me enjoy programming in Perl 6. It's this that makes me feel—once again—the wonder I experienced 16 years ago, when I wrote my first program: writing something simple and getting the result, as if by magic. It's hackers like me who will nurture Perl 6 and help her grow. The trailblazers. The unabashed. We stare in the face of critique without flinching. We use the tools with value, not ones with solely a marketing campaign. We'll build the ecosystem and the killer apps. And should you decide to give our tool a spin and should you like it, we'll welcome you with open arms.
Why in the world would anyone use Perl 6? Well... it's the little things.
Perl 6 hacker