Re^3: PHP over perl

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")

Comment on Re^3: PHP over perl

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]