> but I'm getting a Lisp vibe: clever people use it, they develop cool new things with it, but it doesn't attain market success (aka secret weapon).

The difference is, (AFAICT) Perl 6 also aims to be easy to use for the everyone else. Damian is extremely bright and surely wishes to have (and (I think) has helped design) a language that allows him to do some frightening and epic stuff. Larry is also a very bright guy, and is very humble, and (again, AFAICT) still requires that Perl 6 make easy things easy. "Baby Perl 6" should be easy to pick up and use.

So, the only part of the Lisp vibe I'm sensing is: yes, clever people will use Perl 6 to do clever things. But also, people who just need to get their work done in a straightforward way will be using Perl 6 as well.

My prediction: Perl 6 will have a long and steady increase in use as time goes by. This is because although there's not a tremendous amount of hype, potential users will trickle in and say, "I need to do $x"; and then as usual, Perlers will come out of the woodwork with multiple ways to quickly do $x without much trouble, and bang: you've got one more Perl 6 user.

What the parent was saying, that you seem to be missing is: there's no reason for anyone to use it.

Perl5 took off because for a lot of things it appeared to be the only game in town. Today that isn't the case anywhere. For the web there is a very established PHP (I just tried to make a web store without writing any code and I REALLY didn't want to touch PHP but there are literally no other options) and a very well established Ruby/Rails. For the enterprise you have Java, C# and all the languages that run on their respective VMs.

Perl6 has no killer app (well, I would consider Parrot potentially a killer app, but thankfully that has afaik no perl requirement). Saying "but we can get stuff done fast!" holds no water anymore. So can Ruby, Python, C#, Haskell, etc., etc., etc. It's not a selling point.

EDIT: Forgot to mention, for sys admin perl6 will be competing with, among other things perl5.

IMHO, the things that Perl really has to do are no so much the clever syntax designs and run-times etc. which while cool to people interested in languages and how they work, don't really allow the language itself to be used in larger scoped work. What Perl needs is a robust standard library that supports the kinds of things that people want to do with languages, like build interfaces, or solid web frameworks. Even better would be retargeting Perl to other languages, like a Perl->JS (so I can write Perl code for a browser) or Perl->JVM (so I can build the kinds of things I need that run on the JVM) compiler rather than building a runtime (Parrot), and re-targeting many languages to that platform.

Don't get me wrong, Parrot and Perl 6 are all worthy efforts. But I'm not sure they will have the kind of impact towards growth of the language and userbase that Perl needs. Perl desperately needs better OO syntax and support for functional programming paradigms. But syntax is syntax, libraries are what make a language useful in today's day and age.

Catalyst is surely a fairly solid web framework. Moose provides a more standard OO syntax...

Yeah, I forgot about Catalyst true...

Moose though is an example of what should just be part of the language. I'm glad to hear that Perl 6 will be doing some of what I want, it'll be a good start. But Perl really really needs the kinds of things that people want to use modern languages for. It's still so geared for processing data files (of various sorts), and most of what I see in Perl 6 seems to target this problem in various ways.

Don't get me wrong, Perl is my preferred language, I can crank out a Perl solution to a problem about as fast as I can type it. But when I really want to push the project larger, the language doesn't really do much to help you.

Perl already has a large standard library, it's called the CPAN. Unlike say Python the aim of Perl's standard libraries isn't to give you a good stand-alone programming environment, it's rather to bootstrap the CPAN toolchain so that you can install these libraries.

Perl has numerous web libraries on the CPAN (Catalyst, Mojo, Dancer etc.), and if you don't like the bare-bones object system you should look at Moose.

While I think CPAN is a fantastic resource (I wish other languages had something even half as good as CPAN for a centralized repository of various libraries and other odds and ends), it's not a standard library, it's a collection of libraries. While PPM is sweet, I work on lots of systems that are not connected to the Internet, and believe me, not having a guaranteed minimum standard library can be a serious PIA. Most distros do at least come with a set of stuff installed by default, which is nice, but it also is not the same as a standard library since that loadout might change from distro to distro, or version to version.

Basically the standard Perl library are whatever functions Perl happens to have. Which, while amazing for text processing, don't help much with other needs.

Any standard library is a collection of libraries. While I get your point, mine is that different languages have different ways of handling libraries, with different tradeoffs. Perl's way is to make it really easy to get libraries over the network, instead of trying to ship a large collection of them with the core.

A standard library, I think. Is what you go look for when you need a module to solve your problem. With Java that's [1], with Python that's [2]. With PHP (until somewhat recently) that was using one of the ~1200 built-in functions.

With Perl, the place to go for libraries is the CPAN. I look at http://search.cpan.org, not `perldoc perlmodlib` if I need a library to do X.

There are cases where this is painful, such as offline machines. But in those cases you can pack all of CPAN on a CD (with minicpan), or produce a self-contained Perl program + libraries with local::lib and/or PAR.

1. http://java.sun.com/javase/6/docs/api/ 2. http://docs.python.org/library/ 3. http://perldoc.perl.org/perlmodlib.html

This is exactly why perl is moving out of the big orgs (at least everyone I've worked at in the last 5 years, and I'm a contractor). Getting anything on a production system is a hastle. Using a language like python that just has most everything out of the box is much easier than something like perl where I need to make a hundred different requests to be able to do any big project.

EDIT: And your CD suggestion is a good way to get sacked.

I see and think the complete opposite on this (and I'm also a contractor).

Like a lot of things in working life it depends on where you're coming from and where you are but I find Perl much easier to maintain across multiple servers because of CPAN (especially by using internal mirrors... for eg. minicpan) than with some other languages.

> There are cases where this is painful, such as offline machines. But in those cases you can pack all of CPAN on a CD (with minicpan), or produce a self-contained Perl program + libraries with local::lib and/or PAR.

Which is pretty much what I have to resort to :(

I don't have to do this for the most part with Java or Python.

PAR is good for deployment, but obviously hard for offline development work (sometimes you just have to do the work on those machines).

Thanks for the pointer to minicpan. I might give that a shot, might save me from manually mirroring CPAN.