#! /usr/local/bin/perl -w
use Lingua::Romana::Perligata;
maximum inquementum tum biguttam egresso scribe.
meo maximo vestibulo perlegamentum da.
da duo tum maximum conscribementa meis listis.
dum listis decapitamentum damentum nexto
fac sic
nextum tum novumversum scribe egresso.
lista sic hoc recidementum nextum cis vannementa da listis.
cis.
And people say Perl requires too much punctuation!
I think explains a lot of the polarised reactions people have towards Perl. It's trivial to understand the difference between the scalar var $foo and the array var $foo[0] if someone explains it to you or you read it; but if you're trying to Google-as-you-go, you don't even know what to search for. Those in the former group are more likely to find Perl delightful, while to the latter it's just frustrating.
You don't have to be "wrong". You just have to be not exactly the same as everybody else. And of course, nobody is exactly the same as everybody else, therefore there is not possible for there to be such a thing as The One Perfect Language. The right tool for the job; but also the right tool for the workman.
Then it should have been called "1.0". Calling it "DEFINITELY NOT 1.0" while deciding that that is secret P6 code for "really means 1.0" is awfully bad marketing.
(More seriously, slow performance, missing features, bugs, etc. were part of the reason for not calling it "1.0", but I would agree that to be really successful, the language needs a release that is called 1.0 and acts like it.)
6.c was described, both before and after its release, as being the “1.0” release of the Perl 6 language.
> More seriously, slow performance, missing features, bugs, etc. were part of the reason for not calling it "1.0"
No, they weren't.
The first “production-ready” release of Rakudo Star release was shortly after the 6.c spec release, in version 2016.01 (Rakudo Star uses date-based versions numbers.) If they were using semver-ish numbering for Star releases rather than dates, this would have been the 1.0 implementation (as opposed to spec) release.
A lot of languages — in fact, a lot of software in general — is designed to make things easy for the computer/programmer: "This is how it works and you just have to adapt, deal with it."
Larry Wall put a lot of effort into making Perl try to adapt to the way the user already thinks instead, including taking advantage of having studied linguistics to figure out how the "language" part of a computer language fits (or doesn't fit) the way our brains process languages.
The result was a language that has a lot of power and flexibility. People who like Perl tend to love it, because it fits like a tailor-made suit instead of all those off-the-rack languages. People who dislike Perl tend to hate it, because all that power and flexibility can be easily abused (even when you're trying not to — there's a reason so many people buy off the rack instead of making DIY suits).
I think there's a greater underlying dichotomy here that's relevant to your tailor-made suit analogy: the people who love Perl tend to be the people who are building and maintaining mostly only their own tooling and (usually small) codebases, and the people who don't love Perl tend to be the ones that are responsible for maintaining large piles of other people's code.
A language that's "tailor-made" for the individual is fantastic when you only have to deal with your own code. You get to write stuff that makes sense to you. It doesn't matter if it's unconventional or doesn't make sense to anyone else -- it fits the way that your brain works.
But when cooperating on larger projects with lots of other people involved, this backfires remarkably. You now need to understand the way that half a dozen or more other brains work.
As software development has gradually shifted away from the published efforts of lone hackers and towards the collaborative efforts of teams of specialized people, Perl's "TMTOWTDI" approach has made it a far more expensive language to develop software in than all of the alternatives.
I was stating a syllogism there: understanding and working with different coding styles is difficult, increased difficulty adds increased expense, and Perl supports many different coding styles.
As far as I know, nobody's done a comprehensive cost analysis of similar software built using different languages, methodologies, or architectures. Certainly nothing recent. I've harped on this before quite loudly and I think it's one of the reasons our industry can't be called "engineering".
People's individual experiences just don't make for good enough data because there are too many confounding variables.
No, P6 was intended to fix as many Perl 5 problems as possible, and being eminently parseable was considered very important (and important in deciding to forsake backwards-compatibility, I believe).
In fact, a key design-goal is having the language defined by a well-formed grammar that it actually uses to parse itself — and thus that can be used by tools such as editors to parse it just as easily.
Except that it hasn't. What other language does everything P6 does? (Or even tries, let alone does it as well or better.) What language does "most" or "a lot" of it? To be honest, I would have expected that after a couple of decades, there would be other languages that stole a lot of P6's thunder, but if there is anything remotely comparable, I haven't heard of it.
P6 is an surprisingly ambitious project. (I think even surprisingly so to its creators.) Apparently it just takes this long to do something that big and powerful.
Why would any language do what Perl 6 does? Languages do what they need and typically do at least some things Perl 6 doesn't do and at least some things do better than Perl 6 does them. Sometimes such things are much more important to people than everything Perl 6 does.
You’re ignoring the comment two above you. The suggestion was that there are no uses for Perl 6. That implies there’s at least one language that does what it does. There is not.
If you need real rational number math and are doing a lot of text processing for example, there might not be a better alternative.
As just another Perl hacker, your "not real Perl" made me laugh. And no, let me reassure you that that snippet of line-noise is not, in fact, syntactically valid Perl after all.
...you have to transpose a couple of characters for that:
cat nocarrier.pl
!$#foo->_%[]
perl -c nocarrier.pl
nocarrier.pl syntax OK
(And yes, that genuinely does make me love Perl a tiny bit more. I guess you and I are just different that way, and that's OK.)
