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

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

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.