Re: use CGI and die;

OK, I'll bite too:

1. The internals are a mess

Do you have any idea WHY the internals are "messy"? CGI.pm is arguably the most important Perl module ever. It ships with the core and is used by tens, maybe thousands of users. Which means that it is worth optimizing. To Death. Licoln spent lots of time and effort making it as fast as possible. For you and I it means that CGI.pm is fast. For him it means bearing the cost of a harder-to-maintain module, in which he threw away a lot of the rules that let you write clean code. So be happy he was ready to do this and accept the fact that non-premature optimization leads to non-trivial code.

3. It should only be used for basic CGI tasks, such as parsing params and handling cookies. HTML generation is right out.

This is true for most "serious" projects where you have the time to write proper templates, but believe me, for lots of "quick hacks" the fact that the parameter parsing and the HTML generation are integrated is pretty useful. It lets you write quickly a debug interface to a DB, or a Web interface to a command line tools.

So you are of course entitled to use an other module for your CGI tasks, but please do not think that CGI.pm is not useful and that "it's time has passed". It is still the best module people who start doing CGI can use.

Comment on Re: use CGI and die;

Replies are listed 'Best First'.
Re^2: use CGI and die; by Aristotle (Chancellor) on Jun 10, 2003 at 23:02 UTC
CGI::Simple is twice as fast as CGI. Makeshifts last the longest.	[reply]
Re: Re: use CGI and die; by perrin (Chancellor) on Jun 10, 2003 at 20:47 UTC
As fast as possible? I don't think that was a design goal for CGI.pm. The alternatives mentioned here are generally faster. CGI.pm is a mess because it does too much and hasn't had a good refactoring. Lincoln himself has said as much in the intro to his book, among other places.	[reply]
Re: Re: use CGI and die; by mirod (Canon) on Jun 11, 2003 at 14:05 UTC
I agree with all of these comments: CGI itself is slow, CGI.pm probably lacks from an initial design that tried to cram too much features in a single module, and it is possible to write a much faster module by leaving out the HTML generation parts of CGI.pm. This does not detract from my initial point though: sometimes during the life of the module (I would guess around version 2.0, it's hard to tell from the Changes file) Lincoln started optimizing it, which lead to the current code. In short the code is not hairy because the author can't code properly, it is hairy because the author knows what he is doing and he does hairy things in order to provide its large user-base with as much speed as possible, while staying backward compatible with older versions (how's that for short! ;--). I would add that an other reason to use a module is the support it gets from its author. In this case it has been really good, just look at the Changes list. I really appreciate the fact that CGI.pm generate conformant XHTML for example.	[reply]
Re: Re: use CGI and die; by hardburn (Abbot) on Jun 11, 2003 at 13:41 UTC
Which means that it is worth optimizing. To Death. I have a hard time swallowing that. In a regular CGI, the start-up time to fork off a new interpreter and load your program is going to be the limiting factor for almost any CGI out there. You would have to be running massive numbers of input params before that becomes the limiting factor. If you're running mod_perl, things are different. But in that case, Apache::Request claims to be faster (I haven't looked at the actual benchmarks, so I'll take their word for it for the moment). ---- I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident. -- Schemer Note: All code is untested, unless otherwise stated	[reply]