Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
Perl Monk, Perl Meditation

Ignorant Article

by Anonymous Monk
on Feb 18, 2003 at 12:57 UTC ( #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

Comment on Ignorant Article
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.

      First, let me begin by saying that it is exactly this sort've muddy thinking combined with blind religiousness and techno self-centeredism with a total disregrad to history and context that has pushed me out of the Perl community entirely.

      Regardless of whether or not my code or writting is the best that ever was or the worst that ever was, my pioneering work in Perl CGI brought thousands of people to the community and provided whole careers for hundreds.

      You (those of you in the community who are as ignorant as you) should be ashamed and embarrassed that you alienated such an evangelist. I could have been a great ally to Perl CGI.

      I am sure you say good riddance, and I say the same to you.

      But let me address this post.....

      The fact is that you are reading this article COMPLETELY out of context as you are missing all the pages before and after.

      A couple of things to note...

      1. Fast CGI and mod_perl did not exist at the time of publication. But even if they did, the criticism that I wrote is still valid and an important architectural problem of CGI.

      2. Cookies are a different state mechanism covered in a different page of that article. Obviously, you are ignorant, not the article. But regardless, cookies have nothing to do with the CGI standard. They are a supporting technology.

      That said, as it so happens, I deplore the use of cookies as a state mechanism and prefer much cleaner models such as those available in J2EE or CGI.

      Cookies are one of the slippery slopes that fall from the Model-View-Control peak. With the exception of Presentation logic, I prefer all logic to be in the controller. That you are so keen to suggest JavaScript shows me that your conception of basic design patters is shoddy.

      3. As far as the aesthetic blandness I was complaining about with CGI, this is actually a mistake on my part. Actually, at the time, there were several great Flash and VRML sites using MY CGI SCRIPTS and still are today. But the weaknesses of HTML and even dHTML are important issues that the community should help to address rather than deny.

      You remind me of LINUX users who try to argue that LINUX has great GUIs. Give me a break! I am a great supporter of LINUX, but hello!!!!!!

      4. The entire web is definitely NOT CGIs. CGI is an important part and when used properly, in the right context, is an excellent tool. I have entire books evangelising the use of Perl CGI.

      Whatever the case, you need to do a bit of homework yourself before you start flaming.

        So where are these other pages of the article? The one I read has a title at the top, footnotes at the bottom, and no paging buttons or links.

        I am not a JavaScript advocate. I was merely trying to find out what these other presentation technolgies are that the article alludes to. The bulk of the article laments the fact that CGI's are tied to HTTP and HTML. So is the rest of the web, so what's the point?

        CGI is not Perl. CGI is a way of providing dynamic content. The fact that there are other wrappers around that doesn't change the fact that under it all the same limitations and issues exist, regardless of technology used or language. So in that sense, much of the web (other than static content) is basically a CGI model, usually with some sort of wrapper around it.

        We (or I) obviously hit a nerve based on the tone of your response. I was merely trying to take the points I saw as inaccurate and point out what I see to be the truth. Why does that bother you so much?

        I have, by the way, written dynamic web back-ends in C, C++, Java, and even with shell scripts so don't assume I live and die by Perl. I use the best tool for the job at hand. I can't help it if much of the time that's Perl. 8-)

        The problem is not (ultimately) CGIs. It's HTTP. Any technology built on HTTP is going to run into the same issues. You're going to have to use some sort of kludge to get any sort of stateful information over HTTP, be it hidden input forms or cookies or whatever else. Asethetically, these are all awful solutions.

        Replacing HTTP as an application platform would be wonderful. J2EE doesn't do that, and we shouldn't pretend that the handwaving it does is any less kludgy than solutions CGIs use.

        Reinvent a rounder wheel.

        Note: All code is untested, unless otherwise stated

        Eric, I don't know you from a hole in the ground, so I don't have anything personal against you. However, it doesn't mean I don't have my opinions. :)

        I could have been a great ally to Perl CGI

        Wow, that's news to me. There's a way to ban people from writing and executing Perl scripts? I can be quite sure there is no power in existence that told you "you cannot join the Perl community".

        The fact is that you are reading this article COMPLETELY out of context as you are missing all the pages before and after.
        If it is possible to read that article out of context, then I'm guessing that enough thought didn't go into writing it. Just a guess though. BTW, what pages before and after? I see no links to previous or next pages.

        Cookies are a different state mechanism covered in a different page of that article. Obviously, you are ignorant, not the article.

        Once again, what other pages? The web author that physically posted these different pages of the artcile (whether it was you or somebody else) obviously was ignorant to the fact that web surfers enjoy getting to the next page of an article by clicking a link, not by attempting to find it by starting at the home page.

        Cookies are one of the slippery slopes ... I prefer all logic to be in the controller.

        By 'controller', do you mean the server? If not, then I am ignorant in this case and you can ignore the following lines. I'm sorry to say that not using cookies is really quite a burden. You can't store session information based on an IP address because of dynamic IPs, and using a hidden field on every single page of a site is just a pain in the ass. I'm all for cookies, as long as they are only used to point to a particular session. I'm _not_ for storing all data on the client side. The actual data corresponding to a session belongs on the server.

        That you are so keen to suggest JavaScript shows me that your conception of basic design patters is shoddy
        Hey, something we agree on! JavaScript deserves to be shot in the foot and tossed overboard :)

        But the weaknesses of HTML and even dHTML are important issues that the community should help to address rather than deny.
        I'm interested in hearing more about this one. So HTML is limited. What can we do about that? The last thing I need is for web designers to be given more power than they already have. I don't _want_ to surf the internet with fancy things flying all around. I quite like the fact that sites are restricted as to what they can do. Perhaps we could suggest that all webmasters create downloadable programs for each site they make to provide a fancier, friendlier, more appealing user interface? Oh yes, I'd just _love_ to click a "Click here to download our 100MB software bundle so you can view our site" link every minute or two. Besides, this software would be more buggy and open up hundreds of security holes in itself, much more than a CGI program or script running on the server.

        As for flash and VRML: I hate both of them beyond hate :) The only reason people use these is to move beyond the limits of HTML is to create flashy animations and virtual worlds where you get to walk around. As I already mentioned, I don't like flashy things (ie: Flash). I don't like sitting at my computer for 2 minutes while I watch a Flash script roll text around my screen creating a menu: I want the menu instantly. It doesn't help that some idiots won't put in a 'Skip Intro' button. Grr :|

        If the above content is missing any vital points or you feel that any of the information is misleading, incorrect or irrelevant, please feel free to downvote the post. At the same time, reply to this node or /msg me to tell me what is wrong with the post, so that I may update the node to the best of my ability. If you do not inform me as to why the post deserved a downvote, your vote does not have any significance and will be disregarded.

      Note that the response is from Selena Sol. I have no interest in joining this website as a member
      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.
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 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

      Yes Dave, at least you have a bit more knowledge than your peers in this thread. Selena Sol is in fact a public pseudonym for me, Eric.

      In terms of what I know about CGI programming, I think that I know just enough to have inspired a thousand web developers, written books, spoken at conferences and won awards, and solved lots of problems people were having both technically and not.

      Does that mean I am a guru?

      No, it does not. And Inever ever claimed to be. It is no secret that I am not a programmer and I have no intention of being one. And even if I did, I still know that there would be a hundred punks like you claiming to be better.


      As far as my archive goes, it is a valuable resource which you obviously have not bothered to truly investigate. As an open source project,some of the best perl developers from around the world have contributed to it and the current architecture is far superior to any applicaiton development framework for Perl CGI that exists today.

      - Selena Sol (choose the open source link) and for goodness sakes, at least read the whole article before you all spout off ignorantly.

        Only slight offense intended here.

        I've read the page in question, as well as this thread. There is this thing called personal opinion, and free speech. There is also this other thing called respect.

        Irregarless of how great you or other think your code/repository is, no one has the right to stomp in and start b**chslapping monks around and flaming. I have massive respect for merlyn or tye, who have been around the block a bit more than most I would guess. Why do you ask, because even if they know the intracacies of whatever piece of a problem space I may be having an issue with, I have yet to see them once state to someone else that they are stupid, dumb, ignorant, etc..

        The reason this particular community is so great is directly related to that. Not that an advanced monk knows more, and keeps the little guys down, but rather that they are always willing to help and pull up the next saint-to-be. This whole community works because people "RESPECT" each other as developers and as human beings, instead of defining the relationship as someone at the far end of a text box.

        So you can keep your code, your respository, and your opinions to yourself if the only way you can manage to talk is flaming. If you can manage to communicate like an adult about the timeframe your article was posted, what the 'net was like at that point, the fact that the page was part of a larger article, and what you were trying to get across, you might actually get decent feedback.

        Thank you very much and find another URL

        /* And the Creator, against his better judgement, wrote man.c */
        One last thing before I leave this hole in he web.

        My code...My personal code...helped the scientists at NIH map the human genome. It provided the basis for the online community around the Electronic Frontier Foundation. It handles billions of pounds annually at banks in Europe and Asia. It runs 4 intelligent buildings in 3 countries. It allowed me to build and sell two companies. Has been published 7 times over. It was requested for presentation at the 1st two OReilly Perl Cons. It underlies New York City's Post-September 11th command and Control website that was erected within 2 days for free and is still 100% active today.

        In addition, under other people's customization it runs at NASA, GE, SGI, GM - still AFTER 6 YEARS, several hospitals, at least 1 emergency rescue unit, more personal websites than I can count. It has been translated into 4 languages. And it has been the basis to launch many successful e-commerce websites and careers in web design and development.

        Does this make me a guru programmer?


        And frankly I couldn't give a flying hoot about being a guru programmer. With only a few exceptions, every guru programmer I know, especially those in the perl community, has ZERO clue about the purpose of technology.

        It does mean however, that I helped a lot of people solve a lot of problems. And to tell you the truth, you pin heads can yap all you want to about the fastest, cleanest code, but I have been successful and have helped make the world a better place despite my MANY flaws and despite the MANY flaws in my programming. So I am satisfied.

        And I will tell you another thing, if it was not for me and Matt Wright, Perl/CGI may never have even been born. We were the ones who made it accessible to the masses. We were the ones who made it fun in the 1994 when all of you folks did not even know what CGI was (probably) :)

        - Selena Sol

        It's been a while since anyone called me a punk. It was probably 1977 and as I was listening to the Sex Pistols at the time the description was probably accurate.

        I'll admit that it's been at least a couple of years since I looked at your scripts. I'll take another look just as soon as Extropia comes back up and I'll report back with my opinions. If you're interested, I'll be measuring them against the criteria that I list in my article Finding CGI Scripts.

        I certainly can't claim to have inspired a thousand web developers, but I know I've saved hundreds of web sites from using Matt Wright's scripts by running the nms project. In my opinion this has also been worked on by "some of the best perl developers from around the world". I wonder if they were the same ones as worked on your project :)


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

        Maybe Dave isn't merely claiming to be better, after all. He and friends at have spent a fair amount of time creating properly written drop-in replacements for Matt's scripts.

        Your article is also mixing up many levels of things. That CGI scripts produce ugly pages is a ridiculous claim; they can send to the browser any output they wish to, just like all other dynamic webpage generation technology can. It is true that state is hard to maintain in CGI, but so is it with any other dynamic webpage generation technology because HTTP itself, the protocol on which all them have to build, is inherently stateless. (Whoever claimed cookies were the solution forgets they're conceptually the same thing as hidden fields, which by the way is exactly the same thing as encoding data in the URL at least for GET forms so your article's separate mention is redundant.)

        Makeshifts last the longest.

        Yet another flamefest at Perlmonks? Count me in.

        I know just enough to have inspired a thousand web developers,

        Yeah, inspired them to write secure, maintainable, bug-free code. Inspired them to only release code they feel will contribute something. Inspired them to contribute to central code repositories (like cpan) to minimize needless duplication of effort and encourage peer review. In other words, inspired them to write code completely different than yours.

        written books

        Have you looked at the quality of most Perl books lately? They suck. I haven't read any of yours, nor do I intend to. There is a small minority of excellent Perl books such as Data Munging with Perl written by the guy you're flaming who is exponentially more respected than you in the Perl community.

        spoken at conferences and won awards, and solved lots of problems people were having both technically and not.

        Spoken on what? How not to program, using your own code as examples? What awards? Matt Wright's insecure programming & open spam relay awards? As for solving problems, I'm pretty sure you're creating just as many for anyone who will maintain that spaghetti code of yours.

        Does that mean I am a guru?

        Yuck, you just wrecked a perfectly good word. Now I'm going to have refer to the likes of Elian, davorg, TheDamian, merlyn, tye, Abigail-II and others as something totally different.

        It is no secret that I am not a programmer and I have no intention of being one.

        If you write code, you are a programmer. Check the dictionary definition if you'd like. You can't just totally suck and say "well I'm not a programmer." Keep your garbage code to yourself, you're corrupting minds that could be molded into doing something productive.

        I still know that there would be a hundred punks like you claiming to be better.

        Punks? Now that's not very nice. And yes, if you did consider yourself a "programming guru" there would be a hundred (actually, more like hundreds of thousands) of people who would consider themselves more skilled than you, and rightfully so. Kind of like the current situation now isn't it?

        As far as my archive goes, it is a valuable resource which you obviously have not bothered to truly investigate

        Actually, I did a survey, 80% of people say it was useless crap, the other 20% asked me what the pretty dollar signs mean. There is tonnes of excellent code out there, no need to very poorly duplicate it's functionality.

        As an open source project,some of the best perl developers from around the world have contributed to it

        Once again, Matt Wright isn't one of the best perl developers in the world, and he definately wasn't one of them 5 years ago (sorry Matt, you just make a good example ;-). And while those 500 monkeys randomly typing on 500 typewriters did turn out substantially better code than you, it still wasn't that good.

        and the current architecture is far superior to any applicaiton development framework for Perl CGI that exists today.

        Damn, I just threw up. My stomach couldn't handle that last sentence. Guess you won ;-P

        Heh, </flame> that was fun, we should do it again sometime. This entire post is meant as a half-joke so don't take it too seriously, just remember to look at your work objectively and ask yourself if it really does contribute something before publicizing it. If you feel it does, more power to you, but don't do it just for your egos sake :).

        Have a nice day :)

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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://236240]
Approved by broquaint
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (14)
As of 2014-04-23 10:49 GMT
Find Nodes?
    Voting Booth?

    April first is:

    Results (541 votes), past polls