Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Ignorant Article

by Anonymous Monk
on Feb 18, 2003 at 12:57 UTC ( [id://236240] : perlmeditation . print w/replies, xml ) Need Help??

Hi Monks,
  I was browsing google and accidentally found this link ...this is one of the most ignorant articles i have come across ....imagine someone who does not know much about cgi reads this ???

update (broquaint): added formatting + link

Replies are listed 'Best First'.
Re: Ignorant Article
by steves (Curate) on Feb 18, 2003 at 13:29 UTC

    There's a lot of misinformation in that article. Sounds like it was written by someone who knows just enough to be dangerous. Let's look at a few pieces:

    Maintaining state is possible with CGI using hidden variables, by encoding the URL, or by maintaining a state file on the server, it's just not easy or efficient.
    There's that silly thing known as cookies that a few web sites use.
    Second, every set of question/answers causes the web server to execute a unique instance of the CGI script. This is pretty expensive, especially on a high volume web site which may have 100 instances of a CGI script executing at any given moment, each, perhaps, with its own Perl interpreter.
    How about mod_perl or fast CGI?
    Finally, CGI scripts produce fairly ugly user-interfaces. Basically, CGI is limited to bland HTML-based forms and whatever bells and whistles can be provided by surrounding HTML layout. Thus, no CGI application looks like your swank bootleg copy of Word.
    This may not seem like a big issue at first, but when you start competing for web hits with multi-million dollar companies, image is indeed everything. CGI simply cannot compare with web based applications which are not limited to HTML.
    She's really confused here. Just what are those other companies using? Their own proprietary web protocols? Let's see, it could be JavaScript. I've had CGI's put that into generated pages ... Maybe style sheets? I've used those too. She gives no clue as to what this other magic is. The fact is a CGI script can put whatever it wants into a generated page.

    The real miss here is that the entire web is basically CGI's. HTTP is a stateless protocol. Anything that appears to be something else is just putting wrappers around that stateless protocol to give it state and make it more usable. She appears to be picking on Perl CGI's in particular here (although she never really comes out and says that). What about other CGI programming languages? Are they any better? If so, why?

    CGI's have their issues, but we can't just pack up the web and go home.

      Maintaining state is possible with CGI using hidden variables, by encoding the URL, or by maintaining a state file on the server, it's just not easy or efficient.
      There's that silly thing known as cookies that a few web sites use.
      Cookies are just another type of bandage, trying to patch the same wounds hidden variables and URL encoding are trying to patch. They are all attempts of hammering squares through round holes, creating "state" using a stateless protocol.

      Second, every set of question/answers causes the web server to execute a unique instance of the CGI script. This is pretty expensive, especially on a high volume web site which may have 100 instances of a CGI script executing at any given moment, each, perhaps, with its own Perl interpreter.
      How about mod_perl or fast CGI?
      Yeah, what about them? Sure, you don't have to fire another instance of Perl. But you still need a three way handshake to create the TCP/IP connection (it usually takes longer to render a page and type in a response that it takes for the keep-alive timeout to expire), and the server still needs to do all the house keeping dealing with another request. And that's assuming there's just "a server". Enterprise systems often consist of many components.

      She's really confused here. Just what are those other companies using?
      Java, probably. I'm not at all a big fan of Java (but neither of CGI), but Java applets allow you to push a program to the client, deal with all the intermediate results *at the client*, and only make a connection again when there's an end result. Now, I realize that Java has its drawbacks too, but Java applets certainly fix some of CGI's problems.


        These are all excellent points. I was hoping the author would have thrown things like this out for debate.

        As for client heavy web sites, can you say

        A big part of our day is living within the reality that exists today. Stateless HTTP sucks in many ways. CGI sucks in many ways. Java applets suck in many ways. I can almost guarantee you that if they added state to HTTP tomorrow, we'd all be complaining about some aspect of it. Most -- heck, I'd say all -- of the technology I use has at least one dimension of suckiness. My problem with the article is that it mixes all the suckiness up into on cauldron then assigns a label that, at least in a veiled way, points to one of the ingredients. You get some pointy hairs reading that stuff and next thing you know they mandate "no Perl" or something similarly stupid.

        At one job we outsourced GUI development and got a really bad result, even though from a checklist perspective everything was "okay." The problem was with the coding. Management banned the tool that was used from ever being used again. As if the tool, which actually seemed quite good, was responsible for the poor use of itself. That's the reality of our world. Who here can claim that if the author of N books spoke to your boss he wouldn't listen at least a little? I think it's our responsibility to keep writers, experts, and ourselves honest.

        Abigail, when my darn site finally comes upagain, you might want to checkout the JavaToCGIBridge bean that my CTO, Gunther wrote to allow you to easily integrate Applets to CGI.

        That said, I am not personally a big fan of applets. I tend to think that dHTML does enough of what is required. But I have written my fair share of both types of GUIs.

      The security concerns are valid to a degree

      #!/usr/bin/perl $|++; use CGI qw( :standard ); use CGI::Carp qw( fatalsToBrowser ); print header(),start_form({ -method=>'get' }), textfield({-size=>75,-name=>'command'}), submit('Run'), end_form +(); if (my $command = param('command')) { open( CMD, "$command 2>&1|" ) or die_nice( "$!: running command: '$c +ommand'" ); print "<pre>\n"; print escapeHTML($_,1) while (<CMD>); print "</pre>\n", end_html; close CMD; } sub die_nice{ print shift and exit }




        use strict, warnings, and taint checking. I think taint checking was ahead of its time when it came out, and vastly underused today. Other languages are just beginning to incorporate something along those lines.
    A reply falls below the community's threshold of quality. You may see it by logging in.
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Ignorant Article
by davorg (Chancellor) on Feb 18, 2003 at 14:28 UTC

    It should be noted that the author of the article is Selena Sol. Selena (who is actually a bloke called Eric) is pretty well known for not knowing as much about CGI programming as he thinks he does. His repository of free CGI programs is almost as infamous as Matt Wright's.


    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Ignorant Article
by simon.proctor (Vicar) on Feb 18, 2003 at 13:41 UTC
    As with most ignorant articles, they assume that Servlets are totally different to CGI. Well, apart from the fact that a new thread is created for each request (so your stuff stays in memory) they are inherently the same. They still talk HTTP, they still have to maintain state and they still have their own security problems (SQL injection for example).

    The article would have made more sense if the person had advocated static content for reasons of insecurity of *any* web application rather than make it sound like CGI was the poor mans application platform and there was nothing secure about it.

    The only rose in the pile of compost:
    CGI, for all its flaws, works, and works pretty darn well if done care +fully.
    Still, I guess ignorance is a point of view.

      Simon, note that Servlets are covered on a different page in that article. But I agree with you that Servlets are quite similar in many ways to CGI, yet do have important differences and within the context of J2EE are much different.

      - Selena Sol

Re: Ignorant Article
by Cody Pendant (Prior) on Feb 18, 2003 at 22:54 UTC
    I don't have much to say about that article, but two points of fact:
    1. I am unable to tell that the article was written a long time ago -- it clearly says "copyright 2003" at the bottom and I can't see any other date information on it.
    2. The thing that annoys me most about it is that thing about "cgi interfaces are always ugly". That's so ridiculous, it's surreal. I just have no idea how anyone who understood HTML and CGI could write that.

    “Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.”
    M-J D

      We may never know ... the web site that supposedly has the full original is still down. Maybe a CGI is serving the articles. 8-)

      In the rebuttal, he/she contrasts CGI with J2EE. If his assertion is that the article is too dated to account for mod_perl and fast CGI, then I'd assert that a comparison to J2EE is also unfair. Let's instead compare the alternatives at the time the article was written.

      I can't help myself ... I love a good debate. 8-)

        There really weren't any at the time. There was no servlets, com objects, beans, or php...there was cold fusion though...
Re: Ignorant Article
by Abigail-II (Bishop) on Feb 18, 2003 at 23:34 UTC

    What I see is an article that defends the hypothesis that CGI is far from perfect. It does so focussing on three important issues, and presenting arguments why CGI "suxs". IMO, the article is better written than most articles here - although it's not perfect. You may not agree with its conclusions, but all you say (as an anonymous person) is that the article is ignorant. But you don't actually refute the arguments given.

    All I can say is that you are ignorant one here. And that's without even addressing whether or not CGI "sux" or not.


Re: Ignorant Article
by ignatz (Vicar) on Feb 18, 2003 at 22:34 UTC
    Am I missing something here? Quoting Lincoln Stein... not a source that I've heard characterized as ignorant. Recommending that one learns more about CGI's security problems. And the ignorance of this is...?

    You're going to have to come up with something better than "Yer Stupid" to get onto the debate team there bucko.

    P.S. This one's a keeper for the angry threads list on my homenode. Congrats to everyone!


      One meaning of the word ignorant is "unaware or uninformed." Despite the obvious knee-jerk reaction most of us have when that word is directed at us, I think it applies here. There is an unawareness and uninformed-ness (okay, so that's not a word ... call me ignorant) in statements that blindly link Perl, CGI, HTTP, and HTML without clearly distinguishing which is responsible for what. There is supposedly a more complete article that puts it all in context but I have been unable to access that today -- the referenced site is down. Further, I'd argue that as a writer concerned about this bigger perspective, it's unresponsible to let it be narrowed down into an inaccurate piece of writing if that's what happened. It's kind of like someone taking your code, slicing pieces out then posting it as yours. If you knew about it and let it happen, shame on you. If you didn't know about it, you'd at least direct your anger at the editor, not towards those questioning the validity of your code.

      Things like this don't anger me. I was more amused. If my reply came across as angry, I apologize. I think we should question most things. That's how we learn. This article, starting off with a title of CGI Sucks, reads like one big troll to me. Maybe we shouldn't have taken the bait, but what's a day without a little controversy?

        I have psoted links to the entire article on WDVL so you can see the greater context. Please go there, I would appreciate it.

        As for being unresponsible, please understand this....

        WDVL is in no way associated with me. They are one of **dozens** of sites that has downloaded my work and republished it.

        Part of my own intellectual property agreement with the world is that I have none. I encourage people to take and use whatever they want from me. They are free to cite me or not. They are free to plagiarize. They are free to reformat. They are free to use it to make money, to learn from, or throw away. I believe that information wants to be free and that nobody has the right to ensalve it.

        There are pros and cons to this philosophy as there are to any philiospohy.

        One of the cons is that I lose control of the information I put out. Although WDVL certainly has no copyright over my work, if they want to put that there and reformat it, I have no beef with them.

        It is sad that they do not update when I make changes (cause like everyone I make lots of mistakes and need to revise my work from time to time.)

        I have requested that they update the text, but to no avail and to me it is not worth fighting over as, like I said, there are dozens of similar cases. For me to personally fight this is too much.

        Over the last 6 years, believe me, I have spent time trying and trying to get these mirrors to either shut down, or mirror using software that allows them to constantly keep source control in tact.

        But this is only sosuccessful. I currently have mirrors in over 6 countries that simply never responded.

        As a responsible author, what do I do?

        Keep in mind that I have a life, and a company to run, a baby to look after, and all the usual trappings of reality.

        Should I hire a lawyer to sue?

        In the end, I have honestly done my best to get the information under control using social means. But because I do not believe in force, I am not willing to use it. If someone uses my work in a way that hurts, while I do feel responsible, I also am to some degree powerless to avoid it.

        Telling me that I have a responsibility for keeping tabs with a ten thousand people who either use my code or use my writing is a bit like telling Dr. Dre to keep tabs on every suburbian white kid listening to 'Fuck the Police'.

        I think that is actually wrong headed.

        But I also respect your opinion. This is not a clear cut issue. I don't think that there is a clear right or wrong answer.

        In my own life, I have just tried to counter misuse with as much positivity as possible.

        Now your comment about the title is pretty good. It was a title that set within the context of the article, I think, makes sense. But, it is something that can be easily taken out of context. I used it originally as a stylistic tool in the writing but when can be easily misinterpreted.

        But isn't that the case for every writer?

Re: Ignorant Article
by MarkM (Curate) on Feb 19, 2003 at 06:42 UTC

    I strongly disagree. The article is not a result of ignorance. Rather, the article is the result of the author feeling the pains of CGI. Think about it -- CGI truly *IS* an inefficient interface, especially for web applications that require frequent interactions with the server. The only people that are not forced to recognize this on daily basis, are the people that have only played with 20 lines CGI scripts. Everybody else knows that CGI provides a convenient entry point to dynamic web content, but it stops there.

    This site ( uses mod_perl. Why? Because using CGI would not work. The site would crawl about 20X slower than it does now.

    I suggest that people retain an open mind when reading criticism of technologies. It is entirely possible that the person writing the criticism has experience or knowledge beyond what you have.

    The advent of FastCGI, ASP, PHP, mod_perl, ... is a DIRECT result of CGI sucking.

      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.

        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, 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)

        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. "

        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).


Where to read the full article
by selenasol (Novice) on Feb 19, 2003 at 17:10 UTC
    Hey folks - As I have said in some replies, my website is down so you cannot read the articles at their home (where they are updated when I receive comments).

    However, it was incredibly easy for me (two links) to go from the referenced article above, to my tutorials that have been mirrored by WDVL.

    The URL you want is

    Please note that these articles are not updated by me, so they include errors that have been fixed after publication but not mirrored on this site and also note that these articles are all very old. I have nothing to do with WDVL.

    Now...the complete article from which the referenced page comes from starts at:

    It then continues on

    Then concludes on

    Why WDVL does not provide previous and next links...I have no idea. But if you read the above pages in that order, at least you will see the whole argument for that article.

      I find this much more palatable in its entirety. It's a shame the web site didn't think to include forward and back references to the related pieces of the bigger article. Search engines can be dangerous in this way I guess.

      Interesting that, despite our initial differences of opinion, we seem to reach the same basic conclusion: All of this has some dimension of suckiness.

        I do want to say that of all the sites mirroring my content, WDVL has been one of the best about updating things. I have sentr the editor there a request to provide links backwards and forwards.

      Hmm. That article seems to have been treated totally differently than the other articles in the WebWare section (and most of the rest of the site).

      For one thing, the title in the left column is not a link, and for another the back/next links are missing.

      You can see an example of how they usually look at the bottom of Why Perl (also by Selena Sol).

      "Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work." -- (Author Unknown)

Re: Ignorant Article
by selenasol (Novice) on Feb 20, 2003 at 09:50 UTC
    Hey folks, my 'real' tutorials website is working again. If you would like to see all the collected tutorials, please go to.....

    If after you browse this for a bit, you still want to call me ignorant...well...then ok....I think you are wrong. You can, however, call me wrong if you think anything I have said is wrong.

Re: Ignorant Article
by shirkdog_perl (Beadle) on Feb 20, 2003 at 16:32 UTC
    Hmmm... I was just trying to write some perl poetry and stumbled onto this little brouhaha. What I think is interesting, is how Perl may not be the right solution for the job. However, Perl can do anything. In the case of CGI, or any web application, Perl may not be the correct solution, but it glues it together. Even I am humble when Perl is not the correct solution (i.e., Windows OS and VBScript, bad experience with proprietary software, don't ask ). But Perl seems to be able to do anything, it is just a matter of How and How fast.
Re: Ignorant Article
by scottstef (Curate) on Feb 21, 2003 at 03:38 UTC
    for what it is worth, selena sol and matt wright got me started with perl in the late 1990's. So i guess i should at least say thank you selena sol %^)

    "The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol." -- Larry Wall