Slashdot Log In
Exegesis 7 Released (Perl 6 Text Formatting)
Posted by
michael
on Thu Mar 04, 2004 07:36 PM
from the folding-spindling-mutilating dept.
from the folding-spindling-mutilating dept.
chromatic writes "Perl.com has just published Exegesis 7, Damian Conway's explanation of how text formatting will work Perl 6 (and now, Perl 5, thanks to his Perl6::Form module) will work. Think of it as Perl 1 for the 21st century. Also, Parrot 0.1.0, the virtual machine for Perl 6 and several other dynamic languages, released on Leap Day -- ever wanted to program in an object oriented assembly language?"
This discussion has been archived.
No new comments can be posted.
Exegesis 7 Released (Perl 6 Text Formatting)
|
Log In/Create an Account
| Top
| 319 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I 3 Perl (Score:1)
(http://www.poptix.net/)
The best thing about Perl (Score:5, Interesting)
(http://www.cityofhope.org/microseq)
One thing that you really have to love about the people who write Perl is that they have a sense of humor. This kind of document could be extremely boring and bland, but Damian had the good sense to liven it up by using humorous examples, mostly drawn from Shakespeare. He's doing some great work, but he's also obviously having fun doing it.
Re:The best thing about Perl (Score:5, Informative)
But for something like Perl, it's all in the documentation. Here's to writers like Damian Conway not only providing summaries for new releases, but writing the original documentation!. If only it paid well!
That been said O'Reilly would sell a good deal less books if the original docos were all they should be cracked up to be. Guess it doesn't have to be that good! There's nothing like getting a new fresh O'Reilly title in the mail.
Mac desktops, OSX hints, scripts and more [67.160.223.119]
Re:The best thing about Perl (Score:5, Interesting)
(http://www.ajs.com/~ajs/)
I blame POD for this. POD [ualberta.ca] is just a simple set of markup controls you can add to a plain text document to make it easy to translate it into other documentation and markup formats. It's so simple in fact that there's really no mental hurdles to sitting down and writting the docs for your program, module, language feature, etc., and so people do! Just about every peice of code uploaded to CPAN has a full suite of documentation for every module it provides for this reason. What's more, you can type "perldoc Foo" on any system with the "Foo" module installed and get a copy of that documentation ready at your fingertips.
I even use Pod at work. it's an easy format to teach to people, and what could be simpler than writing a simple text file documenting a procedure you want people to follow. Then it's automatically turned into HTML and added to our internal Web site. Would that the rest of my job was that easy...
Re:The best thing about Perl (Score:4, Insightful)
(http://membled.com/)
$a = $b + $c;
Even if you know what + does, the semantics of the above statement are still not defined anywhere. Which of $b and $c is evaluated first, for example? (And yes, it does matter, consider tied variables.)
The fact is, Perl is defined almost entirely by its implementation - there's no way you could start with the current manual pages and write a different implementation that would be compatible with most code. There's far too much DWIM which is not clearly defined anywhere.
Re:The best thing about Perl (Score:5, Interesting)
A great combination of humour, intensity and analogies created an enthusiasm to listen and in turn learn. He even spent long hours writing applications to demonstrate principles (think virtual C intepreter with GUI).
Whats more he loved to teach, he wasnt just there to complete his hours required like most lecturers.
I wish we could find more people as talented as Damian to teach us. The world would be much smarter if we could.
I tried, but I failed (Score:1, Insightful)
I ended up giving up and learning Python instead.
Re:I tried, but I failed (Score:5, Funny)
(http://www.grub.net/blog/index.html | Last Journal: Wednesday June 27, @08:48AM)
If you like Python, check out Ruby. I've been monkeying around with it at work for small things. It's like Perl but readable.. and object oriented from the ground up.. and easy to work with.. hmm, on second thought, it's nothing like Perl.
Uh... (Score:5, Funny)
Uh... I gotta say... No.
Re:Uh... (Score:5, Funny)
(http://www.usermode.org/ | Last Journal: Tuesday April 17 2007, @09:13PM)
register cx public inherit register ax
push bx
push dx
ax::pop cx
bx.mov ax
shl bx->shr
Re:Uh... (Score:5, Informative)
(Last Journal: Sunday April 16 2006, @10:03PM)
Leaking is especially apropos, because you should be thinking about encapsulation -- keeping implementation details from leaking --, not inheritance.
I actually did a toy program or two -- very toy, class assignments -- in assembly after I knew C++, and consciously employed an Object Oriented outlook in designing the programs.
This really is easier than it might seem at first: the second biggest hurdle -- and the most important first step -- to OO design is to always think of the entities in your program as objects with responsibilities.
(The biggest hurdle is discovering -- and I use the word "discovering" intentionally, because it's a iterative process of exploring your problem domain -- where to "carve nature at the joints", or where one object ends and the next starts. Alas, a further discussion of this hurdle is beyond the scope of this comment.)
Given that you keep in mind that you're dealing with objects, and that OO requires you to do so polymorphically, -- that is, you want to be able to do the same sorts of things with objects of different sizes and shapes -- you'll quickly find that you need a level of indirection, some stand-in for the actual object, a proxy that is itself the same size and shape for every kind of different object. In C (and C++ and Java) that "same-ness" proxy is a pointer; in perl, it's a hash, which the language conveniently handles the pointing to; in assembly it's a pointer too, or given assembly's inherent weak typing, a memory address.
Just as the real first parameter to every C++ member function is the (hidden and implicit) this pointer, any object-oriented assembly is going to have to pass an object pointer to any functions called on that object. The object pointer will be the address of the actual object, and the object's state, instead of residing in numerous functions -- as you'd do in non-OO structural programming -- will reside in the object, at that pointed to memory.
Finally, and most tedious, is the need for one function called on the object to access other member functions of the object. Essentially, we need a way to determine which of several possible functions foos should be the foo called for a particular object. C++ generally implements this as an array of pointers to function, perl by means of a hash map. Implementation details are implementation details, but essentially you need to specify some ordered list of (address of) functions when the object is created. A naive (and inefficient) implementation that would look like very late binding (and weak typing) to a C++ programmer would be simply to have each object include in its state an array of address; better solution would, as usual in computer science, involve a few more levels of indirection.
The point I'm trying to make is this: Object Orientation isn't so much a property of one language or another -- although some languages support it far better than do others --, as it is a property of the way you think about the problem domain and about programming in general. It's an outlook, a mindset, a world-view, and it's maintaining that world-view, much more than worrying about the implementation details, that matters.
Good Object Oriented programmers can -- and do -- write OO code regardless of the language they're writing in. Programmers who still don't get OO will write bad, pointless OO even in languages that support OO the best. And really good programmers know when to use OO, what parts of it to use, and when not to use OO.
Me either ... (Score:5, Interesting)
The main reason being it's potential use as a generic high level "ABI" of sorts. Look at GTK/GNOME for example. The developers choose to use C as the base language, largely because it was the easiest language to create bindings for - everything can link to C. But the problem is that C only implements procedural concepts. Anything else must be crafted from hand, like gObject. So you end up reimplementing all the features of a high-level object oriented language, in C, and often this implementation isn't even as efficent as the high level language's implementation. On top of that, when create bindings for a high level language, you wrap all of these gObjects inside of a native language object, and end up with double the overhead. So what it comes down to is that you worked four times as hard, and came up with something twice as slow, just to be able to have an object oriented library that many languages can link to.
Parrot has the oportunity to be for object oriented languages, what the C ABI has become for procudural languages - a common interface for programs of different languages to communicate. Imagine having high level libraries, that can be efficiently used by python, perl, ruby, befunge. Or having scriptable applications that are not just scriptable by one language, but by anything that targets parrot.
When you add to that they fact that it will be cross-platform, and more efficent then most of these high level languages were to begin with, it's hard not to get excited.
Re:Me either ... (Score:5, Insightful)
(Last Journal: Wednesday August 25 2004, @05:55PM)
Parrot is not the first try at this "execution machine" model, and I suspect not the last one either. The only ones that survived (so far) are the ones that target a single language. Python, Java comes to mind, while mono and
At the same time it would be really exciting to see the birth of the first SUCCESSFUL cross-platform execution machine...
I predict... (Score:3, Insightful)
A guy walks into his coworker's office.... (Score:5, Funny)
of a copy of "The Matrix" screen saver.
He looks at it a minute, and realizes that the coworker
is reading it, so it can't be a screen saver.
He thinks about it a second, and then asks "Do you always
ready your email fully encrypted with PGP like that?
Decoding PGP in you head like that is _really_ impressive!".
"No," says the coworker, "that's just a Perl script I'm
working on".
Re:A guy walks into his coworker's office.... (Score:5, Insightful)
With Perl, you can make the script/program/module as beautiful as you want, or as ugly as you want. Just to contrast with Java, Java forces you to be verbose -- very verbose. People claim that it makes them productive and it leads to maintainable code, but too much verbose code can be very confusing. With Perl, you have a choice of coding style, but there is no choice with respect to verbosity in Java.
There are places where clear, concise expression is useful. The tradeoff is that the readers have to have the vocabulary to comprehend what is written. Very few people complain "Gee, that guy writes in complex language, it is unreadable." Likewise, reading well written Perl code requires some familiarity with Perl.
Regarding how things look to unfamiliar people, try to look at a screenful of the most beautiful poetry (just pick a language that you are not familiar with -- may be Chinese, some Indian language), and then look at Perl code
S
Re:A guy walks into his coworker's office.... (Score:4, Insightful)
With Perl, you can make the script/program/module as beautiful as you want, or as ugly as you want. Just to contrast with Java, Java forces you to be verbose -- very verbose. People claim that it makes them productive and it leads to maintainable code, but too much verbose code can be very confusing. With Perl, you have a choice of coding style, but there is no choice with respect to verbosity in Java.
Other than your suggestion that Java code's "verboseness" makes it confusing, what you describe is exactly how things should be.
Java is highly maintainable precisely because it doesn't employ a "there's more than one right way to do it" approach. That is why it is so suitable to distributed projects, multi-programmer projects, and in fact, why it is used in a lot of large open-source projects.
Perl is a glue language designed to be used for short programs that perform useful tasks for an individual programmer. For such purposes, archaic structures and code conventions are perfectly acceptable. Can it be used for other things? Sure it can. COBOL can. PASCAL was. Doesn't mean that it is the best tool for the job, by the way.
Maintainable code isn't produced by a desire for self-expression. It is produced by following conventions. Java platform code has been described as "self-documenting" precisely because it lacks shortcuts that create obscurity. Of course, no code is REALLY self-documenting, but Java code comes darn close.
Please note that I am not knocking Perl. I use it myself and it is very useful for the things it does well. You should not, however, compare peas and apples. Perl is not comparable to Java. The languages are designed for different purposes and their structures and means of writing source for those languages reflect those differences. Perl was designed to be a super-shell language. Java was designed to be a net-ready systems and application programming language. Different purposes make for different languages and platforms.
Have you ever wanted to... NO! I HAVEN'T! (Score:5, Funny)
Y'know, that couldn't be ANY MORE WRONG than an HTML rendering of a .GIF of a psychotic nun in a bondage outfit clubbing a baby seal to death with an Al Gore doll.
(With apologies to the denizen of the Monastery, from whom I stole the idea.)
ruby! ruby! (Score:3, Interesting)
So, I'm interested to see Perl 6 when it comes out, but I sure as hell won't be using it for anything.
Also I'm looking forward to a common runtime between the three languages so I can use Perl modules from Ruby. Now *that's* the best of all possible worlds, eh?
Finally, a good update. (Score:4, Interesting)
(Last Journal: Thursday March 04 2004, @08:03PM)
Being one who's never gone along with the best methods of coding, I've stuck with Perl for the past few years. I deem myself pretty proficient in it, and I find a new plethora of exploration available to me now that Perl6 is out.
The fact that Perl6 is now a subroutine rather than hardcoded allows me to directly stream the formatting through the test. This is immensely helpful, for it allows me to organize the code more efficiently and get more out of my hard worked code.
Sure, some parts may seem like a step back, but this new versions is much simpler to use, and has some huge advantages that all coders should get use from.
Re:Finally, a good update. (Score:5, Insightful)
I too wouldn't put perl as a "technically" best way to code ANYTHING, but it is however an intensely easy and powerful set of hacks, joined together quite well, and with a consistency that matches my own disorganised brain!.
I'm good for that. Getting something technically 'correct' in the coding world seems to me to be revolved around far more efficient use of resources and cpu speed than perl does. In my job however we have thousands of fast PCs, and only so many good coders. I go for whatever supports the coders, and for many of us that's perl
webalizer stats. thousands served monthly [67.160.223.119]
It's Not Assembly Language (Score:1, Informative)
C++ is object oriented high level assembler (Score:5, Funny)
Re:C++ is object oriented high level assembler (Score:5, Funny)
(http://www.grub.net/blog/index.html | Last Journal: Wednesday June 27, @08:48AM)
Olde Quote:
VM's (Score:2, Interesting)
Re:VM's (Score:4, Informative)
However, for what it's worth, Parrot's relationship to the JVM and the
What specifically about the JVM puts you off? Or is it the host language that bothers you?
'Weak vs. Dynamic': Type Systems (Score:5, Informative)
A weak type system will allow implicit type conversions, even those that are 'lossy' or improper. For example, converting a float to an int without requiring a cast. Or, more importantly, treating memory references (pointers) identically to integers. Pointer arithmetic is an abuse of a weak typing system.
Strong typing requires explicit casts and will throw errors where casts do not appear. Java, Lisp, Python are all strongly typed. Haskell is _really_ strongly typed. When you cast a object to type Object in Java, you are losing type information, but you are doing it _explicitly_.
C, Pascal, and Java are statically typed. Variables are created with a specific type in the code, not on demand. Python and Lisp are dynamically typed -- a variable's type is determined at run-time.
For example, in C:
int foo( int a, int b );
declares a function that returns type 'int' and takes two arguments a, b, both of types 'int'.
In Python:
def foo( a, b ):
declares a function that may or may not return a value (and whose type is known only at run-time) and takes two arguments, which may be of any type (although, internally, the program likely assumes a type).
There are some quirks in the type systems of many languages. In Java, for example, "str" + 3 doesn't have any normal meaning, but the developers have defined any operation using a string as concatenation. In Python, and in most languages, such an expression will either return an error on compilation (static) or when running (dynamic).
However, all combinations are possible and type systems are a fertile area of research.
Perl 6 is hugely ambitious, and that worries me (Score:5, Insightful)
(Last Journal: Thursday September 28 2006, @01:08PM)
So why am I worried? Well, it feels like Larry saw Microsoft's
Also, like a very impatient, immature kid on December 23, I want my Perl 6 now, damnit!
But, I trust the Perl 6 team. They're smart people. Read the newsgroups and the forums, and you'll agree. When Perl 6 and Parrot are ready for prime-time, I am pretty sure that I won't be looking over at Python and PHP and feeling guilty anymore.
Ah well, back to coding...
Agreed, this may just be too much, too late (Score:5, Insightful)
Then there are the practical issues - will Parrot be fast enough and mostly bugless in time for Perl 6 to sit on top of it? I am concerned that we will need eighteen months of point releases and we haven't even had an alpha yet. Meanwhile people are looking at Ruby, Python, Mono/C# etc.
I recommend they just wrap up whatever concepts they have now and start moving toward an alpha. If we don't see one in 2004 I think most people will have moved on.
Re:Agreed, this may just be too much, too late (Score:5, Informative)
Re:Perl 6 is hugely ambitious, and that worries me (Score:5, Interesting)
(http://devers.homeip.net:8080/blog/ | Last Journal: Tuesday April 12 2005, @08:34AM)
Nah, Parrot isn't the bottleneck. Parrot development has actually moved pretty fast: they quickly came up with a raw-functionality virtual machine, and at this point the Parrot engine seems to meet the basic runtime needs of Perl5, Perl6 [as specced out to date], Python, and PHP.
Parrot isn't done yet to be sure, but it's already complete enough that, for example, the employer of one of Parrot's main developers is already using Parrot as the runtime engine for their corporate software. [I'd get in to details, but I forget the details -- Dan Sugalski talked about it for the Boston Perl Mongers a month or two ago.] Likewise, there's already a mod_parrot Apache module under development that will allow Parrot targeted code to run, and run very quickly, while embedded in the web server. Longer term, one of the target languages for Parrot is Z-code, so that Parrot will be able to run old text games like Zork and Hitchhiker's Guide To The Galaxy -- with luck, this could lead to Parrot being the embedded virtual machine for portable game machines.
Parrot is, in other words, being actively developed, and there are big plans for it.
Parrot is hardly holding Perl6 back.
The bottleneck with Perl6 seems like the actual design work. Once Larry Wall puts out one of his Apocalypses, it never seems to be long before Damian Conway comes out with an explanation, including working code that can often be experimented with today under Perl5, with his Exegeses. There seems to be a ready pool of people eager to implement this stuff as it becomes available, it's just that the project is so *big* that it's taking a while for people to get anywhere with it in their spare time.
Yeah, but... (Score:5, Funny)
Yes. However, some nights when I drive home from work I eye a bridge abutment thinking I'd like to bury my car in it at 140mph. So I'm not certain that whether I'd like to do something is a great way to evaluate it. What's your point?
BTW, is there a simple way to disable an airbag? Isn't there supposed to be a switch someplace? Thanks.
Re:Yeah, but... (Score:4, Funny)
(Last Journal: Wednesday May 11 2005, @11:01PM)
Well, sure, it's a three-step process (and I'm sure there's MTOWTDI):
*Click* remove seatbelt.
*Clunk* open door.
*Splat* roll out.
We need an alpha in 2004 (Score:4, Insightful)
I am sure something is coming down the pike, but making a huge announcement like a major rearchitect puts a lot of developers in suspended animation - unwilling to invest more time mastering and extending the "end-of-life'd" perl 5. Many of those people are now looking at other options.
As an aside, I'm not sure where the consensus is coming from for the new language proposals - the code samples in Larry and Damian's writings are becoming more and more cryptic. I wonder if they are making perl 6 to unapproachable by new coders.
Re:We need an alpha in 2004 (Score:5, Informative)
(http://www.ajs.com/~ajs/)
Second, he posted (as you can see from the link above) a full outline of Perl 6's specifications-to-be and explained that he's been spending a lot of time on A12. That's right, he's skipping over A7 (delegated to Damian) and A8-A11 (which he'll return to later) and doing the chapter on objects. This is an important part of the language, and really did need to be covered before the rest could be fleshed out. It seems that he expects most of the rest of the spec to be about as much work as A12 is alone, and he claims that's just a few days or weeks at most away from being finished.
That said, keep in mind that the cryptic things you see on p6l are the result of reading code snippits written in a language that doesn't exist yet. Every time Larry steps in and explains things, the picture gets a bit clearer (partly because Larry is a great communicator but partly because he's quite capable of and willing to cut away a lot of noise and render some signal from its remains).
Perl 6 is, as far as I can tell a lovely evolution of Perl... it's perhaps more orders of magnitude more evolved than I would have suggested as the next step, but looking at the good work it has resulted in for Parrot, I'm not sure I'd turn back.
Python/PERL users unite! (Score:2, Interesting)
(http://www.blindmindseye.com/)
Think about the possibility. First port PyQT and wxPython to parrot. You write your GUI code with Python and byte compile it to a neutral Parrot format. You need to do complex substring matching so you write some good reusable functions that take advantage of PERL's string handling capabilities and then byte compile them. Load them into the event handling code and you've got a great hybrid.
What would be really cool would be to see Java and a form of OO BASIC ported to Parrot.
Re:Python/PERL users unite! (Score:5, Insightful)
(http://www.ods.org/)
Re:Python/PERL users unite! (Score:5, Interesting)
(http://www.ajs.com/~ajs/)
Parrot will run Python before it runs Perl, *that* should demonstrate how commited Parrot is to not just being Perl 6's back-end.
You'll be able to create a class in Python as a sub-class of a Perl 6 class which further derives from a Ruby class, and then call a method on such an object which is defined all the way up in Ruby.... no problemo. Parrot is going to change the way we choose programming languages for the tasks at hand....
Ewwwww (Score:4, Insightful)
(http://www.gamesavants.com/)
God no. It's bad enough when a high level compiler attemps to guess what you want (C++, etc)... it'd be horrid if ya had to have something supposedly machine level guess...
I did RTFA (Score:2)
(http://sharpy.xox.pl/ | Last Journal: Wednesday September 14 2005, @02:12PM)
And for those who hate Perl, it's still worth reading, for great texts used in the "text formatting examples" like a recipe for 2 doomed souls or 10 reasons why you didn't do your English Lit. homework.
Conclusion/Highlights (Score:3, Informative)
(http://shoesfullofdust.f2o.org/)
Aw geez... (Score:2)
(Last Journal: Tuesday September 25, @04:26AM)
Perl remains beautiful (Score:5, Insightful)
It's easy to forget, when using perl, just how, well, tedious, it is to work in C (let alone C++) or shell or Java or even, yes, Python.
The exegeses so far have been full of fabulous goodies to use and abuse. The main problem, as others have pointed out, is that perl6 is still largely vaporware.
OO Assembly? (Score:4, Informative)
(http://www.gidds.me.uk/)
No, but if I wanted to, I could already [sun.com], thanks.
Is text formatting relevant (Score:4, Insightful)
"Who gives a crap?"
Most the projects I've worked on for the last few years have predominately displayed text in web pages. Almost all the reports produced have been generated as HTML and then printed as necessary. The only text output done has been generally into log files, where you really don't need a lot of formatting.
While this is obviously a really great, well thought out piece of coding,
Maybe I'm just missing a huge community of people who spend most of their time looking at command lines and printing out reports in fixed width fonts.
OO assembly anyone? (Score:2)
(http://www.last.fm/user/RJ)
No.
Deja vu all over again .... (Score:1, Insightful)
Object assembler goes back to ~ 1985 (Score:1, Interesting)
See more [byte.com].
Parrot didn't configure for compile (Score:2)
use Parrot::BuildUtil;
there's no file with 'BuildUtil*' name in the source distro.
Conclusion: not ready for prime time.
OO assembly language (Score:1)
(http://mistersanity.blogspot.com/ | Last Journal: Tuesday May 29 2007, @04:42PM)
Comparing to other templating implementations (Score:2)
perl can do text/plain at last (Score:1)
(http://www.vex.net/)
Is it just my imagination or are the two tops of this article linking perls extended new plain text rendering capabilities with perl 6 and the parrot vm? Is that what Larry has been working towards all this time? Better faster plain text reports?
Ouch. (-:
Best things about Perl are... (Score:1, Interesting)
Perl6 will finally cleanup a lot of baggage to make it more competitive with newer/cleaner/easier languages (like Ruby). If done right, it will recapture the former Perl users who migrated to Python and/or Ruby.
Parrot will give us an alternative to the single-language Java VM and the multi-language Microsoft CLR. We can only hope that it leverages the mistakes and successes of both JVM and CLR to provide something that is better than both.
While it shouldn't be limited in a particular CPU, it should take reality into consideration and make it easy to aggressively optimize for AMD/Intel (98% of desktops) and IBM PPC97x (Macs, XBox 2, Playstation 3, future IBM Linux workstations).
Exegesis (Score:2)
You couldn't pick a better name for such a utility.
Object Oriented Assembly does/did exist (Score:3, Interesting)
(Last Journal: Monday November 07 2005, @04:35AM)
OOPs in TASM [mujweb.cz]
Unicode operators! (Score:1)
(http://www.rotfl.com.au/)
Sure, lets add operators that can't even by !@#$% typed. Yes, you can add :is ASCII(!@#$%) but that kind of misses the point.
Not only does Larry get the colon, he gets the entire unicode set!
Why Perl reports are *so* important ? (Score:3, Informative)
Furthermore, 'reporting' is a not a feature of a programming language. The same report package could be done with C++, for example. Will Perl 6 bring something *really new* in the programming languages department ?
Here's some perl for you to look at (Score:1, Funny)
($e,$x,$y,$v,@m)=(shift,0,0,1,1
@p=(1,0);for(@s){push@m,$d
y,$l[$y][$x]=($e=>10?$v<10?'00':$v<100?0:'':
warn"@$_\n"for@l
Re:Parrot progress (Score:2)
(http://www.pobox.com/~meta/ | Last Journal: Sunday February 29 2004, @09:19AM)
There's this CPU that has clearly been designed by a complete bunch of morons... can you believe the documentation listing the opcodes is 566 pages long [intel.com]?
Obviously this x86 thing will perpetually be 6 months from doing anything useful.
Re:Meanwhile PHP surges ahead (Score:2, Interesting)
Judging by the number of sites that depend heavily on Perl I can assure you that it's not going to be sidelined soon.
It's true that PHP is a fantastic language for small sites. Mod_perl is a hog when it comes to memory but memory is cheap and mod_perl is tried and tested. There's a reason slashdot uses mod_perl to power its site.
Re:Meanwhile PHP surges ahead (Score:1)