You're overthinking it. I don't think those who came up with the names did so to, or cared to, convince people to use the language with them...

(Hebrew word formation is from 3-consonant roots, not concatenation, so removing a letter doesn't give a related word. It's either an invalid word or a different root with 3rd voiceless consonant רקוא which is a not a root / רקוע Raku'a "flattened" but that doesn't sounds quite differently.)

Seeing that webinars have caught on like wildfire, become a multi-billion dollar business, and forced all kinds of eLearning and online platforms to say they offer the ability to produce/share "webinars", I'd say this is rather a counter-example.

I.e. more like "A few might find X or Y name off-putting, some outliers might even come with contrived meanings in unrelated not-exactly homonyms in different languages that supposedly would make a name unsuitable, but in most cases nobody really cares".

That created some kind of limbo where people weren't sure if they should use perl 5 or perl 6 (”why develop in perl 5, when it is probably a dead end and perl 6 is the future” and at the same time "why should I convert to perl 6, what if it will be a failure and I wasted my time?")

By renaming it, it revives Perl 5 so developent can continue, and at the same time Perl 6 is presented as a new language, now whichever wins will be based on its merit.

When Perl 6 finally arrived, it was too much of a step change from Perl 5 to convince many people (myself included). Meanwhile, Perl 5 had continued to develop and was, in no way, in need of a replacement.

The name Perl 6 was damaging to the popularity of Perl because beginners were confused whether they should learn Perl 5 or Perl 6. The same confusion existed in Python: Python 2 vs. Python 3 but the Python Wiki was always very clear. Until a certain point, it recommended Python 2 and after Python 3 became very popular, it recommended Python 3. That sort of clarity was missing in Perl. Due to the number of new programmers learning Perl decreased rapidly and finally Python overtook in popularity.

It's what my company's entire code base is written in. So every hour of every work day for the past 6 months.

>To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.

It's no one thing, but a bunch of little things that compound on top of each other. Until you get something like this:

while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };

Mostly though it's how it's used. It can technically do anything, so a lot of the times it is asked to do everything. Until one day you wake up to find you have hundreds of perl files, all tens of thousands of lines long, that all interconnect in an insane Object Oriented hierarchy soup stretching across every conceivable programming space - from database control to money processing to security to web site design.

Indeed, I hope this thread gets picked up by http://n-gate.com/

I'm never sure what people don't like about OO Perl. There's a tiny bit of boilerplate in a constructor, other than that, it doesn't seem different from other OO script languages.

> On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.

So true. I think Perl golf could be Samuel Beckett.

[0] https://en.wikipedia.org/wiki/Larry_Wall

If Raku's "bad day" is basically like "one of the most influential and important authors of the 20th century" (according to Wikipedia)… well, then, maybe I should check Raku out!

In this case, `!$double` isn't a sigil. `!` is just the old prefix operator for negating a value [1]. If you meant to write `$!double`, then it's the twigil [2] for class attributes [3]. Twigils could be considered as secondary sigils but they affect the scoping of a variable. In this instance, `!` is for class attributes and will only be found there.

As for `.@sigils`, I've never seen this syntax. I'm probably out of the loop in this one.

As an aside, sigils are one of Raku's interesting features. They convey information [4] that might not be easy to discern from just looking at the code. What kind of structure is this variable holding? Is it holding an array? A hash? A code object? What's the scope of this variable? Is it class-scoped? Is it dynamically-scoped? Is it a compile-time variable?

> ... Raku is quite slow.

This is a legitimate reason for avoiding the language. However, it's worth pointing out that Raku core developers have made great improvements to the language in the speed department since it was first officially released in 2015. They recognize there's a lot of room for improvement. [5]

[1] https://docs.perl6.org/routine/!

[2] https://docs.perl6.org/language/variables#index-entry-Twigil

[3] https://docs.perl6.org/language/variables#index-entry-$!

[4] https://docs.perl6.org/language/faq#Why_sigils?_Couldn't_you...?

[5] https://docs.perl6.org/language/faq#Is_Perl_6_fast_enough_fo...?

Over the years (announced in 2000, delivered in 2015) it evolved into a distinct language.

In the meantime, Perl5 suffered from the Osbourne Effect.

Meanwhile a rift developed in the Perl community. Some are for Perl 5 forever. Some are Perl 6 forever. Some Perl 5 people blame Perl 6 for Perl 5's perception as a dead language. Some Perl 6 people blame Perl 5's reputation for being "write only" and "dead" for difficulty getting people to try Perl 6.

IMHO, both sides are correct, both sides over-state their case.

Renaming Perl 6 has been discussed for close to a decade, by people who are Perl 5, Perl 6, and just plain Perl partisans.

It's been a difficult decision. Many people have worked very hard on both projects, and have strong feelings tied up in the issue. Important contributors to the projects have quit as a result the issues.

This isn't a change that was lightly made. It's far bigger than the Python 2 to Python 3 divergence. It's more like moving from C to C#.

+1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol?

"Raku" = "cancer" in Polish. Not a lot of Polish enthusiasm forthcoming, I'd imagine.

The reason I think it's not related to the Lisp issue is because the relation of Perl 5 and Perl 6 was like an unofficial successor with a compatibility mode, like C and C++, whereas the relations between Lisps that create the social problem you highlight of people not knowing about "Real Lisp" are the relations of very incompatible forks with varied functionality running around calling themselves "Lisps" or "members of the Lisp family" and people confusing that with "Lisp". (There were some "Perl 5/6, C/C++" types of relations in the path to Common Lisp like Flavors/CLOS but no one remembers or cares about those outside of Lisp users...) Another reason is the timing, why the name change now, years later -- it turns out Perl (5) is less dead or possessing a stench of death as you put it than people might want, it's still vigorous in its own rights, and so really it makes most sense to just call the new thing by a new name and not destroy both. (Larry's wineskin comment is nice.) The Python 2/3 situation is a closer analog if we counterfactually imagine Python 3000 came out with the current 3.7 feature set, syntax updates, and backwards incompatibility. Python 2 users (me among them) would still have dragged their feet, since Python 2 would still have been useful, still had its own vigor, the same as presently, but it might have resulted in renaming some later version of Python 3 instead of the current situation of renaming the continuation of Python 2 (Tauthon).

Going back to the lisp issue to further elaborate why I think it's not very related to this one, the languages that called themselves Lisp (not a Lisp, but Lisp or Some Lisp) shared a heritage going back to the original McCarthy Lisp. The merely "a lisp" languages used that for marketing, but were actually called something different (Clojure, Scheme, even Racket which has to further distinguish itself from Scheme). You see the heritage in the actual Lisp 1.5 manual, where one of the earliest examples should quickly dispel any illusions today about "Lisp's" supposed purity when they show the function 'length implemented with a program block and goto. By only modifying the top-level function define format and substituting ADD1 with 1+, the program works to this day in Common Lisp. For members of the lisp family that don't call themselves lisp, you're not going to be able to make such a trivial transformation, because there's no shared code heritage, just a vaguely shared s-exp-ness to the syntax. And right after that the manual describes the "pseudo-function" 'trace, which to this day is lacking in supposedly modern languages or requires a bunch of IDE ceremony to set up. It's present in CL and behaves the same, though. Continuing to call CL as simply Lisp seems pretty well-deserved.

The Lisp social problem then is that people run into members of the vaguely defined lisp family like Scheme (especially with SICP formerly being a common gateway for freshmen or HS students) or Clojure and confuse "a lisp" with "Lisp". They can spread their confusion further by releasing a project/blog like "let's write a lisp interpreter!" that can be understood correctly as "let's make a program that interprets code for a lisp¹" but tends to be misunderstood (sometimes even by the author) as "let's make a program that interprets code for Lisp".

Of course I also think this "social problem" is way overstated, especially these days when it's so trivial to dispel the old myths and when the gateways via Clojure or Racket are actually good in their own right and so don't leave the same impressions of "Lisp's a neat toy" that only seeing SICP Scheme could. But if people keep talking about the problem as if it is big, perhaps it will become self-fulfilling, hence my long comment in disagreement. ;)

¹ aka a member of the lisp family based on my vague membership criteria that probably don't even pass Steele's 3-part acceptance test in https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf that requires as its final step (atanh -2) to return a complex number. (Bonus if the correct complex number.)

If you did a "major version bump" from here, you'd probably have to bring the "5" along for the ride. Like Java version 2, where you had J2EE version <X> for years.

In reality, there probably never will be another major version bump of Perl 5, in the marketing sense. The minor version number is really the major version number now.

To avoid confusion they would probably break the version convention entirely and name it with the year instead. So instead of Perl6 it would be Perl'19.

There is no DBIx::Class (or related schema loader) for Perl 6. I don't know how mature the web frameworks are. Or even basic stuff like Excel reader/writers (we use lots of Excel for backend data analysis).

On the other hand, most of the async stuff we currently use can be thrown out. With raku's gradual typing, our in-house type libraries can be tossed out. Our local modules for making it easier to write clean procedural and OO code could be thrown out.

And the raku code would be far more concise and easy to read. Here's a simple Point object in Moose:

    package Point {
        use Moose;
        use overload '""' => \&Str, fallback => 1;
        use Moose::Util::TypeConstraints;
        subtype "PointLimit" => as 'Num'
            => where   { $_ >= -10 && $_ <= 10 }
            => message { "$_ must be a Num between -10 and 10, inclusive" };

        has [qw/x y/] => (
            is       => 'rw',
            isa      => 'PointLimit',
            required => 1,
        );

        sub Str {
            my $self = shift;
            return sprintf "[%f,%f]" => $self->x, $self->y;
        }
    }

    class Point {
        subset PointLimit of Rat where -10.0 .. 10.0;
        has PointLimit $.x is rw is required;
        has PointLimit $.y is rw is required;
    }

    class PointLimit:
        def __init__(self, name):
            self.name =  name
        def __get__(self, point, owner):
            return point.__dict__.get(self.name)
        def __set__(self, point, value):
            if not -10 < value < 10:
                raise ValueError('Value %d is out of range' % value)
            point.__dict__[self.name] = value

    class Point:
        x = PointLimit('x');
        y = PointLimit('y');

        def __init__(self, x, y):
            self.x = x
            self.y = y

        def __str__(self):
            return "[%f,%f]" % (self.x, self.y)

We're still out there, but it's not "cool" to talk about.

But you have parser libraries that work very well in all major languages, and I'm not sure being integrated in the language makes Raju more valid for any project.

What it does, imo, is offer a special way to solve some stuff by already being there. But it's like saying someone would choose python for a project because it has a built-in set data type.

> If you thought Perl was a bad language, PHP is way, way worse

In fairness to PHP, it's a lot better today than it used to be. (Though modern PHP would probably strike a Pythonista as too Java-ish.) And WordPress has had tons of engineering resources poured into it for a decade-plus now, whereas Movable Type has been maintained on a relative shoestring due to its fall from popularity.

Every time Perl comes up in a professional environment for me I'm reluctant to say I'm capable, because it's always a hacked-together mess from an engineer who's likely no longer with the company. (obviously this is VERY anecdotal to my career)

I dropped Perl from my resume about a decade ago because I just frankly don't want to work with it. The language is terse, and I don't think anyone who's starting off these days would be spending their time well by learning it. Make your own opinions, but mine is/has always been "ewww."

Because there's a huge amount of applications and websites still built in it, and it's still a great language so new projects are written in it all the time.

source: my very prosperous career, which has been almost entirely in Perl for the last 15 years

Because it works. Scripts/software that works does not experience bit rot. As long as it works, people will continue to use it.

Edit: OK, fine. It seems the downvoters are convinced that the code does in fact experience bit rot, and spoils with time. Probably like fish.

It does the job

Great language, large library on cpan, great eco system, people enjoy using it, they have a large code base that's run fine for decades. Choose 1 or more.

> I moved on in 2011

You're right, it's all about you and what you do...