lc("PHP IS KICKING PERL'S ASS.")

Some stats from indeed.com.

php programmer: $37,000
php developer: $56,000
perl developer: $74,000

Percentage of matching job postings–

PHP: < 0.9% and rising
Perl: > 1.1% and rising

lc("BUT PHP SUCKS.")

PHP is a perfectly reasonable language, is extremely facile with web work, and, like any other language, is as good as the hacker slinging it. You think wiki(pedia|media) just pulled itself out the great goatse?

lc("PERL NEEDS TO ADAPT AND EVOLVE OR ITS GOING TO DIE.") =~ s/ITS/it’s/i

Perl 5 releases are more frequent and more forward thinking than ever. Perl 6 is also on a steady release cycle. PHP won the low-rent web war, in part, admitting your only point, due to reticence in the Perl community to embrace the messy end of the WWW. Java, Ruby, Flash/Flex/AIR, and Python are more directly in competition with Perl for the mid–upper range web. Plack and Mojo and Dancer and others are opening the way back to the low-rent, one-off, quick-fix web again.

lc("PERL IS FAST GOING THE WAY OF COBOL.")

I'll enjoy the guaranteed annual salary increase then.

lc("I'M NOT HERE TO LEARN YOUR WAYS")

RLY!? UR DOIN IT RONG.

lc("MY PARADIGM IS BETTER THAN PHP")

And you’ll certainly make a million on it. Think of the embarrassment and humiliation we’ll all suffer watching you with envy in our bitter, cynical, unhelpful hearts.

lc("F*** PHP")

Study PHP. The community gets much right in many ways.

lc("ON THE OTHER HAND I CAN'T BE BOTHERED.")

In spite of the snark in my earlier reply I was giving a real answer meant to help even if the hand was a bit rough. You sound exactly like any dev reinventing templating for the first time. I’d wager 90% of the regular monks here have done a templating engine at least once and a lot of us have had to deal with some half-assed, quasi-XML, demi-perl, home-brew, file-based, legacy application code, or similar Java, and harbor the hurt to the day.

You’ve described a system that can’t be stream parsed, can’t be readily consumed by available tools, has an inflexible file-only input system, will require running eval on raw Perl, seems to have arbitrary grammar coupled with a highly limited priority system which will always be expensive to parse, and brings nothing new to the game that couldn’t easily be done in TT or Mason or the Alloy family or… And they all have documents, community, examples, tests, profiling, and a really noticeable lack of ego about how effing Earth shattering their approach to solving this well-trod problem space is.

If you would slow down and read some of the constructive, friendly replies you’ve got in the past on this topic instead of charging in here swinging a bag of insults on a stick, alternately swearing you’re done with us because we’re too dim to see your masterful insights that solve all web dev problems with perfect grace and asking for help with code you believe to be too awful to post.

The simple rules–

1. You do not talk about PerlMonks like it’s a code service.
2. You do not talk about PerlMonks like it’s a code service that can be badgered, bullied, or emotionally extorted into building your spec.
3. If someone says “troll,” invokes Godwin, or demands to have his account closed, the thread is over.
4. Only two Monks to a fight.
5. One thread at a time, fellas.
6. Posts show your code. Show what your actually ran, the errors you got, and the output you expected.
7. Threads will go on as long as long as two senior monks refuse to give in… …uh, how did that get in here?
8. Final rule: if this is your first post at PerlMonks, someone has to explain to you that it’s Perl not PERL.

lc("YOU CAN DO WHATEVER YOU WANT WITH IT")

Round-filed!

IT WILL BE INTERESTING TO SEE IF ANY OF YOU ARE CODER ENOUGH TO WRITE AN IMPLEMENTATION OF THOSE RULES WHICH IS MORE EFFICIENT THAN MINE.

It will be uninteresting to see the follow-up post. But it might be fun to write another reply.

Update: s/// bugfix from Tux++.