Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^2: Ignorant Article

by Aristotle (Chancellor)
on Feb 19, 2003 at 07:17 UTC ( #236572=note: print w/replies, xml ) Need Help??


in reply to Re: Ignorant Article
in thread Ignorant Article

It rather is true that the article ignorantly confuses a lot of things that have no relation to each other. Maintaining state is a problem for anything that runs over HTTP, whatever the technique - and CGI scripts producing ugly output? Come on. CGI is also considerably simpler and safer for low-traffic scripts than writing a mod_perl handler or using any of the server-embedded non-Perl technologies. The right tool for the right job, as always.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^2: Ignorant Article
by MarkM (Curate) on Feb 19, 2003 at 14:48 UTC

    If I were to apply your criteria when considering whether any article is 'ignorant', I would probably find that a lot of articles you write are 'ignorant'. Finding two or three conclusions that you can argue against does not force the entire article to be 'ignorant'. Mistaken, perhaps, but don't you think this whole thread is a little bit harsh?

    The CGI interface deserves criticism. The real benefit of CGI is quick-and-dirty hacking, it is not the ability to design an efficient web application (although, on another topic... the idea of an efficient web application may be a contradiction in and of itself).

    CGI is simpler, in that some people find writing 20 print statements to be easier to understand than a loop construct. Heck, when cutting and pasting to hack together a script, 20 print statements over a loop construct is actually *common*.

    Don't get me wrong -- I'm not saying that CGI has no use. Just that for any application that is designed to be used by more than 2 or 3 people, CGI falls short in a number of categories.

    If you want to attack the specific points, yes, the 'CGI tends to produce ugly output' stab is probably better worded 'CGI authors tend to get lazy, and therefore the aesthetic value of the application suffers.' For maintaining state? Consider that for a CGI written in Perl, modules must be loaded in order to store and fetch state information *EVERY SINGLE INVOCATION*. mod_perl solves this problem by keeping modules, and even some data, in memory. mod_perl is not CGI. mod_perl is necessary because CGI is defficient.

    CGI should be used for proof of concept, or for cheap hacks. For a real interactive web application, CGI is always the defficient choice. The users *can* notice the difference. Think about it... how slow is perlmonks.org, and how slow would it be if it was written using CGI?

    The only times I would prefer CGI over mod_perl or PHP, or some such alternative, would be for one shot scripts that do complicated queries, where it is not expected that the script would be invoked later by the same user, or when I am too lazy, or time pressed to get it to work under mod_perl. Some consider lazy or time pressed to be qualities, so I know that some will disagree with me. I only consider laziness an attribute when the quality or efficiency of my resulting code does not suffer. (i.e. lazy enough to prefer not to re-implement the wheel over and over)

CGI GUI and right tool for the right job
by selenasol (Novice) on Feb 19, 2003 at 17:44 UTC
    Yes, yes, yes. I earlier said that I agreed that the argument about ugliness was not really very strong. But at the time, I was comparing a web application using CGI and HTML to client server apps using VB.

    But you are right that this was not communicated in the article as well as it could have been. What I meant to say was that CGI "applications" tended to be too drab.

    As for the right tool for the right job, I would like to quote the conclusion to the "full" article that I have provided links to below...

    "As any good technician knows, there is no such thing as a "best" tool. The best tool is dependent on a whole host of factors from the type of task at hand to the personality of the marketing director. The best tool is a fantasy.

    Instead, every web developer should have at her disposal a wide array of tools to solve problems. Sometimes a server-side solution will be appropriate, other times a client-side solution will be best. Your main goal as a web developer is to develop an intuition about when to use which. "

      What I meant to say was that CGI "applications" tended to be too drab.
      Conceded, especially considering the time of writing. Webdesign has moved quite a bit beyond what was common then.

      Makeshifts last the longest.

Re: Ignorant Article
by Abigail-II (Bishop) on Feb 21, 2003 at 12:57 UTC
    Hmmm, I always thought that mod_perl made use of CGI as well. Note that CGI does not mean "one request to server - one new process". CGI is a (simple) protocol between the server and the application. It defines how information flows from the server to the application (mostly by environment variables, and STDIN), and from the application to the server (STDOUT/STDERR).

    It doesn't mandate the technology. The server might use a seperate process, but it might use threads or something else.

    The problems discussed in this thread are mostly stemming from the fact HTTP is *stateless*, and people try to use it get state (sessions).

    Abigail

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://236572]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2021-07-26 13:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?