Re^2: PHP over perl

Really? I've never run across a vendor distribution of Perl (on multiple Linuxes and a couple versions of OS X) which doesn't include DBI, so I've always assumed it was part of the Perl core.

This is also a two-edged sword, in that PHP traditionally hasn't had anything equivalent to DBI, only database-specific interfaces. So if you wrote your app for MySQL and wanted to switch to PostgreSQL, you'd basically have to rewrite the whole thing if it was in PHP, while most of the transition in Perl would just be a matter of connecting to a different DBD driver (assuming you stuck with vanilla SQL instead of using lots of queries that call non-standard MySQL extensions, of course).

But, yeah, I agree that DBI and DBD::SQLite should be standard if they aren't already.

Comment on Re^2: PHP over perl

Replies are listed 'Best First'.
Re^3: PHP over perl by moritz (Cardinal) on Feb 10, 2009 at 16:38 UTC
DBI and various DBD modules have never been core, and probably never will, simply because there's no real benefit to it. It's much work to maintain many core modules, so the plan is to actually remove everything from core that's not needed to run perl, or install other modules. The philosophy is more that a plain core perl isn't all that useful for many tasks, so it should be distributed with helpful modules from CPAN. So the distributors have a choice, and many make use of that choice (for example the last time I used ActiveState Perl, it came with non-core modules installed by default). Or to put it differently - there's no good reason to connect default installation with core (where core = "maintained by p5p in the perl repository")	[reply]
Re^4: PHP over perl by DStaal (Chaplain) on Feb 10, 2009 at 18:55 UTC
I mainly wanted to bring it up because I see it as one of the main real benifits of PHP for web programming (at least as it is used): A programmer can use a database as a temp file system of sorts, without having to think about what it will take to get it used. This then means that the sysadmin doesn't have to allow the PHP user to write files to the system: They just install a database, and let the PHP user use that instead. The end result is easier to both use and administer: The PHP user can't access the filesystem (which means they don't have to be limited to what they can and can't do, and that it is impossible to perform a lot of trojan-executable attacks), so the admin doesn't have to worry about it, and the PHP user doesn't want to access the filesystem, so they never think about it.	[reply]
Re^3: PHP over perl by AKSHUN (Novice) on Feb 10, 2009 at 18:16 UTC
The problem that I encountered was trying to find the appropriate Oracle DBI Driver for Perl on Windows. Having DBI without the necessary drivers doesn't do one much good.	[reply]
Re^4: PHP over perl by leocharre (Priest) on Feb 18, 2009 at 14:34 UTC
I think I know where you're coming from. I remember being frustrated early on when I thought having DBI meant I could screw with SQLite out of the box. I would suggest this is part of the learning curve. An intermediate perl hacker is aware of DBD namespace (DBI drivers, amongst other things).	[reply]