Results matching “marketing”

LPW2018 Silver Sponsors

Without the investment from our sponsors it would not be possible to run LPW as a free event. We’re grateful for the support at a Silver level from the following four awesome companies!

Adestra
Here at Adestra we empower our clients to maximize marketing ROI through email-driven technology. Our flexible account structure, obsession with customer success, and award-winning service have gained the trust of global and growing brands alike.

We’re proud to say we treat our people well: from excellent opportunities fo…

Promoting Perl

After this weeks discussions about naming a shovel a spade, and how that would increase sales in the hardware store. I hope to start a substantive discussion around promoting Perl.

Dear Reader, please don't let the above metaphor become a stumbling block. Your ingenuity is desperately needed.

The first hypothetical question I would pose is:


  • If you had $10,000 to promote Perl - what would you do with it?


Please don't get lost on the dollar figure. This is intended to be an exercise in stretching the imagination.

Another ques…

Announce: Raku Perl 6 'Diwali' 6.d Language Specification Release

On behalf of the development team, it brings me great pleasure to announce the 6.d ‘Diwali’ major version release of the Official Specification of the Raku Perl 6 programming language.

Please see the PDF of our Release Brochure for all the details: marketing.perl6.org/id/1541379592/pdf_digital (print-friendly version is also available on marketing.perl6.org)

If you are unable to view PDF documents, most important details are also available as a plain text file in the repository github.com/perl6/roast/blob/master/docs/announce/6.d.md

Compiler releases with 6.d as their default language version will follow their standard release scheduling (for Rakudo compiler, release process will start on 2018-11-17)

Happy Diwali!

Untitled.png

A Request to Larry Wall to Create a Language Name Alias for Perl 6

Read this article on Rakudo.Party

I (Zoffix Znet) am writing this document to Larry Wall to request the creation of a second name for the "Perl 6" language. This name is not a rename of the language, but is simply an alternative name, an alias. Similar to how TimToady is an alias for Larry Wall.

It's been a year and a half since the time when I first re-opened this issue with a blog post, and in this document, I compiled the argumentation for creation of the alias, the community suggestions for what that alias might look like, along with the observations of discussions on the topic that occured during that time period.

I ask that Larry Wall renders his decision on the alias by November 1, 2018, so we would have the time to create proper informational materials for the 6.d language release, during which time, the name alias would be officially announced, if one is chosen.

Community Alias

The original idea for the alias came in the form of creating a "marketing alias", for markets where Perl "is a swear word." However, I believe such an alias has a more immediate application closer to home, by improving the wellbeing of the existing community and the interactions of its members with other programming communities, including the Perl 5 community.

The idea of Perl 6 was birthed in the form of the community rewrite of the Perl language. This name alias, then, is the Community Alias for that language.

Reasoning for Alias

The current language name "Perl 6" comes with a set of built-in assumptions that do not apply either to the language or to currently-available compilers for it. The assumptions encoded in the name are:

  • It is similar to earlier Perl language (and thus comes with all the negative connotations attributed to it)
  • It is the next version of Perl language
  • It is faster, more stable, and "better" than earlier Perl language

In reality, what we have is an entirely brand new language. Different, and with all the caveats typical of brand new software.

Similarity

Other than the "spirit" some claim the Perl 5 and Perl 6 languages share, they're dissimilar in many ways.

$ perl  -e 'print "I am a Perl ", "0" && 6||5, " program\n"'
I am a Perl 5 program
$ perl6 -e 'print "I am a Perl ", "0" && 6||5, " program\n"'
I am a Perl 6 program

In Perl 5 you choose your own OO system, concurrency/parallelism system, your list processing utilities, etc; in Perl 6, many of these features are a large part of the standard language itself. In Perl 5, you're told to never use threads; in Perl 6, even an empty program is multi-threaded (JIT runs on a separate thread). In Perl 5, lists autoflatten; In Perl 6, they don't and you have a choice of multiple core list types.

Thus, we lose on two fronts: those who love Perl 5 and come to Perl 6 get disappointed because they get a different language; and those who hate Perl 5 never bother trying out Perl 6, assuming it's the same language they hate.

Next Version

The naming of "Perl 6" has a strong suggestion that "6" is the version number rather than a part of the name. Some suggested it's easy to explain this caveat of naming, but my personal experience was quite the opposite of that. First, it's hard to wedge this information during a real-time meatspace conversation:

— What are you working on?
— Writing an AI for a game in Python.
— You?
— Hacking on Rasperry Pi with C.
— You?
— Making a media center for my car in Perl 6. YES. YOU MAY HAVE HEARD OF PERL, BUT PERL 6 IS NOT PERL BUT A RELATED LANGUAGE.
— ...

Second, even after you make that clarification, people still continue to shorten the name to just Perl ("You're the Perl guy, right?"). Moreover, some media, such as banners and posters, often do not allow for adding a suitable clarification.

Lastly, similar shortening of the name occurs with some software, such as DuckDuckGo search engine producing results for Perl 5 instead of Perl 6 when searching for "perl6 argv".

The biggest issue here, however, is the relationship with the Perl 5 community. The mere existence of a "Perl 6" language paints Perl 5 as obsolete. While the Perl 6 community has to make clarifications to distance itself from Perl 5's negatives that don't apply to Perl 6, the Perl 5 community must make the same clarifications just to convince people they're not dead. This brews understandable animosity towards Perl 6.

The Perl 5 language is effectively blocked from releasing the next "major version", because Perl 6 is squatting on it. And were Perl 5 to release a "Perl 7", that would immediatelly paint Perl 6 as obsolete. The lack of any established alternate names leaves Perl 6 vulnerable to such a scenario.

Thus, we have three community issues: difficulty for community to explain what language they're using; difficulty for community to find information about the language; and difficulty of amicable existence beside the Perl 5 community.

Speed and Stability

The Christmas release of Perl 6 came with a caveat that it's the language spec that's stable now, and the compiler itself needed more work. That is exactly the sort of a caveat you'd expect to come with a brand new language.

However, our brand new language is not named that way. The current name suggests it's the next version of Perl and thus it should be slightly different, and faster and more stable. None of which is currently true. By using the name to associate ourselves so closely with Perl 5, we effectively set a performance target to surpass. Yet, due to how new our language is, there is still a lot of work needed to reach that target, and due to significant differences between the languages, some of these targets might not be met when comparing exactly the same constructs (e.g. Perl 6 regexes produce a much more complex data structure—a tree of Match objects).

Thus, by mislabeling our brand new language with a next-version language, we suffer disproportionally when our compiler does not perform as well or is not as stable as a well-established language.

Summary

In summation, the name "Perl 6" is a misrepresentation. It's a wrong label on a can. It causes friction within the broad Perl community and confusion or difficulty when communicating with those outside the Perl community.

It sets incorrect expectations of performance, stability, and features of the language.

It is detrimental to our future.

No Full Rename

While numerous members of the community would have liked to see a full language rename, there are also those who believe a full rename would be detrimental. The full rename at this point in time is also a lot more challenging due to the existence of books, websites, documentation, environmental variables, and dynamic variables in the language—all with the name "Perl" in them.

As such, we are creating an alias only. One that does not have any reference to Perl in it (i.e. no "Perl++"). If another name is truly as superior as the full-rename proponents claim it would be, I believe the alias can become a defacto name through its sheer amount of use. Thus, the creation of the alias can be seen as a means for the full-rename proponents to prove their claims.

References

What follows are references to real-world examples of confusion and problems due to the current name, additional community discussions on the naming along with suggestions for what that name can be, and other resources relevant to the topic.

Naming Confusion

The (parentheticals) indicate what issue was encountered in an item. The issues refer to issues examined in Reasoning for Alias section above.

Naming Suggestions

Other

Conclusion

With the 6.d release around the corner, we have approached the point where a direct request to Larry Wall is made with the matter of assuaging the problem of the naming of the language.

Through a year and a half worth of discussions, we came to a conclusion that a second name to the language should be created, as opposed to a full rename. This will let the proponents of a rename to prove their claims, without severely upsetting those who believe the current name is beneficial.

This document presented argumentation for why a second name is beneficial, as well as compiled the discussions and suggestions that occured during that year and a half.

It is now up to TimToady to reach the final decision on whether the official alias is to be created during the 6.d language release and what that alias is to be.

See you at the 6.d release party! Bring your own virtual beer.

The 100 Day Plan: The Update on Perl 6.d Preparations

Read this article on Rakudo.Party

Today's is a milestone of sorts: it's 100 days before the first scheduled Rakudo Perl 6 compiler release that will occur after this year's festival of Diwali. As some know, Diwali is also the code name for the next major release of the Perl 6 language, version 6.d, which means there's a high chance that in about 100 days you'll be able to install and use that.

I figured, I'd write a update on the subject.

When?

The oft-asked questions is when is 6.d going to be released. The plan is to have the 6.d specification good and ready to release on this year's Diwali, which is November 6–7.

About 10 days later the Rakudo compiler will be released (compiler-only, not the Rakudo Star), with 6.d language enabled by default. That is, you'll no longer need to use use v6.d.PREVIEW pragma to get 6.d features, and if you wish to get old, 6.c behaviour you'll need to use an explicit use v6.c pragma.

However, there's a ton of work to do and the work is largely done by volunteers, so we have no compunction about delaying the release of any of the deliverables indefinitely, if the need arises.

What?

The 6.d major version of the Perl 6 programming language includes over 3,400 new commits in its specification. The vast majority of these are clarifications to 6.c spec. In other words, most of these define previously undefined behaviour, rather than specify entirely new features.

Many of the clarifications and new features do not conflict with the 6.c specification. If you're using the Rakudo compiler, you are likely already reaping some of the benefits of the 6.d language, as such things do not require explicit use v6.d.PREVIEW pragma.

Those who've seen the 6.d Teasers frequently ask for the full list of 6.d changes. That list does not yet exist, as the spec is still in the process of being reviewed. The changelog will be available some time in October. You may have seen the 6.d prep repo, but that just contains guiding info for coredevs and isn't descriptive of the actual 6.d content.

The aforementioned ton of work includes:

  • Still have to review about 2,100 spec commits
  • Still have ~95% of ChangeLog to write
  • Still have to implement, 7 TODO features, costing 110 hours
  • Still have 0.3 policies to write (a draft already exists, but needs polishing)
  • Review and spec of any new features that were implemented in Rakudo but were not specced in the language
  • Marketing stuff regarding creation of marketing name alias for the language

The Future

Going forward for future language releases, I foresee us doing a point release every 6 months, and 6.e being released 2 or 3 years after 6.d. The previously 6.d-blocking Issue R#1289 still blocks a number of language changes, and all the 6.d changes blocked by that Issue were pushed to later language versions. So, if that Issue is resolved, that will likely be a reason to cut a language release soon thereafter.

Conclusion

The prep work for next major release of the Perl 6 Programming Language version 6.d (Diwali) is in a high gear. There's lots of work to do. Will likely release spec on November 7th, with compiler release following step and being released about 2 weeks after that. The list of changes will be ready in October and does not currently exist in any user-consumable form.

Let the hype begin \o/

-Ofun

Introducing: Perl 6 Marketing Assets Web App

Read this article on Rakudo.Party

As some of you already may have known from occasional tweets and mentions in the Weekly, we have a perl6/marketing repo that contains some flyers and brochures for Perl 6.

With one of the Perl 6 coredevs making a living as a Multi-Media Designer, the repo has seen a steady stream of new pieces designed, when inspiration strikes, or when someone makes a request. There are now several pieces available, but GitHub isn't the greatest interface for this sort of stuff.

Introducing marketing.perl6.org

To make it easier to see what we have available, we made a front-end for our marketing repo, that lets you browse all of the assets. It's hosted at marketing.perl6.org

The Assets

Under the thumbnail of each asset, there are a few buttons that show you which formats are available for download. The last two buttons are the GitHub button and the pencil button. The former will lead you to GitHub to the folder that particular asset is at, where you can download any files that aren't shown on the front end (e.g. the source files). The latter will lead you to the New Issue page on the marketing repo, with title/ID of the piece pre-filled. This is in case you'd like to request different format, size, or some other changes for that piece.

Each piece has an ID number (a Unix timestamp, e.g 1516098660). If you want to refer to some piece, try to include its ID, as that's the easiest way for the designer to know what piece you're talking about.

INB4, the Camelia logo variants are so numerous because the rules allow for her colours to be changed. Personally, I prefer transparent wings, as they're easier on my retinas than the default logo.

Keep in mind, you can request new pieces as well. Just file a new Issue in the marketing repo, describing the content that you want, including the sizes/colour restrictions, and our volunteers will hook you up.

The Prints

While files themselves are easy to make for free, the same isn't the case for hard copies. We (the volunteers handling the marketing repo) can't print any hardcopies for you. Unless you are able to use a local printing company and pay out of your own pocket, your best bet would be to contact The Perl Foundation and ask them if they can sponsor the prints. I know they made prints of the Introducing Perl 6 brochure for a conference in the past.

Licenses

The assets shown in the marketing web app are licensed under Creative Commons Attribution 4.0 International License. The Camelia logo is copyright by Larry Wall. Some of the pieces use purchased stock, which may have licenses that limit super-large print runs (50,000+ copies). Check the files in the repo or contact Zoffix if you have an unusual usecase for the materials and wish to clarify the licensing.

The source files (InDesign/PhotoShop/Adobe Illustrator) themselves can be modified freely, under the terms of Creative Commons Attribution 4.0 International License. Any images/fonts/other assets used by those source files might have additional licensing restrictions, which will usually be noted in the directory for that asset.

Conclusion

Going out for some tech meetup? Print out a few pieces from our marketing web app, hand them out, share the Perl 6 love!

-Ofun

A Call to Action: Polish Perl 6 First Steps Experience

Read this article on Rakudo.Party

If you follow the updates on KickStarter, you may know the Learning Perl 6 book is nearing completion, with the author planning to submit final manuscript to O'Reilly on June 18th.

What this means is the July's Rakudo Star release will possibly be the release the first crop of readers of that book will be using (the next release after that is in October). I've seen several people say they're waiting for this book to get published before they give Perl 6 a try. Coupled with the marketing the author and O'Reilly will be doing for the book, I expect to see an influx of new users.

For that reason, I'm making a call to action, for everyone to polish the experience of the first steps those users will make in Perl 6.

How to Help?

There are several things you can help with, depending on your skillset. And before anyone protests, don't worry, there's one thing everyone is able to do…

Install Perl 6

The easiest thing you can do is grab a clean box and try to install Perl 6 to it. This is especially useful if you've never done it before and have no idea what you're doing, as it'll be very easy for you to see things that need to be improved.

Are you having trouble finding or choosing what to install? Getting installation errors? Having trouble finding support channels? Report it!

Unless you can think of a better place, you can always report these things in our User Experience repo by filing a new Issue.

Learn/Use Perl 6

This, again, is the area where the less experience with Perl 6 you have, the better. Is there something you find difficult to use or hard to find? Let us know.

Code editors, books, documentation, modules, tutorials, excercises, contests, language news, support channels. If you were looking for any of those things and had a hard time finding them, the process will likely need to be addressed.

Rakudo on Windows

This is the area where I hope we'll make a lot of progress before the next Rakudo Star release (it'll be in July, based on Rakudo compiler release scheduled for July 21st). Few, if any of the core devs use Windows as their development environment, so the state of Rakudo on Windows is slightly lagging behind.

While 6.d-proposals roast stresstest is clean on Linux and MacOS, on Windows, there's a bunch of test failures. Several of them are likely problematic tests themselves (e.g. those that shell out and expect cmd.exe to handle Unicode out of the box). When I last looked at the failing tests, some of them were failing due to how &run escapes arguments; since perl6 is launched with a batch file on windows, using $*EXECUTABLE with &run would require using cmd.exe-style escapes of command line arguments, which &run doesn't use. There's some discussion for this issue on R#1325, RT#132258, and self-rejected RFC R#1306.

If you'd like to look into these problems, you can install Rakudo from source on Windows and then run gmake stresstest (or whatever make equivalent you have) to clone all the spectests into t/spec directory and run them, so you'll be able to see what's failing. You can run individual tests with t/fudgeandrun t/spec/42-foobar/the-test-file.t

There's also a second item of lesser importance: Rakudo Star build on 32-bit Windows. The latest build we have for that system is 2016.01, which is quite outdated. On occasion people do ask for 32-bit builds and currently we can only suggests to build from source.

It'd be nice to have a more recent build created. I'm unfamiliar with what's involved. If you're interested in helping. Join our IRC chat and try to speak to stmuk or FROGGS

Help Resolve Issues

Help us resolve open Issues. In the context of this call to action, the most pertinent repos would likely be User Experience, Perl6.org website, Modules.Perl6.org website, as well as Docs, Rakudo Star, Rakudo itself, and Roast Test Suite.

For core hacking resources, there are some tutorials with "Core Hacking" in their titles on Rakudo.Party website and the NQP/Rakudo Internals Course and 6guts blog. I also like to use Z-Script rakudo dev helper script.

Conclusion

The LP6 book is about to hit the shelves and will likely bring a crop of new Perl 6 users. We can improve the perception of the language by polishing the experience of those users. Let's see if there are any problems with obtaining the compiler or any resources a begginer would need to get started with the language.

There are also some issues on Windows that need to be addressed, such as failing stresstests and 32-bit Rakudo Star builds.

If you can give a hand with any of that, it'd be greatly appreciated. File a new Issue in our User Experience repo or just chat with us on IRC.

-Ofun

Why do you have to be afraid of the programming language Perl 6? ... or not.

*** German version below ***

In life or professional life, there are cycles of learning by starting over again or at least partially. If you are a good Perl 5 developer and you start Perl 6, you start again as a beginner. In my professional life, these cycles have never been longer than 7 years. That's why I'm not afraid of Perl 6.

Perl is being developed by community. So I do not need to worry about Perl disappearing from the market with the bankruptcy of a company at short notice. The community also has disadvantages, especially in marketing. The programming language Perl is…

Long Live Perl 5!

You probably have read a recent Open Letter to the Perl Community. The letter has generated a lot of response (173 reddit comments as I write this). Unfortunately, a lot of the responses are quite negative and do not match my understanding of the letter.

I figured I share my interpretation of the words and if that interpretation does not match the author's intent, I hope my interpretation captures the mood of the community on the matter.

A Radical Idea

The first thing the letter talks about is what it calls a "radical idea". The suggestion is for Perl 5 compiler to upgrade its backend. Instead of the current Perl VM the perl compiler uses, it would be ported to NQP compiler toolkit and will support all of the backends NQP supports, which currently is MoarVM, as the leading option, with JVM and JavaScript backends at various stages of completion as alternatives.

Perl 5 the language would remain as is, but the new backend would allow the compiler to make use of modern features such as JIT compilation and good threading support. So to clarify, this wasn't a suggestion to port Perl 5 to Perl 6, but merely to swap the backend Perl 5 compiler uses.

Perl 5 Porters view this radical idea as a non-starter at the moment, so I think we can safely bury it and move on to the second idea the letter talks about

Porting Modules

As I write this, the Perl 6 ecosystem is 8 modules short of 1000 modules total. A lot of the needed features are currently missing native Perl 6 implementation and many users choose to use Perl 5's CPAN ecosystem via Inline::Perl5 module.

While Inline::Perl5 works rather well, it's not an ideal option for many developers. Thus, the Letter's author proposed an incentive for people to port much-needed Perl 5 modules to Perl 6 in the form of a leaderboard and potential support from sponsors who would donate to Perl 6 Core development fund in exchange for ported modules.

So to clarify, the goal behind the porting of modules is merely to beef up Perl 6's ecosystem and is not an implication that Perl 5 users have to or even might want to move to any other language.

The Elephant in The Room

While not mentioned in the original Letter, a frequent theme in the comments was that Perl 6 should be renamed, as the name is inaccurate or is damaging.

This is the topic on which I wrote more than once and those who have been following closely know that, yes, many (but by no means all) in the Perl 6 community acknowledge the name is detrimental to both Perl 6 and Perl 5 projects.

This is why with a nod of approval from Larry we're moving to create an alias to Perl 6 name during 6.d language release, to be available for marketing in areas where "Perl 6" is not a desirable name.

While some may feel an alias—as opposed to a full rename—is not quite what they desired, I believe if the alternate name is as beneficial as the proponents of the rename believe it to be, the alias will naturally be able to overtake "Perl 6" name in usage and become the primary name through sheer amount of use. Thus, the alias can be seen as the chance for the rename crowd to prove their claims.

Long Live Perl 5!

Perl 6 isn't a desirable language for many Perl 5 users, for various reasons. That's perfectly valid and is understandable. Perl 6 is quite different from its sister language and the choice to switch to it isn't much different than choosing whether to switch to Ruby, Go, Rust, or any other of the multitude of languages available.

Since Perl 5 is actively maintained, its users should not feel compelled to migrate to anything else, and should continue using what works for them, regardless of what opinions members of other programming communities might hold.

Conclusion

The Letter suggested a radical idea that the perl compiler's backend be ported from Perl VM to NQP that supports multiple modern VMs. Based on the response to the proposal, it does not appear to be viable at the current time. The more prominent suggestion in the Letter is the call to port Perl 5 modules to Perl 6, to help Perl 6 users get native-Perl 6 access to valuable Perl 5 modules.

While there are Perl 6 users who believe Perl 6 is superiour to Perl 5, it does not mean Perl 5 users should feel compelled to upgrade to anything but the latest stable version of Perl 5.

I hope that regardless of which flavour of Perl we choose to use and call our favourite, we can unite and exist together as The Perl Community.

Perl6 should be renamed Perl++

I have been a Perl programmer and advocate for almost 20 years. It has saddened me to see Perl loosing ground among newer generations of programmers to languages such as Python, Ruby, and php. Although those languages have their strong points and interesting features, in my opinion, Perl is still a superior language for most general programming applications for various technical reasons, which I will not go into in this posting. That's the subject of a different religious war.

At the very least, Perl should be holding at least an equal standing in popularity to these other languages.

I think that one of the primary reasons for Perl's declining image is the naming of a completely new language with the same name. I believe that calling it Perl6 has been the most destructive thing that has been done to the Perl language and will continue to be so. Never before has that been done with another programming language that I'm aware of. It puts up a big stone wall in front of Perl and blocks it from ever having another major version increase. That alone does ongoing long term damage to Perl. Couple that with Perl6 going on 17 or 18 years without becoming ready for mainstream, and it creates a public sense that Perl is dying.

Case in point. I recently had a debate with a colleague, who has been a Perl programmer for a number of years, about this very thing. He is looking seriously into changing over to Python for his companies projects. And, surprise, surprise, he cited the 17 year stagnation of Perl as one of key reasons. Like most other people, being that this is the next major release number of Perl, he directly associates Perl6 with Perl in general being stagnant. He thinks he can get employees more easily to take over code in Python because he thinks Perl is not attracting new programmers. New programmers don't tend to be attracted to languages that have the appearance of fading away. In the end, I still don't know if I have convinced him that Perl is alive and well.

C/C++ is the closest example of this scenario. Just like C/C++, Perl and Perl6 are two different languages. Perl6 has more integrated object oriented features along with a host of other enhancements, very similar to C++ and C.

Although any name other than Perl would be better for a new language, Perl++ appears to me to be the logical name choice if Larry Wall wants Perl6 to benefit from the momentum and name recognition of the Perl name without creating all the confusion and making it look like Perl version 5.x is deprecated. I found a couple other past blog comments where this was proposed and it had fairly positive response.

Here is another good blog posting on the subject by Zoffix Znet.

The Hot New Language Named Rakudo

And a followup blog entry about it.

6lang: The Naming Discussion Update

In that discussion, it is mentioned that

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.

I also feel that this is not a good idea at all. You start having third party distributions marketing different names for the language and you are likely going to kill Perl6 for good. Nobody is going to know what the official language is or which one is standard. And if they get associated in any way with Perl[5] then it will enhance the image even more of Perl being disorganized and ad hock. Businesses are not going to want to use a language that has no organization behind it. And if businesses are not using it then new programmers are not going to waste their time learning it.

Names such as "Rakudo" and "6lang" have been proposed. We should really be careful not to choose an obscure, hard to remember, name or especially a name that is ambiguous to pronounce. 6lang, for example, to be pronounced slang. Please No! Nobody is going to know how to pronounce it and the 6 has no obvious meaning other than to tie it to the current major release version of the language.

Names such as Perl, Python, and Ruby are all great names. Catchy, easy to remember, and easy to pronounce. Again, Perl++ fits the bill.

Now, if the powers that be insist on keeping the name Perl6, then I have an alternative proposal.

Bump the latest release of Perl to version 7.x, and just call it Perl version 7.x, removing the stone wall from in front of Perl version 5. Now you have two languages. Perl version 7.x and Perl6 version whatever. But at the risk of repeating myself, I still think that Perl++ is a much more descriptive name for indicating it's relationship to Perl than Perl6 is.

Since it has been made clear that Perl6 is not the next version of Perl, then it would have actually been more logical to call it Perl2 than Perl6. But I doubt that is going to happen.

Actually, any post number in the name is problematic. Too many projects already do that with their names to distinguish incompatible versions of the project. So people are used to always viewing that as the next major version of the same project. You are never going to overcome that perception with the name Perl6.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  

About coke

user-pic Perl 6 hacker