I have a couple of disconnected thoughts on this ...

First of all, it's a very good idea to treat – and therefore to package – a Perl-based website application as a distribution. In other words, do all of the stuff that CPAN packages do to automatically satisfy whatever dependencies there might be. (And to automatically discover them, as you are building your distro. O'Reilly's Intermediate Perl book has a pretty good, albeit short, section on this... for those of us who still like to read paper.)

Second, “all I can say is that I have made a very good living lately, replacing PHP and encouraging people not to use it” ... even though, of course, I still do a fair amount of PHP coding myself, because you inherit what you inherit.

Your “bologna” analogy is a very good one. (I'll take my London Broil medium-rare. Now that you've made me hungry, at eight o'clock in the morning, “is it ready yet?”) It reminds me of what they say in the very-excellent book, In Defense of Food. PHP is like what they call “a food-like product.” So is bologna.

The essential drawback of PHP lies in its stated design:   it is built to embed functional logic into an HTML page. Everything about that language is really geared toward the generation of HTML output (one way or the other...) to insert it into a surrounding HTML page. Presentation and logic are therefore inextricably linked. Furthermore, both presentation and logic are also tightly coupled to the underlying (SQL) database. What results is a very quickly-built, but very short-lived “application” that costs many thousands of dollars.

There are gobs and gobs of “newbies” out there right now, churning out just such applications, and managing to disappear before they have to start maintaining them. It's impossible to maintain profitability when the shiny new car that these guys sold them winds up being in the shop every few weeks or months. So they abandon that car and that client and go searching for another car to build. Word gets around, though. (Just how many Drupal hacks does one town really need?)

PHP is “easy to deploy” because so much is built right into the executable:   pragmatically, it has to be. You've got a library of hundreds of built-in functions, whether you want them or not. You've got “one way to do it, and if you don't like the one way that PHP has to do it, you have to change what you do. For a business, that's not good.

In the real world:

1. Web-sites do not exist in a vacuum. They are part of a much larger system.
2. Web sites must not be tightly-coupled to the underlying database.
3. Nothing is really CRUD.
4. Very quickly, we see that we are having to deal with many more types of interaction than “just HTML,” to many more types of devices than “just web-browsers running on laptop computers.”
5. So, if presentation is tightly-coupled to everything else, you're already dead.

Suddenly, the very designed-in characteristics that make PHP-based development “easy” also conspire to sabotage the shelf-life and the maintainability of the applications that are built in it. Mind you, I'm not slamming PHP when I say that:   PHP was designed as it was designed, by “good and competent workmen,” to be a power-tool for the then-prevailing conditions. But those prevailing conditions have since changed. The very same design decisions that were so vital to allowing PHP to accomplish its mission then, have now become a box.

The more you look at Perl, and especially Moose.pm and the forthcoming Perl-6, the more you come to understand that you could literally spend years plumbing its depths. It just doesn't come with a marketing-department.

I'm building “a web-site, among other things,” now that is aggressively built on (Moose-based) Perl objects. The web-site is strictly just a surface-layer; nothing more than presentation, and it's only one of the several types of presentation that must be available. Because I do not have the time to build, let alone to maintain, any such thing, the corresponding design is extremely orthagonal. Presentation, logic, and data persistence are widely separated. While it took many more weeks to “achieve lift-off” than I had expected it to do, let's just say that it did not leave any pieces of its landing-gear on the runway. I can't do that in PHP. I can't even come close to doing all that needs to be done, in the very-short amount of time available to do it, at the speed it needs (no time to snooze waiting for a JRE...), with anything other than Perl.

But the final deployment does need to be “a distribution package.” That's an extra step, but well worth it. Deploying the final product onto a web-server needs to be a hands-off repeatable process just like going to CPAN and saying install my_stunning_app, and it needs to avail itself of the same (existing) techniques.

I've installed many commercial products, written in C, Java, and even (partially) in Perl that don't send you to install hell. It doesn't conflict with an existing Java or Perl installation. It doesn't require you to hunt down libraries or modules which may or may not install. It comes with all bundled. I've added a complete Perl distro to the software my employer at the time was producing, just because I prefered to write some supporting scripts in Perl instead of shell or C and wanted to be sure perl was on the system.

Yes, that may mean you have five installations of Java and six times perl on the box. The price of the extra diskspace is well worth the ease of installment.

Now, I'm not suggesting you should include perl to every little application you want to distribute. But you may want to bundle in the modules your application depends on. (Of course, if you distribute your application for free, you're free to do whatever pleases you ;-))

I don't get it. You compare Perl to a London Broil, but you complain that people would rather program in PHP because it is more like a McDonald's Hamburger. Inexpensive, easy to get and bad for your health. Should we grind up a London Broil and make it more like a cheap burger because that is what most people eat? I hope not.

PHP is built more on a direct approach, most people have a hard time visualizing programming in an abstract manor( like an MVC model) because they don't have the experience. PHP fits with most peoples thinking when they getting into something new, it is simple and easy to see short-term results.

The question becomes, do they develop a need or a desire to take a different approach when it becomes apparent that what they are doing is not a long term solution. Most programmers stop learning and stick with what they know, even if it is not productive( they are happy with McDonalds and happily eat it 3 times a day every day).

Other people decide they want to move onto something better, we will always have Perl, the London Broil. Lets not try to make Perl something that it is not (PHP). There is a reason for both existing.

Several issues here. Fedora? Ok, Fedora. I run it myself, but! Perl is not the language of choice of them Fedora people. They'd rather weed out perl completely and replace it with python. I don't care, as long as the rest of the distro does what I want. I'm still able to compile and use old stuff with minor tweaks.

For perl modules, I use RPM::Specfile. I have hacked the (included) cpanflute2 to build packages optionally and get dependencies right, and all my perl modules are rpm packages. Which means that I have source and binary (or noarch) packages of them, which means ease of rebuilding. Of course I check every time the existence of a perl package in the Fedora repo, because I'm a lazy boor. And that's just the reason I didn't hack into it the 'follow' mimic of cpan... but then, that's the most time consuming lack-of-features. I guess I should implement that 'follow option', if it hasn't been done already - to just type in cpanflute2 Module-Foo.tgz or cpanflute Module::Foo and get a cup of coffee while it is installing the whole bunch of deps.

Next, PHP vs. Perl. That has long been discussed, and the only bit I'll add to it is the following observation: perl is multipurpose, while PHP isn't. It is easy to stuff functions addressing all kinds of needs of a one-domain-language into one binary; it is hard for a multi-domain language to compete here on the grounds of that specific domain. And why should it specialize, anyways?

PHP is to perl what orcs are to elves.

update: corrected last statement

>> For perl modules, I use RPM::Specfile. I have hacked the (included) cpanflute2 to build packages optionally and get dependencies right, and all my perl modules are rpm packages. Which means that I have source and binary (or noarch) packages of them, which means ease of rebuilding. Of course I check every time the existence of a perl package in the Fedora repo, because I'm a lazy boor. And that's just the reason I didn't hack into it the 'follow' mimic of cpan... but then, that's the most time consuming lack-of-features. I guess I should implement that 'follow option', if it hasn't been done already - to just type in cpanflute2 Module-Foo.tgz or cpanflute Module::Foo and get a cup of coffee while it is installing the whole bunch of deps.

Interesting, I'm going to have to do a little spelunking and noodling on this. I definitely need a more robust deployment system

>> Next, PHP vs. Perl. That has long been discussed, and the only bit I'll add to it is the following observation: perl is multipurpose, while PHP isn't. It is easy to stuff functions addressing all kinds of needs of a one-domain-language into one binary; it is hard for a multi-domain language to compete here on the grounds of that specific domain. And why should it specialize, anyways?

Completely agree, except for the one niggling issue that I think Perl + Mason (or add your favorite template/web technology here) actually does trounce PHP, without trying too hard. The adoption problem seems to be just getting things up and running (examples: new Macbook, hosted environment). The problem seems to be simple choice and packaging. Perhaps this is something people will eventually just figure out themselves and we are seeing a short-term phenomena. But the difficulty in the setup just stops people dead. On the other hand some might argue that this keeps the unwashed masses far from the Monastery Gates.

>> PHP is to perl what orcs are to elves.

The funniest thing I've seen today. I'm going to start propagating this meme...

On the other hand some might argue that this keeps the unwashed masses far from the Monastery Gates.

I don't mind unwashed masses, as long as they spend time in the sudatorium before they drop into the refectorium...

So many technologies emerge as highly-targeted solutions, which are then pushed to do more than they were designed to do. PHP is an example. I got the impression---even when I used to write PHP several years ago---that it was designed to be a sort of one-off embedded Perl to simplify CGI. This isn't all that different from Ruby on Rails, which makes the simple use cases easy, but the more complicated ones are still difficult. A technology designed to make one or two special cases trivial has the tendency to make everything else no easier; and it frequently makes them more awkward, if not actually harder.

Perl's strength lies largely in refusing to commit to any given problem domain. So when I read people complaining about Perl's baroque syntax, I realize they really don't get it. Perl's refusal to be a fill in the blank language is precisely why it is a good fit in so many other places. To misquote a friend, Perl isn't best at anything; it's best at everything.

I work with some people who denigrate Perl and look longingly to Python/Ruby/Erlang, etc. Those are fine languages, and there's nothing wrong with using them. But I've written code in a lot of languages, and I always enjoy coming back to Perl. Baroque syntax is annoying, and the promise of "cleaner code" is appealing. But I have to say, solving the same problem in other languages never actually comes out as cleanly or succinctly as promised. It seems I always end up with something that's a little clumsier than what Perl can give me.

And I need hardly mention the Perl written by those who look elsewhere is hardly masterful. I'm left with the opinion that, had they merely tried to learn Perl correctly in the first place, there would be no real appeal in looking elsewhere. Which is not to say I never use other languages! I use several, but Perl is the one I find myself using most frequently.

I am once more struck by the wisdom of a mentor who told me Perl's biggest problem is, people aren't taught to write good Perl. The interpreter can read all sorts of garbage as real code, so there's not a lot of incentive to writing good stuff. And because the Perl community has had so many people wanting to show that off, we've developed an unfortunate reputation for obscurity in our code. Perl isn't a "read-only language" but we've done a good job of convincing people it is. I am convinced that's our biggest problem when it comes to advocacy.

I rambled a bit there.

I think the essential issue is one of culture. Perl has descended from the "Unix Traditions", which come mostly from University culture. Even the choice of a representative way to present itself to others "Perl Monks," gives this away. Monks take a vow to abandon the outside world, and retreat to an inner world. In the monastery they work on interesting problems and avoid the world of Bologna, or to use a popular spelling "Baloney". In a twist of irony, the word "Bologna" is a popular college town in Italy. But I digress.

I am not criticizing the monastery, but these ideas are relevant to my exposition.

Some of the Unix Traditions (according to me): "Doing it right," "Minimalism", "Teaching/Learning/Culture embedded in University forms (professor-student, focus on research, etc.)", "Evolution and Competition", "Openness".

One of the things accepted in University is the idea that not everything is obvious, and the onus is on the pupil to persevere to attain knowledge. This is in direct contradiction to "market driven consumer culture," which tries to make things as oriented as possible toward the consumer so they will give us money. The web started out initially as a University exercise, and took a little while until it exploded into the all encompassing thing that it is today. At this point, consumer demand has overshadowed the original culture that brought it to life. Google is not so much famous for page-rank (a good idea, but is it really that good? matrix math? c'mon). Google is famous for creating a huge, consumer driven, money machine. Of course there are all the Googley things like Google maps, and things are free, and they have a "unique culture" (more marketing...think Xerox Parc, IBM, MIT, etc. etc.). The real thing they did better than anyone else is to capture the consumer demand. If you think about it, Google search is really just a box that people type consumer demands into.

I mention the web because Perl really took off with it's use in CGI. Before that it was just an interesting way to not have to use sed, awk, grep as the bits and pieces. It was the Unix Borg Unit, which gobbled up all the evolutionary DNA. It was the Pathetically Eclectic Rubbish Lister. Anyone who had the Unix history would immediately realize it's value. But then the web came along, and Perl gained huge popularity through it's use in the web. It harnessed, I would argue accidentally, the huge consumer demand that was now creating 100K jobs (a lot of money at the time) for anyone who could write a for-loop. Oh, you also had to have a nose ring, at least in San Francisco, that was mandatory: for loop (check), nose ring (check) OK you're hired. I have nothing against nose rings. In fact they are an essential part of street cred in various technical enclaves in SF.

The web technologies, despite being developed in the hallowed halls of CERN, were always designed to gain mass adoption. Look at how simple HTML is. It made a generation of people who could use tags call themselves "HTML coders". The audacity. Look at how simple HTTP is (I refer to HTTP 1.0, and not the far more complex 1.1), GET, POST, URLs. Totally brilliantly simple. So simple, that our nose-ringed-for-loop-equipped web master can use it to make 100K. Do I fault him? Please. This is why the web is important - because everyone can use it to enrich himself and others. The barrier to entry is very low. I would argue that the web is complicated, but many of the things that people interact with hide that complexity (and that is where the A.C. Clarke comment on magic comes from - the hiding of complexity, not the display).

We should not confuse "easy to learn" with "easy to use". Nor, should we believe that they are mutually exclusive. Legos, for example are easy to learn, but they also provide incredibly expressive power for those willing to risk the carpal strain. Making something easy to learn, does not imply you have to dumb it down. However, this is a strategy which works. You can often dumb something down and make it more popular. However, there are different ways to make things easy to learn. Training wheels don't ruin a bike. Well, not quite true, they do mar its appearance as one lists to one side...however, one eventually take thems off. In the same way Microsoft created the "Wizard", a thing that would parametrically generate a working application, which you would then fill in the blanks. This made C++ accessible for the newbies. It was the training wheels. Eventually people took the wheels off, and yes would laugh at the newbies listing to one side. But the underlying Visual C++ "bicycle" was pretty good technology for the day. At the end of the day they were successful in capturing the market because they focused on the training wheels that gave the average programmer, a good "out-of-the-box" experience.

The reason PHP has taken the spotlight away from Perl is that it was designed to make generating web pages really fast and easy. The creators concentrated on this. It was a goal. In the same way that Microsoft concentrated on the "legions of average programmers", PHP focused on providing this simple, out-of-the box experience. It can be argued that this simplicity "costs you down the line", but this is the sound of one hand clapping (i.e. nothing). Very few people are going to take the time to rewrite a system in a completely different language, just to learn a few things. Again, this is a University culture idea => research, the quest and attainment of knowledge.

Competing with PHP, if this is, in fact, something that is desirable, could be done by concentrating on the "out-of-the-box" perl for the web experience. Increasingly, people are consuming things in LAMP stacks. Also note the P used to be Perl but now it is increasingly PHP (there is the newly minted acronym LAMPP). Perl, mod_perl and all the relevant Web toolkits (I'm thinking Mason is the thing to push) should be in every single LAMP distribution.

Another out-of-the-box issue, from my experience: I recently got a new Mac laptop and could not use CPAN. The problem was that this was the new Intel architecture (64 bit). The solution was, after searching for a long time, to install xcode and set ARCHFLAGS. How the heck is someone supposed to know to search for ARCHFLAGS?.

The more interesting meta question is: why was it so hard for me to find the answer to this? It surely must affect thousands of people. I think the answer has to be "culture". I looked around and found all the little details, got it working and moved on. If the culture had the goal of widespread adoption, there would be a single website that had the steps to fix this, it would come up at the top of the search page, and would have been discovered quickly after the new macs came out. Alarm bells would have been ringing.

In closing, I think Perl+Mason _may be_ far superior to PHP. I'm going to give it a shot in my pursuit for knowledge. I certainly enjoy writing Perl far more than PHP. I'm currently "performing the experiment" to see what the objective differences are.

I'd argue that it's important for Perl to mount a comeback in the web space against PHP and things like Python. I'd also argue that the comeback strategy would require realizing that the goals of making things easy for newbies to adopt, and having a superior flexible technology are not contradictory.

I've got an analogy. Maybe it's twisted. Unix is to Ubuntu as Perl is to X. Solve for X. Perhaps X = Perl, mod_perl, Mason, tutorials, community outreach, LAMP(P) stack ubiquity, and a good out-of-the-box experience. Remember, the training wheels do eventually come off (and you get to laugh at people who list to one side as they ride).

Caveat: I'm one of those "guys at Zend", and in fact work on Zend Framework. In the past I've done a ton of perl coding, but I am and have been primarily a PHP developer for the past six years.

What is said here, while it resonates to a degree, can also be said within the PHP world. There are many "unzip and go" types of PHP apps that are exactly as described here -- they just worked, but you really, really do not want to look at the source code. Besides being boring, much of it is indeed an unmaintainable mess of spaghetti.

But there are movements within the PHP community to consolidate and standardize best practices, and you can see these with organizations such as PEAR and the various PHP frameworks that have cropped up the last few years. PHP, too, can be a London Broil -- it's simply a matter of how you do the development, and the mindset you bring to it. With PHP 5, PHP now has a credible and usable object model (something that, until I saw Moose recently, actually had advantages over Perl 5), and many developers are creating enterprise-ready frameworks and applications with it. And if you were to ask most PHP developers working on a site of any size, they'll be well aware that a website is not just spitting out HTML, but involves coordinating with web services, memcached, and more. Balogna refers to the old style spaghetti code that has made PHP popular, whereas London Broil represents the new wave of frameworks and applications being developed in PHP.

This post seems primarily geared at comparing PHP to Perl for the purpose of web development, and that's the primary flaw I see here, because the two languages were designed for different things. PHP is scoped for short-lived, non-stateful requests primarily focussed on gluing together various sources and returning the result. Perl allows for long-lived, stateful requests that may or may not have input or concrete results. Sure, Perl can do the web -- but that's only one facet of its capabilities, and not the primary use case it was designed for. And on top of this, I've seen crap code in both languages; Perl has its own share of Balogna scattered around the web.

By the way, if you're interested in efforts to make creation of and use of Perl web applications easier, you may want to take a look at this interview about mod_perlite, as it addresses some similar ideas.

I don't think that anyone is seriously trying to hold either language up into a comparison with the other, such that either one would be “found wanting.”

With the possible exception of a handful of n00b's who still think that “an O’Reilly book is a recipe for a lifetime career-plan” (most of whom are rather unlikely to frequent these parts), I don't think you have any reason to fear a flame-war here. (Yawn... feels nice, doesn't it?)

As you say, PHP and Perl are both well-designed for different purposes, and Perl's scope (in practice...) is much larger. Yet, within the context of both languages, pure-magic can be done. And most of us make our living today with both.

Interesting thread here.

Monks know that this is not a “Perl vs. PHP” thread ... and, Monks know why.

Really, I think the core issue here is ... the standards of professional practice that we see in our chosen field. It runs the gamut from the seasoned pro to the tyro. And, of course, it shouldn't.

No one can seriously dispute that PHP is not a good, well-designed tool. The folks at Zend, in particular, are without question good at what they do. The problem we see, rather, is with the web-sites themselves. How rugged they prove to be; how long they last in service, especially as the business grows ... and as the personal computer continues its ever-more-rapid migration from the desktop to the shirt-pocket.

A few years from now, I think we'll see another few casualties along the computing roadside:   PHP and Ruby will have their hoods up. Java will be lumbering along with “WIDE LOAD” signs and escort-cars. COBOL(!) will still be zipping along on the nearby railroad tracks with its accustomed loads of heavy freight. And on the highway, Perl will still be doing “damn near everything.” Quickly.

There's a reason for that. And the reason is, adaptability. Because Perl consists of a fairly small but well-built core, surrounded by thousands of strongly-tested CPAN modules, it continues to have a strong life-span. Products built this way last longer.

It's a real shame that we don't have the notion of “apprentice...journeyman...master” in the software development trades. Maybe we should. Just getting a University degree is not nearly enough. (“Certifications” are truly laughable.) Maybe one of the reasons why we're grousing at PHP-junque ... why there is so much of it ... is really that “while experience is the best teacher, she runs a very expensive school.”

>> Monks know that this is not a “Perl vs. PHP” thread ... and, Monks know why.

Well one interesting question is: "Why isn't Perl used as much as PHP is for web development"? It got there first. It had the limelight. I'd argue it's technical merits better than PHP: language, CPAN, community. But look at the usage statistics for languages in the web sphere and you'll see PHP way out in front.

PHP has proven it's usefulness in the web space. But why is it being overwhelmingly chosen over Perl for this task? Maybe monks don't perceive this as a problem. I think it's kind of a shame given the head start Perl had and technical merits of the language.

On cheap/free hosts it is a pain in the ass to get the various modules you need installed.

Even worse, there is no easy way to cross compile your modules your own modules. So if your host does not give you access to a compiler, many modules are impossible to use.

There is often no easy way to see what modules are available on your hosting provider. So portability between providers is unsure.

In practice, it is easier to get PHP working and move it from place to place.

Since there are 306,127 different module distributions for template handling, can rely on your module of choice being installed on your next hosting provider?

The core of the problem: As a skilled Perl programmer, it was easier for me to learn enough PHP to get a quick site together than it was to negotiate with the hosting provider to get a decent Perl kit. How much worse would the trade-off be for someone who didn't already know Perl?


TGI says moo

I think that PHP was definitely “more approachable.” Also, it's easy to conceptualize the notion that “the right|easiest thing to do is to just mix the SQL right in there with the HTML, since all you're really doing is CRUD.”

“Easy to conceptualize,” “easy to deliver release 1.0” ... and utterly impossible to maintain as things change. Two or three years out, the app is $DEAD $BEEF. Everything's so tightly coupled together that you can't change either the presentation or the data-structure without starting over.

I'm not sure that it's really PHP's fault, though, so much as the (lack of) experience of the programmers... And I'm sure that there must be some “dazzlingly good” PHP out there. I just haven't seen any yet.

I think that PHP was definitely “more approachable.” Also, it's easy to conceptualize the notion that “the right|easiest thing to do is to just mix the SQL right in there with the HTML, since all you're really doing is CRUD.”

“Easy to conceptualize,” “easy to deliver release 1.0” ... and utterly impossible to maintain as things change. Two or three years out, the app is dead beef. I'm not sure that it's really PHP's fault, though, so much as the (lack of) experience of the programmers...

Well, I think CPAN is what most developers are jealous of when they don't get to work in Perl. The problem here seems to be one of distribution packaging.

While Python's cheeseshop is definitely no CPAN, the distutils tools provide a good starting foundation for creating a standard way for packaging and distributing Python modules and applications.

Perhaps there's a Perl equivalent (or maybe there should be if there isn't one).

PHP is really behind on pretty much everything. It's a nice toy, but is no real comparison to Perl or much of anything else.

The biggest issue that very-quickly appears, when I'm using “quick and simple” tools like PHP or Ruby, is that when you bump up against their intrinsic limitations ... a great big hole is ripped into the side of your ship and you sink straight to the bottom of the harbor.

The PHP executable, for instance, “is what it is.” Whatever you compiled into it, or more likely, what the hosting-company compiled into it. It's got “everything you'll ever need,” but when the moment inevitably comes when it doesn't... (and that moment will come...) ... you're scroo’d.

So, I think that what has been keeping Perl going for so long, in so many different applications, is precisely the fact that it isn't “quick and simple.” It's “general purpose.” And what makes it that way is CPAN. (Uhh, and Moose.) This is what gives it life-span.

The implementation decisions made with these “other” language were, of course, made quite deliberately and purposefully. But given that “the web” is changing so rapidly, I think that just a few years down the road there will be a really nice CPAN module to recompile PHP into Perl. :-)

(Oh, hell. What am I saying? This is Perl. It's already out there someplace, isn't it?)

Never heard of it mate.

(Note to self - avoid pun about Perly Kings/Queens)