|
in reply to Tao Perl Ching - The Scripture of the Way of Perl
Refusal to use CGI.pm leads to bad code.
Thanks.
I think CGI.pm is a big, ugly monster that should only be used when needed, and even then only for what this module does more than others. There's a lot in its source that makes me think Mr Stein never really bothered to learn (modern) Perl, but the easiest to find and refer to weirdness is "/gso". Apart from the somewhat weird code, CGI.pm is huge, inefficient and does things that shouldn't be in a CGI module, like generate HTML (HTML exists outside CGI, CGI can be useful without HTML. They have no close relationship).
Fortunately, there are CGI::Lite, CGI::Simple, and others. The latter unfortunately is interface-wise compatible with CGI; and I don't like that interface much.
I refuse to use CGI.pm in almost every situation. Does that make my code bad?
|
Re^2: Tao Perl Ching - The Scripture of the Way of Perl
by Errto (Vicar) on Dec 18, 2004 at 01:25 UTC
|
I have not studied CGI.pm in great enough depth to evaluate your crticisms, though they seem legitimate. However, what I have seen a lot of in my time here (including two years lurking before signing up) is a long stream of Monks who were unaware of CGI.pm or thought they didn't need it, and instead believed incorrectly that they could parse query strings, interpret application/x-www-form-urlencoded and multipart/form-data POST submissions, and parse or create cookies on their own using only regexes and Perl's builtin operators. These things can be done, but doing them right is harder than these people realized. There are a few problems with this:
- As a general matter, application developers should not have to worry about the implementation details of the protocols and calling conventions they use. This is what APIs are for.
- Failing to properly treat these kinds of inputs can likely lead to security problems.
- All developers should learn the habit of looking whether the problem they're trying to solve has been solved before in a way that they can reuse. People who try to read web forms or cookies by hand are likely not to be following this rule in other regards as well. This is Laziness in the good sense.
So if the issue is that people are using the wrong module, you may be right. But the bigger issue is people who are unaware of/refuse to use the excellent modules at their disposal.
| [reply] |
|
|
You are absolutely right. However, the root post explicitly mentioned "CGI.pm", and not "the excellent modules at their disposal", and my rant is about just that: CGI.pm has a status it (IMO) no longer deserves.
| [reply] |
Re^2: Tao Perl Ching - The Scripture of the Way of Perl
by jryan (Vicar) on Dec 18, 2004 at 01:43 UTC
|
There's a lot in its source that makes me think Mr Stein never really bothered to learn (modern) Perl, but the easiest to find and refer to weirdness is "/gso"
Which, conveniently, occurs right next to my favorite line in CGI.pm, 2124:
# hack to work around earlier hacks
That said, my first reaction to the root node was: "Great. Another Soccer-Mom Node." Honestly, I've been a regular at this site for almost 3 and a half years, and really-syrupy-sermony still bothers me. From the "COME BROTHERS, LETS BASK IN THE GLORIOUS LIGHT THAT IS PERL!" style nodes to the "HUGE PEDANTIC NODE WITH A CONTROVERSIAL TITLE THAT IS ACTUALLY ABOUT AN ISSUE THAT IS OBVIOUS AND YOU PROBABLY KNOW ABOUT ANYWAY" style, I still can't keep myself from rolling my eyes and Crl-W-ing my browser tab about a paragraph into the node. The node might even have some sort of topic I might have been interested in reading otherwise, but the tone completely drives me off before I even get that far. I wonder: is it because this website has "Monastery" in the name? Would these same nodes have been written if we were http://www.perlclub.com, The Perl Clubhouse? Anyways, I needed to get that off my chest.
At any rate, who uses CGI these days anyway? ;)
| [reply]
[d/l]
[select] |
|
|
I decided to post this node for a few reasons. Firstly, there have been a number of nodes talking about how Perl relates to other pursuits -- many of which are considered noble or philosophical. Throughout my life and career, I have found that far too much emphasis is placed on "this new, insightful way of thinking". So, my first intent was to illustrate that very old ideas can still apply to very modern pursuits.
Secondly, I've studied the Tao Te Ching for a good chunk of my life; I've applied my own interpretation of it to my system designs -- and while I still have much to learn about software design (and Perl), I feel that applying it has made me a better developer.
Thirdly, part of my job is training others. The day will come when I will have to train a department on solid coding practices. Having "gimmicks" like this that help teach and help students retain is useful. I hope to refine the analogy through discussion.
And, finally, I find it fun and useful to put my ideas onto a forum to have them picked apart. Maybe it doesn't teach me Perl, but since a node like this contains bias resulting from my personal outlook, I have found that I am able to find flaws in my outlook through discussing it.
As for the last line, I use CGI on a regular basis, and a lot of people still use it for simple web applications. It hasn't outlived its usefulness, yet. ;-)
radiantmatrix
require General::Disclaimer;
s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}
| [reply] |
|
|
OK, I'll try to make this less opaque than my other response.
When I read the root node, it smelled like karma whoring. I'm not saying that it was, but it came across that way. You wrapped up non-controversial statements and a good dose of congratulatory back-patting with a thin veneer of pseudo-Eastern philosophy. I neither found useful information about that philosophy or Perl. Indeed the attempts to derive a moral about Perl in a very literal way from each sentence detracted from my appreciation of the philosophy.
Furthermore upon seeing the philosophy quotes I saw that they could have been taken somewhere very interesting. For instance from the insights I tried to express in What you refuse to see, is your worst trap I can see how acting in accord with those principles would result in your being very effective in interpersonal relationships. That is something that could be very insightful and helpful.
Hence my attempt to express this feeling in a somewhat poetic matter.
| [reply] |
Re^2: Tao Perl Ching - The Scripture of the Way of Perl
by archen (Pilgrim) on Dec 18, 2004 at 17:14 UTC
|
The latter unfortunately is interface-wise compatible with CGI; and I don't like that interface much
Why is that? Not to troll, I'm just curious. Personally I only use CGI::Simple + HTML::Template which is about 50% faster than useing CGI.pm in most of my circumstances. | [reply] |
|
|
Why [do you not like CGI.pm's interface much]?
Mostly because it's terribly inconsistent. Why is is Vars ucfirst, but param all lc? Why are some, but not all words in names separated by underscores? Another thing I absolutely do not like is the prefixed minus for arguments. Perl is not a shell, so stop trying to look like one. And even then: no, that minus doesn't make it look like shell command line arguments. Of course, the minuses are needed because CGI.pm mixes positional and named arguments.
Yes, CGI::Simple is much faster than CGI.pm. And that's a good reason to use it. I use it often. Doesn't mean I like the interface. I understand that it wants to be compatible with CGI.pm.
| [reply] |
|
|
There are good reasons for many of those things. Vars begins with an upper-case V because vars is a Perl reserved word. All the other functions use lower-first casing, so better to make the one exception than change the entire module's syntax.
The prefixed minus is familiar to me from another language (I can't remember which, now) -- it's not an attempt to make them look like shell arguments, but rather a very common style; I suspect the author(s) of CGI.pm were used to using and seeing that style for named parameters. Because of this, when my functions accept named parameters, I use Params::Validate to normalize the keys, allowing but not requiring the prefixed minus.
Anima Legato
.oO all things connect through the motion of the mind
| [reply] |
|
|
Re^2: Tao Perl Ching - The Scripture of the Way of Perl
by itub (Priest) on Dec 18, 2004 at 19:52 UTC
|
I agree that CGI.pm is generally not the best CGI module. But its main advantage is that comes pre-installed on the system because it is a core module. Sadly, it has a lot of historical cruft that has to be kept for backwards compatibility. As for it not being "modern" I suspect it is because it was originally written a very long time ago. | [reply] |
|
|
I agree that CGI.pm is generally not the best CGI module. But its main advantage is that comes pre-installed on the system because it is a core module.
I prefer to call that "standard module" and call modules that enable core functionality "core modules", like strict, warnings and File::Glob.
Anyway, it's not hard to deal with both, as interfaces are compatible:
# Fall back to CGI.pm if CGI::Simple is unavailable.
# We prefer CGI::Simple because it much lighter and faster.
my $cgi =
eval { require CGI::Simple; CGI::Simple->new }
|| do { require CGI; CGI ->new };
I do think avoiding CPAN modules is a bad idea.
| [reply]
[d/l] |
Re^2: Tao Perl Ching - The Scripture of the Way of Perl
by radiantmatrix (Parson) on Dec 18, 2004 at 03:53 UTC
|
Well, you don't refuse to use an already-extant CGI module, which is really what I meant. When I figure out a good and quippy way to say that, I will make an update to the node.
radiantmatrix
require General::Disclaimer;
s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}
| [reply] |
|
|
| [reply] |
|
|
