Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Perl Books Media Programming Book Reviews

Writing CGI Applications with Perl 250

Posted by timothy from the use-little-scripts dept.
davorg contributes his review of Writing CGI Applications With Perl, writing "There are a very large number of Perl CGI books in the shops. Unfortunately the number of good Perl CGI books is far smaller. I'm happy to report that this book is one of them." Read on for the rest.
Writing CGI Applications With Perl
author Kevin Meltzer and Brent Michalski
pages 500
publisher Addison Wesley, 2001
rating 9/10
reviewer Dave Cross
ISBN 0-201-71014-5
summary Great Introduction To Writing CGI Programs in Perl

The problem, of course, with most Perl CGI books is that they are written by people who just don't know very much Perl. That's certainly not the case here. Both Kevin and Brent are well-respected members of the Perl community and they know what they are talking about when it comes to writing CGI programs in Perl.

Another common mistake in Perl CGI books is that the authors try to take people who know a bit of HTML and teach them programming, Perl and CGI all at the same time. The authors of this book realise that this approach is likely to lead to, at best, patchy understanding of any of these concepts so they aim there book at people who are already programmers and who have some knowledge of Perl. This means that they can concentrate of teaching the parts of Perl that are useful when writing CGI programs.

One corner that is often cut when discussing CGI programming is security. This is a very dangerous approach to take as a badly written CGI program can leave your web server open to attack from anyone on the Internet. That's not a mistake that is made here as the authors introduce security in chapter 2. Add to that the fact that the code examples all use -w, use strict and CGI.pm and the book is already head and shoulders above most of its competition.

Early chapters look at common CGI requirements such as file uploads and cookies. Each chapter is full of well written (and well-explained) sample code. The example of an access counter in chapter 6 even locks the file containing the current count - this is possibly a first in a Perl CGI book!

By the middle of the book we have already moved beyond simple CGI programming and are looking at mod_perl. This chapter covers both the "faux-CGI" Apache::Registry module and also writing complete mod_perl handlers.

In the second half of the book we start to look at some bigger examples. The authors present a web-based email system and even a shopping cart. In order to fit these examples into their respective chapters a couple of corners have been cut, but there's enough information there to enable anyone to write the complete systems.

Chapter 13 introduces the HTML::Mason module as a way to separate content from presentation. It's obvious that the author's are big fans of this module and this leads to my only real criticism of the book. At no point do they mention the fact that the same benefits can be gained from using any of half a dozen templating systems found on the CPAN. I would have been a lot happier if they had mentioned things like Text::Template, HTML::Template and the Template Toolkit before picking HTML::Mason as the system for their example.

There are then two more long chapters with examples of a document-management system and image-manipulation software. Once more, the code in these examples would serve as a great starting point for anyone wanting to implement something along these lines. The last chapter looks at XML and, in particular, the use of RSS files to provide data feeds to other web sites.

All in all this is a very useful book for someone wanting to write web-based applications using Perl. It's packed full of good advice and code that follows all of the best practices for writing CGI programs in Perl. This book won't teach you Perl, but if you've read Learning Perl or Elements of Programming with Perl then you'll find this book easy enough to follow.

You can purchase Writing CGI Applications with Perl from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.
This discussion has been archived. No new comments can be posted.

Writing CGI Applications with Perl More

Writing CGI Applications with Perl

Comments Filter:

  • 24 Hours (Score:2, Insightful)

    by JohnHegarty ( 453016 )
    I found sams Teach Your Self Perl in 24hour very good as a starter.... (isbn 0-672-31773-7)

    got all the basics and enough to start on cgi... evan if you don't know perl to start with...
    • Bah, php is sooo much more intuitive than cgi. cgi is dead, dead as ASP

      • Re:24 Hours (Score:3, Informative)

        by sheriff_p ( 138609 )
        Your ignorance is exceeded only by your stupidity. CGI is, and I quote:
        "A set of rules that describe how a Web Server communicates with another piece of software on the same machine, and how the other piece of software (the 'CGI program') talks to the web server."
        This also makes PHP use CGI, so your comment is somewhat akin to saying "Windows is dead! Use Windows 2000!" or something equally thoughtless and banal.
        As far as concerns intuitive, what do you mean? It's easier to learn? Or do you mean you can guess at writing it? Time to find a dictionary, young Jedi.
        But, assuming you hadn't been talking utter nonsence, a quick look at jobserve, one of the biggest UK jobs sites, shows 812 ASP-related jobs, 351 Perl-related jobs, and 70 PHP-related jobs.
        So, what *exactly* are you basing your ignorant comments on?

        • Common Gateway Interface (CGI) is a specific [uiuc.edu] interface between web server and code. This interface relies on a "shelling" style system.

          PHP does not use CGI neither does ASP. By your own statement you state "A set of rules that describe how a Web Server communicates with another piece of software on the same machine..." oblivious to the fact that neither ASP, PHP or any of the modern decent languages comply with these "rules".

          Both environments utilise intstructions within the HTML code that are recognised and subsequently executed by interpreters often loaded in the web server application space.

          They DO NOT rely on environment variables, command lines and input/output files all of which are part of the CGI standard. CGI is quite rightly on it's last legs because shelling out to executables is both a security risk and processor intensive.

          Perhaps you should be more careful what you are basing your ignorant comments on.

        • Wow, arrogance and ignorance, all wrapped up into one big ball!

          Common Gateway Interface is, yes, "a set of rules that describe...", but note the indefinite article in your definition. There are, young jedi, other sets of rules as well, and PHP and ASP, among others, use those other interfaces. To continue your analogy, "Windows 2000 is a software layer between applications and hardware, and Unix is a layer between applications and hardware, so...Unix is Windows!"

          (Oh, and if you're going to quote so plonkingly, would you mind citing the quotation? If you're quoting your bother-in-law the butcher, that's a little different from quoting an RFC.)


          • To continue your analogy, "Windows 2000 is a software layer between applications and hardware, and Unix is a layer between applications and hardware, so...Unix is Windows!"

            actually they are both operating systems.


            [golux.com]
            The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.
            • Yes, of course they are both operating systems! I was simply echoing sheriff_p's reasoning [slashdot.org] in a sarcastic manner. How in God's name he got a +3 informative I'll never know -- given the way he wrote that post it's hard to believe he has three friends, yet it's even harder to believe that three people (people with mod points, at that!) thought they'd learned something reading that post.

              Thank you, BTW, for citing your source. It doesn't change sheriff_p's point, since the issue wasn't so much that his definition was wrong -- it wasn't, just not as complete as he apparently thought -- but that he made such a big deal out of it ("and I quote", he says, but doesn't get around to telling us whom he's quoting)

        • Your ignorance is exceeded only by your stupidity. CGI is, and I quote: "A set of rules that describe how a Web Server communicates with another piece of software on the same machine, and how the other piece of software (the 'CGI program') talks to the web server."

          Brother, you seem to have a beam in your eye.

          Although it is possible to compile PHP to use the Common Gateway Interface, this is extremely rarely done (I do still have one server on which it is done, but that's because that particular server has had no software change since 1996). Almost all PHP is now run in process (as, indeed, can PERL be scripts if you use Apache's mod_perl). The Common Gateway Interface is now very rarely used in professional or production projects, although it remains appropriate for quick'n'dirty hacks.

          But, assuming you hadn't been talking utter nonsence, a quick look at jobserve, one of the biggest UK jobs sites, shows 812 ASP-related jobs, 351 Perl-related jobs, and 70 PHP-related jobs.

          ... and 2002 Java related jobs, of which the majority will be server-side. So you're comprehensively wrong on all points.

          CGI is, indeed, " A set of rules that describe how a Web Server communicates with another piece of software on the same machine, and how the other piece of software (the 'CGI program') talks to the web server." However, it isn't the only set of rules or the best set of rules, and most server-side dynamic content is now produced in-process one way or another. CGI is just too inefficient for production use.

      • Re:24 Hours (Score:3, Insightful)

        by gimpboy ( 34912 )
        php may be more intuitive at first, but it seriously lacks alot of the functionality that comes with other languages like perl and python. while i can only speak for perl, i understand python has a similar component base. perl has cpan [cpan.org] which makes php look like a screwdriver in a workshop full of tools. if you only plan on making a web page to take form variables and email them to someone, sure php is great. if you want to make a serious web-based application and you dont want to make everything from scratch then php is really inadiquate.

        i speak from expirence here. about a year ago i made the switch from php to perl and i haven't been happier. at the time of leaving the only database abstraction layer was in beta while perl had dbi in a quite stable form.

        while i realize the parent was probably a troll, i would strongly encourage people considering php vs (perl, python, etc.) to consider the amount of code already available outside of the base distribution of the scripting language.

    • Re:24 Hours (Score:4, Insightful)

      by southpolesammy ( 150094 ) on Wednesday June 12, 2002 @09:33AM (#3686020) Journal
      You may be able to learn some neat things in Perl in 24 hours, but will you remember them without the book in 24 more hours?
    • got all the basics and enough to start on cgi...

      Ok, while I agree that Perl is easy to learn, one should be carefull to call himself a programmer afther reading one of these book.

      Obviously, if you get down to programming CGI in one day, how can you know all the pitfalls you will have to avoid in order to make your CGI secure?

      So many scripts are flawed or even dangerous. Just look at the (popular) pile of crap that is Matt's Script Archive. Those CGI aren't even programmed with CGI.pm, they are badly designed, and aimed at non-programmers that will install them on their servers, not knowing much more than they have to make the script executable so it will run.

      Programming CGIs should always be done with great care, and is a task best left in the hands of professionals.

      • Re:24 Hours (Score:5, Informative)

        by twoshortplanks ( 124523 ) on Wednesday June 12, 2002 @09:54AM (#3686178) Homepage
        There are some good resources out there that have scripts that have been peer reviewed by many many skilled and professional Perl programmers.

        nms [sourceforge.net] is such a place. It has replacements for all of Matt's scripts - and Matt himself has suggested using them as replacements for his buggy versions

        I'm sure the author of this review would agree with me that this is a good place to go to get scripts ;-)

  • It's good to finally see a CGI/Perl book pushing strict and warnings. Of course, that's not going to ensure good programming, I've seen some horribly stupid code pass the test with use strict;. Do they use Taint mode at all? Is there any mention of how dumb CGI can be, and the nasty pits it can leave when problems (not obvious to the new guy, like unchecked open filehandles) are ignored?

    Also, what's wrong with Mason? They may have recommended it because it makes an easy transition into mod_perl, as it can be used either way.

    • Re:Strict (Score:1, Informative)

      by davorg ( 249071 )
      Do they use Taint mode at all?

      Yeah, that's covered in great depth the section on security that I mentioned in the review.

      Also, what's wrong with Mason?

      Oh, nothing. It's just that I would rather not have had it presented as the only templating solution.

      • Re:Strict (Score:2, Informative)

        by twoshortplanks ( 124523 )
        davorg wrote:
        Do they use Taint mode at all?
        Yeah, that's covered in great depth the section on security that I mentioned in the review.
        Also, what's wrong with Mason?
        Oh, nothing. It's just that I would rather not have had it presented as the only templating solution.
        And someone marked it offtopic. How can that be offtopic? It's a direct answer to a question about the review

  • Uh, what? (Score:5, Insightful)

    by jabbo ( 860 ) <jabbo@yahooMOSCOW.com minus city> on Wednesday June 12, 2002 @09:29AM (#3685990)
    This is a little late in the game for a book that discusses ways to fork off a separate process for each hit on your dynamic pages. I'm sure the authors are studs and all, but if you're programming web applications in Perl, how about using mod_perl, and if you're going to do that, why not bite the bullet and buy Lincoln Stein and Doug Eachern's book from O'Reilly? It is a classic.

    Speaking of classics, the old "Writing Web Clients with Perl" is being superseded this month by Sean Burke's "Perl and LWP". Now speaking of Perl studs, they don't get much studlier than Sean, and LWP is (IMHO) the Killer App for Perl programmers. Another fine O'Reilly title (too bad "fine O'Reilly title" is not redundant anymore).

    Also from O'Reilly (yawn) is Rasmus Lerdorf's "Programming PHP". I was *very* pleasantly surprised by his book, it is MUCH better than it has any right to be, discussing everything from PEAR DB abstraction classes to speeding up your site with a Squid reverse cache and profiling.

    Anyways, that's just my shelf's worth. I use Perl and PHP every day (or at least every day I wear my programmer hat) to get things done fast. I know other people prefer Python and Ruby, hey, more power to them. But I figured I would point out some Fine O'Reilly Titles (note, once again, that phrase is now said more like "Honest Senator" rather than "Stupid Microsoft Security Hole") which have made me some money lately.

    YMMV...
    • If you're writing your apps using CGI.pm, and they're ok under 'use strict', then it's very very easy to get them running under mod_perl simply by using Apache::Registry.

      • Re:Uh, what? (Score:3, Interesting)

        by jabbo ( 860 )
        In the long run, though, you'll find that Apache::Registry is not the Better Way to do it... either .pm modules with tiny bits of front-end code for the handlers, or (IMHO) PHP with the same approach (class libraries or .so extensions in C). I chose PHP after a protracted battle and some development in both. PHP is slower than mod_perl for execution, but faster than either for development (assuming you push any nasty complex code into either C, classes, or classes calling C). Even with Inline.pm, and even after 4 years of writing Perl for web apps, I've finally sworn I'll never write another line of interface code in Perl. Backend? Sure. And reading the Eagle Book is a great way to get comfortable with how Apache actually works. But I've had enough of Perl on the front end, and if you look around, so have most other people.

        Not a flame, just an observation. Apache::Registry is not a panacea.

        • Re:Uh, what? (Score:3, Informative)

          by gorilla ( 36491 )
          My prefered solution is actually HTML::Mason [masonhq.com], which gives simple embedding of perl code & components into webpages. However, CGI.pm and Apache::Registery is the most portable solution, as it gives a program that can be run on both CGI & mod_perl enabled webservers.
    • This is a little late in the game for a book that discusses ways to fork off a separate process for each hit on your dynamic pages. I'm sure the authors are studs and all, but if you're programming web applications in Perl, how about using mod_perl, and if you're going to do that, why not bite the bullet and buy Lincoln Stein and Doug Eachern's book from O'Reilly? It is a classic.


      Not reading the article - bad; not reading the writeup at the top of the page before commenting -- very bad; -1 redundant post moderated up to 5: mind-blowing. Moderators, if you can't be arsed to read the article, don't moderate! Sheesh...
      • The book takes 6 chapters to get to mod_perl handlers. In that span, Stein and Eachern have already:

        1) shown you how to fit the pieces of Apache together,
        2) written sample code for 3 of the 7 standard phases of the Apache request cycle, and
        3) actually given you some insight into how to extend Apache for other purposes.

        Lincoln used to write CGI scripts. He wrote CGI.pm, in fact. Don't you think the fact that he wrote his most notable programming book on mod_perl is a telltale sign of what I find wrong with this book AND the review?

        And that witty riposte -- my god! I've never in my entire life heard that one before! Quick, somebody get Jerry Seinfeld's agent on the phone.

        I can be 'arsed' to read an article and (gasp!) form an opinion about it based on my own experience... 7 solid years of it, in this field. And looking back (with the current toolset) I would not want to see ANYONE start off re-inventing the wheel with Perl CGI scripts. Hell, if you're going to re-invent the wheel, at least make it round. CGI is, was, and will always be a kludge. Apache::Registry is a kludge to shoehorn CGI kludgers into the Better Way. Personally, I'd rather see people start out with PHP, because even if their code looks like trash, at least I can write a parser to fix it.

        End of rant.
        • CGI is, was, and will always be a kludge.

          What, you don't think that using shell environment variables is a natural way to access http request information?

    • I think people often completely miss a lot of great titles on open source topics because of O'Reilly. There have been many times where I found a topic that O'Reilly and some other press had a title published about the topic, and often the non O'Reilly titles were at least as good as the O'Reilly titles.

      I wrote a book, with a co-author, on PHP that was released about the same time Programming PHP was. Nothing against Programming PHP, it is a nice book. I read it cover to cover. It has strengths and weaknesses. But I think the book I wrote stacks up at least as well as Programming PHP, yet it is practically invisible because of the O'Reilly open source factor.

      Don't take this as me saying, "my book is the greatest thing since sliced bread",or anything like that. My book does not cover extending PHP in C, among a couple of other topics it really should have covered. But it does cover database abstraction using Pear DB. Also covered is Image manipulation, creating PDF documents, XML, almost everything a professional PHP programmer would encounter. Yet, the PHP book had very high visibility before it was even out! Anyways, don't take this post as cynical or jaded about my book not having the high visiblity etc., I wrote the book for the love of it, not for the money.

      A quick and interesting aside, Rasmus did not write a majority of the book yet he always gets the credit for Programming PHP ;).

      Jeremy
      • A quick and interesting aside, Rasmus did not write a majority of the book yet he always gets the credit for Programming PHP ;).

        This explains a great deal of why it didn't suck. I had a sneaking suspicion that was the case.

        Bummer about your book getting spined ;-). I agree with you about the O'Reilly 'shadow'; I have a Manning title ("Data Munging with Perl") on my shelf at work that, in 2 chapters, probably made my company $50K. There is no comparable O'Reilly title worth a damn. And like I said in my post, "fine O'Reilly titles" are becoming a rare thing. But it's a lamentable reality of the current publishing environment that O'Reilly's brand recognition will carry all but the absolute weakest titles, at least for a while. They need some competition in order to bring the quality back up.

        It just doesn't sound (to me) like the reviewed book is an example of the caliber of competition needed. YMMV.

      • "Another fine O'Reilly title" is still often redundant. Even if not Excellent, they are often Very Good, or at least Good Enough, and I've only once encountered one (on UML, and it's long out of print) that was Mostly Useless. I trust the brand. Often I can't wait weeks to months for the reviews to come out before I buy a book. So I buy the brand I trust.
    • buy Lincoln Stein and Doug Eachern's book from O'Reilly? It is a classic.

      A classic, and no longer the only book in the field. mod_perl Developer's Cookbook [modperlcookbook.org] is a tremendous tome, and I use it more than the the LDS/DOUGM book. It's well worth looking at.

      It's not better than the eagle book, but if I could only buy one, that would be it.

  • Although I love using Perl and am pretty good with it, I don't see why people still use Perl for CGI applications. I've grown accustomed to using PHP for all of my web apps and stick to using Perl for system administration tasks and in cron jobs that populate my databases. With languages like PHP, Python, and Ruby, why would someone still use Perl for CGI? I guess the only exception that I can think of would be if you need to make a web application on a server that you don't admin, and on which one of these other languages isn't available.
    • Because Perl is more powerful and faster than PHP? Perl is a far more developed language than PHP, Python, or Ruby.

      Translating your question into client side programming speak:

      "Why use Visual C++ when you can just use Visual Basic?"

      Of course, thanks to .NET, VB.Net is as powerful as VC++.NET, but that never used to be the way ;-)

      Perl is a powerful language with far more backing than PHP, Python, or Ruby. The amount of modules you can get for Perl makes it a very wise language to use if you want to do anything advanced.. i.e. XML-RPC, SOAP, image manipulation on the fly, system integration, etc.

      PHP cannot do many of these things well.. and it cannot do them very quickly. PHP is a toy language for kiddies who are still playing with MySQL databases ;-)
      • I don't think the argument is whether or not Perl is a better language than PHP, I think the argument is whether or not writing web apps using the CGI is better than writing web apps using PHP.

        I recently started learning Perl/CGI, just for S&Gs to use on some hobby web sites I'm thinking of developing. I realized that a lot of what I was doing in Perl w/CGI I could do just as easily, and in many cases in fewer lines, in PHP. I already knew PHP so I ended up using PHP instead of Perl.

        I think that Perl is still best used for it's original purpose, as Operating System "glue". It's great for system admin tasks, parsing through many lines of text, etc... PHP is better for rapid website development.

        PS Visual C++.NET is still more powerful than VB.NET since it allows you to use pointers and manipulate the memory directly. So the hierarchy of power in .NET, at least with the MS family of languages from most powerful to least powerful is
        VC++.NET
        C#.NET
        VB.NET

        at least from what I can tell.

      • It's not so much what you can do with a language, it's what the language is good at.

        PHP is great when you want to quick and dirty mix code and HTML. As such is serves a purpose.
        If you try to separate content and presentation, fine, it can be done, but it's not the natural strength of the language.


        Perl's natural strength, in my opinion, is in writing routines that process textual data. PHP's natural applications are, in a sense, a subset of these, when you want to do this in the context of HTML.


        Python is not as convenient as Perl for processing data, and much less convenient than PHP for web programming, but better perhaps for generation complex systems of objects, particularly persistent ones.

    • Re:Perl for CGI? why? (Score:3, Informative)

      by jc42 ( 318812 )
      > ... the only exception that I can think of would be if you need to make a web application on a server that you don't admin ...

      You hit the nail on the head.

      I run web sites on four machines. The one sitting in my home office is the only one where I'm the admin, and the ISP blocks port 80 on that one (not that this is a real problem, but ...).

      After experiments with PHP and Python, I've pretty much settled on perl for almost everything, with a few C programs as helpers. My perl CGI scripts run on all the machines without any changes, as do my C programs. With PHP and Python, I've found that every new machine requires a debug session to get anything to work, and I have to maintain huge sets of diffs for the different machines.

      But with perl, I can drop a new script in all my directories, and they just work. I have exactly one "per-machine" file CGI file, which lists the directories in which things are installed. Even that isn't necessary, but it's faster than the code to discover where things are.

      On one of my web sites, they still have perl 4, and my CGI scripts work fine. I can't install a current perl release, because my disk space there isn't enough to hold the unpacked perl source.

      Also, all the timing tests I've been able to run have given perl a substantial edge over everything else except C. But this is a small sample set, due to the difficulties in matching perl's capabilities in PHP (and the difficulties getting a recent Python version installed ;-).

      It would be nice to be able to depend on mod_perl, but the admins on several of these machines don't see the need for it. Even at several requests per second, my perl CGI scripts are an unmeasurable load on the machine. So why should the admins waste their time installing mod_perl for me, when it would only save a few seconds of cpu time per day?

    • Perl combined with a good template parser and you have the best tool for developing web apps. Perl is fast, stable, powerful and ubiquitous.

      The primary mode of PHP development is to mix code within your html. This works for small or single purpose applications but sucks if you want to develop a server app that uses several different sets of templates customized for different users.
    • Why do I write CGI with Perl? You said it yourself. "I love using Perl and am pretty good with it." If given the choice between spending my time learning a new language or spending my time writing scripts in the language I know, I'll chose the second.

  • I can see why they chose Mason (Score:3, Insightful)

    by madprof ( 4723 ) on Wednesday June 12, 2002 @09:33AM (#3686010)
    HTML::Mason is one of the most sophisticated Perl tools for templating web sites, and indeed it does a whole lot more than mere templating.
    It'd be my first choice for including in a general book as although it can get more complex (and powerful) when necessary it is actually very easy to use for simple sites.
    However yes to be fair you'd not want to ignore the very good work done by other module authors.

  • CGI isn't used much anymore... (Score:4, Informative)

    by FortKnox ( 169099 ) on Wednesday June 12, 2002 @09:33AM (#3686018) Homepage Journal
    Sure, when perl was booming, CGI was all about the web, but now-a-days you find more PHP in use than perl for quick projects (or ASP for IIS users), and ColdFusion or J2EE for large web apps (I prefer J2EE with struts and taglibs, as they are cleaner).

    Hate to sound like a "*BSD is Dead" troll, but CGI is a dying breed (NOT PERL, just CGI). I'd suggest skipping this book in lew of a more popular web-app language.
    • I understand your point. CGI isn't used as much as it used to be, however...

      As I said in another post, since you can run Perl CGI scripts in mod_perl (i.e. with perl built directly into Apache itself) the stuff covered in this book is still quite useful. Many powerful sites (including this one) use mod_perl, and it's a good skill to learn...starting off with CGI programming is one good way to start to go about that.

      • Just to be a twit:
        isn't CGI the generic standard? Possibly, "Perl CGI" is less used than it used to be, (which is an interesting groundshift, one of the first non-MS developments that I'm behind the curve on--PHP seems really kludgey in parts to me, though I respect its builtin libraries) but I think just about every form in HTML points to a "Common Gateway Interface" script, you know, the thing about POSTs and GETs.
        • People think PHP is something special. The reality is it is more like perl than not. It's truly funny watching people say perl is old and outdated for CGI use and then turn around and claim PHP is somehow better. PHP is simply an ad-hoc language just like perl. Each uses various syntax and semantics from C, Java, even BASIC (probably much closer to BASIC semantics than anything). Having two or more syntactic ways of doing a semantic process is _not_ really a good idea (code maintenance becomes more difficult).

          CGI is CGI. Perl has mod_perl, so it is on par with PHP. I'd really love to see mod_scheme. Scheme is perfect, IMO, because the ease of use and the base language, R5RS, has very useful functions which are perfect for web use. All that would be needed is an addon library to make the language a little more complete. Of course there is always mod_python, which I've heard is Lisp/Scheme-like.
    • ColdFusion for large apps? Now that's a scary thought.
    • Sure, when perl was booming, CGI was all about the web, but now-a-days you find more PHP in use than perl for quick projects (or ASP for IIS users)

      For a while there I was giving ASP a try. But 80% of the time, I would do the little project in ASP, and then a couple weeks later I'd get a request for more and more advanced features which were either impossible in ASP, or much much more realistic in a real Perl CGI application. Inevitably I'd have to rewrite the application in Perl for any real power.

      I'll stick to Perl CGI.
      • ASP is pretty language-agnostic. You can use VBScript, JScript, or PerlScript to write the code in the pages. Since ASP does a lot of nice things for its hosted languages (session context, form parsing, script precompile/caching) I can't see why you'd want to go Perl CGI when you could go PerlScript ASP.

    • Re:CGI isn't used much anymore... (Score:4, Informative)

      by pubjames ( 468013 ) on Wednesday June 12, 2002 @10:59AM (#3686774)
      Sure, when perl was booming, CGI was all about the web, but now-a-days you find more PHP in use than perl for quick projects [..], and ColdFusion or J2EE for large web apps[..].

      It's a shame that PHP has this reputation for only being good for 'quick and dirty' projects. I guess it is because there is so much badly hacked together PHP code available on the web. Or perhaps it's the "it can't be good - it's free" meme.

      I have come across a couple of CTOs who are put off PHP by its reputation, which is a real shame. They think it is a toy language and not suitable for large commercial projects. However, the reality is that PHP is now an extremely well designed and advanced language, and good for even very large projects. It has some extremely competent techies working on it. It is also well maintained and advancing rapidly. So, if you don't fancy PHP because of its reputation, I suggest you take another look at it.
      • Our own http://www.logicreate.com [logicreate.com] product is an example of a complex system which makes PHP development of large scale projects easier than you'd think, based on the tediousness of most online PHP tutorials.

        Yes this is primarily a shameless plug, but rather than just saying 'PHP is not a toy' I figured I'd give an actual example. :)
      • I wouldn't say it's a toy language, but neither would I say it's suitable for large commercial projects. I use PHP for a lot of CMS stuff and there is little that can touch it for speed of development. However, I would say PHP suffers compared to J2EE in two areas:
        • Lack of persistance - in Java you can share memory-resident data between threads which means J2EE can scale considerably beyond PHP
        • Human 'resources' - Java programmers tend to come from a software engineering background, are used to working in teams, and have experience in using the tools such as CVS that are needed for larger projects.

        I agree that a lot of people underestimate PHP, which is excellent, but it is a tool for a job. imho it's for small to medium-large projects. I'm not sure I would recommend it for a seriously large project though.

        Phillip.
    • Hate to sound like a "*BSD is Dead" troll, but CGI is a dying breed...

      But it will never go away entirely. For a lot of simple things CGI is quite appropriate. At work, we have a feed monitoring utility that just generates tables of timestamps. I have very rarely seen it fail. And when it does, it doesn't happen twice in a row unless there's something wrong with the database or the web server. For something mission-critical like your feed monitoring utility you don't want some stateful enterprise application amorphous cloud super server to get it's tentacles in a tangle. CGI is very easy to use, understand, and debug. Don't rule it out alltogether. It's just a tool for niche stateless applications.

  • As an alternative to Perl...... (Score:3, Informative)

    by forged ( 206127 ) on Wednesday June 12, 2002 @09:36AM (#3686032) Homepage Journal
    I don't mean to criticize Perl, since it's my favourite language for medium to complex applications for years. You just can't beat the power of regexps :)

    Yet, I've found myself writing more and more smaller apps using PHP [php.net] instead of perl. It's by the Apache group and essentially merges into the www server, making it very quick. You can still use mod_perl for perl apps.

    Along with your preferred SQL database, progranmming in PHP is a breeze. Basically, write html pages and add the commands you need embedded inside. The best PHP book I have on that topic is PHP and MySQL Web Development [amazon.com] (ISBN: 0672317842) second to none.

    • You might want to look at some of the templating systems that are avalible. davorg mentioned The Template Toolkit [tt2.org] in his review; This is a templating system that would allow you to use a very basic set of commands inline inside HTML to do simple looping and SQL stuff - and then to use pure Perl plugins (which you can easily write yourself) to get at the full power of Perl when you need it.

      And yes, templating systems do scale. The code that runs this site uses the Template Toolkit - there's even a section in the Slash ORA book on it.

    • If you want a good alternative to PHP check out EmbPerl (works with mod_perl, but it is a lot easier than writing mod_perl scripts by hand), it allows you to embed Perl code into HTML similar to the way PHP works, except you've got all the power of Perl, all of the CPAN goodness to draw from, and you can much more easily mix-and-match with other Perl code (for instance back-end code like cron jobs and other stuff that most apps need).
    • I've done a lot of web development, in a variety of languages. I've been working in the ISP sector since 1993 - I wrote tools and utils for AmiTCP in-between increasing the dogearedness of my pink-cover first version camel book.

      PHP suffers from the same issues as JSP when it comes to building webapps and toys. It's also not really the most efficient system around either.

      Much as I love Perl, and have always enjoyed knocking out CGI systems - including one of the first "fansite"s which offered people free custom emails and URLs (warbirds.org), and I've had lots of fun with PHP, I have personally found Roxen [roxen.com]s built in RXML mark-up language to be one of the most efficient systems for developing web applications in terms of design, implementation and operation.

      Roxen was born "Spinner" back around, if not before. In all those years since, I've yet to find a good or compelling reason to use Apache, Perl or PHP instead of Roxen beyond the head-count factor. The Roxen developers make their money through 'value adding' their open source webserver platform, but never really tried to market themselves.

    • OT: Perl... (Score:2, Funny)

      by Erotomek ( 584106 )

      I don't mean to criticize Perl, since it's my favourite language for medium to complex applications for years. You just can't beat the power of regexps :)

      You can call me a twisted pervert, but I just can't wait until I sit in front of my future Debian GNU/Hurd 4.0+ system to hack some insane Perl 6 code, drinking espresso and listening to The Ride of the Valkyrie of Richard Wagner...

  • I've got this book (Score:5, Informative)

    by legLess ( 127550 ) on Wednesday June 12, 2002 @09:51AM (#3686154) Journal
    I bought this book, and I wish I hadn't. It's not horrible, but I think there are better alternatives (like "the Mouse book" - O'Reilly's CGI Programming with Perl [oreilly.com], which I love). These are a couple of my specific gripes with the book:
    • It looks like a nice thick book, but it's very padded. The font is huge (12 to 14 points), there's a lot of padding (most code samples listed twice, 40 pages of appendix material that could have been 8 URLs), the margins are huge, and there's an awful lot of repetition (the 10 lines justifying -wT are repeated nearly every time it's used in a program). I bet that the Mouse book squeezes twice as much content into 450 pages as this one does in 525.
    • Some chapters belong better in a Perl book ("Tied Variables").
    • Some inclusions/exclusions and focus choices are very odd. There's a very detailed chapter for Mason, but no mention of templates (literally - not even in the index).
    • Their style is very choppy. They'll present a couple lines of code, then a paragraph talking about it, repeat. It's very difficult to get a cohesive view of the program this way - it's spoon-fed to you rather than presented whole. (Undoubtedly this is why they repeat all the code at the end of each chapter, but I prefer longer chunks of unbroken code).
    In short, the book is much more vocational than educational. I think this was a conscious decision of theirs, and as such I can hardly fault it - they know their target audience better than I do. However, I've not opened this book once since I read it (cover-to-cover), while I still refer to the Mouse weekly.

    Need to hack up some code fast? This book will help. If you really want to learn CGI, to know why and how it works, to have a broader grounding in the technologies used with it, and to build a firm foundation for future self-teaching, then IMHO nothing beats the Mouse book.
    • I agree -- the mouse book rocks! The part on CGI debugging is particularly good. Not only that but the first edition is free [oreilly.com] in digital form.
  • ...is the best way to eat all the memory on a server and end into a complete freeze. That's what I can see everyday on servers running different CGI apps written in Perl. On the other hand, PHP is fast and doesn't eat your memory. Of course I'll be answered that well-programmed Perl CGI apps don't eat the memory. Maybe, maybe not. The fact is I can see all those Perl CGI apps designed by more or less experienced programmers, and all those PHP apps designed by the same people. And the consequences of each ones are (very) different.
    • It's not hard to write good CGI programs in Perl if you know a little about Perl, and this book would help you do that. Let's not get into language flames. This website runs on Perl and slashcode scales pretty well indeed.

      For a bunch of secure well-written CGI programs for specific tasks, you can't beat nms [sourceforge.net]. Hope this helps.


  • One corner that is often cut when discussing CGI programming is security. This is a very dangerous approach to take as a badly written CGI program can leave your web server open to attack from anyone on the Internet. That's not a mistake that is made here as the authors introduce security in chapter 2. Add to that the fact that the code examples all use -w, use strict and CGI.pm and the book is already head and shoulders above most of its competition.


    This is a big one for me. As a programmer, it has become increasingly difficult to compete with hackjobs out there. Anyone can pick up a book and begin writing Perl CGI or PHP websites, but not everyone has the experience to secure those systems, or to identify bad code design that leaves built-in vulnerabilities. With some companies this is hard to convey -- well, when you are proposing a $25,000 solution and there is another company willing to do it for $5,000. Nevermind that they have two programmers on their staff willing to make $20,000 this year each and they have been programming off and on for a couple of years, but they like making web pages!

    • It sounds to me that your real complaint is that you are getting underbid by people without mortgages and car payments. Not that their code is insecure, which it usually is.
  • I have this book. I found it very useful, but lacking in some ways. The authors advertised this book as not merely presenting code, but the concepts that underlay what is going on. I found this book to be primarily a bunch of recipes...just the opposite of how it was advertised. They present alot of topics and I found the breadth of this book to be very good. I do feel however, that many subjects that were addressed were incomplete. For example, in the chapter on databases, they present the SQL function calls that they need for their example, but don't even provide a list of the interface functions to write a more general application. "How about telling me how to update an existing record?". I bought this book with a little exposure to perl, and less exposure to developing websites. I found that for most topics that they presented, I needed to track down additional documentation to do anything different then what was presented in the book.

    I did find the information on mod_perl, HTML::Mason, and RSS to be especially interesting.

    If you are looking for an introduction to developing web apps with perl this book presents a large number of technologies, and does a pretty good job. It definitly is not a reference, however.

  • Coming from an ASP background (Score:3, Interesting)

    by Pinball Wizard ( 161942 ) on Wednesday June 12, 2002 @12:02PM (#3687271) Homepage Journal
    I found this book very helpful. This and MySQL and Perl for the Web [amazon.com] were the two books I referred to most when translating a good sized ASP project into Perl. BTW the MySQL and Perl book is written by Paul Dubois, the author of MySQL [amazon.com](the book), and if I could choose only one of the two it would be that one.

    Both books show how to run CGI programs under a mod_perl enabled web server, using Apache::Registry. So the myth of the server forking a new process for each request is not true. CGI and Perl in this day and age can actually run rings around an ASP solution without the performance hit CGI applications are known for causing.

    I know Perl has a lot of detractors, but really you should at least give it a chance before you make up your mind about it. Perl is probably more portable than even Java, and it certainly is better for writing quick scripts and programs. You can make the code very readable if thats your goal, or you can express in one line of code what it would take other languages 5-10 lines to accomplish. Perl/CGI is the most portable way to write web apps so if you do consulting its a good way to go if you need things that will run on lots of different web servers. I've found the neatest libraries for Perl that I haven't seen in any other language - I just wrote a shopping cart that uses SQL to read and write to comma delimited text files! This made for a perfect solution for my client, and it will be easy to upgrade to a real database when he's ready.

    Oh by the way if you don't think Perl/CGI can handle heavy duty web sites, look at the slashcode sometime - unless they rewrote everything its still CGI code running under mod_perl/Apache::Registry.

  • Finish this book... (Score:3, Interesting)

    by pHaze ( 19163 ) on Wednesday June 12, 2002 @12:31PM (#3687521) Homepage
    ..and graduate to the excellent mod_perl cookbook.

  • Frameworks and Perl Criticism (Score:3, Insightful)

    by suavew ( 240392 ) <<suavew> <at> <yahoo.com>> on Wednesday June 12, 2002 @12:45PM (#3687643)
    I find a lot of Perl criticism is caused by the lack of a standard framework for CGI applications written in Perl. Other programming languages (PHP, ASP) provided a relatively more confined method for writing your app, whereas Perl can be a treasure chest or a pandora's box depending on your perspective.

    There are so many ways to write dynamic Web programs in Perl: embed Perl into your HTML (embperl), embed HTML into your Perl, use a templating system (HTML::Template, Mason, Template Toolkit, etc), mod_perl, and various combinations.

    In the end, I think this is a good thing. It means more choices and better adaptability for various situations. However, it can discourage new users of the language that can quickly write CGI programs in Perl, but wind up writing bad programs.

    For anyone looking for a Perl CGI framework, I highly encourage you to check out CGI::Application on CPAN. It integrates with HTML::Template, is lighweight, and makes it relatively easy to mod_perl-ify your code if you need performance boosts.

    -Will
    • I think Perl shines in a web application development environment because you can use it back-end to front-end. I'm running a mod_perl enabled Apache server with a MySQL DBMS with great success. I write my Apache modules in Perl, add a few PerlModules lines in my httpd.conf config file, and embed Perl directives in my HTML template pages with HTML::Embperl.

      One language glues together a web server and a database nicely. You could do something similar with Java using Jakarta and Tomcat [apache.org] if you are prefer Java. Both ways are terrific ways to expand your content delivery.

  • Perl and CGI? (Score:4, Funny)

    by tshak ( 173364 ) on Wednesday June 12, 2002 @12:45PM (#3687644) Homepage
    What next? A review on "Datastructures in Fortran"?

  • Muahahaaahaa (Score:2, Insightful)

    by Perlguy ( 17814 )
    For all the PHP zealots out there. Yes, I too like PHP, it has many good features.

    But, I find that if I want to do dynamic content, HTML::Mason is much better (for me at least). I can embed the Perl right into the HTML, plus Mason has a lot of other nice features that make it worthwhile.

    Plus, I am having a lot of fun reading all of the comments generated by this discussion.

    It really amazes me how people basically say things like "Well, I use X for this so everyone else should too"... The key to being a good web developer is using the right tool for the job AS WELL AS utilizing the tools available to you. you also need to take into account what you are better at. I am a Perl developer, sure, I could choose to write apps in C, Java, PHP, Ruby, whatnot, but then I am not utilizing MY talents to their fullest.

    Lots -O- flame-bait in these discussions, that is for sure...

    Brent

Slashdot Top Deals

Hackers are just a migratory lifeform with a tropism for computers.

Close