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

Comments

cgi underrated

[Anonymous Coward]

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

CGI still has uses

[LordNimon]

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.

hmm...

[gyratedotorg]

instead of "why cgi is evil," maybe this article should have been named "why you should buy our product."

This is a press release

[legLess]

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.

He's setting up a straw man, then claiming that his own (proprietary, for-profit ... 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).

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

Bunk!

[HRbnjR]

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!

Re:Misuse of an acronym?

[aridhol]

Servlets are small Java programs that are mapped to a directory on the website (like /administration/). They're compiled and placed into the classpath, and then the server executes them in the JVM when a request is made.

Yes, servlets exist, but I feel that they are closer to CGI than to template- or content-based languages. In order to create any output, you still have to use a print()-like function (haven't done much with Servlets, so I can't remember the actual method used here).

However, a JSP is automatically preprocessed into a servlet before it's compiled into bytecode, so it actually is a halfway point ;)

Re:Misuse of an acronym?

[jrumney]

Unfortunately, your rant is wrong. CGI is not an interface between a server and a browser at all. That interface is called HTTP.

CGI is an interface between a webserver and external subprocesses that has been in decline since faster alternatives started appearing in about 1995. While it is technically possible to write CGI programs in Java, PHP or Perl, it is not common. Servlets, PHP, mod_perl and other modern ways of generating dynamic content do not use the CGI interface, instead they have their own more efficient interfaces.

Debugging with printfs

[p3d0]

Actually, sometimes debugging with printfs is much better than gdb. Two situations occur to me:

• The problem is nondeterministic. If the failure occurs only once in 100 runs, you probably won't see it when you run it in gdb, especially if it's timing-dependent (in which case gdb may stop it from occurring at all). However, with a proper debug trace, you can just grab the log file when the crash does occur, and do a lot of diagnosis from that (plus possibly the core file if you get one of those).
• The program state and state transitions are too complex. For instance, try to debug a compiler without a good debug trace facility. It's just not very practical to walk complex IR data structures manually after various optimizations have been performed.

Re:But why does the Linux kernel use so many 'goto

[aridhol]

When you're initializing a driver, it's generally easier to do something like this:

int driver_init() {
if (!init_step_1()) goto error_1;
if (!init_step_2()) goto error_2;
if (!init_step_3()) goto error_3;
return success;
error_3:
cleanup_step_2();
error_2:
cleanup_step_1();
error_1:
return failure;
}

Because you can't just exit a failure with half-initialized resources that won't be freed automatically on exit ('cause it won't exit until you shut down).

Dammit, <ecode> killed my indents. Anybody know how to prevent that?

Re:But why does the Linux kernel use so many 'goto

[Mr. Slippery]

Because you can't just exit a failure with half-initialized resources that won't be freed automatically on exit ('cause it won't exit until you shut down).

Right. Basically, well-used C gotos provide the functionality that a try-catch block would in C++. Like many C constructs, they can be dangerous in the hands of the ignorant and elegant in the hands of the wise.