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 ???
http://www.wdvl.com/Authoring/Scripting/WebWare/Server/CGIsux.html
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. | [reply] |
by Abigail-II (Bishop) on Feb 18, 2003 at 23:54 UTC | |
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.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.
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.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?
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. Abigail | [reply] |
by steves (Curate) on Feb 19, 2003 at 00:18 UTC | |
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 boo.com?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. | [reply] |
by selenasol (Novice) on Feb 19, 2003 at 16:49 UTC | |
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. | [reply] |
by Abigail-II (Bishop) on Feb 19, 2003 at 19:44 UTC | |
by tachyon (Chancellor) on Feb 19, 2003 at 03:39 UTC | |
The security concerns are valid to a degree
cheers tachyon s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print | [reply] [d/l] |
by John M. Dlugosz (Monsignor) on Feb 20, 2003 at 23:03 UTC | |
| [reply] |
| |
| |
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. --<http://www.dave.org.uk> "The first rule of Perl club is you do not talk about
Perl club." | [reply] |
| |
Re: Ignorant Article
by simon.proctor (Vicar) on Feb 18, 2003 at 13:41 UTC | |
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: Still, I guess ignorance is a point of view. SP | [reply] [d/l] |
by Anonymous Monk on Feb 18, 2003 at 16:29 UTC | |
- Selena Sol | [reply] |
Re: Ignorant Article
by Cody Pendant (Prior) on Feb 18, 2003 at 22:54 UTC | |
-- 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. | [reply] |
by steves (Curate) on Feb 18, 2003 at 23:44 UTC | |
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-) | [reply] |
by selenasol (Novice) on Feb 19, 2003 at 17:38 UTC | |
| [reply] |
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. Abigail | [reply] |
Re: Ignorant Article
by ignatz (Vicar) on Feb 18, 2003 at 22:34 UTC | |
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! ()-() \"/ ` | [reply] |
by steves (Curate) on Feb 18, 2003 at 23:08 UTC | |
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? | [reply] |
by selenasol (Novice) on Feb 19, 2003 at 17:31 UTC | |
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 reauoted....it can be easily misinterpreted. But isn't that the case for every writer? | [reply] |
by Rex(Wrecks) (Curate) on Feb 19, 2003 at 19:49 UTC | |
by selenasol (Novice) on Feb 20, 2003 at 01:47 UTC | |
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 (http://perlmonks.org/) 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. | [reply] |
by Aristotle (Chancellor) on Feb 19, 2003 at 07:17 UTC | |
Makeshifts last the longest. | [reply] |
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) | [reply] |
by selenasol (Novice) on Feb 19, 2003 at 17:44 UTC | |
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. | [reply] |
by Aristotle (Chancellor) on Feb 19, 2003 at 20:31 UTC | |
by Abigail-II (Bishop) on Feb 21, 2003 at 12:57 UTC | |
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 | [reply] |
Where to read the full article
by selenasol (Novice) on Feb 19, 2003 at 17:10 UTC | |
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 http://www.wdvl.com/Authoring/Scripting/WebWare/Server/ 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: http://www.wdvl.com/Authoring/Scripting/WebWare/Server/ It then continues on http://www.wdvl.com/Authoring/Scripting/WebWare/Server/CGIsux.html Then concludes on http://www.wdvl.com/Authoring/Scripting/WebWare/Client/ 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. | [reply] |
by steves (Curate) on Feb 19, 2003 at 17:50 UTC | |
I find this much more palatable in its entirety. It's a shame the www.wdvl.com 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. | [reply] |
by selenasol (Novice) on Feb 20, 2003 at 01:15 UTC | |
| [reply] |
by Wysardry (Pilgrim) on Feb 21, 2003 at 04:19 UTC | |
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). __________ | [reply] |
Re: Ignorant Article
by selenasol (Novice) on Feb 20, 2003 at 09:50 UTC | |
http://www.extropia.com/tutorials.html 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. | [reply] |
Re: Ignorant Article
by shirkdog_perl (Beadle) on Feb 20, 2003 at 16:32 UTC | |
| [reply] |
Re: Ignorant Article
by scottstef (Curate) on Feb 21, 2003 at 03:38 UTC | |
"The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol." -- Larry Wall | [reply] |