Pedantically, and this also helps serve your point, Parrot isn't used by any modern Perl 6 implementation, it's effectively dead (if not totally). MoarVM is the less ambitious (not trying to support every dynamic language like Parrot was) and more mature VM that is in use now.
And the requisite, ParrotVM is just pining for the fjords joke goes here. It has ceased to be, gone to meet it's maker, it is an Ex-Parrot.
EDIT: For reference, Parrot VM really was named because of that sketch. It started as an April Fools joke and kinda stuck. https://web.archive.org/web/20100718195724/http://www.perl.c...
# copy stdin to stdout, except for lines starting with #
while left_angle_right_angle:
if dollar_underscore[0] =eq= "#":
continue_next;
}
print dollar_underscore;
}
Did We Change the Definition of 'Literally'?
Literally every modern dictionary includes this definition
https://www.merriam-webster.com/words-at-play/misuse-of-lite...
Ignoring the Perl angle, it's a language with a small ecosystem that doesn't seem to provide any groundbreaking advantage compared to existing languages, so no reason to adopt it.
In general, to become popular a new language needs to provide one of those:
1. A new groundbreaking and useful paradigm that cannot be added to existing popular language ecosystems without a total compatibility break (e.g. Rust)
2. Compatibility with an existing ecosystem and significant improvements (e.g. Kotlin)
3. Being the best among languages required by a platform or program (e.g. Swift, also JavaScript when introduced)
4. Have one of the best ecosystems for a specific niche (e.g. Ruby when Rails got popular)
I don't think it'd be instantly super-popular if it were a standalone, non-Perl-affiliated language, but I think it'd at least be talked about like Elixir or F# or Elm.
I always felt Perl <6 was the papa of Ruby: optimizing for (a) programmer's happiness. Perl showed the way in so many ways, combined with the object model of SmallTalk we got Ruby.
Maybe P6 also has a some new ideas in that find their use in future languages. But we will only know after P6 gets used and loved and exposed to real world scenarios, what those "most valuable/copyable innovations" are...
Is that really a thing that couldn’t just be added to PCRE and be available in any language with bindings?
F# has the advantage of easy interoperability with the vast .NET ecosystem.
Here's your perennial reminder that the word "modern" is a thought smell.
> it's a language with a small ecosystem that doesn't seem to provide any groundbreaking advantage compared to existing languages
I'd almost prefer this conception went uncorrected, because Perl6 is not just Ruby or Python in different clothes, and it's not just Perl5 with nicer aesthetics, and I don't mind enjoying niches or competitive advantages.
Sometimes it's a thought smell, but sometimes it's shorthand for "has learned the lessons of recent history", which is indeed valuable.
By analogy, "modern" might indeed sometimes mean "has learned the lessons of recent history."
One can even sometimes test this by asking people what they mean by "modern."
My experience is that they usually don't know, or have a conception uncomfortably close to "it was released more recently" or "it's more like what everybody does right now," which are both certainly worth observing... but stopping there is where the thinking becomes distinctly less so.
Not familiar with the term and can't find it elsewhere.
"this smells off" -> nonspecific indication that something might be wrong "code smell" -> nonspecific indication that something might be wrong with software code "thought smell" -> nonspecific indication that something might be wrong with a way of thinking
The reason the implementation is named (Rakudo), is because there's a spec, and originally there were a few people making implementations. There was good effort from individuals on C and C# versions that were more monolithic, and Rakudo was where most the community work went since it was designed in a way to be more cross platform (it's mostly implemented in the minimal NQP languages, which is "not-quite perl". It's a much easier thing to port to a VM, and then you get like 90% of the language features already designed and working).
The reason the VM is noted is because it changed a couple of times. Bringing the VM name into it lets people know that if it's different, maybe it will have fixed their main performance complaints. To my knowledge, they haven't used parrot in a decade or so, and there's actually some bad blood between the VM and Perl 6/Rakudo (which had different teams, another reason to brand with both.
So, Perl 6 is the standard. There have been multiple implementations to varying degrees of completeness, including but not limited to Rakudo, Pugs, and Niecza. Those implementations have generally targeted one or more VM targets, including Parrot, MoarVM, Java, .Net and custom VMs.
It may or may not have hurt adoption seeing this terminology, but it was there for a reason, because it denoted very large important aspects of what was going on behind the scenes, and in some cases doing otherwise could have worked against some relationships that were going on between projects.
That sounds like a really solid foundation to build a business on...
I think if people are willing to look with an unbiased eye, there are a lot of software marketing lessons to be learned from the rise and fall of Perl. It got a bunch of stuff right back in the day.
Perl 6.c, Perl 6.d -> SQL-2011, SQL-2016
Rakudo Star -> MySQL
Rakudo compiler backends (for MoarVM, JVM, JS) -> MySQL storage engines (InnoDB, MyISAM, ...)
Having different names for languages, language spec versions, language implementations, and backends doesn't seem unknown in successful projects.
Other than the problem of “Perl” in the name, all of this is fairly boringly normal.
Of course part of that is technical, but part of 'marketing' is understanding what your users want and delivering it to them.
This article I wrote about Tcl a while back is what I'm talking about: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
Yeah, but you keep pointing to things that are exactly like many successful projects as wrong, like having a different name for the language vs. an implementation vs. backends used by the implementation.
I will suggest that the two things they actuallt got wrong were:
(1) Calling it “perl”, and
(2) Taking forever.
And, really, those two in combination: even being as distinct as it is, had it stabilized in a reasonable period of time, and had once it stabilized a reasonable transition path been provided, it might have been another Python 2 to Python 3 problem, but not a complete disaster. Conversely, ha for been a new experimental language and not “Perl 6”, taking forever to stabilize would have been more tolerable.
To spell it out, Parrot the project started around the same time as Perl 6 the project. Initially, a lot of Parrot's purpose in reality was to be a VM for Perl 6, but Parrot also had a goal of being a good general VM for dynamic languages. From that perspective, I think they were often mentioned together because neither wanted to be overshadowed by the other to the point of obscurity, and they wanted to draw on the general audience each might bring (and there were quite a few people doing stuff in Parrot with nothing to do with Perl 6 eventually).
Did it cause problems? Probably, even if you ignore the eventual blowout they had. That doesn't mean it was it was entirely a stupid technical reason by technical people ignoring marketing concerns, as part of the reason I think it was done was purely for marketing. Initially, it might have even helped (a VM for dynamic languages was a big idea back then, I know I saw a lot of people excited about it).
It was a CPS compiler, but after they drove the first creators away, a bunch of people who had no idea about compilers nor CPS started destroying it. First the destroyed the jit. The technical justification was bullshit. Then they destroyed the run loops, and finally the CPS (2007 YAPC workshop). This caused every function call to allocate 2 objects, continuation contexts were not reused anymore, but created on the fly for every call. After this desaster they gave up (their new idea was to create a 2nd LLVM, called something with m), and I came back to cleanup the mess. I readded the compiler optimizations, added proper lock-less threading (their current VM is lockful) and started fixing the CPS, the run loops, the GC and the Jit. But before that they decided to kill it off, and rewrote everything by themselves. But not as committee anymore and without the previous leadership, which was a very good decision. It's still a very naive architecture still, that's why it's even slower than python, the slowest scripting language on earth.
Realizing that this is futile, I started improving perl5 towards perl6 instead. Just without breaking backcompat. perl11 (5+6)
Reini, it seems like you think everyone who disagrees with you is stupid. This isn't an explanation for anything.
We were boxed in for two really good not-primarily-technical reasons:
* we had users we didn't want to abandon or cause churn * we had architectural decisions we had to improve
Now I know I'm not as smart or as experienced or as knowledgeable as you are, but that doesn't mean I'm a drooling buffoon, and it certainly doesn't mean I don't have good reasons. Sometimes it means I make mistakes. Sometimes they're not even mistakes; sometimes they're just differences of opinion.
It is the simpliest explanation. In fact it was stupid and arrogant leadership mostly.
There was no disagreement, as we didn't say a beep then. They made those stupid decisions all by themselves, and didn't listen to any advice. The better people just silently left, shaking their heads.
It's the laziest explanation.
Did you ever ask yourself why, for example, all of the calling convention code paths were consolidated into a single code path? It wasn't to make a single, inefficient code path as you claim.
It was to provide a gradual transition for clients to a better designed calling convention system which could then be optimized for actual client uses.
The goal was never to create the fastest possible VM at every single point in time. That's where I think you never understood the goal of the project, and that's where I think you've never understood the goal of p5p.
The goal was to make something that works, continues to work, and can be improved while continuing to work. That's why you're no longer welcome in p5p -- because your goals and your actions are incompatible with that.
I wish you understood this. You're very smart and very talented and you have a lot to offer, if you can get out of your own way and accept that people who don't share your exact goals in the exact same way aren't irredeemably stupid.
How odd then that ~90% of the discussions about ditching Parrot were primarily complaining about the deprecation policy and first-class Rakudo support, not speed.
I suppose you would know better though, being objectively smarter than everyone else who ever made a decision about the project. How unfortunate that we can't take your word for it; we can only read all of the public discussion about it.
This was, initially, for two reasons:
* allow Perl 5 code to run in process with Perl 6 code (without linking in libperl) * provide a unified VM on which Perl 5.12 could become Perl 6
I'll defer to your memories if they contradict that though, I know you were involved to varying degrees for the first decade or so, and all I did was lurk.
Well, more accurately, it's the language name (like SQL).
Standards include Perl 6.c, and Perl 6.d (Like SQL-2011 and SQL-2016)
Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. (EDIT: And "Dalvik", for all the Android fans). I'm unsure if Java has multiple compilers, but its quite possible.
Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few others.
When Perl 5 was huge, there were multiple VMs and interpreters: IronPerl comes to mind as a Windows implementation back in the day that had different quirks than the canonical Perl interpreter.
A lot of people care. It costs $3500 per server to run Zing Java. Every user of Zing cares enough to pay $3500. Everyone who has written an Android app cares about the distinction too. Dalvik has different quirks than regular Java. (EDIT: Oh boy, that shows how out of date I am. Apparently Android is now using Android Runtime instead of Dalvik....)
> If they need to find another implementation, it's possible, but there's no question about what the default implementation is.
The implementation can, and does, change without the language changing. That's the unfortunate truth about real world deployments. As such, you need a unique name for the interpreter.
> A lot of people care.
Both of these claims are true, but yours is missing the point.
You grow a userbase by appealing to people who don't use or understand your product. People who are already invested to the point of spending $3500 for a custom VM aren't the ones you're trying to clarify things for by using consistent branding.
That's the problem.
And it always had a single official and complete reference implementation in the form of the Sun JVM and later the OpenJDK. kbensons description makes it look as if Perl 6 had/has neither.
> And "Dalvik", for all the Android fans
Dalvik was intentionally incompatible in many ways and wont run a spec conform jar no matter how hard you try. Might as well call CPython a Perl implementation.
> Python has CPython 2.0, CPython 3.0
With CPython X being the official reference implementation for the corresponding language version and all other implementations being incompatible to varying degrees.
It had and has a spec. It's been evolving over time though. It was ambitious enough that no one implementation ever fully implemented it until recently, if ever (I stopped following the project actively a few years back. I'm not sure if any current implementation is fully compliant). That's not a surprise, it's an amazingly complex set of features that are describes, and there's many specs that are never fully implemented, and it's not uncommon to have an aggressive specification run up against reality when people try to implement it. For example, I've heard that the IMAP spec has never been fully implemented, or at least the later ones versions of it.
So, they have a spec, and have had one for a very long time. They have implementations that do the vast majority of the stuff you'll want from that spec, and they've been in that state for a few years.
True though even in the mid to late 90s there were other JVMs available from companies such as Microsoft and IBM. In fact for a period, Sun’s JVM was one of the worst implementations despite being the reference implementation.
...and IronPython, Cython, PyPy, PythonNet, MicroPython, probably plenty more I'm forgetting.
Python 2.x language has several implementations CPython (the reference implementation), Pypy, Jython, IronPython.
Python 3.x language also has several implementations CPython, Pypy
Cython understands Python but it is not Python (I don't know whether it is a strict superset).
MicroPython implements some subset of Python 3.4 (mostly)
It does have multiple compilers for java, at least javac and ecj (eclipse compiler for java) http://blog.deepakazad.com/2010/05/ecj-eclipse-java-compiler...
And if you consider groovy and scala and kotlin it has many more compilers.
JustInTime, HotSpot, Swing, Beans, etc.
That's not really a great comparison. There is one single organization that both defines what python is and implements a compiler/interpreter for it, and that is all you would ever need to know to use it. No ambiguity.
For the most part, language specs are either bundled fairly tightly with a reference implementation, or have a completely different name. (e.g. ECMAscript, SQL)
I'm surprised by this comment because this is how pretty much every language works. C++ has specs and different compilers with different names and has done for decades. As does C, Python, Perl 5, Javascript, PHP, Lua, LISP, LOGO, BASIC, Pascal, SQL and your own example of Java has different compilers/interpreters/VMs.
Often even in languages where the "spec" is defined by a reference implementation, you still find people building their own compilers or VMs for different platforms or use cases.
It's really quite common to separate the language name (and specification version) from the compiler and runtime branding. In fact that used to be the norm back when target platforms differed wildly.
There's no coyness; the language spec and implementations are both actively developed, and it's a spec-first design, so Rakudo is sometimes incomplete with regard to the most-recent spec, but Rakudo is and for some time been a “production-ready, stable” implementation of Perl 6.
The language has been consistently described as stable since the “Christmas” release, Perl 6.c, on 25 December 2015, though it took a bit longer before Rakudo had a production-ready 6.c implementation; the current (and currently supported in Rakudo) spec is 6.d, released last year.
> Yes, it has a VM.
Several, in fact. (More if you count defunct historical ones like Parrot.)
> But why do people talk about ParrotVM and Rakudo as if they're different things?
Because they are: ParrotVM is a (AFAIK) essentially dead multilanguage VM that Rakudo used to support; Rakudo currently has a MoarVM backend, and a JVM backend, and IIRC there is a non-production-ready JS backend that is available separately.
I'm seeing a pattern of things that are named tools which are not the exact name of the language they compile or run.
When I ask "What's an implementation of Perl6" The answer is "Nothing implements perl 6, isn't that wonderful!" It used to take forever diving around to find something that could run some subset of perl 6, usually with the disclaimer of "This isn't really perl 6, but rather a language that seems like perl 6" And you'd get the same thing from the mailing lists/etc.
Niecza is an implementation of Perl6 which targets the CLR. Last I checked it lagged rakudo a bit but was still being updated and maintained.
There are other, independent implementations of Perl6. There's STD.pm which implements Perl6 in Perl6 and uses viv to transliterate portions of itself into Perl5.
Pugs is last I checked dormant, but it was an independent implementation of Perl6 in Haskell.
So if someone asks for an implementation of Perl6, they probably want rakudo. Just like if someone asks about an implentation of Ruby they probably want CRuby / MRI unless they for some reason don't. Ruby, however, doesn't really have a language spec so other Ruby implementations like JRuby chase MRI compatibility. This was a problem with Perl5 which was defined by its primary implementation. Python has the Python Language Reference for alternate implementations like IronPython and Pypy to develop against, much like the R5RS and R6RS Scheme documents. This is why Perl6 the language is defined by the spec - so multiple implementations can compatibly exist.
Rakudo (compiler) and Rakudo Star (full distribution). Both of which have been production-ready since shortly after the Perl 6.c spec release in December 2015.
Your rant would be understandable back before there was a stable spec, especially long before when the in-process language description and the various implementations were sometimes far apart. But it's been years since it had even a remote resemblance to reality.
The legacy of confusion and weirdness around the Perl 6 project is a legit problem, even/especially if it's no longer true and now Perl 6 is like a normal language.
There was talk about Perl 6 being ready soon. It sounded really cool like many people I was quite excited about it.
Sadly the screwing around and refusing to give a real release date really messed things up ("It will be ready by Christmas, we just aren't saying which year"). I moved on to Python - which has been a good move career wise, but its a shame as I enjoyed using Perl and Perl 6 does have a lot of interesting ideas.
Like you say, I have no idea about the release status either.
Perl5 had a period of slow releases in the 2000s, this changed in 2010 with the release of version 5.12. Since then, Perl 5 has been on a yearly release cycle. The current release is version 5.30.0. When it became clear Perl6 wasn't coming any time soon, some people left Perl. Others knuckled down and wrote some great code that made Perl5 into a much better language. With many core feature additions and deprecations, new CPAN modules, and tooling to support consistent work by teams, the Perl5 language is more expressive and better than ever.
Perl6 took forever, had major internal conflicts, but managed to survive and ship a specification in December 2015, version 6.c (6.a was an alpha version, and 6.b a beta). The Rakudo Perl6 compiler gets monthly releases, but most people install the Rakudo Star distribution, which bundles some extra modules and just makes life a bit easier. Rakudo Star began shipping "A usable Perl 6 compiler" in 2010. Regular releases tracked changes in the compiler.
The Perl6.c spec was announced in December 2015, and the first Rakudo to implement it was released at the same time. Rakudo Star, lagged a bit and released in January 2016.
Here's the Perl6 release announcement: https://perl6advent.wordpress.com/2015/12/25/christmas-is-he...
The Perl 6.d spec was released in November 2018, and the Rakudo 2018.11 version defaults to supporting it.
Here's a link the Perl6 FAQ with more info on the Perl6 versioning and releases. https://docs.perl6.org/language/faq
If you liked Perl5 then, come back and give modern perl5 a try.
Perl6 is an amazingly expressive and fun language to write with.
Perl 6 is quite nice as a language but the implementation is slow and it has too litlle lib support. Also not great for scripting because of the VM penalty.
They're both extremely knowledgeable, but neither of them can work with other people, so their forks seem motivated by the desire to do what they want without question, rather than any purely technical concerns.
Developer ergonomics matter! Yes, when you run 'python' you get cpython, and Java is probably hotspot vm or openjdk or something (but Java is not a good example of developer ergonomics).
Rust is one of the best examples here -- adoption is being driven by the ease-of-use of the entire toolchain, including the package manager and things as small as human readable compiler errors.
But all the things the parent comment listed, particularly branding, are in my mind part of developer ergonomics. And there is room for improvement. They wouldn't be talking about renaming the language if this wasn't the case.
It has some genuinely ambitious features, some things that (as someone who barely dabbles in new languages) that I haven't seen before, or combinations I hadn't seen.
Something novel instead of the umpteenth iteration of "x with a better type system" or "x without that pesky type system".
(To be clear: not because people aren't writing Perl, but because we tend to reflexively reject any technology that people are passionate about because "risk". But the risk of writing trash code that nobody ever could be passionate about is less visible. Also: I'm not saying there's an easy solution to this problem.)
Unfortunately, that direction stems from their motivation which is easily tainted by group ego. Maybe the developers feel like they're not getting the attention they deserve, maybe they have a big idea they want to solve and their tool is tangentially related. Or maybe they know exactly what to do, and the "other" people in the system do not.
Whatever the rationalization is, it's enough to transmute their original purpose into a larger mission that everyone in their little silo agrees with, and that gradually diverges them from the rest of the system.
"We're necessary and therefore we're important... more important than the system we were built for!"
Eventually, a new name springs forth to signal their existence or even assert their dominance over the system to which they belong.
The kind of thinking that plagued ParrotVM:
OTOH, "Perl" has existed forever... it would be kind of a shame to lose the name.
I don't have any real experience with Perl, so could you maybe expand a little? I'm curious about what you think the limitations are.
There's a kind of elegant flexibility to that, but it also makes it really hard to program reliably in the large, to build useful tooling, or even to glance at a function and know what you should pass it.
Beyond that, classic Perl was full of things that make it quick to write small programs (as CGI scripts were at the time) without a lot of boilerplate, but which don't scale up.
(Perl 6 is very different, and has an almost comically flexible/powerful function signature system (https://docs.perl6.org/type/Signature). Whether or not you like Perl 6's stuff, it's nothing at all like Perl 5's.)
Sorry, you are misinformed. That hasn't been true for a long time, see http://p3rl.org/Kavorka::Manual::Signatures
Other languages would kill for this kind of beyond-complete maximum overkill feature set.
> This page gives a good overview of the situation: https://perl101.org/subroutines.html
No, it doesn't. That page is not wrong, but incomplete and teaches the wrong stuff, wouldn't recommend. Instead see http://perl-tutorial.org/ for recommended tutorials.
YOU are the one misinforming, it would seem. Granted, I don't work with perl (5, never tried 6) for about 15 years, but most criticism of it seems to align with my experiences back then.
[0] http://mvp.kablamo.org/basics/functions/
Edit: The second [1] also recomends the @_ method, and the third [2] the shift method. Did you even read your own links?
[1] https://perlmaven.com/subroutines-and-functions-in-perl [2] https://learnxinyminutes.com/docs/perl/ (search for subroutines)
> WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl.
Which is to say: a lot of the reason they're still experimental is because Perl's commitment to backward compatibility. Other languages might have said "oh well," but Perl 5 said "oh, an unintended consequence that might break real uses in the wild; we should wait another year."
On Perl6 those are officially supported, so I imagine they work.
That is also true for the overly simple object model of Perl 5, it is more like an OOP construction kit, which enables things like Moose which has for almost 15 years provided Perl 5 with a very flexible object model.
It would be very interesting to know if anybody knows of similar systems for other languages?
Large OO codebases can be downright nasty to navigate and while I have never had the opportunity to use something like Moose for large scale projects I imagine that's where it would shine.
These days, people that aren't novices tend program much more clearly in my experience, and there's style guidelines and code linters to take up the slack. It's not like other languages never have to deal with people writing odd or unintelligible code either, there's a reason why style standards are a big thing in many places. Here's an example of a module I use that I just looked up. It's fairly terse in parts (but it's a module, so I hold it to a different standard than my own code), but I would expect anyone familiar with perl would have zero trouble determining what's going on in here, and a lot of code bases will be a little more verbose or use more white space to error on the side of caution and help people process what they are seeing easier.[1]
1: https://metacpan.org/release/Path-Tiny/source/lib/Path/Tiny....
Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha.
Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).
That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio.
I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.
‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.
There's nothing inherent about Perl that causes people to use $z instead of $somethingDescriptive. And regexes have for quite some time allowed for insignificant whitespace to comment things in detail.
If you comment your regexes and use decent variable names, you solve 98% of the readability problems of Perl, and both of those could be enforced with a linter. But as I said, a lot of the problems come from one liners being slowly expanded. Using single letter var names for anything is fine in a one liner, but not good for long term program legibility or maintance in any language.
However all that flexibility means that it's not possible to run static analysis with full confidence. Yes, tools exist - but it's been proven impossible for them to catch all cases, and this uncertainty carries real risks for critical business processes.
When you have a code base encompassing a set of core modules, with hundreds of auxiliary programs using them across the business, then any attempt to update perl or its modules grinds to a halt. It's impossible to even enumerate which programs will be impacted by the change with confidence, let alone the effects of such a change.
For details see "Perl Cannot Be Parsed: A Formal Proof" (https://www.perlmonks.org/?node_id=663393). You can mitigate the impact with coding style guides and code reviews but once the damage is done it's very difficult to untangle an existing code base that loads modules at run-time and makes full use of Perl's flexible nature in other ways.
1. The name, saddling it with the legacy of Perl. (I say this as someone who really liked working with Perl back in the waning years of the old millennium, and believes that Perl was visionary in pointing the way to the state of modern programming... but also that it had some limitations that have only become more glaring over the years.)
2. The coyness around whether it's "done" or not. Right now today, as someone who has paid attention to Perl 6 and even written some toy code with it, I do not understand its release status at all. That's absurd.
3. The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing.
4. In a distant, distant last place: any actual functional stuff about the language.