Follow Slashdot blog updates by subscribing to our blog RSS feed

 


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

Web Development with Apache and Perl 221

Posted by michael from the what-you-need-to-know dept.
davorg writes "In the dim and distant past when I first started doing web development, there was a book that everybody had a copy of. It was called 'How to Set Up and Maintain a Web Site' and it was by Lincoln Stein. The reason why everyone owned (and, more importantly, read) it was that it contained a complete high-level snapshot of everything you needed to know in order to run a web site at that time. Unfortunately, after a second edition in 1997 the book hasn't been updated. I suppose that the subject area has grown so much that no-one thought that a complete overview would be too high-level to be useful. They were probably right." davorg's review continues below.
Web Development with Apache and Perl
author Theo Petersen
pages 400
publisher Manning
rating 8
reviewer davorg
ISBN 1-930110-06-5
summary Good Overview of the State of the Art in Open Source Web Development

I mention Stein's book because that's what this new book reminded me of most (that, by the way, is a huge compliment). Petersen realises that an overview of the whole web development area would be difficult to write (and, ultimately, unhelpful) so he restricts himself to a subset of the available technologies - Perl and Apache - and gives a thorough review of the state of the art of web development in these areas.

But before he gets into the details of Apache and Perl, in chapter 1 Petersen takes a look at the wider world of Open Source Software and in the process presents one of the best arguments I've seen in print for why a company should choose Open Source Software. In chapters 2 and 3 he takes the same approach with web servers and scripting languages, giving compelling reasons for choosing Apache and Perl.

Having chosen his architecture, in part 2, Petersen moves on to looking at some common tools for web development. Chapter 4 looks at databases. The two main Open Source Databases (MySQL and PostgreSQL) are compared and MySQL is chosen as the basis for the rest of the examples. Chapter 5 discusses the shortcomings of the standard CGI architecture and introduces mod_perl as an alternative. This is a good introduction to a technology that some people can find hard to get to grips with. Petersen takes us through the use of Apache::Registry before moving on to the complexity and power of mod_perl handlers.

Chapter 6 looks at the importance of security in web applications and discusses in some depth the problems of user authentication and the use of SSL for secure data transmission. Chapter 7 looks at ways to separate content from presentation. First we look briefly at server-side includes, but the majority of the chapter is taken up with a review of the various templating systems that are available for Perl. The chapter finishes with a detailed look at two of the most popular templating solutions - HTML::Mason and Template Toolkit.

Part 3 of the book looks at three different types of web site in great detail. In each case Petersen uses the examples to take a brief survey of a number of the existing tools. For example chapter 9 looks at a community web site and contains information about a number of web-based forums and chat rooms. It also takes an extended look at Slashcode the software that runs Slashdot. Chapter 9 takes a similar approach for intranet sites and Chapter 10 for online stores.

In part 4 we take a longer term view of a web site. Chapter 11 looks at content management systems and chapter 12 lookat at performance tuning. Both of these chapters are full of useful advice on how to make running a web server as painless as possible.

I think this is a very useful book to have on your bookshelf. Anyone who is developing web applications using Apache and Perl will find something useful in the book. It should be obvious that in order for a single book to cover so much ground, sometimes there isn't quite as much technical detail as you might like, but there is a good bibliography that will show you where to go for more information. In my opinion the high-level approach makes the book particularly useful for a couple of groups of potential readers. Firstly I think it makes a great introduction to the subject for someone coming to Apache and Perl for the first time. Secondly (and perhaps most importantly) I can see the book (in particular the first three chapters) being very useful reading material for a manager who is making a decision between using Open Source Software or some proprietary technology.

You can purchase Web Development with Apache and Perl from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Web Development with Apache and Perl More

Web Development with Apache and Perl

Comments Filter:

  • Sounds Like A Good Book, Creepy Cover Illustration (Score:4, Funny)

    by Gryphon ( 28880 ) on Thursday August 08, 2002 @10:28AM (#4032591)
    Manning Publications Company always seems to have these creepy cover illustrations.

    I much prefer the O'Reilly animals.

    And yes. I am being a little facetious here.
  • I really find it hard to believe that Perl with apache could be the best example for why OSS works! These are hardly the best example of what they can do for a person or corporation. When the possibilities are endless, how does Perl fall into the fold?
    • You obviously didn't even finish reading his sentence..I really find it hard to believe that Perl with apache could be the best example for why OSS works!

      From davorg's commentary, "in chapter 1 Petersen takes a look at the wider world of Open Source Software and in the process presents one of the best arguments I've seen in print for why a company should choose Open Source Software." That does *NOT* mean that Perl/Apache is the best argument for going Open Source, he's merely saying that the book provides good reasoning for doing so. The Mythical Man-Month was written 25 years ago and refers mainly to assembly and PL/I code (which is irrelevant since 95% of coding occurs in a higher level language today, and all's quiet on the PL/I front), but it still remains a definitive reference on software engineering principles and how to manage massive software projects. Good insight comes from the abstract, not the implemenatation.
  • Apache and Perl was the way to go in 1996, but times have changed. Systems like PHP and (here comes the -1 Flamebait mod) ASP are faster and more efficient than Perl CGI. Serious webmasters do it in Java or C anyhow, for serious speed.
    • You need to read up on EToys (RIP):

      http://www.perl.com/pub/a/2001/10/17/etoys.html [perl.com]

      Java is *not the answer*! Besides, I thought discussion on Slashdot was limited to software libre . . . .
      • The link points to a story about how EToys set up a corporate website on mod_perl. Not about how mod_perl was the greatest thing since sliced shit and regularly tromped C++ and Java in benchmarks, but just that one could do it. Big deal! I'm not talking about how one *can* do it -- I'd advocate Common LISP in that case -- but about how one should do it.
      • Perl CGI, when done correctly, can be a good solution for a large enterprise E-Commerce website. I don't like the look of the language, nor do I like how OOP is slapped in.

        BUT

        The chances of getting a large group of perl developers to code a large enterprise E-Comerce website and not take shortcuts nor kludges, and not to just fall away from good design and architecture is very rare.

        Java, along with J2EE, JSPs, and taglibs FORCE you to follow good practice and design. Its a lot harder to 'kludge' something up without still following design and OOP (granted, its still possible). Another thing I LOVE telling C++/Perl/ASP people is taglibs. No other language has anything similar. An HTML monkey, that has NO coding experience, can modify JSP's that utilize taglibs. It just produces XML that HTML monkeys view as just more HTML tags.

        All in all, having a perfectly designed J2EE website (built with experienced J2EE developers) vs a perfectly designed Perl/CGI website (built with experienced Perl developers) would show that the J2EE website would be easier to maintain and the ability of non-developers to change the design of the pages without any trouble.

        The only negative point of J2EE is that its MADE for large projects. If you have a small e-commerce website, J2EE is overkill, and will take too much time to write. Perl/CGI is great for this type of site. But that is where I draw the line.

        • Java, along with J2EE, JSPs, and taglibs FORCE you to follow good practice and design. Its a lot harder to 'kludge' something up without still following design and OOP (granted, its still possible). Another thing I LOVE telling C++/Perl/ASP people is taglibs. No other language has anything similar. An HTML monkey, that has NO coding experience, can modify JSP's that utilize taglibs. It just produces XML that HTML monkeys view as just more HTML tags.

          I think you should go to AxKit.org [axkit.org] then and tell them they have nothing similiar :-) . It's a direct (I think) port of Cocoon from Java into Perl.

    • yeah, but for some websites speed and beauty really don't matter.

      For a quick and dirty form or simple "database" of information perl is easiest for me. Why should I have to sit down and read through PHP stuff when I already know perl?
      • Why should I have to sit down and read through PHP stuff when I already know perl?

        You know, I thought exactly the same thing - I've written a LOT of perl-driven sites over the years and always considered PHP a sort of "perl for dummies" until I actually decided to use it.

        Maybe the earlier versions were bad (you can see by the fact the language still has a lot of ugly constructs that it's evolving all the time), but it really is excellent for putting a dynamic site together very quickly. The huge amount of convenience functions just save so much time (yeah, ok you could have a massive library of Perl objects and functions you coud pull in to every script, but it's not going to be as fast).
        Then there's the fact a designer can work on the same files as a coder without having to use templates.

        It's fast too! No, not C/C++ fast, but I certainly haven't noticed any database driven sites being held back by it - and freedom from /cgi-bin/ is nice.

        Of course, for command-line tools I still use Perl.
    • From the review it looks like the book contains a lot of info about mod_perl so I don't see your point!

    • Re:Isn't it time web development moved on? (Score:5, Insightful)

      by Daniel Dvorkin ( 106857 ) on Thursday August 08, 2002 @10:54AM (#4032775) Homepage Journal
      Old-school Perl CGI is relatively slow, yes, though an awful lot of that has to do with the quality of the back-end code. But mod_perl is unbelievably fast -- and I say that as someone who makes his living developing and maintaining a database with a Web interface written in PHP, so it's not like I'm prejudiced in Perl's favor. "Serious webmasters" choose whichever tool gets the job done best, and if they're also good programmers, they write good, clean code that executes fast enough that the client doesn't have to care what's driving the site.

      That being said (anti-flamebait!) I'm amazed you mentioned ASP, not because of of its flamebait value, but because, um, it sucks. I swear to God, there must be "if(client != "IEWin"){slow_down(); crash_unpredictably();}" in the source somewhere. Even these days, old-school Perl CGI is often the right tool for the job. Unless you're developing 100% for IEWin, IIS, and MS-SQL, ASP never is.
      • Unless you're developing 100% for IEWin, IIS, and MS-SQL, ASP never is.

        that has nothing to do with ASP at all. that's 100% in the web programmer's hands. MS-SQL is certainly no worse than MySQL, which the book advocates.

        i'd rather use Apache than IIS anyday though.
        • i'd rather use Apache than IIS anyday though

          Wasn't there comparision of Apache and IIS done last year that basically found that you should use the platform that your server software is best suited for? that is, they found that if you need to run a bizniz web server on Win32, then you should use IIS, MSSQL, ASP and friends.

          They found that, from a maintenance, performance and development standpoint, running Apache on Win32 (for example) was pounding a square peg into a round hole. Note that nobody was saying "you can't run Apache on Win32", just that it was not recommended for various reasons. The number one reason was performance.

          Obviously, Microsoft has plenty of access to obscure or even "secret" Win32 APIs.

          Just one study, AFAIK, and I don't know how dependable the source is, but it seemed to confirm some anecdotal evidence I had accumulated.

      • Even these days, old-school Perl CGI is often the right tool for the job. Unless you're developing 100% for IEWin, IIS, and MS-SQL, ASP never is.

        Go to monster and search on perl/cgi based jobs for web work.
        Now search on Java based jobs for web work.

        In general,
        Your general simple/small/little processing pages use perl.
        Your smaller companies that require dynamic pages use ASP.
        Large business that have huge enterprise sites with multiple intraweb applications run Java/J2EE.

        I've had multiple jobs that required me to change a smaller webapp from perl into Java since it started small and grew into a large program and started becoming difficult to maintain.
        If I had time, I'd love to take slashcode and make it into a fully J2EE website to prove, once and for all, how much of an advantage it is for large websites to change to J2EE.

        Now, don't get me wrong, perl is a WONDERFUL scripting language that I use almost daily. It makes great little sites (or even large sites that don't require a huge amount of processing/code) that you need to create in a short amount of time. Just, when it comes to making a large project with funding and time, J2EE has enough advantages and features that makes the job so much nicer. Maybe I'll make a journal entry to fully argue the points back and forth.
        • When we talk about the advantages of different languages, how much of the time are we talking about the language, and how much is about the tools?

          I mean, when I've played with OS X programming in Obj-C, I know that Cocoa apps could be written in Eiffel or Ada or any number of other languages. But the tools don't support these languages, and the tools make things so unbelievably easy.

          So is it the tools, or is the language/runtime?
          • In web development, it's all about the tools. The language doesn't really matter. Think about it. For web development, you need a language which can:
            1) Connect to a database
            2) Be good at string handling
            Why are strings important? Well, most stuff in web development is about strings. You interact with the DB via strings, you send the client a bunch of strings etc. Hell, even a god-awful language like Tcl can be really good for web development when you couple it with a kick-ass toolkit, like aolserver/openacs. Incidentally, aolserver/openacs and expect are the only reasons any mentally stable person agrees to learn Tcl.

            Performance, on the other hand, is not that important. Most of the time you'll be waiting for the database or to push data to that guy behind a 14.4 modem anyway. What matters performance-wise is that you have some mechanism of keeping the script interpreter loaded all the time (like aolserver/mod_perl/php/java) and having persistent db connections.

            So why use Java? It's not really good at handling strings, strong typing is often not necessary in web development and having to compile your code before you test it slows you down (yes, I know JPS:s are automagically compiled). As I said at the beginning of my rant, it's all about the tools. Java has _excellent_ tool support. XML stuff, web services, layered architectures (J2EE), you name it. Java has it. And all the major players in the industry are behind it, except Microsoft of course.

            Java is also scalable. For the really simple site, writing a JSP page is as simple as writing a PHP/ASP page. For the high-end stuff, you can have 27 bazillion layers all cleanly separated on separate clusters costing umpteen million dollars.
    • Look at the benchmarks for PHP vs ASP lately, it usually outperforms it. i'm sure C is faster, but i haven't read a thing on java servlet pages and how it performs speedwise. I actually thought java servlets would be slower than php but i could be wrong.
      • Check out the "hello world" benchmarks at www.chamas.com [chamas.com]. mod_perl is right at the top of the heap when it comes to performance (after a C-based apache module) then java, THEN php.

        From the site:


        Welcome to the Hello World! benchmarks. This site seeks to give its visitors a sense of web application execution speed on various software platforms running under the Apache web server. ...... The benchmarks instead tend to be written for a lowest common denominator so more web applications can compete than not.
        • And if you put a cache product on the PHP machine, it'd be as fast or faster than mod_perl. mod_perl is caching the script in memory, something the default PHP doesn't do. Compare apples to apples please.
    • I am probably biased because I learned perl first. However at work I use both of them(perl and PHP). And consequently I hate PHP with a passion. I dislike the monolithic approach. I like CPAN where I can bite off one module at a time, get its documentation all in one place, and get my head around it. In PHP I find my self wading through oracle database calls to find docs on basic functions. Speaking of database calls, why is there zero abstraction in PHP? why do I have to find and replace every function call to change databases.

      Also I think the embedded nature of PHP, while handy in simple cases, encourages people to mix up program logic and presentation.

      And of course my favorite, you can't beat using the CPAN shell to install new modules.

      I don't know about performance, I haven't seen benchmarks on mod_perl vs. PHP, but if you think most web apps are hindered by program runtime, you are looking in the wrong place for optimizations.
      • Speaking of database calls, why is there zero abstraction in PHP? why do I have to find and replace every function call to change databases.

        Have you heard of Pear DB [evolt.org]?

        What is PEAR? [php.net]

        Good Luck.
      • And of course my favorite, you can't beat using the CPAN shell to install new modules.
        Actually, I prefer CPANPLUS, read the article [perl.com] about it.
      • why is there zero abstraction in PHP?

        Because it's using native drivers wherever it can and you get the best performance that way. If you WANT abstraction (and the accompanying slowdown) you can use ADODB, Metabase, PEARDB, or other projects.
      • <i>"...get its documentation all in one place, and get my head around it."</i>

        Ever visited php.net ? the official PHP manual is one of the best manuals I've ever read.
        Everything is there! Well organized and easy to find. You also have user comments which are extremely helpful.

        <i>"Speaking of database calls, why is there zero abstraction in PHP?"</i>

        How hard is it to code your own wrapper functions to add your own level of abstraction on top of php's DB functions? Or use one of the million classes out there already created for you?

        <i>"Also I think the embedded nature of PHP, while handy in simple cases, encourages people to mix up program logic and presentation. "</i>

        So you are telling me that you prefer:

        #!/usr/bin/perl
        $var="Hello World";
        print "Content-type:text/html\n\n";
        print "<html>\n";
        print "<body>\n";
        print "$var\n";
        print "</body>\n";
        print "</html>\n";

        Over this?

        <?php $var="Hello World"; ?>
        <html>
        <body>
        <?php print "$var\n"; ?>
        </body>
        </html>

        Embedded languages like php/jsp/asp PROMOTE separation of presentation and program logic!

        In addition for more complex cases, it is easy create html templates to add yet another level of abstraction to your scripts/presentation.

        Ask your html designers to try importing the .pl file into their favorite html editor (dream weaver? front page?) You can say bye bye to your perl code. In the other hand, with script tags like <? ?> The editors will know not to touch those!

        How about text editors that do syntax high-lighting? with <? ?> they can do syntax highlighting for both, HTML AND PHP! giving the programmer a visual of the actual separation!

        So.. the embedded approach encourages people to mix up program logic with presentation? Don't think so.

    • You never heard of mod_perl [apache.org], FastCGI [fastcgi.com], Embperl [apache.org], or the Template Toolkit [template-toolkit.org] if you're still talking about PERL CGI scripts, have you?

      Apache and PERL is still the bleeding edge of web developement. It's just no more alone at the top. Perhaps you should take a look on these Benchmarks [chamas.com]. Especially the JSP don't look very good there and Embperl2 is usually very close to PHP regarding performance. Only Apache modules written in C are without real competitor. But you should also think about the ease of developent if you compare C code with PERL, PHP, ASP or JSP.

    • Apache and Perl was the way to go in 1996, but times have changed. Systems like PHP and (here comes the -1 Flamebait mod) ASP are faster and more efficient than Perl CGI. Serious webmasters do it in Java or C anyhow, for serious speed.

      Serious Web programmer do not even mention "CGI" and "speed" in the same sentence.

      Now,for some serious flamebait : PHP has always stuck me as an adequate, if somewhat anemic, Perl replacement but nothing more. It have a few very good library (PEAR and Horde), but nothing nearly as complete as CPAN. Zend is reputed very fast, but is it faster than mod_perl ? Instead of throwing half-baked opinion, please provide some hard number to back up your claim.

      And what's ASP ? Is this some kind of tasty threat ? Never heard of that before ...

    • Serious webmasters do it in Java or C anyhow, for serious speed.

      If speed is your only concern for using a particular language in web development, I think you're missing ths big picture.

      IMHO, the difference in speed between C/Java/Perl/PHP/ASP for web development doesn't mean squat. If you are querying a database 1,000,000 times a day for content that changes twice, you have a problem.

      Pick any language you want. Who cares. When you start talking about high hit counts and high loads, more of the problem will come down to caching, push vs. pull of content, and server/cluster/network layout.

    • I can't believe this was modded up to +3.

      "Apache and Perl was the way to go in 1996, but times have changed." What?! This is the same type of fallacious argument that Microsoft uses against UNIX; "it's 30 years old, it can't be any good!"

      Of course, generally, the entire reason one uses a high-level language (like Perl, or Python, or PHP, or whatever...) is because quickly putting something together is more important than lightning-fast speed. It's safe to say that web development is one of those tasks which generally benefits more from the former than the latter. With this in mind, your (unsupported claims) of Perl CGI's "efficiency" problems are irrelevant. Could we see something like benchmarks, or any kind of evidence?

      Your comment about "serious" webmasters "doing it" in "Java or C" for "serious speed" strikes me as being particularly odd. Your use of the word "serious" seems quite silly; there are plenty of serious [kuro5hin.org] 'webmasters' [slashcode.com] using [apache.org] Perl [w3.org]. As for the languages you mention, almost no one uses C; that defeats the entire purpose of general web development methodology. Again, your claims are completely unsupported by any further evidence.

      Personally, if I need to do any web scripting, I have my own language of choice [python.org].
    • Systems like PHP and (here comes the -1 Flamebait mod) ASP are faster and more efficient than Perl CGI.

      Perl with mod_perl is *very* fast and no slower than PHP with mod_php. Perl on it's own certainly isn't very nippy under high load, but then PHP without mod_php isnt great either, though many PHP fans don't take the time to understand the difference before determining which is better (which is understandable when you take into account that PHP is now used more than Perl by less experienced users, due to it's greater ease of use).

      ASP pages (at least served by IIS) are significantly less able to cope with high load than Perl with mod_perl. IIS really strains when serving dynamic load (though it's superb at serving static content, though that's not so useful :). Of course I should say that it's entirely theoretically possible that an ASP solution under Unix might give comparable, or even better, performance but given it's such a small market share and has comparatively tiny amounts of development time (measured in developer hours) associated with it it's not realistically likely - to the extent that I don't think anyone would even claim it is. It's more of a way of giving customers ASP without having the system administrator management headache of having to run NT servers.

      There seems to be a big PHP bandwagon among the hip and trendy crowd these days. That's not entirely a bad thing, because (like Perl) PHP is a GoodThing(TM) but it is a when they are just repeating what everyone else is doing (which is always a bit worrying).

      The most compelling arguments are that PHP is of course easier, and so on balance PHP markup is much less prone to errors than Perl scripting.

      Serious webmasters do it in Java or C anyhow, for serious speed.

      Sorry, but I really dispute this. Not that serious webmaster to it in Java or C, just that it's not always very quick (I'll justify that in a minute) and that there is an implication there that 'serious webmasters' work only or even mostly in Java or C which I disagree with.

      If you are writing a large scale project with many developers some find it easier to keep control over the project if it's written in Java or C (over Perl) because of Perl's flexible nature (which some see as a curse when you have a large project). I can certainly see the merits of this and am a big fan of Java.

      The drawback is with C is that C code takes much, much longer to write, takes longer to modify and is more prone to errors due it's complexity. Very little CGI is written in C due to this. I think that most appropriate place for C CGI's is for particular CPU or memory intensive functions who's functionality will remain relatively static over time. This way you can rapidly build flexible CGI interfaces around a very fast C program, meaning that your servers are not tied up with that function, but that you can still easily modify and adapt the front end of your site. Perl modules written in C are typically created to be used in this sort of context.

      Java is excellent in that it imposes a similar strictness to C while allowing you to still comparatively rapidly produce code that is less error prone than either C or Perl (IMO), meaning it's great for development among many developers. The drawbacks are however that it still takes longer to code a solution in Java than in Perl (though it's quicker than C) and Java does not really become an option for high load situations unless you have large Sun hardware with plenty of RAM (several Gigabytes) to throw at it - though at which point it really shines.

      So 'speed' is a relative term, yes certainly code in C will execute faster than in Perl, but if it takes you a month instead of a week to write, you may have just wasted 3 weeks worth of project time (and this can doom a project or kill a startup). It's much, much quicker to write and modify code in Perl (or PHP) than in Java or C (though modifying _other_peoples_ Perl can be a different story, though I've never had any problem doing that, I can see how other people do).

      I once worked out timescales for a project that went like ~2 months of Perl coding or ~4 months of Java or ~6 months of C and noted the problems/advantages of each and let my manager pick one. We went with Perl (with the option to have parts in Java or C as we came across parts of the project that would benefit), even though Perl alone might struggle with the load of the task we were doing, because it was felt that Perl would easier to maintain, given that more people in the company were comfortable with Perl, Perl meant rapid development allow us to bend with typically ever changing requirements and that Perl monkeys are easier and cheaper to find (should we all leave and minion adjustments required to the software at a later stage).

      As I final note I'd say that PHP certainly is quite appropriate in many situations and I don't dislike it at all, but for those with a strong Unix bent, unless they have good Perl already they might be better off doing at least a couple of projects in Perl, as Perl becomes a key 'life skill' due the fact that it can be used to write extremely useful scripts that do very complex things very quickly, so learning it is very useful.

      • Serious webmasters do it in Java or C anyhow, for serious speed.
        Sorry, but I really dispute this.

        And I'll back you up on this. Although you disputed it by talking about time-to-deployment, I dispute it on grounds of actual speed of page returns. I worked at Borland and built tons of apps using Perl (pre-JBuilder), then at Arzoo using JSP, and now at SST using PHP. PHP is by far faster than the rest. And there is another Web team at SST, and that team works on competing projects, and they used ASP at first, and now JSP, and they regularly come and ask how the hell we return pages so quickly. Because we're experiencing some real-world payoffs -- for example, our group is getting the new projects -- I'm sticking with PHP.

        I think the biggest problem with PHP is that it is fast enough to allow us to be sloppy -- if we want to put 20 SQL queries on a page and have 15 included files, we can do it without much of a performance hit (though MySQL is crazy-fast on selects, so that deserves credit too). Back in the old days, I'd have to optimize, optimize, optimize. Maybe even drop some less necessary features because the slowdown was too much. If you really want to talk about super-slow Web apps, remember IntraBuilder. Anyone remember that? It was a Borland product with a LiveScript clone on the backend, and oh my God would it crumble under pressure. We had to use it at Borland, sort of a eat-your-own-dogfood kind of thing. But when your own employees start to hate your product and bristle at the mention of it, the product is doomed.

  • Unfortunately, after a second edition in 1997 the book hasn't been updated.
    And yet, it's still being used in the Department of Foreign Affairs as need-to-know material for our intranet site developers.
    However, most of the n00bs here seem to read PHP and MySQL web development [amazon.com], by Luke Welling and Laura Thomson.
    The Canadian government uses Java, XML, VB/VBA, SQL Server, and ASP, but SQL and PHP are the primary ones.
    I did ask around at web development and we did in fact order copies of the new book that you reviewed though. Cool, eh?

  • Are books the way forward? (Score:5, Insightful)

    by Aliks ( 530618 ) on Thursday August 08, 2002 @10:34AM (#4032632)
    Don't want to be a troll but no matter how good the book is, surely for material like this, the web itself is the best medium.

    A paper book is certainly more portable, and for most people easier on the eye, especially when you read for a long time but . . .

    Topical material is quickly out of date

    You can't search too easily for the topic or phrase you want

    You can't easily look up a reference for a term or concept you don't understand

    If a certain paragraph doesn't make sense you can't look for alternative statements of the same concept

    Once you've read it there isn't any easy way to look up a particular section when you next need it (the books at home, borrowed by a colleague etc)

    Books cost!
    • For people like you they also provide the book in ebook format(PDF)(See http://www.manning.com [manning.com]). Good price too and a discount if you wish to go to a more tree based existance. I wish more publishers woukd do that!

    • Re:Are books the way forward? (Score:5, Insightful)

      by bluGill ( 862 ) on Thursday August 08, 2002 @11:13AM (#4032917)

      Depends on what you want to do. Online is better when you are at a computer (with net access) and know what you want to know about. Paper is better when you just want to learn something interesting. I have not yet found a good way to skim online documentation and when something catches my eye drill down deep. Scrolling doesn't seem to work that way for some reason. An index is worse, it doesn't tell you if something is useful, so you have to look, which means wait for page loading times. After a few misses you give up.

      Both types have their place. I wouldn't want to be without my printer, even though I haven't turned it on in several weeks. There will never be a paperless office because when the problem gets really tough I print out everything, and then (as Fred Brooks said) take to the floor to figgure things out. Don't try to get rid of paper, use both paper and the computer to compliment each other.

      • You want Texinfo.

        Really.

        No page load times, the document is on your hard drive. It has good indexing and its hierarchial structure makes "drilling down deep" easy. And if you want, just throw the source document to TeX for the printout.
    • Topical material is quickly out of date

      I think that's why things that are generally at a higher-level (as the review says this book is) tend to be much better, and have a longer shelf-life, than the typical programming book. At the same time, I find it to be helpful to get particular books to build my own basis for a particular language or application, and then find more detailed and up-to-date information from there. Of course, I have about 6 boxes of computer books (mostly programming, some administration) sitting in my room waiting to be unpacked after moving across the country about a month ago.

      As another poster pointed out, though, the ebooks that are packed on the CD with more and more of the new books are great, especially when you don't want to lug a 900 page book around (or worse, 3 or 4 of them, as I have a tendency to read on multiple things at a time to keep from getting bored with a particular subject).
    • Lots of reasons.
      For one, Subways, busses, trains, airplanes, sidewalks, and doctors offices.

      Two, it's always better to have a paperback copy of documentation when fixing a computer. Even if you have another computer around (and you should), paperbacks still leave smaller holes in the wall.

      Three, when you are done with it you can loan it to a colleague. I've worked with enough clueless people to know that a little education can go a long way in smoothing a long term working relationship.

      Likewise, many of the supposed advantages proported of HTML are not so, namely timeliness and loanability. For some reason it seems to take as much cost to keep a site up to date after two years (or so) as it did to create the thing in the first place. Why would the publisher plunk down the coin to keep the site current? If they are going to recieve payment for updated versions of the html book, how is that any different from buying a dead-tree edition? And how, exactly, can you loan out a html book with the publisher's blessing? I understand that in HTML you can just page through and download the bloody thing, but... That seems like a lot more trouble than figuring out who you loaned your book to.

      And furthermore, if you are at a computer you can look up concepts you don't understand without any trouble. The portability of white pulp doesn't preclude reading it at a computer. And when Mozilla / IE / Netscape / AOL / ICab / Opera / Lynx / Konqueror crashes your system, your paperback will still be running fine and you will still know what you were looking up. (Opera, BTW, automatically saves the windows you have open, allowing you to painlessly resume after crashes).

      I don't think, in the current state, that searching and easy dissemination outweigh portability, ease-of-reading, and loanability in this circumstance.

      Dead tree technology has been around for three thousand years. Three thousand years of R and D is a lot of engineering. Let's not be so quick to abandon that power, eigh?

      -Chris
    • For a technical reference, yes.

      For a through analysis of the abstract concepts, no.

      1) A good book that deals with the real problems ("web development" in this case) will stay up to date for as long as the problem is. The implementation details are incidental to the real value of the book.

      Half of my web development books are obsolete, they use Tomcat 3.x/JSP 1.0/Servlets 1.x code and examples, and things have changed dramatically in that area.

      Yet those are the same ones I actually use, because I'm not consulting books about APIs or specs, I'm reading books about software development.

      A better example is perhaps "Design Patterns". I consider it a book that NEEDS to be skimmed over; that's how you read and use it. No single line of code has helped me in that book so far, but I consider it invaluable.

      From what I remember of "The Art of Computer Programming", it's technologically irrelevant and obsolete, yet many consider it's invaluable to help understand technology because Itanium-assembler code is not the issue.

      2) To most people a monitor is an inferior surface to read, and even for some who are comfortable with it (like me) it's just not as flexible as a book: we have learned to detect patterns over multiple pages, even multiple chapters, and we haven't learned to do it with the scroll bar. For some reason, we seem to be more efficient with 3-4 open books on our desk than 3-4 books on our "desktop", sharing psychological space with our software applications.

      This could be solved with electronic paper, but many still feel the need for paper books.

      While software makes it easier to look for things you already know you're looking for, in ways software is good at looking for, paper still lets humans do the kind of searching they are best at: browsing through the unknown.

      3) You can look in a book for an alternative statement of the same concept.
      It's called an "index", it's normally at the end of the page, and it tells you where the concept is mentioned/explained/used.
      Hyperlinks are nothing more than the bastard child and logical extension of indexes and references. That's what makes them so insanely useful.
      Now, if you mean you can't look for alternative statements by doing a search in Google, well, that's called research. It's been done ever since there were books, and it's the reason why the Dewey system was such a big deal back then.

      Conclusion:

      Electronic text is more convenient for some things (directed searches, instant references, etc) but it still doesn't offer some important advantages of the paper-world.
      Besides cost, there is no logical reason, however, not to have both versions of the text in a newly produced text.
      Even the most generalized, theory-oriented book would benefit from hyperlinking and searchable text, and some updated material. Providing both versions is the sensible solution.

      But assuming that costs restrict the publication to only one kind of media, there are books better suited to e-text (most O'reilly books, essentially technical manuals) and there are books better suited to paper (a good Data Structures or Software Engineering book).
      I guess it depends on whether you're meant to read the book, or to "consult" it.

  • Amazon has lots of sample pages (Score:5, Informative)

    by sootman ( 158191 ) on Thursday August 08, 2002 @10:36AM (#4032640) Homepage Journal
    TOC + 48 pages of text here [amazon.com].

  • No Discussion of XSLT? (Score:5, Interesting)

    by Mirk ( 184717 ) <slashdotNO@SPAMmiketaylor.org.uk> on Thursday August 08, 2002 @10:41AM (#4032664) Homepage
    Chapter 7 looks at ways to separate content from presentation [...] the majority of the chapter is taken up with a review of the various templating systems that are available for Perl. The chapter finishes with a detailed look at two of the most popular templating solutions - HTML::Mason and Template Toolkit.

    It's a real missed opportunity if this book doesn't also talk about using XSLT as a way to separate content from presentation - especially as the Apache project has its own XSLT engine, Xalan, available in both C++ and Java.

    A quick HOWTO on wiring that gear into an Apache configuration would be really useful.

    • Actually there is a section in that chapter about XML technologies. It mentions AxKit [axkit.org] in particular.

    • It's a real missed opportunity if this book doesn't also talk about using XSLT as a way to separate content from presentation
      I'm not familiar with XSLT, but one of my big gripes about Perl web development (and developers) is that so many Perl CGI scripts do something like...

      print "<html>\n";
      print "<head>\n";
      print "<title>\n";

      ... ad nauseum.

      No wonder so many people think Perl is obsolete as a web development tool. This is a hideous way to do things. Anything but the most trivial HTML produced in this way will be very difficult for a programmer to maintain - let alone a web designer.

      Here is a short tutorial I recently wrote on separating content from presentation using HTML templates with Perl.

      http://www.calypteanna.com/templates.html [calypteanna.com]

      • Here is a short tutorial I recently wrote on separating content from presentation using HTML templates with Perl.

        Interesting article. But Im'm interested why you invented your own templating system instead of using one of the ones aready available for Perl, like HTML::Template, HTML::Mason or the Template Toolkit.

      • Stinky Cheese Man: Here is a short tutorial I recently wrote on separating content from presentation using HTML templates with Perl. http://www.calypteanna.com/templates.html

        ARF! I hope you are joking. That you got modded up for implementing Model-View-Controller using $MAGIC_NUMBER is the funniest thing I've seen all week.

      • Simple variable substitution templates are old hat and really very limited utility. I may as well just say:

        print <<EOT
        <body>hello $yourname; ... etc ...
        EOT
        ;

        I think every web developer ends up inventing their own template engine sometime in their professional lives. Most who know anything about the industry already know they're reinvented the wheel, and that it was a learning process, or that it had to be small and self-contained and therefore not use an external lib (my rationale for one that I wrote) and not something terribly revolutionary. I'm not saying you're that naive, but the posts to freshmeat I keep seeing for Yet Another Template Based Content Management System seem to indicate that not everyone has gotten the message.

        If you want a perl template system that's mature, use something like TT2 [template-toolkit.org]. A simple CMS in TT2 was something like 20 lines of mod_perl code and a couple template files.
      • If that's the way you code your Perl, no wonder you think it's crap. Separate program logic from presentation, dude. Perl lets you make extremely easy-to-read code, that's also easy to maintain. Here's what my Perl code looks like:

        blah.cgi
        #!/usr/bin/perl

        DBConnect();
        # do all the SQL stuff here. No HTML in CGI
        $SQL = qq[SELECT ....];

        do "inc/blah.inc"

        DBDisconnect();
        exit(0);

        .. and inc/blah.inc contains:
        print qq[Content/type: text/html

        <html>
        <head>
        </head>
        <body>
        </body>
        </html>

        ];

  • Good documents on security (Score:1, Informative)

    by Anonymous Coward
    www.cgisecurity.com/lib [cgisecurity.com]
  • i know this is slashdot and all but i would like to hear some sensable (non religous) reasons that post-1998 php would not be the default open source web application development platform.
    Im currently engaged in trying to update someone else's perl web application and the five hairs i have left are screaming for me to just ditch it all and reimplement in php. It just *seems* more web oriented, perl tries to be many things to many people, while php is all web all the time. I think this shows in the fundemental design of the languages.

    • i would like to hear some sensable (non religous) reasons that post-1998 php would not be the default open source web application development platform

      Because mod_perl using some sort of templating is sooooo much nicer than PHP. PHP makes it a pain to separate code from presentation. Yes, people do do it, and there are templating php modules available, but none as nice as the perl offerings (Template Toolkit, HTML::Template, etc). Perl is also just a funner language to write in than php. You can do about everything in php you can do in perl, but it just doesn't feel right (doing re's in php makes me want to vomit, calling those stupid preg_match() functions and stuff). I maintain two semi-complex web-sites that I had originally written in php, but moved to mod_perl because it's so much nicer to write in. And according to my benchmarking, the mod_perl sites are as fast or faster.

    • I'm going to come out and say straight away that php has some really good points, and I'm all for using the best tools for the job. Just shoulting "My Lanauge is Better than Your Lanauge" gets us nowhere.

      When doing a full evaluation I'd like to have a look at all the options. People looking at Perl tend to overlook some of the support systems in it which allow you to produce a more structured application and tend to try and reinvent their own systems. This is bad, and is where people who haven't stopped to think about what they're doing get their misconceptions.

      For example I suggest you have a look at the Tempalte Toolkit [tt2.org] language that allows you to use a simple templating system to write directly in HTML and then call to pure Perl plugins when you need the power - and the ability to use existing modules off of CPAN. Slashdot uses the Template Toolkit to do some of it's templates.

      Another system that someone sensible would look at is the AxKit [axkit.org] system. AxKit is Apache Foundation project similar to Java's Cacoon system that allows you to use XSP and XSLT and other buzzword friendly XML systems to do dynamic transformation of XML with perl taglibs as you need it. What's PHP's way of dealing with XML? Can you write XSLT stuff in it? Can you use XPath, SAX and all that to process document pipelines? What's the framework like to work with? Honestly, I'd like to know - I haven't looked into it at all.

      On a simplier note, you might want to look at some of the very simple web application frame works, for example CGI::Application (which despite it's name will run very fast under mod_perl.)

      Finally, I'm not sure how easy it is to test PHP. Perl has quite a powerful set of testing tools that you can use to easily determine if each bit of your code is working correctly...I'd be really interested if someone could post a discussion of what PHP has to offer in this area.

      I can understand how someone else's web application could seem terrible....but I've seen terrible php too! But it's unfair to blame the language for a particlar code example - I congratulate you on your sensible decision to examine the options properly.

      • What's PHP's way of dealing with XML?

        At Devshed.com:
        Using PHP with XML (part 1)
        http://www.devshed.com/Server_Side/XML/XMLwith PHP/ XMLwithPHP1
        Using PHP with XML (part 2)
        http://www.devshed.com/Server_Side/XML/XMLwith PHP/ XMLwithPHP2

        Disclaimer: I have not used XML with PHP before. I just remembered seeing these tutorials when I read the parent post.
        • Thanks for the links.

          I was wondering if anyone knew anything more about XML frameworks for PHP. In Perl, undef AxKit (and in Java, under Cacoon) you don't have to go though all this file opening and closing stuff that's covered in the article - rather the framework knows (thought the httpd.conf) what filters to send each XML 'document' (object tree, SAX stream, etc, etc) to convert it to the right thing.

      • The problem with Perl is that it is a "career language". It has a large learning curve if you want to be able to effectively *read* Perl written in many different styles ("more than one way to do it").

        PHP is more "easy-come-easy-go". You get in, learn, use it, but feel no real loss when some other new-fangled paradigm or language comes along and all the PHB's want you to use that lang instead.

        Plus, there are less ways for bored programmers to make mince-meat out of PHP. There are no serious obfusication contests for it, so nobody will be training for it on production code.

        (I just wish they would add named parameters to PHP. I miss those.)
        • Yeah, I can see where you're coming from. Perl's a very complex language and there's a lot to learn there - it's certainly very powerful. However, one of Perl's main advantages is that you can get an awful lot done before you've learned the whole language - perl baby speak. It's also one of it's main failings - people often stop learning there.

          This is one of the reasons I suggest things like the Template Toolkit - for simple things like loading other templates in, doing calculations, itterating over lists, etc, etc, it's really simple. It's designed that way. It's really got that easy come easy go quality that you were looking for.

          Of course, if you need the power of a fully fledged language you can use a plugin - or better you can get someone else to write the plugin for you (which in my experience normally means creating a interface for an existing module so you can easily use it how you want from within the template.)

    • I like PHP as much as the next guy, it works for the simple stuff quite well, and it's easy to install...

      Anyway, here's my list of why you should consider mod_perl more "web-oriented" than PHP.

      1. Hooks directly into the Apache API. You can run code at many different levels, URL munging, authentication, logging, etc.
      2. You can use mod_perl to configure apache. For example you could configure a thousand virtual hosts from the information in a database. All using a few lines of perl code.
      3. Great Architecture support. Want to implement sessions, what about authentication to any number of protocols? Templates? check.. Complete application frameworks? Yep that too. Often the problem is choosing between the different platforms built on top of mod_perl..
      4. Fast, fast, fast! need I say more..

      Swing on over to the mod_perl Cookbook [modperlcookbook.org] site or the main mod_perl site [apache.org] for many reasons why you should consider this great technology.

      (note I co-authored the cookbook above. But I've used mod_perl professionally for quite some time and have compared it to other, more lacking environments and whole-heartedly recommend it.)

    • Re:not to be too flamey (Score:3, Interesting)

      by scrytch ( 9198 )
      This story is all anecdote, and to say that my disaffection with PHP is more political than technical is probably correct. I merely throw it out as illustrative of my frustrations in dealing with it.

      I really tried to like PHP. It has somewhat more "regular" syntax than perl, lacking most of the awful @$% decoration of variables and such. I launched into creating this monstrously nifty CMS system in PHP, very OO in the internals, very extendable...

      Then I learned that PHP passes all objects by value. There is a pass by reference syntax, I just had no idea that this was the required default for objects. Fine, ok, it looks kinda like perl, but it's not perl, I can accept this. Then I learn that PHP has no facility to distinguish objects by identity. Now I need to generate a unique ID on every object. I went to Zeev himself to address this problem, and the man had to be taught the concept of object identity (what eq gets you in lisp and a pointer compare gets you in C, basically). He then proceeded to dismiss out of hand the entire concept, and went and suggested a === operator that actually did the polar opposite of what it is supposed to do, resulting in more expensive comparison (still by value mind you) than any other comparison operator. Zeev said "PHP is not an object oriented language" (direct quote).

      I asked for a facility to disable certain functions at runtime -- I needed to run them first, then in the same process, disallow them from being run again (since it could take arbitrary user code that would be fine so long as it didn't touch the filesystem or open sockets). Actually I had it able to override built-in functions, but all I really cared about was being able to disable them. Offered sample code. Refused. The rationale was that the idea was too dangerous, that people could hang themselves with it. I pointed out my failure to grasp how deliberate disabling of functionality opened up any problem areas. Silence.

      I asked at one point whether PHP had the intent of achieving a broader focus beyond the web. The response was "no, php is a web language". Perl not only tries to be many things to many people, it *is*. PHP itself has a nice bazaar culture of development, but the Zend virtual machine is absolutely a cathedral. I can't in good faith use a language that has been crippled, in ways that affect me directly, and has been deliberately left so in order to effect some sense of parsimony. This is "why PHP is not my favorite language" (one of those euphimistic forms going around, like "___ considered harmful")
      • Zeev said "PHP is not an object oriented language" (direct quote).

        It's not, though it has OO support tagged on. If I need to write a complex app that needs a high level of OO I use Java. For 99% of my PHP needs though the basic OO in PHP sufices.

        I asked at one point whether PHP had the intent of achieving a broader focus beyond the web. The response was "no, php is a web language".

        You say that as though it's a bad thing. I like the idea that it's focussed. It does its job and it does it well.

        Perl not only tries to be many things to many people, it *is*.

        Including being a real pain in the ass?

        I can't in good faith use a language that has been crippled, in ways that affect me directly, and has been deliberately left so in order to effect some sense of parsimony.

        You mean you are pissed off that the language hasn't been warped to suit your needs but stayed within what the majority of its users want? Did it occur to you that perhaps PHP wasn't the appropriate tool for the job?

        This is "why PHP is not my favorite language"

        That's only half the sentence. The other half is "for web development", which is what we are discussing here. PHP is a tool that suits a purpose, as is Perl, Java, Python, etc. Perhaps you should analyse the problem then choose the language rather than the other way around?

        Phillip.
        • I'm not pissed that the language hasn't been, ah, "warped" to suit my needs. I was annoyed at developers that first didn't understand, then refused to listen. Finally, when it came down to it, I did choose a tool that fit my needs. And it wasn't PHP.

          I don't know why you felt compelled to reply to my anecdote in such a fashion. I'm not really trashing PHP the language, but merely pointing out my rather negative experience in trying to engage in productive dialogue with the makers of the virtual machine it runs on. Frankly I think you just wanted to get your digs in.

  • The arguments (Score:3, Insightful)

    by InsaneCreator ( 209742 ) on Thursday August 08, 2002 @10:59AM (#4032819)
    Petersen takes a look at the wider world of Open Source Software and in the process presents one of the best arguments I've seen in print for why a company should choose Open Source Software

    Could you _please_ share some of them with us? Because I'm really sick & tired of the same old "Anyone can change the source and fix the bugs" argument. Sooner or later people will have to realise, that the companies we want to convince switching to linux is a good idea, couldn't care less about the ability to change the source. Some of them even get turned off by this argument, since they believe it contans an implicit "You will have to change the buggy code yourself", just like when you're buying a house and the ad says it's perfect for a creative, DIY-type person - and you know you'll have to replace the roof, the walls and the floors within 2 weeks. :)
    • Well, right not i have a code generator that produces one bug, about 200 times, so now instead of devoting my time to fixing that bug or moving on with software, I have to waste time creating a workaround because the next release isint due for 2 months. If it was open source I could fix the bug once, and share it. That is the big win. The implicit "change the buggy code yourself" you are bitching about indicated to me that your mother must have done everything for you. What do you do when she is busy with her other children?
    • Well, the other big ones are cost (obviously) and transparency. All the data structures and file formats for Open Source Software are necessarily available for anyone to see. This means it's very easy for other applications to interact with your data. Of course, using published standards is also a big help here.

      Also because of the large developer base for most Open Source Projects the software produced tends to be of a higher quality. I'm not saying this is true of all Open Source software, but there seems to be a very high correlation.

    • But that cuts both ways. The house you sited is attractive to the can't stop handy person who wants to buy a house, fix it, and sell it at a big profit a few years latter. Doubling your moneyin two years is not unusual on a house like this. (note, if you hire the work done you fall behind, but if you do it yourself, and live there you come out ahead when you consider the rent you would pay otherwise, and you have to love working on houses).

      The advantage of openSource is you can, but don't have to modify it. Instead of dropping the statement entirely, we should drop the "and fix the bugs" part. When you use a closed source program you are at the mercy of your vender to get new features. If you want X, and they say it won't sell enough to be worth it, then you are stuck. With open source you can do it yourself if you have to.

      • I have to agree with you. :) While it is not very easy to find someone who can fix the house, or in this case a linux bug, by themselves, they still are an important part of linux developement.
      • You do realize that the whole point of the parent post was that the companies you're trying to convince are NOT the "can't stop handy person" kind, don't you?

        Which means that, as any good real state agent knows, insisting with the same pitch is not likely to convince them to change their nature to adapt to the house.

    • Could you _please_ share some of them with us? Because I'm really sick & tired of the same old "Anyone can change the source and fix the bugs" argument.

      I use source as a "manual" all the time. It's the definitive guide, and when you really have to know how something works (or you want to create a quick work-around, or do something the software was never intended to do) the best way is to take a look at how the thing is built. In fact, it's become annoying when I don't have the ability to see the source code, I'm so used to being able to see it.

      Here's a real-life, recent example of where having source would have made my life easier. I had to design a tool that would export data from Steltor's CorporateTime calendaring system. I was making XML of all the events based on certain criteria, and arranging everything in cronological order. The CorporateTime API uses as a timestamp a 7 digit value, and all data is tagged with this number as representing when the data was created. Trouble is, what does the number mean? How do I take this number and translate it into April 3rd, 2002?

      After some fiddling around, I figured out what he number meant. It's the number of minutes an event occurred past CorporateTime's epoch, which is midnight on 1/1/1990. Instead of having to waste time "decoding" this as coming from a blackbox (there was no information in any manual, web site or documentation about this value other than it existed and was a timestamp), I would have loved to go looking through the source code to find out what they were talking about. The only place this value is documented is in the source, and it was frustrating not to be able to see it.

      Don't always think of having source code as being able to change that code. Think of it as (at least) a way to see inside the minds of the developers who wrote the application. That's a valuable thing, for any kind of organization.

      -B

    • I agree with you completely, the benefits of open source are only as good as the quality of the source in the first place. Linux is open source, but I'll be damned if I have to rewrite pieces of kernel code to fix something. However, even without a lot of interest in hacking C code, I managed to port the session affinity patch to newer versions of fastcgi, then with a day of perl hacking, put in new directory search behavior in template toolkit 2. With that combination, less than three days work, I had the start of a killer fast flexible CMS system in perl (see, I'm being topical). Well, I thought it'd be killer, I've since sort of lost interest. Might consider a port to python in the future.

      Basically, *you* (a company) may not have the interest in hacking the source, but some of your developers probably will. A house is actually a perfect analogy. No, no one wants to buy a house where they *have* to replace everything, but if I had a nickel for every time I've said "I wish we could paint the walls in this apartment to something not glaring white", I'd have enough to buy the paint.

    • Re:The arguments (Score:3, Insightful)

      by pmz ( 462998 )
      Because I'm really sick & tired of the same old "Anyone can change the source and fix the bugs" argument.

      That's fine, but if you haven't seen other arguments, you haven't been looking very hard.

      1) The code is auditable. Individuals might find little value in this (although some really do), corporations and governments can fund a few people to look for trojans, back doors, or spyware, or even just to check for overall quality or functionality. This gives people and organizations an extra tool in their risk-mitigation toolbox. A real world example is Sun Microsystems' adoption of GNOME for Solaris. Could Sun be as sure that GNOME met their needs had the source been closed to them? Probably not. Has Sun found ways to "pay for" GNOME? Absolutely. They don't hide the fact that GNOME is Open Source, and they have contributed back to the project. There is a pretty good chance that people using GNOME on Linux or FreeBSD have benefitted somewhat from Sun's work.

      2) The developers' motives are different. Why is it that OpenOffice.org uses an easy to work with documented native file format? Why have binary configuration files not appeared in the /etc/ directories of Linux distributions? Why aren't there Open Source EULA clauses about preventing benchmarking, reverse engineering, or criticism of the software? Why are Open Source developers not very concerned about collecting marketing data about you and your habits?

      3) Open Source software lasts longer and is more stable (in a configuration-management mindset). If I install a Linux distribution today, there will always be an upgrade and maintenance path independent of any corporation. Linux has long since reached a threshold, where it can never go away. Many Open Source applications are like this, too. Emacs will still be here in ten years, as will GCC and XFree86, for example. An Open Source system almost never ceases to be useful. An executable is corrupted? Just recompile it. Discover a previously unknown bug? Contact the authors directly and talk about it. You need to collect data from old files? Unpack-n-grep.

      4) Open Source software lasts longer and is more stable (from a robustness point of view). Many Open Source applications are so mature that people take their stability for granted. How often does Emacs fail due to flaws in its code? Under normal use, almost never (the last time I saw Emacs crash was years ago). The same is true for Apache, GCC, XFree86, and the Linux kernel. While there is a huge pool of Open Source projects that are not this mature, it is a normal process for the occasional super-star to emerge and become best-of-breed in its category.

      Now, how much of all this is true of Microsoft and their products?
      • 5) Things are getting better for the dumb-end-users. I recently installed GNOME on Slackware and was very impressed. I use OpenOffice.org and Mozilla nearly every day and am very impressed. It is getting to the point where the difference between a hackers-only system and a "grandma" system is a matter of a few details, mainly concerning things like audio configuration and resolver setup. I'd certainly say that Linux and GNOME are far enough along that I now fight with them less than I do Windows to get everything the way I want it to be. This is a very encouraging threshold.
        • As a happy user of Open Source software (and some Free Software too :-) ), I'm also very encouraged by the improvement in user-friendliness of the high-profile OSS/FSS projects.

          However, "things are getting better" is an argument for the convinced. If anything, it's an apology on the eyes of someone who's considering the switch, but has not made the decision.

    • Heh, I was going to reply but then remembered reading the Troll FAQ.

      Don't ask me how I am typing this while sitting on my hands.
    • 1. 99.0%: I don't have to worry about the vendor going out of business or dropping the product or refusing to port it to a new platform.

      2. 0.9%: Read only source is the ultimate documentation. If there is some weird config file question, or I wonder about exactly how it manages a session, or exactly what happens if ..., then I can go look.

      3. 0.1%: Writable source means I can edit it, add features, change features, fix bugs -- if I want to / have to. I can also pay someone else if necessary.

      To sum it up:

      6. 100.0%: I retain control. No vendor has a lock on me. I am not dependent on someone else's lawyers, business plans, competitors, you name it. I retain control.
  • I threw together a light little intro (I believe this one uses Perl / Apache on a windows platform) for some classes I taught.

    http://www.kilgallonfamily.com/perlhappypath/ind ex .html

    It is about 8 months out of date, but is VERY simple and straightforward. Perfect for a newbie. It walks you through just about all the basics, and is designed to keep a new and inexperienced student motivated and excited about what they are doing.

    I taught it several times, and it works well in a classroom. It is released under the GPL.

    Bill

  • another PHP vs Perl flamewar?

  • Why Perl (Score:5, Insightful)

    by LinuxParanoid ( 64467 ) on Thursday August 08, 2002 @11:47AM (#4033177) Homepage Journal
    When I started web programming 2 years ago and faced the choice between working with Java, Perl and up-n-coming PHP, I looked around and it seemed to me that the people using Perl were doing the most innovative, creative stuff on the web. (Slashdot's "distributed moderation" scheme, which I regard as a quantum improvement over USENET moderation for providing large-traffic yet readable forums was just one example.)

    I wanted to do innovative, creative stuff, so I started writing Perl.

    No regrets. I don't think that aspect of Perl has been particularly usurped. Nor do I think there's another language which provides a platform for faster time-to-market and feature iteration.

    As mentioned elsewhere on this thread, and Java and PHP have their own distinct advantages also.

    --LP

  • Perl is very useful (Score:2, Insightful)

    by PerlPunk ( 548551 )

    Perl & Apache is an excellent combination for bringing sanity to legacy systems.

    As far as dealing with legacy systems, nothing is better than Perl. For example, in a project I'm working on, in my company there is a vast array of legacy tools which require using telnet to get the work done. And the web interface I'm building (CGI & Net::Telnet) get's the work done beautifily. (Try doing this in PHP or Java.) The admin people are happy, and the development time so far has been almost negligible. Perl is the supreme glue language.

    • What would be the impediment to do a Servlet (since you're using CGI) interface and a telnet client in Java?

      Not that I have tried so far, but I don't see what the great difficulty would be: interface code would be trivial, client code would be not too difficult either. There are more than a few Telnet classes out there if you don't want to deal with the raw Socket class yourself.

      Now, whether the development time would be "negligible" or not, is another matter. For a Servlet-based application, it could very well be.

  • I have compiled a list of books I think should be on every web developers bookshelf. While I don't cover perl (I'm a PHP/JSP guy), if you are interested in this topic, you may find my page of interest. (http://www.starvingmind.net/tech.jsp [starvingmind.net])

    For the Perl/Java tech argument. Well designed java pages can be just as fast, or faster then poor perl cgi's, and vis versa. I too have seen very slow JSP/servlet's. JSP's should not be programmed the same way as a language like PHP or perl in many cases, it will be slow. Perl ranks third for me, but not totally off the charts.

    I for one would argue JSP based development makes more sense for most sites, due to development productivity, and language functionality. And as I said before, a well design Java site can execute as fast or faster than some perl CGI sites. PHP ranks right behind JSP's in my mind, since they don't provide as much functionality, although they are very fast for simple things.

    Perl should be a tool in your developer's toolbox, although I believe PHP or JSP's are in most cases a better tool for the job of making dynamic web sites.

    -Pete
  • I do not want to start a flame war or anything. I have been getting into Python lately and am starting to wonder why I don't see more sites using Python over Perl? Can anybody point me to some dynamic sites that have passed over Perl, PHP, JSP, CFM -- and decided to go with Python. Having played around with many languages over the years? -- there is something about Python that made me do a double take and I have been indulged ever since....
  • any website based on perl is doomed to become an unmaintainable mess. look at languages better designed for web use or at least maintainability (php, python, etc).
    • You can be both more incisive and factually correct:

      any website coded by perl 1337 hackers who spent more time reading slashdot than studying CS is doomed to become an unmaintainable mess. look for programmers whose code is better designed for web use or at least maintainability (be it in perl, php, python, etc).

      There you go.

  • I reviewed How to Set Up and Maintain a Web Site [dannyreviews.com] many years ago - and agree that it was an excellent book.

    Danny.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close