The benchmarks just do not support. I mean, roughly in parity with Python and PHP, 20x slower than Clojure on average, 30x slower than Haskell, and on many tasks 100x slower than C. Over the whole bredth of the Alioth shootout programs, Perl trades places with JRuby as the slowest tested language.

Performance handling in high level languages is more about knowing where the landmines are (total heap usage in GCed languages, various troublesome malloc()s, weird caches in dynamic languages...) and trying to figure out as quickly and cheaply as possible if the program you're planning on writing is going to hit them, and how much it's going to cost to mitigate it. It's not relevant if the actual runtime overhead of the problem is 5% or 1000x, the end product is either fast enough or it isn't, and the workaround is either viable or it isn't.

Trying to protect yourself from this by picking the fastest language in a shootout isn't going to work because the perfect, gotcha-free language hasn't been invented yet. There are sound performance reasons to avoid any language, not just Perl.

So far I have not found anything faster than perl unpack (1), but I would be happy to. I plan to investigate Go soon.

Would you have another suggestion?

1 : or marginally faster, with the advantages negated by the time it takes to write the code. However, a 10x improvement would be very interesting to me.

I managed to optimize a similar problem as yours until it was I/O limited. 1/10th the CPU would not change anything in the overall system.

What else have you tried?

So, that rules out Brainf--k I guess

[1] https://metacpan.org/module/Moo#SYNOPSIS

Any toy example can be made to look clean.

Perl uses sigils for two reasons. First, to provide a separate namespace for variables and language keywords. Second, to allow amount contexts.

Reasonable people will disagree about the value of both of those reasons, but those are the reasons why sigils exist in Perl.

You complained about the simple presence of sigils, without even stopping to think and consider what advantages they bring. I may be rude, but close-minded? No.

Imagine how ugly C would be if every variable that wasn't a pointer dereference had to be prefixed with $.

I am not necessarily opposed to meaningful sigils, e.g. Ruvy's @, but using them everywhere is a pure misfeature that hurts readability.

First off, in Perl the parens for a function call are not mandatory.

As such it is very useful for functions and variables to be visually difference, especially when you're using functions to generate parameters for other functions without any temp variables inbetween.

my W = qq_mult ConjugateQ, qv_mult RotationQ, Vector;

You can't tell at a glance what's going on and will need to look carefully. Adding sigils makes it quite clear:

my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

Further, most languages have only one type of variable, a name for a single thing. Perl has multiple types of variables that behave differently. For example:

my $res = munge $one;

I see this and know that the function munge is passed one single variable. However, consider this:

my $res = munge @two;

If there wasn't the @ there, it would be easy to assume that munge gets exactly one argument. However the @ there alerts us to the fact that @two is an auto-flattening array, and munge will end up with anywhere between 0 and MAX_INT arguments passed to it.

Similarly with hashes:

my $res = munge @two;

They also auto-flatten, so they need to be marked as being different from scalars, but they also flatten in a very different way from array, in that they flatten into a list that alternates the keys and values. So they need to be marked differently from arrays.

Lastly, due to functions, variables, array and hashes having explicit sigils, they can be recognized by editors without any heavy analysis, enabling editors to mark these four types with different colors, which is extremely useful. Personally i don't see the sigils anymore, and instead just see the colors with which the types are highlighted.

(Bonus set: Actually C is often written with sigils too. I've often seen code where variables are prefixes with p_, s_, a_, i_, etc. They are not enforced by the language, but people often force themselves to use them. The downside: They are inconsistent from project to project and have to be relearned every time.)

Actually, that's clear as mud. Is this a function call of 3 arguments? Function composition/chaining, an array of 3 items?

Regardless, please defend how that is not just an improvement over, but better than, say:

    my $W = qq_mult $ConjugateQ, qv_mult $RotationQ, $Vector;

    w = qq_mult(qv_mult(CondugateQ, Vector))
         

    try {
        die "foo";
    }
    catch {
        warn "caught error: $_";
    };

    try(
        sub {
            die "foo";
        }
        catch(
            sub {
                warn "caught error: $_";
            }
        )
    );

As for the example, with mandatory parens it would look like this:

    w = qq_mult( ConjugateQ, qv_mult( RotationQ, Vector ) );

    my $W = qq_mult $ConjugateQ, qv_mult( $RotationQ, $Vector );

Where is this general case? I clicked thru the presentation and it boils down to here are some obscure yet interesting and trendy corners of the computational world where Perl doesn't work well, therefore we have to change everything.

We could have had the same presentation 20 years ago, just the trendy weird corners would have to change to match the times. Doesn't mean those trendy corners are useless, just not required to write 'good code'.

Not that the goals are inherently awful. I don't do anything requiring UTF-8 at work. Someday I probably will, and it'll probably be a PITA.

I tend to see this kind of presentation as rabble rousing. "Here's some stuff that other languages care about, although you don't care, but it obviously doesn't prevent any of you from being profitable and gainfully employed writing good code so its obviously not required, which is why Perl doesn't have it. If I can convince you to care about it, Perl would gain it or more likely you'd just leave Perl. Hope you feel uplifted, here's some internet meme pictures, k thx bye" I'm not sure other languages consider it "insightful" when they get a cut and paste rephrasing of the same presentation, which is possibly the most interesting part of the whole story.

It's like saying: Hey, all I do is bang in nails! The hammer is only tool anyone ever needs!

Shell scripts are for things that have almost no logic besides running other programs.

Perl is for things that do have internal logic, and aren't big enough for the lack of formal function parameters to be an issue.

Java is for things that talk to the database (or need other libraries, such as for reading/writing Excel files), or are too large to keep in my head all at once (most of which talk to the database anyway).

C is for the one program I have that needs the suid flag set, and the one wrapper that resets the process group ID. I don't like C.

The server that all these need to run on, is an AIX box that doesn't have Python or OCaml or Ruby installed. If it did, I suppose it's possible I'd use one of these for some of the cases where I use Perl or Java now. Or probably not, since less people know them (except maybe Python?).

PL/SQL is for things that run inside the database, because it's what the database (Oracle) comes with.

C#/.NET is for things that run on my and my coworkers' laptops, because Visual Studio provides a wrapper/installer that makes it dead simple to publish updates.

http://search.cpan.org/~barefoot/Method-Signatures-20130222/...

(And others on CPAN.)

>> [C for suid flag]

Afaik, you should be able to use anything for suid stuff.

---

Edit: What I do see is all the fastest test program for the interpreted languages, ruby, python, etc are all trading places for the slowest language - the differences seem to be completely minimal. (As there seem to be more perl test programs per benchmark the slowest of them is often near the bottom - perhaps that was your methodology.)

On that particular benchmark Perl is faster than the fastest JRuby, and Python benchmarks. And faster than 11 other benchmarks, but the secondary perl benchmark program is the slowest of the bunch...

My problem is with people claiming that some popular scripting language, say Ruby, is massively faster than all the rest. Which as a general rule is simply not true (although it may be the cases, for some well defined set of problems).

I don't make money writing benchmarks. I would challenge that given a flexible enough language, they're nearly meaningless.

Another very important point is most of my Perl is glue between enormous systems. Spending any time optimizing it would be a waste of time/money. I'm not writing real time video encoding here.

That's the case for any microframework whose language you're comfortable in.

BTW, Maybe buying a home in Detroit (especially now that it's officially bankrupt and will hopefully be able to break out of the unions commitments) would be a good business move? That's a cheap place to bootstrap a business for sure.

Not really because part of having a business is staying alive :)

- Perl 6 will STILL be in development

- You just lost 10 years of development experience and related marketability because now all those fad-du-jour systems are established industry leaders

- Nothing would have have changed back in Perl 5 land because everyone can only develop in 5.8.x or 5.10.x in case they break something.

The upside of course is that there will still be COBOL and perl programmers making a living ...

I'm trying to think of what the fads were in 2003. That was the tail end of extreme programming. Kernel03 or kernelcon or whatever it was called had a presentation about replacing devfs with udev since adsorbed into systemd. Simultaneously the new JACK system running on top of ALSA was going to take over sound on the desktop. In 2003 Moodle was the new leader of online course software. I would claim PHP4 was a very popular web programming language in 2003. Firefox was beginning its explosive growth. Bonjour/Rendezvous was new and making noise in networking. By far the most dominant handheld computing platform was the Palm, I still had my couple year old 3 and my wife had one of the M100 series. Dot-net and/or mono were going to take over the entire world; we're still waiting. I believe by this late the cuecat had already sunk along with most of the dotcom era stuff.

At this point I'm running out of ideas from 2003. I don't think "all" would be a good adjective. I'm having an easy time remembering fads that took off, and forgetting things that sank.

Seems doubtful to me. With yearly releases and a two year support cycle, only the enterprisey distribution nonsense is still infected with that particular brokenness.

Depends on what you're willing to give up. Emergency response time can be pretty important.

(disclaimer: I live in Flint, MI, another of those top-5 cities)

Me too! Most violent city, 3 years running!