Larry is correct to point out that anything PHP can do...you can do with perl (mod_perl)...often better, and still keep the language you use for everything else. In this sense the rise of PHP has mystified me.
Why the need for a novel language to do web scripting? The only argument I can see is ease of installation and learning, but those aren't good reasons for serious developers.
Why the need for a novel language to do web scripting? The only argument I can see is ease of installation and learning, but those aren't good reasons for serious developers.
When all you have is a hammer... everything looks like a nail.
Perl is a really, really, honkin' big hammer. It can smash just about any nail into anything. But sometimes, a wrench or a screwdriver would do the job better.
A master carpenter doesn't say "I can do anything with this hammer, given enough effort." He's got a giant toolbox filled with a dozen wrenches, a few hammers, screwdrivers... you get the point.
If you want to consider yourself a "serious developer", you should really consider broadening your skill set. There's a lot of things that I can do very fast in perl, but sometimes I need to come up with a quick database enabled website on Windows 2000. I immediately think, "Cold Fusion." Sure, I could install ActiveState perl, but I can do the job twice as quickly in CFML.
Likewise, PHP has it's job creating webpage templates in a UNIX environment. PHP has great database hooks and CGI handling. I can do some things in PHP in fewer lines than in Perl. The converse is also true -- in which case, I use Perl, and not PHP.
So, if you're handy enough with the Perl hammer, you could probably use it for everything. But you might dent up the walls a bit on the way.
Re: great database hooks: while the individual database extensions for PHP are dandy, the fact that there's no real database abstraction layer (yet) for PHP is a bit of a pain in the arse. Yes, there is the dbx extension, it isn't terribly roboust, and yes, there is the PEAR DB abstraction classes, but I would much rather see a true compiled extension. I have written a fairly decent abstraction layer which essentially mimics Perl's DBI (hasn't everybody), but it's just a stepping stone.
Hopefully in PHP 5 we'll see some sort of DBI-like interface for PHP, as I see no indiction of it happening in 4.x, and unfortunately I have no time to even attempt it myself. (Hell, I still need to look into writing a generic crypto interface for PHP 5...)
While it's not a part of PHP core yet, I suggest you check out ADODB [weblogs.com]. I've used it and find it just as easy as DBI. I've not used perl in a while but don't you still have to declare what db you're using? You would still have to CPAN the mysql support to DBI.
Quite honestly if uniformity in accessing a database is that important, shouldn't you be using ODBC?
Then you just go ahead and set up your statement handle and go nuts...
my $sth = $dbi->prepare("select * from mytable");
$sth->execute;
etc. To change database drivers, you just replace DBI:Pg: to DBI:MySQL or whatever. One little change, barring any SQL changes, which would be less of a problem if you use SQL92-compliant SQL.
In PHP, everything changes with each database: functions have different naming conventions, take different parameters, etc. (which is being cleaned up, actually). For instance, with the MySQL extension, you have a function called mysql_db_name(), the Postgres extension has a function called pg_dbname(), without the extra underscore. Somewhat annoying.
With PHP, multiple changes would be needed. I suppose you could use variable functions and such and just change them once and be done with it, but in the end, Perl's DBI is easier to work with than PHP's multiple database extensions.
ODBC would be nice, but after having many issues with it while working with it through Postgres and Access, it's more trouble than it's worth.
Not that I'm harping on PHP. I like PHP and I stick to Postgres almost exclusively, but in the end, there's a part of me that wants platform neutrality that Perl's DBI sort of has. DBI isn't perfect, but it's easier to remember and use it's unified interface than 15 separate PHP interfaces. Naturally, there's more to keeping your code easily portable across multiple database platforms than the language's interface, but it's a step in the right direction.
If you are eager to write language extensions then why not contribute to a project where you can make a difference.
The Moto Programming Language [webcodex.com] is new language geared at web programming. The interesting thing about Moto is that you can run scripts in interpreted mode while developing, then when things are ready you can compile your entire site into an Apache DSO, so it can run at super quick speeds.
We have basic MySQL connection abilities, PostgreSQL support will be out in one of the next few releases, and the user base is growing fairly fast.
We would love to have more help with writing extensions, or even just testing new releases. A major overhaul of regular expressions will be available in the next release, with lots of small additions soon to follow.
It would be great to have some sort of DBI-like model for Moto, but if you are itching to write a crypto interface then feel free.
We have a low traffic mailing list (8-9 posts a week) that anyone can sign up for and post to. All new users are welcome to post suggestions!
To the carpentry analogy I can claim the kitchen analogy - any master chef will tell you that you only need three or four knives. There simply isn't a practical reason for the twelve knife set.
Likewise with Perl and PHP. As your organization matures, you will find that your offline and online processing reuses techniques and tools. Why not reuse packages themselves? Using your approach I would more or less end up coding everything twice, once to support perl users doing offline work, and once to support PHP people doing the same/similar thing online.
The converse also holds - if you are already using PHP online it makes sense to use it for offline work as well. These languages are so similar in capabilties that I don't buy the domain-specific arguments.
Good point on PHP (Score:2)
Why the need for a novel language to do web scripting? The only argument I can see is ease of installation and learning, but those aren't good reasons for serious developers.
Re:Good point on PHP (Score:5, Insightful)
When all you have is a hammer... everything looks like a nail.
Perl is a really, really, honkin' big hammer. It can smash just about any nail into anything. But sometimes, a wrench or a screwdriver would do the job better.
A master carpenter doesn't say "I can do anything with this hammer, given enough effort." He's got a giant toolbox filled with a dozen wrenches, a few hammers, screwdrivers... you get the point.
If you want to consider yourself a "serious developer", you should really consider broadening your skill set. There's a lot of things that I can do very fast in perl, but sometimes I need to come up with a quick database enabled website on Windows 2000. I immediately think, "Cold Fusion." Sure, I could install ActiveState perl, but I can do the job twice as quickly in CFML.
Likewise, PHP has it's job creating webpage templates in a UNIX environment. PHP has great database hooks and CGI handling. I can do some things in PHP in fewer lines than in Perl. The converse is also true -- in which case, I use Perl, and not PHP.
So, if you're handy enough with the Perl hammer, you could probably use it for everything. But you might dent up the walls a bit on the way.
Re:Good point on PHP (Score:2)
Hopefully in PHP 5 we'll see some sort of DBI-like interface for PHP, as I see no indiction of it happening in 4.x, and unfortunately I have no time to even attempt it myself. (Hell, I still need to look into writing a generic crypto interface for PHP 5...)
J
Re:Good point on PHP (Score:2)
Quite honestly if uniformity in accessing a database is that important, shouldn't you be using ODBC?
Re:Good point on PHP (Score:2)
my $dbi = DBI->connect("DBI:Pg:dbname=mydb...");
Then you just go ahead and set up your statement handle and go nuts...
my $sth = $dbi->prepare("select * from mytable");
$sth->execute;
etc. To change database drivers, you just replace DBI:Pg: to DBI:MySQL or whatever. One little change, barring any SQL changes, which would be less of a problem if you use SQL92-compliant SQL.
In PHP, everything changes with each database: functions have different naming conventions, take different parameters, etc. (which is being cleaned up, actually). For instance, with the MySQL extension, you have a function called mysql_db_name(), the Postgres extension has a function called pg_dbname(), without the extra underscore. Somewhat annoying.
Anyway, with PHP, you do something like...
$pg = pg_connect(...);
$pgQuery = pg_query($, "select...");
$mysql = mysql_connect(...);
$mysqlQuery = mysql_query($mysql, "select...");
With PHP, multiple changes would be needed. I suppose you could use variable functions and such and just change them once and be done with it, but in the end, Perl's DBI is easier to work with than PHP's multiple database extensions.
ODBC would be nice, but after having many issues with it while working with it through Postgres and Access, it's more trouble than it's worth.
Not that I'm harping on PHP. I like PHP and I stick to Postgres almost exclusively, but in the end, there's a part of me that wants platform neutrality that Perl's DBI sort of has. DBI isn't perfect, but it's easier to remember and use it's unified interface than 15 separate PHP interfaces. Naturally, there's more to keeping your code easily portable across multiple database platforms than the language's interface, but it's a step in the right direction.
J
Re:Good point on PHP (Score:1)
The Moto Programming Language [webcodex.com] is new language geared at web programming. The interesting thing about Moto is that you can run scripts in interpreted mode while developing, then when things are ready you can compile your entire site into an Apache DSO, so it can run at super quick speeds.
We have basic MySQL connection abilities, PostgreSQL support will be out in one of the next few releases, and the user base is growing fairly fast.
We would love to have more help with writing extensions, or even just testing new releases. A major overhaul of regular expressions will be available in the next release, with lots of small additions soon to follow.
It would be great to have some sort of DBI-like model for Moto, but if you are itching to write a crypto interface then feel free.
We have a low traffic mailing list (8-9 posts a week) that anyone can sign up for and post to. All new users are welcome to post suggestions!
Try it out for yourself.
So you code everything twice? (Score:2)
Likewise with Perl and PHP. As your organization matures, you will find that your offline and online processing reuses techniques and tools. Why not reuse packages themselves? Using your approach I would more or less end up coding everything twice, once to support perl users doing offline work, and once to support PHP people doing the same/similar thing online.
The converse also holds - if you are already using PHP online it makes sense to use it for offline work as well. These languages are so similar in capabilties that I don't buy the domain-specific arguments.
Re:So you code everything twice? (Score:1)
Curiously,
Re:So you code everything twice? (Score:1)
Re:Good point on PHP (Score:1)
Re:Good point on PHP (Score:2)