MySQL and Perl for the Web 244
Craig Maloney writes "MySQL (love it or hate it) is one of the most popular databases for deploying websites. Perl (also love it or hate it) was almost synonymous with website programming. Arguably there are different choices for different needs in web development (PostgreSQL, PHP, Java, etc.), but there is no argument that if you are planning on putting together a website, using MySQL and Perl that MySQL & Perl for the Web will aid immensely in that development." Read on for the rest of Maloney's concise review of the book. While not new, he says it's still a valuable volume.
| MySQL and Perl for the Web | |
| author | Paul DuBois |
| pages | 552 |
| publisher | New Riders |
| rating | 10 |
| reviewer | Craig Maloney |
| ISBN | 0735710546 |
| summary | A clear, well written book for Perl and MySQL |
Who is this book for?
Developers looking for a quality book on Perl and database development should not pass this book up. While the title of this book is MySQL & Perl for the Web, it could have easily been called DBD/DBI & Perl for the Web. The SQL examples may or may not work with various databases, but the DBI interface code should remain the same. This book will also do well as a reference for experienced coders looking for well-crafted examples of web-based applications.What's good?
The second chapter should be enough to get anyone up to speed with using Perl, DBI, CGI, Apache, and MySQL. After a brief introduction and configuration of MySQL and Apache, the author settles in to discuss coding DBI and Perl. The remainder of the chapter details the best practices for using Perl and DBI together. Near the end of the second chapter, the author creates a fully functional to-do list, demonstrating ways to add, update, and delete information from the database using Perl and DBI. Instead of taking small baby steps over many chapters, the author shows important concepts and best practices for those concepts quickly. Even seasoned (hardened?) programmers may learn new tricks or methodologies from the second chapter of this book.Is that the end? Are we left with one very well written tutorial chapter? Thankfully, the rest of the book has plenty to offer. Subsequent chapters include:
- Improving performance with mod_perl
- Generating and processing forms
- Writing form-based applications
- Automating the form-handling process
- Performing searches
- Session management
- Security and privacy issues
- E-commerce applications
Each chapter is clearly written, with several examples used to demonstrate the concepts presented. The examples are clearly written, and the author makes the whole learning process enjoyable and fun. The examples range from a give-away contest (including a random drawing), an electronic greeting card program, polling programs, and a shopping cart program. Each of the examples is presented completely, but are introduced in pieces (subroutines, modules, etc.) The full source code is available from the author's website at http://www.kitebird.com/mysql-perl/
What's in it for me?
MySQL & Perl for the Web is the book that Perl programmers on any project will wish The Other Guy had read. The examples are clear, the writing is engaging, and the code is maintainable. This is a practical book and should not be overlooked in any serious Perl programmer's library.
You can purchase MySQL and Perl for the Web from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Web, schmeb (Score:5, Insightful)
Love Perl for most anything, hate it for web "programming". There's a good reason it was synonymous with website programming. It's because there now exist more flexible, robust, easy-to-use platforms for web development.
Re:Web, schmeb (Score:5, Interesting)
But, I will give perl it's props.
I often use it to prototype large projects. Despite most arguments for other languages, I will say that you can pump out perl code pretty fast and it does help when you need some mockups and basic functionality to sell a concept.
Re:Web, schmeb (Score:2)
Re:Web, schmeb (Score:2, Informative)
Perl had to be adapted to web development, and it still suffers from various problems (for example, it's significantly slower than php). Php was written to be a web processing language. It's easier to understand and easier to
Re:Web, schmeb (Score:2)
Re:Web, schmeb (Score:4, Informative)
?? Support your inferrence that perl is faster than PHP?
I don't have hard numbers, but I have been in environments where both are used, and perl seems to perform much worse. Specifically, I administer ~100 webservers, and clients that use more php put far less of a load on the system than people writing in perl scripts executed through web pages or mod_perl. In multiple years of working with both, perl just has become synonymous with higher system load.
The load jumps related to PHP that I see are always MySQL based loads.
~Will
Re:Web, schmeb (Score:5, Funny)
Re:Web, schmeb (Score:2)
Damn, that's a beautiful post! I'm in tears laughing. Bravo. Not only have you tossed an asbestos blanket over the smoldering flame war, but did it with some humor.
Thanks.Re:Web, schmeb (Score:4, Interesting)
Re:Web, schmeb (Score:2)
Possibly, but, in my world, you have to take that into account. You can't just say "properly written perl is faster". It might be; however, it is just as important that badly written perl brings a server to its knees, while PHP seems to fail gracefully.
I'm honestly not trying to sing the praises of PHP, I'm just trying to point out that a LOT of system load of computers I deal with is due to perl code. I didn't write the code, so I don't know the specifics of how good/bad it is, but I'm just making a ge
Re:Web, schmeb (Score:2)
Regardless, I have never seen a benchmark where PHP ran faster than mod_perl, and for the most part, performance differences between them are negligible compared to the performance differences resulting from well-written code vs. poorly-written code.
CPAN Schmepan (Score:2, Interesting)
I would have to agree with you here. If you are going to compare speed of perl to speed of php, you have to compare the two doing the same thing.
Also, You cannot forget CPAN. The PHP folks will typically say something like, well we have PEAR. Unless PEAR has made some amazing strides in the last year or so, it is still no comparision to the massive body of code that CPAN provides.
Re:Web, schmeb (Score:2)
Well there you have it. Treat Perl like a scripting language and you get what you deserve.
Check out TTK, Mason or bricolage. I think you'll find that writing very low-footprint, scalabale applications is as easy in Perl as it is in many languages, and moreso than most. The problem arises when you get someone who doesn't even understand what a stateless system's likely bottlenecks will be trying to write c
Re:Web, schmeb (Score:3, Informative)
Here are some benchmarks [dmst.aueb.gr] you might find interesting. Particularly:
Rooting (Score:5, Funny)
So PHP is ideal unless, you know, you don't want to be rooted
Noted.
(Backs away slowly
Re:Web, schmeb (Score:5, Informative)
Saying that perl had to be addapted to web development is just wrong. perl also, is not slower than php. Perl is a VERY modular language. You can do traditional CGI programming in it, just like php. There are many templating options as well as mod_perl, which more resembles java servlets than it does php.
Also, stating that it's clearer means nothing. At least with DBI, i know how to connect to any database. With php, there's a seperate function to open a connection to the database, per vendor. Their function names are quite conveluded, switching orders of word types, i.e. noun_verb vs verb_noun.
PHP is built for the web first, and is a programming language second.
Re:Web, schmeb (Score:3, Interesting)
http://www.bagley.org/~doug/shootout/
This is old info but it does show that php's scripting engine has room for improvement.
Ultimately, when you consider the price of memory and processor speed, it doesn't really matter.
Re:Web, schmeb (Score:4, Interesting)
No more so than any other language. PHP really doesn't count here... it's an HTML templating tool that was adapted to programming, which is why it's great for prototyping small web tools, but even at the medium-scale (e.g. PHPNuke/PostNuke) it's already cumbersome in the extreme (look at how many times those two projects have had to re-architect). Insofar as PHP is getting back to its roots and becoming Perl again, it's a good language.
If I were starting from scratch on a new Web-related project I might use PHP, but I would almost certainly treat it as a templating system only, and then write the back-end in Perl or Java depending on the platform. But that might just be that I've not explored TTK enough... I've heard very good things about it as a templating system.
it's significantly slower than php
No, no it's not. Running any kind of benchmark on real code it's not. When you integrate Perl poorly with a Web server, then it's slow. When you integrate it well (e.g. bricolage, TTK, Mason) it's quite reasonable, and VERY easy to develop in.
[PHP is] easier to understand and easier to program in
well
PHP is a Perl derivative in roughly the same way that Java is a C++ derivative. One's children always spend their youth claiming that their parents "did it all wrong", but as they grow and mature they find that their parents had gone through all of this before and that their decisions were not so very surprising after all. PHP has come a long way, and bravo to it, but let's not get hyperbolic.
Familiarity with perl (slashdot)
Were you using Slash as an example of something written by someone familliar with Perl or as an example of something one would be familliar with?
If the former, it probably should have been "Familiarity with Perl and PHP not having been written yet (Slashcode)"
Re:Web, schmeb (Score:2, Insightful)
If so, PHP beats Perl on every graph except one, where they tie... and it has better memory utilization too... or am I way off on how I'm reading these?
Either way, they're both pretty close on that specific benchmark, I don't think I'd consider it proof of much of anything.
Re:Web, schmeb (Score:2)
I call bullshit on your link:
While there are some numbers here available for your review, benchmarking does not provide a real world assessment for any application operating in a specific real world scenario, and this does not try to demonstrate any proof that any system is better than any other.
Not to mention that, in those graphs, perl occasionally handles more requests per second than PHP, but almost ALWAYS has higher system load, and in many applications is SIGNIFICANTLY slower than PHP. For inst
Re:Web, schmeb (Score:2)
Pathologically Eclectic Rubbish Lister (Score:3, Informative)
I love perl for what it was designed to do: process text in just about any way imaginable. I hate it for the purpose proposed here: CGI scripts.
I usually use PHP for Web pages, a mixture of PHP, Perl and Bourne shell (and whatever else is at hand) for the back end, and I wouldn't touch MySQL for a database if my life depended on it, when there are vastly superior OSS altrernatives [postgresql.org] available.
Re:Pathologically Eclectic Rubbish Lister (Score:5, Funny)
<1/2 g>
Re:Pathologically Eclectic Rubbish Lister (Score:3, Funny)
Re:Pathologically Eclectic Rubbish Lister (Score:3, Insightful)
Also, there's pgAdmin III which is a nice database tool, but it's not web based.
Personally I just use psql, which is command line, but I understand a lot of people don't like to work with a database that way.
Why bother? (Score:3, Interesting)
Now with systems like Java Server Faces and Creator you can design a web form in a few seconds using a drag-and-drop designer, clip in some data validators, and visually design navigation through a complex website. A few more clicks and you have an single archive file that can be dropped into any J2EE application server, using any JDBC database on any platform.
You can design, code and test complex form-based web applications in minutes.. and al
Re:Why bother? (Score:2)
I'll believe it when I see it. Right now, the situation is that Java Server Faces is a very complex API and mature tool support does not appear to
Re:Why bother? (Score:2)
You may need to crack open the lid at some point, but GUI tools will get you most of the way.
Re:Why bother? (Score:2)
JSF Creator URL (Score:2)
Re:Web, schmeb (Score:3, Interesting)
The things that keep us using Perl are easy to identify:
1) very rapid development and even our non
Three cheers for LAMP (Score:2, Insightful)
Re:Three cheers for LAMP (Score:3, Informative)
Re:Three cheers for LAMP (Score:2)
Meaning that PHP is a real PITA - couldn't agree more. :)
Re:Three cheers for LAMP (Score:2)
Actually, both are equally valid and recognized, and LAMP is often broken out as Linux - Apache - MySQL - perl/PHP. The P stood for perl first though.
Re:Three cheers for LAMP (Score:2)
$db = initialize('dbauth');
#'dbauth' is a file with all of the database/authentication information for the restricted web account
($category, $categories) = selectquery($db, "select ID, name from sport order by name");
#returns a reference to an array, and the number of elements in the array
($mindate) = singlerow($db, "select min(date) from event");
#returns an array with values
Re: (Score:3, Funny)
Re:Three cheers for LAMP (Score:5, Funny)
How the hell do you Godwin a thread about a Perl book?
Perl / MySQL CMS solution. (Score:4, Informative)
now. It is a full CMS system that is truly open source and cross
platform, running on *nix, Windows and MacOS.
It truly is powerful yet very easy to use. Plenty of features such as Submissions system, Bulletin Board, Calendar, Syndicated Content and much more.
If you are looking for such a solution, feel free to give it a try.
are the plainblack docs still non-free? (Score:2)
If you're familiar with DBI... (Score:3, Informative)
It's being actively developed - a FrontBase release just happened a few days ago - and it supports a big list [rubyforge.org] of databases.
I'm going to have to get my copy.. (Score:3, Informative)
The whole love or hate thing in the article intrigues me I might add. I love both MySQL and Perl. Why? Well, you can't beat MySQL for its cheapness facor. Let's face it, most people don't need some professional job, myself included. And as far as Perl goes, well, anyone who's used it significantly can understand how great it is for practical answers on the fly.
Re:I'm going to have to get my copy.. (Score:3, Insightful)
By that, do you mean most people don't need more features, as in PostgreSQL [postgresql.org] and Firebird [ibphoenix.com]? Both are free (in fact, more free, if you consider MySQL's licensing requirements for businesses [mysql.com])
I used to enjoy coding in Perl… (Score:5, Funny)
Re:I used to enjoy coding in Perl… (Score:3, Funny)
old book? (Score:5, Informative)
Paperback, August 2001
also.... on the same bn site
A new copy is not available from Barnes & Noble.com at this time.
One whole chapter? (Score:3, Interesting)
As there are already books such as Programming the Perl DBI and Web Development with Apache and Perl, is the niche that this book is trying to fill actually worth it? Would I be better off reading Writing CGI Applications with Perl and The Official Guide to Programming with CGI.pm?
Personally, I haven't read a single one of them, so I'd really love to know. (one of these days, I'll actually read the copy of Practical mod_perl that's been collecting dust on my shelf.)
Authors other books... (Score:3, Informative)
When I first started out with MySQL I bought the book titled 'MySQL' written by DuBois. Since then, I've obtained a couple of other books about it and still find myself referring to his most often.
Too bad it isn't MySQL and (PHP|Python|Java). Who uses Perl in web programming anymore?
*dons flame retardant suit*
-Pat
Re:Authors other books... (Score:2, Insightful)
We use it at my company for the vast majority of our web programming tasks, and it works very well for us. Reasons I personally like it:-
* Contorl. While PHP may do a lot more for you (e.g. form parsing), there have certainly been issues related to how it did things. In Perl you can do it as you want. If you put this in a module, as we did, then Perl is no more work than PHP beyond that one-off cost.
* I find the Perl database access model preferable to PHP. C
Re:Authors other books... (Score:3, Informative)
Well, there's me... then there's sites like IMDB and Amazon.com, and *um* Slashdot?
Re:Authors other books... (Score:2)
I love programming in Perl! The sheer power and expressiveness combined with the (less than totally elegant) everything-and-the-kitchen-sink approach is fun!
But I really don't get this harping about the OO model? It's ugly syntax (and a "bit" of a hack), but it works. Perl's OO has much fewer things to do wrong than e.g. C++. (Advice -- read "Effective C++", I wish I had before! :-)
With good coding
For those getting started with Perl... (Score:3, Informative)
Nice. I'm planning on learning how to tie scripting (have decided on Perl yet but it's a contender) and databases this summer anyway. This book might make the decision as to what to use for me.
However, for those just picking up Perl for the first time I recommend the free ebook Picking Up Perl, and the [ebb.org] ActiveState Perl Interpreter [activestate.com] for Windows (this was a while ago-- if you are using Linux it probably aleraday has Perl installed). And then as it was Windows I was learning Perl on I used OpenPerl IDE [sourceforge.net]. For Linux I recommend using Kate and Konsole.
Not trying to be off-topic here but I figure someone reading this may want to try out what this Perl thing is.
Disclaimer: Not a Perl fan at all, I actually perfer Python, but to each their own and as any Perl hacker can appreciate TIMTOWTDI! ;)
Re:For those getting started with Perl... (Score:2)
Personally I've never seen a use for a Perl IDE (maybe it's just that I haven't seen a good one) - I use UltraEdit [ultraedit.com] day in and day out for Perl development and it's absolutely beautiful.
one thing perl did right (Score:4, Insightful)
With php, the commands for connecting to a database and running a query change, sometimes drastically, depending on the database you are using. For example, until recently if you had a query to run on a mysql backend, you did mysql_query($query) but for a postgres it was pg_exec($query). That is changing at least so now it's pg_query($query) but it still makes changing backends a large search, replace, and hope nothing breaks task.
Re:one thing perl did right (Score:3, Informative)
ezSQL [justinvincent.com] is one that comes to mind. There's plenty more.
Re:one thing perl did right (Score:3, Insightful)
And there's no problem with this? I have the same reaction when people tell me that X language now has regular expression libraries available for it. That's great in some circumstances, but unless there's one or two really good implementations of an API that everyone clusters around, it ends up being a drag on the community. Perl has very good built-in strings, associative arrays, and regular expressions, and this is very helpful the community. The community uses CPAN and generally
Re:one thing perl did right (Score:2)
Re:one thing perl did right (Score:2)
Similarly, if you look at the PEAR project [slashdot.org] site, you'll see no less than four database abstraction layers. PEAR DB is mature, widely used, and actually ships with the core PHP distribution these days. If you don't use it, that's your own affair.
Re:one thing perl did right (Score:2)
Just one quick example, the highly common operation of obtaining the value of an autoincrement column for a row you have just inserted. That is to say, obtaining (usually) the id of the row you have just inserted. This is not abstracted across RDBMS platforms. So for MySQL it is
Why actually choose MySQL? (Score:5, Interesting)
Maybe so, but I still have trouble figuring out why MySQL is given so much credibility in the first place.
In the previous story about MySQL [slashdot.org], I posted a comment asking what it actually did that other databases (including the also-free PostgreSQL) didn't do at least as well, or better. The main responses seemed to include:
The Windows build issue seems quite reasonable, but the other reasons imply that the main reason MySQL is so popular is simply due to lock-in. People use it because they have to, or because they're not familiar with the alternatives --- not necessarily because it's actually better for the task-at-hand.
Perhaps MySQL is such a common name that people haven't heard of better alternatives out there. Presumably the book that this story reviews, which gives it even more publicity, is yet another reason that someone might consider MySQL without even thinking about alternatives.
Can anyone tell me if I've missed anything, though? Besides the typical lock-in reasons for using MySQL, does it actually do anything better than other databases as any sort of killer feature?
If not, and if you're looking to start learning about a database and actually have a choice, it seems that you're much better off looking at an alternative database.... whether it be a free one such as Postgres, or one of the big ones such as Oracle or SQL Server. At the very least, you'd get a more reliable database than MySQL, a more portable database than MySQL, and even postgres (just as free) offers a wealth of additional -- often useful and important -- features such as stored procedures and more complete data integrity. You'll probably also become much more familiar with correct SQL syntax ... for what it's worth.
Re:Why actually choose MySQL? (Score:3, Insightful)
I love people screaming that the tool I am using is wrong, when they have no idea of just what I am doing. We also use Oracle, where needed, but we run MySQL 24/7/365 in an incredibly mission critical spot and are very satisfied with it. We tried other DB's and technologies including:
LDAP (Open and Sun/Netscape's)
Oracle
Postgres
Informix (Ok we still had a license and were bored
and none of them offered any better stability and only
Speed? (Score:2)
Really? Without partitioning? Without automatically maintained materialized views?
Ah, what you probably meant to say is that mysql does a read-only index-oriented workload better on small hardware than its larger competitors.
I'll buy that.
But, it's nonsensical to think that mysql can scan 300 million rows faster than Oracle/DB2/Informix when you add partitioning into the picture. In that case they can often simply scan the 5% of the data needed.
Sa
Re:Why actually choose MySQL? (Score:3, Informative)
I agree with most of your post, indeed I'd go further: MySQL doesn't deserve to be called a database at all, because it does not support transactions with commit/rollback, and cannot therefore guarantee to maintain referential integrity.
But to answer your question: I think the answer is performance, compared with Po
Re:Why actually choose MySQL? (Score:4, Interesting)
If a tiny easy to use database is all that you need, HSQL is for you. The one real gotcha though is that it can't handle datasets larger than 1/2 a GB. That's way too small for real database servers, but more than enough for most websites, even many commercial ones, I imagine.
In addition, HSQL can run within your java apps, which is really nice. I usually go for a dual pronged approach. use HSQL to handle all the file BS that you app might need (various config parameters, a small data cache that can be sifted efficiently in lots of different ways, other nastiness) and as (small) test databases to try a new idea.
For real DB work though, trade up to Postgres, and be sure to get 7.4, the 7.3.x line has a lot of crippling bugs.
The one real gripe I have about Postgres, is god, these people are in love with Hash joins. Any really good database should avoid hash joins like the plague unless it can guarantee that all the data that could possibly be returned by a subquery will fit into RAM. Postgres often wildly mis-estimates the size of a sub query, decides to hash it, and then gets killed when the query returns 100,000 rows, rather than 100.
A real database using a hash join when it doesn't know that it can take the whole table into RAM (if needed) is just begging to get run over. This is one of the few things that can really knock out an otherwise good database, and really should be considered more carefully. Hashjoins are for small reference data tables (few thousand rows), and should not be used unless you're guaranteed to be surprised.
HSQL of course doesn't have this problem, because it doesn't mess around with these "big" tables that are all the rage nowadays.
Re:Why actually choose MySQL? (Score:2, Informative)
Dude, check out SQLite. It's written in C. It's fast. And it's smaller than your java shite.
The one real gripe I have about Postgres, is god, these people are in love with Hash joins. Any really good database should avoid hash joins like the plague unless it can guarantee that all the data that could possibly be returned by a subquery will fit into RAM. Postgres often wildly mis-estimates the size of a sub query, decides to hash it, and then gets killed when the query returns 100,000 row
Re:Why actually choose MySQL? (Score:2)
Re:Why actually choose MySQL? (Score:2)
It's fast out of the box, and even moreso if you know how to tune it. Coming from an Oracle background, that's a breath of fresh air.
It's very, very easy to administer. Don't have enough room on this filesystem? Move your largest table over to another with "mv" and "ln".
It comes pre-installed just about everywhere.
Is all of that true for [pick your fav DB]...perhaps, but shock though it may be, people generally look for a tool that suits their needs, not EVE
Re:Why actually choose MySQL? (Score:2)
Re:Why actually choose MySQL? (Score:2)
Re:Why actually choose MySQL? (Score:2)
Answer to third question: If you're in psql interpreter, and connected to the database, type \dt and voila, a list of the tables. There are various ways to get the same list by querying the system tables, but I never learned them (I admit to using phpPgAdmin [sourceforge.net] which is superb for administering PostgreSQL databases, and which makes those kinds of things easy).
Answer to fourth question: in psql type describe your_tablename and it will show you the structure. Many of the commands in psql are the same as in SQL
Re:Why actually choose MySQL? (Score:2)
You must be blind. The first thing you see when you start the "psql" command-line utility is:
So, try out the \? command and you'll be presented with all the useful commands ...
Perl synonymous? (Score:3, Insightful)
Re:Perl synonymous? (Score:2)
Re:Perl synonymous? (Score:2)
Sometimes 4000 simultaneous instances just plain need to consume less than 256mb of RAM, it's just the way it is.
Perl, the Web, and Rapid development (Score:3, Insightful)
A book which claims to detail how to do web development with Perl and MySQL and doesn't address the following issues is painfully out of date:
* Class::DBI [class-dbi.com]
* SPOPS [sourceforge.net]
* Kake's How to avoid writing code [perl.com]
With the Perl Foundation funded work on Maypole [simon-cozens.org] being the most recent efforts in this direction.
Re:Perl, the Web, and Rapid development (Score:2)
wtf? (Score:2)
If you already know perl ... (Score:2)
Makes it trivial to create web-based apps. If you use Apache::Session, then state maintenence is a simple matter of populating an element in a hash. Makes web development really fast and modular, and mostly XSS-proof (it's sometimes a pain to make embedded perl actually create something like a link if you refer to it in a variable, unless you really think about it).
http://perl.apache.org/embperl/
Use it with mod_perl, some sort of database, and a bunch of your
I'm a little confused... (Score:3, Insightful)
A fully featured website (which needs it all), has several layers, at most:
The client-side dynamic content, javascript, vbscript, etc
The middle-ground dynamic content,
SSI's, PHP, ASP
And the backend,
Perl, C/C++, Java, (insert any true, full blown, fully featured, programming language here, which none of the above are).
There are places where these overlap, there are number of things you could do in Perl, PHP, ASP, or with SSI for instance, which it should be done with is a matter of efficientcy of course and preference when it's just as fast at 100,000 simultaneous connections either way (even if you only expect 5). But something like PHP is not a replacement for Perl anymore than Perl is for PHP.
It's apples and oranges guys, if you want to compare something go with the SQL database flames, at least there you are comparing pretty much the same thing to pretty much the same thing. And there that same thing and generally used for the same purposes.
Why mysql? OR perl for that matter? (Score:3, Informative)
IMO Perl is rapidly losing steam due to the enormous popularity of PHP. PHP is easier to learn, faster to master and less confusing to begin with. Not to mention, PHP's online documentation is really hard to beat sporting many easy to follow examples, a very functional layout, and features (such as the http://php.net/ search) that i'm pretty sure i've only seen mysql.com adopt.
Granted, PHP is not great for everything, but for small to medium websites (and arguably large websites as well, I know of some corporations that use PHP, see bravenet.com [bravenet.com], one of the largest providers of ready-to-run webmaster tools. They use PHP quite extensively.). For rapid application development, it's a dream.
As we come closer to PHP5 (which is RC2 now) we're also seeing the integration of sqlite as an option which may appeal to people who just want to write small blogs and other applications which simply do not demand the need of mammoths like mysql or postgresql. This means less headache for budding programmers, and easier migration of applications since sqlite does not require an SQL server.
Re:guffaw (Score:3, Insightful)
Tee-hee. I still laugh when I see that phrase.
Heh, not every website is a 50 line PHP hack made by a kid. You can do extremely powerful things with a website and those things can require complex programming skills. And that programming can be done in Perl.
Re:guffaw (Score:2)
Re:But why would you use Perl? (Score:2)
That's kind of ironic, coming from "FatSean (18753)."
Re:Good! (Score:2)
Re:Good! (Score:2)
Re:Good! (Score:3, Funny)
Oh, hell, you know the rest.
Re:Good! (Score:2)
Re:Huh? (Score:2, Insightful)
Blah blah blah buzzword buzzword buzzword spacefiller spacefiller blah blah this submission is now longer.
Re:Huh? (Score:2)
Translation: either ignorance or flamebait.
You don't use phrases like 'no argument' without expecting an argument.
Re:I'm sure I'm redundant (Score:2)
I'd love to know where you got that statistic from. My guess is "nowhere" or "my friends like PHP." PHP is popular within a certain community of designers who became programmers, but I strongly suspect that Perl has a wider base of users if you look at programmers as a whole.
As for your comment about borrowing code, there is really no language out there that has been as successful
Re:I'm sure I'm redundant (Score:2)
Perl (5498 projects)
PHP (8923 projects)
Re:I'm sure I'm redundant (Score:2)
Re:I'm sure I'm redundant (Score:2)
There are some large and complex sites written in Perl: TicketMaster.com, Amazon.com's newer stores, imdb.com, and others. PHP can be made to work in many situations, but Perl has more features for progamming in the large with teams and sharing code.
Re:I'm sure I'm redundant (Score:2)
Installing PHP = not so easy.
Learning PHP -- now that's where its strengths lie. I don't know much about the strengths and weaknesses of PHP vs. Perl as programming languages, but the learning curve for PHP is much lower.
PHP is understood by more people than Perl?!? Since when did PHP take these large grounds in popularity to overtake the most popular scripting langua
Re:USE ASP! (Score:3, Interesting)
ASP's not a scripting language, it's a technology. The language in this implementation is PerlScript, which is pretty much - wait for it - Perl. You don't specify how this implementation of ASP makes PHP "look like a kids' [sic] toy" but I've used two implementations of ASP - ChiliSoft (now SunONE) and Microsoft's - and PHP compares very favourably to both. I'd be surprised if apache-asp differed significantly.
Re:USE ASP! (Score:2)
No. Apologies for the confusion. The AC recommended apache-asp, a PerlScript implementation of ASP. I use <whispers> VB Script </whispers> on Chilisoft. I agree that mod_perl seems a far saner way to run Perl on Apache.
Re:USE ASP! PHP is not object oriented. (Score:2)
I use Chillisoft's ASP on Apache with MySQL, and it works quite well: it seems more stable than IIS. It's not object-oriented, though it can use Java "chillibeans". It's a reasonable platform for small- to medium-sized projects.
I've got to admit I still can't see any advantage .net has over Java, but I try and stay current in both.
Re:Put me down for... (Score:2)
Re:Perl or PHP faster? (Score:2)
Perl isn't exactly in competition with php, they have different purposes and are used for different things. Might as well start comparing perl to SSI's. True they overlap, and there are many things you could do in either but generally, if it's the front, you want php, if it's the back, you want perl.
Perhaps your perl backend might output a little html/php but it's certainly not going to be the other way around
Perl is great for cgi's, php is grea
Re:Perl or PHP? (Score:3, Interesting)
If you're the kind of coder that has an urge to make things