Slashdot Mirror
Web Programming by printf()
An anonymous reader writes "Art & Logic has posted an article titled 'Why CGI is Evil'. CGI might be an obvious way to create a simple web application, but this article provides some excellent high-level reasons why CGI rarely makes long-term sense. A nice review especially for new web programmers."
First GOTO and now CGI. Why doesn't someone call C evil so we can call it a night
One of the author's complaints against cgi was the slowdown and overhead of having to fork a separate process. Let's look at that claim.
There is a penalty to forking, but there is also a penalty to running interpreted code (java, php, perl, etc). Additionally, for scripting languages like perl and php, there is also cost of parsing and validating the code -- something that doesn't need to be done with compiled C code, and which takes a much longer time.
Additionally, forked CGI runs in its own process space, and can't cause errors with the web server (IIS/apache).
Executive Summary: CGI is slow, and you can't really use MVC principles. The end.
It's interesting to see the parallels between the traditional web development world and the "embedded web" world. Firmware engineers, dealing with less evolved (ie tiny) web development tools, are learning the same thing traditional web developers learned a few years ago.
What if your CGI programs need to get data from libraries that only have C and C++ interfaces? On the embedded system I'm working on, everything that talks to hardware is written in C or C++, and in many cases the only way to get the data my CGI programs need to is to call a C++ class library. No one would take me seriously if I proposed writing this stuff in PHP or Perl.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
As you can see, I'm not a web programmer and the article actually made things more unclear for me. Did I misunderstood something? Can someone clarify things up for me, please?
instead of "why cgi is evil," maybe this article should have been named "why you should buy our product."
Gyrate Dot Org - "Where high-tech meets low-life"
Notice how the author compares CGI unfavorably with something he calls DMF? Here it is, and it looks like one of the flagship products of this company. Imagine that.
... not that there's anything wrong with that) solution is better. When he says "CGI" he's talking about something that few people use for anything but toys. Slashdot (e.g.) uses the Perl CGI module, but runs it under mod_perl, thus obviating most of his arguments (CGI is slow, must be compiled at run-time, and has no access to the web server internals). Slashdot, again, uses a templating system, thus taking care of his second argument (programmers must copy-paste HTML into their code).
/.
He's setting up a straw man, then claiming that his own (proprietary, for-profit
Both these problems have been solved for over 5 years, yet he's trying to make it sound like his beautiful DMF is the first to even discover them. *Yawn* - another press release day on
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
This is bunk! Pure FUD!
CGI is slower?? I write CGI in C++. Compiled C++ is fast. It's on par with interpreted Perl or PHP execution speed at the very least... more likely vastly faster. And this myth about process spawn time is starting to bother me. Linux can spawn processes VERY fast. Threads on Linux have traditionally been implemented as a special form of process anyhow. And even if this was a problem...the author mentions the solution, FastCGI - but seems to somehow ignore that it obliviates his whole point!
What people really like to ignore when developing on Windows is COM, Apartment Threading, and the whole process model. When you call a COM object in an ASP page or whatever, you are crossing process boundaries - all arguments are martialled through COM by VALUE. All these ASP programmers that create a COM object to use, for example, MSXML have obviously never tried creating a LARGE DOM tree. Let me tell you, it does NOT scale. Compiling all my code into a single CGI allows me to keep everything in the same process space, and vastly improves performance when things get large.
And who the hell debugs using printf? For one, I like CGI because it's easy to launch one directly from GDB! Ever tried attaching a debugger to a thread for your process inside a web server? HA! GDB lets me easily script the piping of a file to stdin of my CGI. If you are still using printf, you have more problems in learning about programming than will be solved by not using CGI.
Now, if your application is heavily template based, then yes, PHP definitely makes more sense than CGI!!! The other has a point in that you shouldn't be embedding HTML in your C code. Which brings me to my last beef...
Their product is about using pre written features rather than writing them yourself as you need to with CGI? Uh, DUH!! There are like umpteen billion CGI LIBRARIES out there!!! I happen to like GNU CGICC. It does everything, form uploading (mime and file uploads too), cookie handling, templating, etc - and it works with FastCGI too! Write it yourself??? As if! And I have no problem linking in libraries for database access, and everything else under the sun (Boost, etc) into my CGI, just like I would link them into any other program. Who the hell writes software without using any libraries?
This article is basically a bunch of FUD just to sell their product. You can safely ignore the whole thing!
It seems like the author thinks the majority of CGI apps are written in C.
On cgi.resourceindex.com, there are 2933 Perl scripts and 165 C and C++ scripts combined.
This would seem to disprove his point that the "binary image" on the server must be replaced every time one wants to edit the html...
Proof once again that CS > EE.
I've read the ad, it's lame but I'm wondering what kind of person publishes with a lower case middle name? ( Brett g Porter ), that just seems a little too clickish..
Has the author never had never heard of templating systems? The issue here lies with the architecture and design of the application itself, and not the use of CGI. You surely don't write your Java servlets using out.println(), do you?
... back off printf();
I'm with you on everything else though bro'!
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
When you consider that all (or most) web servers in the embedded systems market are currently using CGI, the author's article is quite brilliant. Remember, the embedded systems world is about 5 years behind the traditional "web development" world. The embedded guys are using many of the same technologies but for completely different purposes. For example, it looks like Art & Logic is also using XML-RPC and SOAP, but in a completely different context than most of us are used to.
int main(int argc, char ** argv)
{
printf("I disagree.\n");
printf("CGI is great - ");
printf("I don't see why anyone doesn't like");
printf("writing web pages like this!\n");
printf("CGI all the way!\n\n");
return 0;
}
A Minesweeper clone that doesn't suck
I've written jsp, asp, php, cold fusion, perl, vb, and even the slightly less used shtml and of all of them, I much prefer php.
I love perl for many things, but in terms of web page development, I can't stand it - I'd much rather have it running in the background updating files or databases and then have a frontend script like one of the **Ps come in and get the data and make it all purdy.
JSP is retarded slow until the first time it has been loaded - which is all fine on a live system that precompiles at bootup (that always is blazing fast... right) - but for development, it could be a major pain in the ass - esp if you had anything remotely complicated in there.
It is excellent to write in and I like that part, I just don't feel that the performance and ease of use are high enough over the others to merit me using it on any of the most recent projects that I've been doing.
ASP is nice and relatively fast. It *can* run on a *nix system, but really, who are we kidding - it should be under IIS. I have very few complaints about it, but again, if given the choice - I'd rather use PHP.
PHP is free, fast as hell, and has the best documentation - their site is fast, easy to use, and there is a discussion on the site at the end of each function description that allows you to post up different ways to use the code.
It is enough like perl that I can flip flop between the two and not get too loopy trying to remember syntax, and yet it allows the easy tag manipulation that the server side scripting languages **Ps are good for.
Did I mention it was free and retard fast?
hot damn.
There are some odd things afoot now, in the Villa Straylight.
I think there are many times when PHP's print/echo and ASP's Response.Write need to be used. In every project. Functions generate output, and Response.Write sends it to the output stream.
However I was shocked to use ASP.NET and found that unless ASP compat mode was turned on. to output something to the web page I had to create a label, set the label's text, then add it to the body/form control. Talk about the long way of doing something. It isn't any more flexible. It is much harder to change.
IO, IO, It's off to work I go, 1 bit in and 1 bit out... IO IO IO IO
I frequently run my cgi's from a shell, to debug. first set some env vars (I use the uncgi() routine so vars are coming to me as WWW_foo). then 'dot-slash' the cgi and send the output to /home/httpd/html/test.html or whatever. easy and clean to run and debug.
plus, cgi's JUST PLAIN WORK. nothing nonstandard, nothing platform-assuming, no browser extensions required, no heavy overhead. they Just Plain Work.
oh, and they're frequently such 'least common denominator', so they're usually 'lynx-able'. try that with java or jscript code...
--
"It is now safe to switch off your computer."
I have not used a print statements to output html directly in years of CGI programming. The use of templates completely obviates the need to use print or printing "here" documents. The article is pure gibberish.
In fact html in the code is considered sophomoric where I work and is shunned.
Too bad slashdot does not have a mechanism to rate the article it reviews.
$ grep -R 'goto' /usr/src/linux-2.4.20 | wc -l
16677
$
If you want to know how CGI can be made real fast, then lookee here: CGI-lib
--- Nothing clever here: move along now...
Scroll down a bit and you'll find a link to another article the guy wrote, about the "the benefits of using XML-RPC and SOAP" (emphasis mine). For god's sake, even if the CGI article wasn't a promotion for his company, anyone who thinks that XML-RPC and SOAP has any kind of benefits really can't be taken too seriously.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
Excuse my ignorance, but how do you get the HTML code back to the user?
This isn't the sig you are looking for... Carry on...
If its Java, then you have to do:
i nt ("I forgot what I wanted to print");
system.utils.writable.writeManager.render.io.pr
Just kiddin' guys........half
Table-ized A.I.
I've been using C-based CGIs for years - once I started doing it and got used to coding everything in C, and developing my own libraries and what-not, it was very difficult to change.
Seems to me the overhead's pretty low compared to the competition. People argue for things like JSP as more efficient and cleaner than CGI, but I've never seen a JSP web site that's not dog slow.
When I started reading that opening a database connection had enormous overhead, I got worried that I was really doing something dumb. So I wrote a program to open and close a mySQL database 1000 times and it took a total of 2 seconds. That's 0.002 seconds per open/close combination.
Then I stopped worrying and went back to work. I'd rather be right in practice and wrong in theory than vice versa.
D
The cgi application processes a template which consists of replaceable parameters, this template is then sent to standard out - no html exists in the code and the template is viewable and editable using the browser/html editor of your choice. The process is sort of like this
cgi_app.pl --|
-----> std_out
Template.html --|
There are a variety of template processors out there (at least for Perl and Python far as I know), the one I use and have grown to love is TemplateRex
Seriously, this is some kind of timewarp or something. CGI? People still use that? Holy heck.
dominionrd.blogspot.com - Restaurants on
Well, C isn't propably the safest language BUT... I really think that people should learn how to write code and "safe" code. All of these nice features to prevent buffer overflows and stuff like that isn't really the answer IMO. I think it's just a great way to procude bad coders (maybe Java coders :P )
You don't know what you don't know.
Oh, I see.
I guess I use a mixture.
Most of my HTML is a table with some stuff on the top and some stoff on the left. And I have the main body of my page in the bottom right.
Also, I want to be able to do a lot of stuff in the head, like change the title, or create meta information.
Therefore, I create my own stuff each time. I can also change the content-type if I need to. Then I create a before template and after template. The before template is the HTML that sits before my main body and the after template sits after it. I could look for a content or something, but by splitting the page up, I avoid having to search for stuff in the page, which saves some time.
But perl still ends up reading each line of the template in and printing each line of the template out (some lines modified), right?
This isn't the sig you are looking for... Carry on...
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
So, how much does slashdot charge for these adverts then?
Dammit, <ecode> killed my indents. Anybody know how to prevent that?
I can't say that I don't give a fuck. I've just run out of fuck to give.
Premature End of Script Headers
This is not a news article. It is a corporate advertisement for Art and Logic's Device Management Framework. It basicly says: Don't use CGI, use our product instead.
Also there are a bunch of inaccuracies in the article. For one, there is no reason the HTML would need to be included in the C code (if you even use C with CGI. I rarely see it). Rather you would just put it in template files that the C code reads in. HTML layout changes would not need to be reflected in the C code.
Thank God for moderators.
As for IPC, most IPC should be done through a little piece of software called *GASP* a database. If you really need something other than that there are modules ( IPC::Sharable comes to mind ) that make IPC easy. Write a nice wrapper around your use of that and it is not hard - really.
Purveyors of Application Servers are just marketroids that try to FUD middle managers into telling their programmers to scrap all their perfectly functional and extensible code so they can buy ( for mucho $$ ) a buzzword-compatible 'framework' that their programmers will have to learn. This framework will be closed source and won't do everything you want it to. You will find yourself wanting to change something that you can't.
"But what's to change? Our framework has modules to speak tons of protocols and zillions of useful utilities." they say
SO DOES CPAN! and you can look at/change the source of those! I seriously doubt there is a canned Application Server with a 'useful code' library that can compete with CPAN.
But middle manager types make their careers by taking 'ideas' from salesmen and then taking credit for getting them implemented, so many will find themselves in charge of bigger budgets and get promotions for causing existing code to be reimplemented with an inferior product that locks their companies into spending more money. ( Look at how much money I can spend! Gee that's alot of responsibility. I need a raise or a promotion or something for pissing this much away! )
Eat at Joe's.
Try a twenty-step initialization. Or one that isn't completely linear. You'll learn to appreciate goto.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
I can't say that I don't give a fuck. I've just run out of fuck to give.
huh? how would you write equivalent code for the driver_init() example using exceptions, without adding some other complexity that wouldn't need exceptions to work?
I'm not familiar with all the nuances of C++, but it doesn't seem possible using Java-style try-catch.
Its a bit like saying a 747 pilot might have to learn to drive a car to get to and from the airport. The skills to do the latter are virtually inconsequential compared to the skills required by the former so the point is trivial and irrelevant.
--- Hanji 2003-02-21 13:40:53.000000000 -0600
+++ lkaos 2003-02-21 13:40:26.000000000 -0600
@@ -1,5 +1,6 @@
int main(int argc, char ** argv)
{
+printf("Content-Type: text/plain\n\n");
printf("I disagree.\n");
printf("CGI is great - ");
printf("I don't see why anyone doesn't like");
int func(int a);
func((b += 3, b));