Slashdot Mirror

PHP is a bit easier for creating web pages. It automates some of the things Perl makes you do for yourself {like grabbing form variables and function parameters} and you don't have to remember to send a MIME type, but

Pick HTML::Mason for doing this and much more with mod_perl and apache

Not to be a troll but I thought this would be an excellent opportunity to mention Mason for those of you who use PHP but are more proficient in Perl. All my previous web development has been performed in PHP, however, recently I've started to use Mason/Perl.

Mason/Perl provides similar functionality as PHP using in-line constructs such as "<%perl> $perl = goes($here); </%perl>", "% $perl = goes($here);", "<% $variable %>", and "<& function.html &>". Its modularity has allowed me to create a dynamic website coded completely in Perl! It provides all the power of Perl, combined with the convenience of in-line PHP, and adds a new level of object-oriented modularity.

Not that I didn't enjoy PHP, it's just that I always felt like I was coding with one hand tied behind my back. If you like Perl, check out Mason.

Michael.

Not to be a troll but I thought this would be an excellent opportunity to mention Mason for those of you who use PHP but are more proficient in Perl. All my previous web development has been performed in PHP, however, recently I've started to use Mason/Perl.

Mason/Perl provides similar functionality as PHP using in-line constructs such as "<%perl> $perl = goes($here); </%perl>", "% $perl = goes($here);", "<% $variable %>", and "<& function.html &>". Its modularity has allowed me to create a dynamic website coded completely in Perl! It provides all the power of Perl, combined with the convenience of in-line PHP, and adds a new level of object-oriented modularity.

Not that I didn't enjoy PHP, it's just that I always felt like I was coding with one hand tied behind my back. If you like Perl, check out Mason.

Michael.

but Mason kicks ass

working link

To be fair, I'm young as well (I'm 20). Minus a year for college, I've been working as a programmer at my company since the summer of 2000 (with a lot of recreational programming before that).

For the last year, I've been working as a "Software Analyst". I get bug reports that our setup folks can't solve and I solve them. This often requires a lot of code hunting. We've got everything from extremely junky Fortran 77 (no whitespace, no variable names over 6 characters -- and Fortran at that) for our legacy app, and some CGI programs written in spaghetti-code C (with a good mix of HTML templating and javascript thrown in)! Even better, this all runs on HP-UX. Needless to say, I get plenty of practice fielding bad code and weird issues. =)

Our development team is comprised of 12 developers total, and only in the last 4 years has it grown past a four man team. The company is now around 50 heads total, and a QA department is in sight (the Software Analysts will eventually be QA).

Anyway, our newer products are all based on open source tools. PostgreSQL, Apache, Linux, Perl, Mason, ORBit, etc. The source code, mailing lists, IRC, etc. and the open attitude have made things a breeze, not to mention these tools have saved us a very large sum of money in licensing costs.

This is quite possibly the exception to the rule, I have no problem admitting that. Somehow, though, from what I hear of other companies, this isn't all too uncommon.

Cheers

First the cheap shot :) mason.org is some guy's homepage and has nothing to do with Mason.

More substantially, however, your comparison is ridiculous. Mason is not a programming language. I could say "Perl? You've got to be kidding! BinaryCloud (or ezContentManager or Roadsend Sitemanager etc) is a better solution." That, however, is comparing apples to oranges: perl is a language, the application server/CMS/apis that I mentioned happen to be implemented in php, but they are not languages...

Even if I take your comparison at face value though, it immediately falls down. PHP, you tell me, is the epitome of mixing content and presentation while Mason is the way to truth and light. Yet when i go to the Mason home page the first thing I see trumpeted is that Mason allows you to (drumroll please) EMBED Perl CODE IN YOUR HTML!!!

Pardon my Irony, but this is too much. I write php code for a living and use templates religiously so as to keep the presentation seperated from the content as much as possible. PHP, like most web-oriented languages out there, allows for a quick and dirty code-and-html-all-mixed-together style. But nobody is forcing you to use it. If you want to be a language bigot, at least be cool and learn Lisp. But don't compare my language of choice to your application framework and say that's a valid comparison. And don't stereotype my code based on the way you may choose to use the language...

-regards
Simeon

perl.apache.org. This is the mod_perl site, nice docs, faqs, mailing lists and so.

masonhq.com This is the mason web site. Very well documented. There are also Mason Books

In addition mod_perl won't work well with apache2, it's still beta, so you better try with apache-1.3

perl.apache.org. This is the mod_perl site, nice docs, faqs, mailing lists and so.

masonhq.com This is the mason web site. Very well documented. There are also Mason Books

In addition mod_perl won't work well with apache2, it's still beta, so you better try with apache-1.3

If you are comfortable with Perl then one way around the "stuff HTML into a variable and print it" problem is to use the MASON system. This allows you to embed Perl inside an HTML page rather than trying to print HTML from within Perl. One positive side effect of this role-reversal is that all static HTML remains literal text in the source code so that you can do page layout using wysiwyg editors and can structure your code so that opening and closing tags are easily identifiable and balanced.

Visit the site if you want more details on what's good about it. In a nutshell:

• Much easier seperation of presentation and logic
• Easy templating and page filtering
• Excellent but easy component caching (great for those slashdottings :-)
• It's perl

Lastly, if you want to start from scratch, not having experience in either, can I humbly suggest you start with perl rather than PHP. You'll regret having to unlearn all the evil habits you get into once you start travelling the PHP road.

Haven't seen mention of this yet... HTML::Mason is one of a few embedded Perl solutions that operates very similar to PHP/ASP/JSP, etc.

To take your above example, rewritten in HTML::Mason would look like this:

% if ( something ) {
Something was selected
% } else {
Something was not selected
% }

HTML::Mason also takes care of the variable collection. All arguments are put into %ARGS, in addition to putting them into declared variables:

<%args>
$id => 0
$name
</%args>

Also, general printing of variables is easy, too:

Hello, <% $name %>!

In general, a very decent system that addresses what you thought Perl couldn't do. Of course, this is just the tip of the iceberg for Mason. I won't even go into its inheritance model, it's default handlers, autohandlers, component model... that's worthy of an entire O'Reilly Book. =)

</perl-plug focus="HTML::Mason">
In the end, use the tool you're more comfortable with. If you like canned scripts (mail submit forms, BBSes, etc), PHP has a ton of them. If you want to code more of it yourself, Perl's CPAN is extensive. JSP for... uh, something, I'm sure. And if you're masochistic, there's ASP. ;P

-Ducky

Mason: http://www.masonhq.com/

An example of one of these content management systems would be mason, http://www.masonhq.com, and mason apps such as Fuse CMS and Bricolage. I find Mason to be just as powerful as multi-thousand dollar applications such as StoryServer

Of the little work I've done in PHP (~two weeks worth), I personally don't care for it, but everyone has their own style. No bashing from me.

What I will say: Mason, baby, Mason.

The Mason enviroment offers a heck of a lot that 'bare' perl doesn't. I use it for all my websites nowadays.

You said you have perl programmers so you might want to look at Mason. I don't know if it does what you need but I haven't seen anyone mention it yet, so check it out.

You left out Mason, which could very well be a solution for the OP.

I agree, mod_perl + HTML::Mason is a win for developing big sites.

My prefered solution is actually HTML::Mason, which gives simple embedding of perl code & components into webpages. However, CGI.pm and Apache::Registery is the most portable solution, as it gives a program that can be run on both CGI & mod_perl enabled webservers.

What extra hassle? It took me 15 minutes.

Specially Mason.

Mmmm. I write large-scale web applications for a living, and I do it in Perl. By large-scale, I mean sites that are expected to support hundreds of thousands of page-views per day, serve hundreds of thousands of distinct users per month, and collate hundreds of thousands of distinct chunks of content into dynamic pages.

My company is a high-end development shop. We generally bid on projects that will take six to nine months to complete, and we only do jobs for clients who understand how we work and why. Part of our approach is to use very small teams of extremely experienced web developers. We usually deploy four programmers on a project. Other companies that bid against us sometimes use several times that many people on a single development team. Another part of our approach is to build everything on top of our open-source development framework. That sometimes used to be a tough sell ("what, give software away for free, heaven forfend") but these days, most customers are pretty receptive to the twin "more eyeballs means better code" and "you're not locked into our closed, proprietary product" arguments.

We also generally build small clusters of dual-processor Athlon or PIII machines, whereas our Java- (Oracle-, IBM -, BEA-, etc) wielding colleagues often specify absurdly-expensive hardware.

Perl is flexible, complete, performs relatively well and has an extroardinary base of skilled developers and re-usable components (CPAN). We couldn't work as quickly or write code that is as concise and maintainable using any other currently-available language/approach. Most of the lines of code that we write actually go into Perl modules, with HTML::Mason templates handling the dynamic web-page generation. We can push Mason out of the way and use straight mod_perl for small, defined tasks. And we can easily integrate C code into our Perl frameworks in places where performance is really, really critical (though those places are rare, as when push comes to shove, one is almost always waiting on the database).

There are lots of things that aren't "right" about web development. The package that results from gluing HTML and program logic together in a stateless execution environment is sometimes a little lumpy, and unavoidably so. There's no magic bullet toolkit, and (as with other specialized programming arenas, like graphics or embedded systems) a lot of hard-won, domain-specific knowledge goes into the development of a fast, reliable, maintainable web app.

The Perl/Apache/Mason combination that we use is far from perfect. But it's better -- for us -- than any of the alternatives.

I really like Java, and have written big systems in that language, too. If for some reason I had to manage a very large team of programmers, or had to manage a team with a large percentage of less-experienced programmers, I would use a Java-based solution. Java is a more rigid language than Perl, and the structure that the language provides would be a useful management tool in those contexts. But for my small teams of skilled hackers, Perl is more productive. (We have an extensive, evolved, self-imposed "structure," so we don't need the language to impose one on us -- in fact, it gets in the way.)

I would never use PHP for the kind of work we do. PHP just isn't the kind of powerful, flexible, complete environment that Perl is.

Zope and Python are really neat. I'm a fan of the work that folks on that side of the fence are doing. But Python+Zope don't offer us anything new that Perl+Mason+Comma don't. I also like Perl more than Python (which is a subjective preference), and think that the Perl development environment is more mature (which is a subjective judgment).

So don't listen to the folks who tell you to dump Perl. You should certainly consider all of your options and make an informed decision about core tools, but anyone who thinks that Perl is just a "scripting" language, or that it doesn't scale, hasn't been paying attention.

To finish this up with a little more specific advice to the original poster: You mentioned "150+ perl CGIs" in your question. You should consider moving away from the CGI model, if possible. Take a look at HTML::Mason, which is a very good embedded-perl environment. You can build solid, consistent application layers using Mason as a base. Also, I couldn't agree more with the folks recommending writing perl modules and requiring complete regression tests for each module. There are lots of ways to write tests, but in perl-land one of the easiest is to simply make a t/ directory down your module tree, write a bunch of scripts in that directory named <some-test>.t that print out a series of "ok <n>\n" lines, and use make test or Test::Harness::runtests() to invoke them.

It was particularly interesting to me since we at Goofball.com went through the exact same process a while back ourselves. We initially were a free site and at our peek were doing close to a million pageviews a day - not including the Apache requests for video downloads (that amount to like 500 GB per month in bandwidth). We were actually leasing 7 Linux boxes (3 running HTML::Mason dynamic content servers, 3 plain Apache image servers, and a MySQL DB server) and paying through the nose for them due to the bandwidth. However, back in the good old days of the CPM advertising model, we were making plenty to afford the costs.

We were of course f----d when the "new economy" came to bear and we suddenly had no income for close to a year. Good thing we saved all that money we made on ad banners. We were eventaully forced to either close it all down or move to a payment model. We polled our viewers and decided to try the payment model based on their feedback.

The site is now 80% pay / 20% free. We're not just charging for access to specfic areas of content, but for the actual utility provided for by the site's various personalization services. We also decided that micropayment were not feasible. Can you imagine the headache of tracking pennies for pageviews and the associated overhead of dealing with people's questions/complaints about charges to their credit cards? A yearly fee of $19.95 (or a nickel a day) was the way we went and you know what - it actually saved the site.

Granted, traffic is at 10% of what it was, but that allowed us to drop off a few machines from the server farm and thus reduce costs further - keeping us slightly in the black each month.

HTML::Mason is the key to the site's success for sure. We can provide dynamic content on the fly pulled from the database, but a key element of the delivery machanism is Mason's built in caching. Only the first page request for a given URL (that uses the DB) actually requests the data from the database - subsequent requests are pulled from a GDBM replica of the DB's content that was cached by the first request. Mason also provides us with the ability to maintain a persistent DB connection during the life of the Apache daemon. Additionally, the same Apache/mod_perl/Mason binary also listens for requests on port 80 and 443 for SSL requests. All credit card transactions are handled through a Mason enabled API gateway. All of our back-end tools are HTML::Mason as well.

I didn't really get the part about "needing Java/JSP" in the Salon.com story. It sounded to me more like the author was not really in touch with the particulars of the technology at hand and was just repating what reasons he may have been given by the development team (who may have been looking to learn something new for the sake of it). I just came from a job where a decision was made to "go with a Java solution" simply because of the name of the programming language more than any other factor. I have nothing againsts Java believe me, but I'm so tired of buzzwords being used to influence decisions that are actually in dire need of pure business and software logic instead.

I'd encourage everyone - if they haven't already - to have a look at HTML::Mason. And also, for a good diversion, take a look at Goofball.com.

• apache module
• web templating system

I strongly suggest you look at Mason. It is a Perl equivalent of ASP or PHP. It also has several very useful tricks such as templating and caching. While it traditionally works with mod_perl under Apache, some people have got it to fly under CGI.

The author of that article obviously does not know about Apache mod_perl (http://perl.apache.org/), HTML::Mason (http://www.masonhq.com/), or Embperl (http://perl.apache.org/embperl/).

Those provide a PHP or ASP like templating system with full access to the Apache API and all of full fledged Perl (and thus the CPAN modules). It's way better than PHP!

Anything that can be done in PHP could be done with either of these systems. I think it would be worth doing to port a lot of that fancy PHP HTML magic over to either HTML::Mason or Embperl. (May the better engineered solution win!)

There is, additionally, an emacs extension called "mmm-mode" (found via the HTML::Mason site) that makes psgml-html mode and cperl-mode co-exist! The perl parts are in cperl-mode, and the HTML parts are in HTML mode. It's really cool!

I have the ability to search the database for a particular tune, save playlists, save favorites, recommend titles to others, etc. It's pretty stable, so if you're interested, pop me an email here: dcarnage at spookyworld.dnsalias.com.

-bp

Mason is pretty nice, I checked it out when it was just getting started. They've done a lot since then.

The high-level features are outlined on their site. Among them are: caching of HTML and data, use of the Perl debugger, and staging vs. production execution modes.

The CPAN repository is chock full of mind-bogglingly useful code, so it's nice to see more tools coming of age that allow you to take advantage of all of that through the Web. mod_perl is very nice, but for some tasks, it's just too cumbersome to work at that level. Mason nicely abstracts that away.

I'm not sure if the performance is as good as some other soutions, but I've written some pretty big, fast sites on it and I know others have. It runs under mod_perl, so that makes it a bit faster, but does limit you to apache, I guess, in case that matters.

It's a pretty good way to make compnent-based web applications and lets you seperate the HTML stuff from the PERL a little more than some solutions. This means that the artsy people can hack some components and the coders can hack others.

The component based aspects of it make it my tool of choice when I'm writing a set of pages which have a lot of little seperate boxes, like a portal or something. It makes it a lot easier to keep track of what pieces of the pages are coming from which pieces of code.

Hope it helps.

It won't win any "Hello, World" benchmark contests (and, therefore, is probably unsuited for your described needs), but Mason is another "embedded perl" candidate, which is well-suited for robust application development.

er, module: HTML::Mason

http://www.masonhq.com

All the goodness of Perl, embedded in your HTML.

<cynic>
But of course, they'll never get advertising dollars from this...
</cynic>

If you need (Perl) templating, have a look at Mason, http://www.masonhq.com. It's very fast (runs under mod_perl) and unbelievably flexible.

Chris

My perl CGI scripts -> your ASP (VB) scripts

You would be better off with something like Mason for a better analogy. It's like ASP on steroids. It works with "components" that allow you to split up your pages into reusable blocks and provides great mechanisms for templating and caching. It beats PHP hands down too, but then it is based on Perl! :)

I looked at php briefly a while back, and it looked like it was kind of like Active Server Pages, but the language was really primitive. I then ran across Mason, which is an ASP-like project except it uses Perl as the embedded language. I've used it in a couple of projects, and it's really, really cool.

I guess my question is why would you want to use PHP with such a primitive embedded language, when you can have full-blown Perl?

--

I asked myself the same question, but in the reverse direction. I'm not a professional web developer, but I do alot of web development in my job. I had been using PHP, and was looking at learning Perl. Perl has since become so useful to me for doing miscellaneous things that I wanted to use it for web development as well -- why bother remembering two sets of syntax for doing essentially the same thing? Then I discovered Mason, which lets you embed Perl into web pages just like PHP does (there are other ways of doing this too). That sealed the deal; I haven't touched PHP in months.

Here are a few technologies to consider (using Perl):

• Apache::ASP
• Embperl
• Mason
• Template::Toolkit

There are many more, but these are the ones I would consider for people who already know ASP. Apache::ASP looks like a very mature and solid product, as does Embperl. I would trust either of those.

Also, is there a business need to convert the existing ASP code to work with the new platform? If so, you might consider looking into ASP2PHP, if you're already considering PHP. The author says that it will convert most of the code to PHP.

Also, I can tell you that there is (sort of) a project in the works right now to build an ASP to Apache::ASP/Perl converter and/or interpreter. To follow this, just keep an eye on the mod_perl mailing list at one of the archive locations. It will probably be called VBScript::Parser. See http://perl.apache.org/#maillists for a list of searchable archives. Most of them are updated weekly.

Also, I've noticed some comments along the lines of "JSP is without a doubt the best/fastest technology out there". Uh... Where is your proof on this? I have a suggestion, go to the mod_perl mailing list and make this statement. See where it gets you. According to them, "It's widely accepted that server side Java solutions such as JServ, JSP and JRUN, are far slower then mod_perl solutions" (http://perl. apache.org/perl_myth.html#Java_does_away_with_the_ need_for).

That being said, I think that JSP is a fine technology, and there is nothing wrong with using it. I'm about to embark on a project myself using JSP. Just don't try to tell people it's the "Holy Grail". That's more than arguable.

....you might like to look at Mason which builds on mod_perl to give you Perl in a ASP/PHP style. It's strength is that it has a strong component-based system which supports ideas such as automatic templating of pages (thus avoiding "include header" and "include footer" on every page).

Think of what RedHat, Caldera, or whoever could do with a single package now. RedHat 7.0, webserver addition: includes your end to end large scale site solution, web services by Apache, Content Management by GO.com. With a good ecommerce suite, that could be one hell of a package if it all came preconfigured.

The go.com stuff provides you with the tools to build a website - it'll never be an out of the box solution.

CMP released their perl-based CMS a while back - Mason. It looks very nice, it's used on some high-volume sites, and has a feature site suprisingly similar to Vignette's StoryServer (which is TCL-based, and grew out of C|Net).

None of which will do anything magical out of the box.

Inside.com recently had a decent article about CMS pros and cons, but I can't find it. Anyone got the URL?

...j

Yes, I use this and it's great. It provides many features above and beyond "code inside you HTML" model. These include a coherent (now OO based) component structure, data caching, page templating, a previewer, and even a content management system a la Zope (although I haven't used this myself, and I think it's still experimental). These feature definitely put it towards the top of the pile. If more service providers gave this as an options I'd never touch PHP again, version 4 or no. And don't be put off by the sub-1.0 version, it's being used in a lot of production systems already, including where I work. You can find out more at Mason HQ.

If you want the power of Perl, that you can embed into your HTML documents, Mason is wonderful. The component design works wonderfully and cuts hours off your design and implementation time over straight CGI.

A couple of other strengths not previously mentioned:

• Mason does an excellent job of allowing you to embed your code in a way that does not mess up things for designers / non technical folks.
• Components encourage a write once, use many attitude. I can't stress enough how much time this saves in the long run.
• Open source. Built upon an open source language (Perl) for that "get under the hood" feel :-)
• Handlers give you the ability to apply global behaviour to pages etc. Also gives you a level of control that you won't find with other languages.
• Much, much more...

I'm surprised noone has mentioned mason.

When I was looking at PHP, all I could
think was:=
"What a sorry language. It's a cheap perl
wannabe."

So, I went on looking for a way to embed perl,
such that it would be as easy to embed as
PHP.

Mason http://www.masonhq.com was the solution.

You can write perl code embedded in HTML just as
easy as you can write PHP; but you get
a real language.

Also, mason has an amazingly powerful include
and functions capability with its components.

PHP seems to be currently developed to the level
that perl was at perl4. It still has seperate
functions for each type of database, limited regular expressions, etc.

Also, I wonder when PHP will have something as developed/complete as CPAN?

Dude, I've gotta say that HTML::Mason is the greatest thing I've ever seen. My goodness.

If you're unfamiliar with it, here's the idea: It's similar to embed_perl but more powerful. You create "components" which are perl, or html, or both. Plus you can do the nifty stuff that mod_perl allows you to do...like creating a default handler and using the filename given as an argument to it.

Check out www.masonhq.com for more info on it.

The best way I found for creating multilingual web sites is with apache + mod_perl + HTML::Mason

1. First, this module helps you a lot to separate content from formatting.
2. Next you put people write content and have a file per language: index_es.html index_uk.html
3. Then when index.html is requested, the default handler reads the browser language preferences and loads the most appropiate.

You might want to try HTML::Mason (MasonHQ) it hasn't got all of Zope's features, but it is less complex, and easier to learn (especially when you know Perl).

1. Php Pros:
   1. Easy to learn. Once Apache is configured with Php, it is seductively easy to write code.
   2. The Db connection pooling comes in handy.
   Cons:
   1. It is yet another language (I mean, I already know perl, right? Why do I have to learn another language?).
   2. Also, you tend to design page by page. it does not have a great library system to use. It has lots of code snippets you can copy.
   Notable sites: Sourceforge.net, and persiankitty.com (reputed to be the yahoo of porn))
2. mod_perl: This beast can be used in several ways. If you use it with Apache::Registry, y use Php,ou almost are doing a disservice to yourself. The three ways of using it are:
   1. embperl: Looks like Php style of embedding. Comes preconfigured with DBI and friends. But, too cumbersome to programs. It also does not encourage component programming. It provides the substrate for you to build other features you might like.
   2. mason: Has cool component features. Has neat features such as caching with intesting way of managing it, and autohandlers. Looks ideal for the publishing world, where it evolved. On the cons side, not too many components.
   3. Apache::ASP: Not used it much.
   Notable sites: dejanews uses embperl. techweb, stamps.com use mason.
3. Zope: Too different from others. The strongest suite is the built-in authorization systems and web based management system. You can program at embedded HTML level called DTML, or you can write python classes. There are several prebuild modules that run out of the box. As long as the prebuilt modules serve you well, you can go ahead and use zope. Otherwise, be prepared for a long learning curve. It almost looks black magic to me.

   As an aside, python has the weirdest variable scoping and declaration rules. I ought to know, I have a PhD in programming languages.

4. ACS: ACS is entirely different from others. It is not a language like Php, it is not a webserver like APache, it is not a app server like zope. What it is one man' use Php,s vision and experience about community web sites distilled into a toolkit. It is a datamodel, it is a set of practices, and a set of programs. It happens to use TCL, Oracle, and Unix. But that is almost besides the point.

   The biggest selling points of ACS for me are:

   1. The documentation. Quite possibly the best documented system. I can take an average joe out of the street and train him to use ACS in a systematic way in no time.
   2. The Data model. I would expect to pay in hundreds of thousands of dollars for such a datamodel. It constantly amazes me to find the little details that I needed in those datamodel.
   3. Best practices to run a website. How to harden a Unix system and set up the services so that you can sleep peacefully.
   The negative points are:
   1. Alas, it requires Oracle. I just learnt the existence of ACS/pg and I am rejoicing!
   2. Not too wide spread usage. I expect this situation would change. Look at this way. I tried building a community web site. It took me untold hours to gather all the snippets of information for a Php based site. It took me no time at all to build it using ACS. I would use ACS for a community based website over any other toolkit anyday.
   3. No good enough template mechanism. Fortunately, ADP in AOLServer is changing that.
   So, in conclusion, php and modperl and zope vs ACS is not a right question. You can implement ACS in php, and I frankly hope somebody does to save lot of human misery and suffering.

   Rama Kanneganti

1. Can pick and choose the "best of" Perl.
   
2. Some odd Perl tics (e.g. bareword IO handles) can be dropped.
   
3. Byte and native compilation of modules and programs would be a primary goal. I won't be happy with Perl byte-compilation until everything in the library can be byte-compiled and used from non-byte-compiled programs. But, there are some very compelling reasons not to re-tool Perl's core to allow for this (it would break too much).
   

There are lots of ways to use Perl effectively to build and maintain sites. I used modules and mop_perl for my Aliens, Aliens, Aliens site. Most of the functionality comes from a single module which is used by various scripts which access particular tables.

However, if I had to build it again, I would have gone with HTML::Mason, which is a very powerful embedded perl system, like PHP, Cold Fusion, ASP, Zope, etc. It is open source and very nice if you already know Perl. If you don't, wouldn't Cold Fusion be the easiest embedded HTML language to use? Consider that Allaire is close to release CF for Linux. 8-)

In the end, any system which helps you the programmer separate form from functionality is the tool to use. The days of hard coding perl scripts to generate HTML are over, I hope.

There are lots of models one can set up for distributing independent music, and obviously the models are really the issue here, not the file format. I run an mp3 site (www.mirrormusic.com) that has a totally different model, at least for now: we're not _selling_ any mp3s, we simply distribute them. Artists upload for free, listeners download for free. The only people paying anything are us, who pay to have the site hosted. We're not selling ad space either (yet, anyway).

We plan to offer artists a way to charge for their music if they want to, but so far nobody's really asked for that kind of service. People just seem to want distribution.

One interesting thing about the site (we do this just because it's interesting) is that we impose no genres on the songs. Songs are associated with each other by comparing various people's ratings of various songs to come up with correlations between songs.

Also, the technology we're using is pretty fun - Apache, mod_perl, HTML::Mason, CVS - the stuff I like.