The language has tons of warts, but also an amazing community. Participating in that community taught me more about the practice of software engineering than my computer science degree.
Have a frontend that can invoke the perl5 interpreter as well as Rakudo as appropriate, supporting the perl5 command line flags, and arguably quite a bit of the problem goes away.
Branding is not the problem with Perl 6, though it is the easiest thing to bikeshed. The problem is compiler speed, language interoperability, and enough of a toolchain to start building serious apps. Make that good enough, and no one will care what our language is called.
https://www.haskell.org/onlinereport/
https://www.haskell.org/onlinereport/haskell2010/
The purpose of these documents is to specify what an implementation of Haskell 98 or 2010, respectively, should support. Just like the analogous standards published for the C and C++ languages, the Haskell reports make no reference to any specific implementation.
The most popular implementation of Haskell is the GHC compiler. (In fact, in reality it's the only compiler anyone uses, with very few exceptions. For better or worse, Haskell is a one-implementation language at present.) GHC accepts a greatly expanded language compared to what the reports specify, including a large number of language extensions that can be turned on with flags. (sort of like how Clang or modern GCC accept C++11/14). There are minor changes from one version to another, so the language accepted by GHC today is often called GHC Haskell for disambiguation.
What GP is pointing out is that almost everyone using Haskell today writes in the language that GHC accepts today instead of sticking to some official standard.
If you want to learn Haskell, you don't need to worry about this at all. All reference materials and books teach modern GHC Haskell, which is also what is used by practically all Haskell users. As noted before, very few people use non-GHC compilers (usually it's just the people implementing or testing them) and you're very unlikely to encounter these implementations.
s/by GHC today/by the newest available GHC/
I learned Python 3 because it seemed that it was the new one, but to great confusion Python 2 is alive and default in Linux distributions.
Things break sometimes.
In response to parent comment, Perl 6 is Perl. I don't think that it's difficult to understand that Perl is a family of languages, and Perl 6 is a more recent and sophisticated sibling to Perl 5.
All of this is bikeshedding to me.
I think that you are overlooking the fact that the vast majority of python 2 code wouldn't run by default with python 3. Yes, there are now conversion utilities that handle most (all? maybe?) of the scenarios, but the fact remains that both Python 3 and Perl 6 break backwards compatibility.
C and C++ have tried very hard to not do this. Your old C code and your old C++ code will almost always compile as is with a newer standard.
Depends on the code: Some of it won't compile without providing just the right set of flags.
In case of C, for me the crucial feature is not so much full backwards compatibility, but interoperability (you can link the object code regardless of the language version) and the convenience of using the same frontend executable.
In case of Perl, the former is currently possible to some degree via the Perl5 module Inline::Perl6 and the Perl6 module Inline::Perl5.
Personally, I would like to see the latter become a reality as well - this is the solution I'd perfer over trying to distance Perl6 from Perl5 via rebranding.
I may be imagining things but, peering years into the future, it seems this versioning management aspect of the P6 toolchain might end up being the foundation of a new multiple lang/compiler/module version juggling Perl package manager that can be used with P5, P6, python etc. Does that make sense to you?
One of the things I've heard is that `print` went from a keyword to a subroutine in Python, or something to that effect. In Perl 5 for most of them there is not really a difference, and what difference there is gets smaller every year.
Another is Unicode, which Perl 5 managed to improve without breaking most existing code. (some of it has to be enabled with a pragma statement)
Usually the only code that gets broken, is code that digs into the internals in some fashion, or use an unintended “feature”. (or occasionally even a feature that should have never been added in the first place)
One such unintended feature which relied on the compiler generating incorrect code was:
sub foo {
my $bar = 10 if 0;
say $bar++;
}
foo; # 10
foo; # 11
foo; # 12
sub foo {
state $bar = 10;
say $bar++;
}
Perl 6 breaks backwards compatibility in all the ways that needed to be broken to modernize the syntax, and reduce special cases. Even infix operators are no longer special.
From what I can see Python 3 breaks backward compatibility for things it didn't really need to if they tried harder. (It would have made the implementation more difficult to work on.)