Right now the Perl5 codebase has stopped being developed (at version 5.8.0)

Absolutely not true. 5.8.3 came out just a month ago, and work definitely continues on perl5. I don't see this changing any time soon.

The problem is that Perl5 code will not run on Perl6 without translation

Also not true. Thanks to Ponie, perl5 code should run side-by-side with perl6 code on Parrot.

Another downside to Perl is it's [sic] *apparent* lack of market share when compared to PHP.

The only thing that matters is whether there is a large Perl community. Pissing contests about market share are just that -- pissing contests. I don't see the Perl community going away any time soon. Besides, if market share was all that mattered, we'd all be using MS Windows and VB.

That said, I'm not sure it matters. This person apparently doesn't care enough even to do some basic fact checking, so how much logical argument can convince him to change his mind?

Update: after reading the forum hossman linked to at Re: Perl myths ?, I feel even more that we're wasting our time talking about this. There doesn't appear to be much serious research or comparison going on there. Their decision does not appear to be based on technical merits. In light of this, PHP might well be the better language for this project.

Their comments about PHP being "much faster" and putting a lighter "load ... on the server" than Perl strike me as particularly funny. There's lots of anecdotal evidence, and nothing in the way of specifics or technical details. They don't even mention the differences between CGI, mod_perl, and mod_php. Again I repeat: there's not much point here. I'd be happier just to leave these people alone.

Update: I might have spoken too soon. Some of the later posts bring up some of these issues. So my criticisms might not be well-founded, but my main premise stands: let the folks who will have to work with the project decide its fate.

Right now the Perl5 codebase has stopped being developed (at version 5.8.0)

Absolutely not true. 5.8.3 came out just a month ago, and work definitely continues on perl5. I don't see this changing any time soon.

Hell, didn't they just release a patch for 5.004?

What wrong having support for several stable branches?

AFAIK 5.9.1 is going to be released that is development for the stable future 5.10.0 release.

Courage, the Cowardly Dog

Another downside to Perl is it's *apparent* lack of market share when compared to PHP. When looking at resources sites two years ago, Perl scripts numbered around 3,000 and PHP scripts numbered around 400. Now most resources sites show around 3,500 Perl scripts and 5,000 PHP scripts. There are two factors at work here:

PHP was geared for the person who didn't have this type of access, or want to deal with it. The creator of php ran it on his own box for the purpose of web forms, which doesn't really help in design of the language. With perl, ther is consistancy all over the place, plus a sense of expression. With php, you get convenience and that's about it.

For example, creating a tool to render a page will always be an "easy task" that should be relatively short. One of the biggest problems with php is that the designer never thought out everything. Quite frankly, it's a mess with 3000 core functions, many of which duplicate functionaliy, and things arne't abstracted out nicely, like DBI. mysql_pconnect vs pgsql_connect anyone?

the Perl scripts available are robust programs. Perl is still the de-facto language for e-commerce on the Net.

I worked with php for 4-5 years, and the more i worked with it, the more ugly the design flaws appeared. The only theing wrong with perl's designs, are the innards (from what i hear) and actually writing a parser against the language from scratch. Other than that it is a very real programming language that isn't going away.

If there is anything I've learned from Linux, it's that competition is a good thing. We have upteen billion different window managers, CD programs, etc. It's great!

What am I getting at? PHP, Python, Java, and Ruby all have elements that can and will affect the future of Perl. They all "compete" against Perl in one or more ways. Competition is healthy.

Why are so many languages seemingly beating against Perl? Perl, being the ultimate glue language, can be applied in multiple environments -- thus it faces many competitors due to it's versatility. It is not specialized like PHP. Perl isn't going anywhere -- it already is *everywhere*.

Some recent trends away from Perl are due to cleanliness of the language (well, I don't get this -- I love Perl -- but anyway).... I predict the Python and Ruby hype machine to be well countered by Perl6, though --- if Perl6 can get out fast enough Python and Ruby will never attain "peer" status. Perl6 also has position to take a bit more java share, but this isn't a war. This is no corporate animal. We keep Perl around because we love it. Remember -- we shouldn't look to see these other languages fall, again, competition is a good thing.

Don't be worried about Perl's future. I'd be worried if you were a fan of Forth or Pascal or Cobol. Perl? "The future's so bright I've gotta wear shades".

Some recent trends away from Perl are due to cleanliness of the language (well, I don't get this -- I love Perl -- but anyway).... I predict the Python and Ruby hype machine to be well countered by Perl6, though --- if Perl6 can get out fast enough Python and Ruby will never attain "peer" status.

I'm gonna risk the downvotes here.

While Perl 6 will clean up some of the ugliness of Perl's syntax (no more @{$array_ref} stuff, etc.). It seems to me that they are adding alot of new operators, and in particular Unicode operators ( see Peir's summary about this here ). Maybe when the dust settles this will be a good thing, and clarity will reign supreme. But I am very wary of languages with weird character sets, I mean if this was a good thing, we would all be programming in APL.

Now I love Perl as much as the next monk, but I also realize why other people don't like it. And I see too that when it comes to clarity of code, Python is really really nice. They don't call it "executable pseudo-code" for nothing. But you can't do the same 3-weeks-worth-of-work-in-one-line scripts you can do in Perl in Python, its just not that "expressive".

Don't be worried about Perl's future. I'd be worried if you were a fan of Forth or Pascal or Cobol. Perl?

Pascal, maybe, but I would hesitate to call COBOL dead. Yeah it sucks as a language, and I highly doubt that there are any new COBOL projects in the works, but there is ALOT of existing COBOL code out there, and that code needs to be maintained. Just look at the work on COBOL.NET (by Fugitsu) to see that its not dead (old, crochety and with a severe case of senility maybe, but not dead).

As for FORTH, its certainly not a widely used langauge, but its also not dead. You would be hard pressed to find another language that can fit into some of the places where FORTH can, its tiny and endlessly extensible. It tiny footprint and fast execution speed make it ideal for small embedded microproccessors with limited memory, you can't say that about Perl/Python/Ruby/etc. Weird, but not dead, its a niche language thats all.

Perl is still alive and well for sure, and PHP (IMO) is just an ugly stepchild of Perl. But PHP is a niche language like FORTH, its ideally suited to small to medium-scale web applications. Perl on the other hand is more of a "general purpose" programming language. PHP may edge it out of the "slap-a-quick-web-site-together" market one day, but who cares, there is still alot of other places Perl lives and works in that PHP will likely never go.

Perl is Dead! Long Live Perl!

-stvn

As for FORTH, its certainly not a widely used langauge, but its also not dead.

Every single modern Apple (PPC) and Sparc machine contains the "open boot" ROM, and that's programmed in (and extended with) FORTH. If that's "not a widely used language", I wonder what you consider "widely used".

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

... highly doubt that there are any new COBOL projects in the works

Then prepared to be surprised ;-) There are a heck of a lot of new COBOL work in the works. I know a couple of people doing COBOL development work and they're continually in work - a lot of it new code (and they're paid very well for it too).

According to this little list of COBOL facts Gartner are predicting that 15% of new code in 2005 will be in COBOL.

Actually, I very much hope that I can use Python and Ruby alongside Perl6 via Parrot. In fact, I'd love to see a version of a Java compiler that can target Parrot, too. That way I can choose each language based on its merits alone and not just because it needs to integrate with a larger application that is written only in language x.

I doubt Cobol is going away any time soon. If you've still got Cobol code laying around, it's because it's mission critical and you don't dare replace it with a solution that doesn't have 20+ years of debugging behind it like your current Cobol code does. You don't keep Cobol around because you want to, but because you have to. I don't see how Parrot will change that.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

There likely will be a version of a Java compiler that can target Parrot. However Parrot does not consider all languages equal. It considers highly dynamic languages as first class citizens, and all other languages will pay overhead whether or not it makes sense for them. This means that Java running on Parrot will be far slower than Java running on a traditional JVM.

Therefore while it is an interesting proof of concept, people will only run Java on Parrot if they really, really have to.

FYI -- my comments on Cobol were about a language that had no room to go. I did not imply that Perl was going to some how take share from Cobol, or Forth.

I wanted to mention Lisp and Smalltalk as languages that weren't really growing too -- but many folks still use those. Plus, I was trying to avoid a flamewar with any AI professors that might post here :) It's blatantly obvious TONS of folks still use Cobol.

Languages never really die. They just cease to grow. That's what I meant when discussing Cobol and Forth.

I released a partially finished JVM -> PASM translator to the p6-i mailing list several months ago. It was mostly complete as far as opcodes are concerned, but I couldn't really test it as parrot didn't have real object support at the time. Of course, it does now, so maybe I *should* finish it...

http://www.ukuug.org/events/linux2002/papers/html/php/index.html

Courage, the Cowardly Dog

That article is the best I've seen at explaining the downside of PHP's ease of use. No namespaces? Good grief!

PHP seems to be almost as bad as Tcl after looking at that article.

The fact that PHP came a long time after Tcl makes it about ten times as bad as TCL.

For those of you who are interested in sharing your views on this topic with the people who made the above mentioned statements, this appears to be the appropriate forum.

(Just a reminder: they are seeking input from their customer base -- their paying customer base. So while you should feel free to point out flaws in their reasoning, please make it clear wether or not you are making your comments as as a customer, or as a conscientious observer.)

Perl5.10.0 is under development;

Well, technically it is, but it's crawling along. 5.8.0 was released a year and a half ago, and the road towards 5.10.0 was started soon afterwards. Hugo, the pumpking had some big plans for 5.10 - but I don't get the impression any work has been done on it. Do you know the current goals for 5.10, and how much of it has been done for it? Have you heard any target date for 5.10? How many patches have you seen the pumpking apply the last year? How many patches have you seen submitted recently? By how many people?

As for perl6, we're now 3.5 years down the road and it's almost a year ago since the last apocalypse was released.

Sure, the 5.8.x track has a 3-month release schedule. But those are maintainance releases.

Perl development hasn't stopped - but it isn't bursting either. There are only a few contributers. I can't blame outsiders from thinking Perl is hardly being developped. We all like to chant that development of open source goes faster proprietairy software. But that doesn't seem to be the case for Perl.

Abigail

I see an initial statement from Hugo at http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-07/msg01609.html; I thought he had another list later, but I can't seem to find it. There don't seem to be a lot of specifics there.

As far as current goals go, I posted my (short) list here. Since then, Module::Build has had something of a flurry of development; I've been waiting for it to settle down before saying anything more. I have a m// enhancement patch I'm working on, also, but that's been slow going.

No, there's no target date; I'd just as soon set a cut off date at 2-4 months from now and put out an RC, but there doesn't seem to be a great drive for a release. I'm not sure why.

As to how many patches by how many people, my memory isn't that good. Recently, Dave Mitchell has certainly done a lot of work; Rafael Garcia-Suarez has also; others have worked on various specific ports/modules/issues: Paul Johnson, Greg Matheson, Autrijus Tang, SADAHIRO Tomoyuki, Stas Bekman, Tels, Marcus Holland-Moritz, Brendan O'Dea, Tassilo von Parseval, Alan Ferrency, Paul Szabo, and I have posted patches in the last week.

I'd never actually seen (that I recall) the claim that open source development is faster, but indeed it doesn't seem to be the case for Perl.

Ow! That breaks ascii sorting of version numbers! Perhaps Perl needs to follow Zeno's paradox and keep moving a half step towards six with each major release. Of course, this would cause a lot of really bad jokes, since "we'd never really get there" :)

This is not a problem. You can still compare either $] as a number or $^V as a string (or will it become a version object?) and it will give you correct results.

GNU ls has the -v option to sort 8 before 10, I also find that useful.

(OT: Did you notice that files of dos version x.yy are released with modification time x:yy am?)

Also, that would be an epigon of the version nubers of TeX and plain.tex, that converge to Pi.

And odd minor version numbers are only for development releases, so if you want that people use new Perls, you should not use version numbers such as 5.9.999.

The arguments used pretty much all seem rather fallacious! Experience here is that PHP is much slower than mod_perl - thats what you call comparing apples with apples. PHP is, after all, an Apache module.

They even admit in their analysis that much of the module support they currently enjoy with Perl will be unavailable - they will have to write it for themselves and contribute it to PEAR if they want to have it to use. Nwo that is good for everybody - make more of it to spread it around.

But really, those of us who have to work both sides of the fence know which is better, which has fewer bugs, which is more extensible. The question they are aksing is not "which is the better place for us to be technologically" what they are really asking is "how many of our users who may want to hack this thing are PHP scripters, versus programmers capable of using Perl5?".

Every day I see examples of poorly written PHP scripts out there, some of which are actually more security hole ridden than the infamous Matt's Script Archive! I see these things because my office is getting more and more calls from people who rejected our "higher priced" Perl solutions and went with PHP. Now I have to admit, that I do see some really good PHP stuff too! Just not very much of it at all.

Don't worry, Perl wont disappear, nor will PHP. Perl has a long history of capabillity which spans pretty much any aspect of computing you can think of. PHP started out in one small niche of the ocmputing market and is working out from there. Give them time, they will catch up. But obviously the Apache Foundation wouldn't be working on Perl and PHP as well as Java based systems if they thought one was going to triumph now would they?

jdtoronto

Well, let's try to make a purse out of the sow's ear. There are some grains of truth in the above. The stuff about development is clearly rubbish, but some of the other stuff does ring a little true.

There is probably more PHP stuff around the 'net at the moment. There is some really horrible code (worse than MSA), but it is at least voluminous. I think PHP definitely has mindshare, if not marketshare, and the development of PHP is probably more rapid than Perl.

PHP is almost always easier to deploy. It is more widely supported on ISP webservers (at least in the UK), and if you want a big app it's also a lot quicker (you run up against the limits of CGI quite quickly with OO/database code, and getting access to a mod_perl server is hard - very few ISPs run it, since it's so difficult to manage).

Lord knows I've been shot down on these forums enough times for suggesting that PHP might not be a worthwhile language, but the truth of the matter - as the paper Courage linked to discusses - PHP is a truly horrible language. It's only widely supported because running mod_php is a cinch: if there was a usable, supported mod_whatever than ran Apache::ASP or something it would instantly 0wn, because Perl is 100x a better language than PHP. PHP makes me want to pull my teeth out. It makes others feel the same too. Yet, we continue to develop in it - it's not out of love of the language, I assure you.

Is it true that PHP has no multibyte (unicode) support?

In PHP, a character is the same as a byte, that is, there are exactly 256 different characters possible. This also implies that PHP has no native support of Unicode. See utf8_encode() and utf8_decode() for some Unicode support.

See the online PHP Manual

Since the famous "C Programming Language" it is generally accepted that the best way to learn a programming language is to start as soon as possible to write simple "Hello World" programs in it. But there is no one way to write and install such a program in mode_perl that would be guaranteed to work at once on every server.

It's obvious that the reason perl lost so much market share for PHP are the difficulties with mod_perl. I would blame here a variation of the TIMTONWTDI

Of course we are only talking about one specific market here - web applications. PHP is certainly not making in-roads in the use of Perl for system administration, testing, build management, telecommunications, etc.

I don't think that the number of different ways of setting up mod_perl is the issue. The reason PHP is used more is that it's basically impossible to setup mod_perl for a shared hosting environment in a secure way. PHP does it out of the box.

I am patient. I listen to some of my workmates expressly prefere PHP to Perl. That's an understatement. "Deride Perl in favour of PHP" might be a better phrase for it. Now, I might prefere PHP to Perl on occasion if only for the fact that I am a novice to each. But I think that's beside the point.

The fact of the matter is, I prefere Perl on easthetic and social grounds. It feels "good". But that does not defend the language from its critics (AFAIK). (Though I think it should be a consideration when choosing your tools. Provided that what you choose isn't wildly inapropriate)

What bothers me is the insistant statement that "Language X sucks" etc, without supporting information, or very little. Further, when it occures in my environment, I am at a loss to really compare the two, and I feel that I shouldn't have to. So, Perl does not yet get a good defense from me, and thus gets less use. *sigh*

So, my reply is really a question:: What are the best social actions that can make these debates clear and without malice?

thanks,
    willy :)

$state->{tired} = "true";

One more comment -- I just went to a rather boring bioinformatics presentation. "What can an Engineer do in the field of Bioinformatics". These guys were pro-java and the guy uttered a comment once about "crap Perl scripts", so I walked out towards the end of things. I think these folks would say the same thing about other cool languages like lisp, etc. They allow you to shoot yourself in the foot, but they also allow you to do incredible things.

What folks need to realize is that bad software design is possible in all languages -- and that shooting oneself in the foot is possible in all languages.

I also think I just lost an interview for a replacement job, due to my love of Perl -- this is probably the sign the place wasn't right for me -- he said they were rewriting a perl driven interface in JSP (with an ugly look on his face when he said Perl) and I asked him why. He also asked about Perl experience earlier and I gave him a pretty good discourse on why I enjoyed functional programming and mixing styles -- plus the inherant flexibility in the language.

I think some of this myth comes from the fact that Perl, in some ways like VB, has a low barrier to entry, so often you get codes who do not have a strong software design ethic. Most folks do.

The proper analogy for me reminds me something of LEGO's... A 4 year old can play with legos, but he's not going to be able to create that Mount Rushmore the master builders made (and way off-topic, but for those in Orlando, check out the Lego Store on the Disney property...AWESOME and complete with lego sea serpents in the Lake!)

So we pay for what the inexperienced do. Is that so bad? No, I say it's really a plus. We have a wide array of users, and there are various stages in the evolution of a Perl programmer. There are functions I've written that I now look back on and smile...looking at how I once thought I was good and what I wrote then...

Myth or no myth, the accusers of other languages need to realize that in all languages, shooting oneself in the foot is equally easy. It's just that the bullet wound may not be immediately obvious in all of them.