The problem with Perl, IMO, is that there are too many clever ideas and it takes way too much to fit all of them together (and they never give up and ditch some of the less clever ones like Python people routinely do), which is why Perl6 is moving so slowly.

Perl's learning curve is shallow (easy to pick up) but long (the language is big).

One explicit design goal from perl which isn't talked about much is "huffman coding" in the language. i.e. frequently needed language features should require fewer keystrokes.

This comes directly from Larry's background as a linguist. For example, English has the word "it" to mean "the thing we're talking about". Perl has "$_" to mean the same thing.

The meaning of "it" is dependent on the surrounding context. So it is with perl.

Similarly, it can be confusing to have long, runaway sentences using such context dependent words. You can write bad English and bad perl in this way if you're not careful.

However, the benefit is that, used correctly, it allows you to express yourself clearly and concisely.

I have to correct my statement about Perl6: it's not moving slowly, but it takes too much to get there.

Perl6 as an language is remarkably complete. http://perl6.org/compilers/features

Its performance has been absolutely terrible though. They've been (rightly) focused on features first.

But note that Perl6 on JVM is doing very well. I believe the effort is about a year old, and they've been performance optimizing it for a fraction of that time. And that's with nearly all of the 'remarkably complete' features.

https://github.com/rakudo/rakudo

Last time I did a benchmark a few months ago, Perl6 on JVM was very roughly 2x slower than Perl5. With Perl6's native but optional typing, I fully expect that Perl6 on JVM will get even faster than Perl5.

This year, I need to evaluate a 'scripting' language to run inside of big Java processes, and I'm going to give Perl6 a very close look.

The Operators page (http://perlcabal.org/syn/S03.html) scares me O.O

: :: .: .:: .. ... {...} .^ ..^ ^.. ^..^ ^^ , ;

And several of those have 2-3 uses. Heck, there's probably a way to use only those and some $'s and make something that runs.

Anyway, you can make a good argument for Perl with the best OO (Moose) of the scripting languages, CPAN (+ Testers, so it works), etc.

But please, no more of these language wars, it makes for really boring reading to e.g. see the same arguments whenever Perl is mentioned.

It's really nice for stubbing out code that otherwise needs to compile.

    sub not_impl {
        die "Not implemented";
    }

    if ($some_clause) {
        not_impl;
    }

I'm sure Ruby could do something similar. It may be less pretty but it works, and it is useful during certain types of development, I find.

The primary goal of the `...` feature was to make example code compile safely. (I implemented the feature in Perl 5.)

  def not_impl(reason = 'unknown reason')
    raise NotImplementedError.new reason
  end
  not_impl #=> NotImplementedError: unknown reason
  not_impl 'TODO' #=> NotImplementedError: TODO

  define_method("...") { raise NotImplementedError }
  send "..." #=> NotImplementedError: NotImplementedError

like the typed/untyped debate, the amount of primitives a language ought to have seems to be a topic of disagreement even among experts (touched on here http://www.infoq.com/presentations/functional-pros-cons although not the main topic). also, like type systems, primitives seem like something that, while important to consider, are easy to get hung up on, to take a stance and apply it to all languages without the consideration that different languages are good for different types of problems. my own snap judgements of perl were that its notions of context and pragmas make it easy to express one or two ideas both quickly and intuitively, but that its type system makes it difficult to reason about larger programs.

so to cap off this ramble, my question to the perl people: what problems are you solving with perl? to me, perl seems to mainly fit two use cases: sys-admin stuff (where it's basically used like bash++, although i realize it's much more powerful than that) and an embedded language for c programs.

I think you can think of it this way. ANSI C doesn't have a built in linked list, or hash/dictionary, or line count when reading a file, or map or grep or a bunch of things... and you can implement them (though map/grep are a bit tricky) but you have to worry about the implementation, and matching other people's implementation. By having the many useful primitives Perl does, it provides a broader standard interface for doing things, and that makes hacking easier.

Perl tries to give you lots of tools to express yourself. If you are a wood carver, you know that you can work wood with very limited tools, but having the right tool in your shop makes things a lot easier and simpler for the expert. So it is with Perl.

perl's syntax for regexp matching definitely makes it a good choice for programs that have to do a lot of string-munging, but that's what i meant by "sys-admin-type stuff."

I think, given that Perl is being used, the question might be, what features make javascript or Python a good reason to switch? I'd want to avoid losing features.

Perl is stable. Perl written two decades or more ago still runs fine in modern perl. That's important for data analysis, especially in the sciences.

I'll have to read up on Python ... I'd want a tie equivalent to be able to treat large files as if they were arrays/hashs (lists/dicts) without loading them into memory as such.

please do. i'm a language user, not a designer.

> what features make javascript or Python a good reason to switch?

or, for a mostly-disinterested (in programming, i mean), entrenched group of users like biologists, this question becomes more like, "what features would necessitate a switch?" same question for plan 9 vs. linux or any technology that's trying to do a better job of filling a need that's already being met. ...and, of course, the answer is that there are none. perl has notions of object-oriented-ness. it's possible to build in your own type-checking. the backwards compatibility thing is definitely helpful for the sciences, and it's free, so, like the fortran routines that parts of numpy ultimately wrap, their code can live on.

i mentioned python and javascript not because i think they're such great languages but because i feel that they're in that position relative to perl. of course, unlike plan 9, python and javascript got a lot of users.

> treat large files as if they were arrays/hashs (lists/dicts) without loading them into memory as such.

not totally sure what you mean here. isn't that what databases are for?

anyway, for a new code base that's going to evolve a lot and possibly get scrapped entirely (i.e. most hn readers' situation), python is worth checking out.

Perl is not just a string mangling language, it's a full-fledged generic programming language.

Any problem, there are even 3d opengl games implemented in Perl.