By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,050 Members | 1,283 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,050 IT Pros & Developers. It's quick & easy.

PHP Modules?

P: n/a
I'm fairly new to PHP, but a long time Perl coder.

This is probably answered somewhere, but I haven't been able to find
it. The "strength" behind Perl is in its modules; are there modules
available like that for PHP?

TIA,

Mike
Jul 17 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
In article <46**************************@posting.google.com >,
cs****@hotmail.com (Mike) wrote:
I'm fairly new to PHP, but a long time Perl coder.

This is probably answered somewhere, but I haven't been able to find
it. The "strength" behind Perl is in its modules; are there modules
available like that for PHP?


There is a lot of interesting stuff at http://pear.php.net/.

JP

--
Sorry, <de*****@cauce.org> is een "spam trap".
E-mail adres is <jpk"at"akamail.com>, waarbij "at" = @.
Jul 17 '05 #2

P: n/a
Mike wrote:
I'm fairly new to PHP, but a long time Perl coder.

This is probably answered somewhere, but I haven't been able to find
it. The "strength" behind Perl is in its modules; are there modules
available like that for PHP?

TIA,

Mike

You would probably be looking for php "classes" or "extensions". Many sites
such as http://php.net http://pear.php.net and http://hotscripts.com has
classes for many needs.
Jul 17 '05 #3

P: n/a
Mike wrote:
The "strength" behind Perl is in its modules; are there modules
available like that for PHP?
Mike


You have to be joking, Mike. CPAN is the reason I gave up on Perl for web
development and started using PHP. Basically to get Perl to perform as
quickly as PHP you need mod_perl, which doesn't handle memory in shared
environments as well as mod_php does. Consequently many hosting services
don't offer mod_perl.

CPAN modules, despite what everyone on the Perl lists tell you, are
notorioulsy unreliable when compiling. I have a Fedora box running Apache
2.0.48 and a G5 running Apache 1.3.29 on Panther. To get the same templating
features as PHP offers I would need Perl 5.8 + mod_perl + Apache::Template
or HTML::Mason. Well, Apache::Template doesn't work with Apache 2 so that
limits me to the G5 running Apacha 1.3.29. When I tried to install
Apache::Template via perl -MCPAN -e shell it wouldn't compile and left no
clues as to the reason why. As for HTML::Mason it won't work with Apache
2/mod_perl-1.99, which is now the default for Red Hat Enterprise Linux and
Fedora.

I've had MANY, MANY Perl module compilations fail in perfectly good UNIX
environments (OSX, Linux) and I'm sure this has something to do with why
many ISPs only offer a limited range of Perl modules.

Please don't take this as a flame against Perl because I started with Perl
and grew to love the syntax. I reluctantly switched to PHP for web
development because Perl CGI with CGI.pm is simply no match for mod_php.
Perl made the mistake of not offering a decent templating system as part of
the core. Sure, there are many good Perl templating systems (Template
Toolkit, Mason, Embperl) but they all require mod_perl for decent
performance and have many dependencies. Listen to the mod_perl developers
and you will learn that mod_perl gives unseasoned developers "plenty of
rope". That's also true for sysadmins who have to manage mod_perl processes
and shared memory. Most virtual hosting companies won't touch mod_perl so
Perl is reduced to dog-slow CGI. Endgame = PHP is becoming the de facto
standard for webdev. The Perl gurus don't care because they're all sysadmins.

The level of expertise required to get the best out of mod_perl is the
reason many developers of small-to-medium websites have turned to PHP -
because you don't need any modules and you have the same performance as
mod_perl BY DEFAULT, without the need to know all the ins and outs of Apache
processes simply to keep it running safely. PHP made the smart move of
aiming at the web development/HTML templating area that Perl neglected and
bundled everything needed into the core. PHP's strength is the fact that you
don't need modules.

I'm sure there are many PHP programmers, like myself, who reluctantly
migrated from Perl but who would have preferred not to have been obliged to
do so because they prefer Perl as a language. I blame the Perl community for
keeping their heads in the sand while PHP stole their ground in web development.

gunzip


Jul 17 '05 #4

P: n/a
gunzip <no**@none.com> wrote:

I'm sure there are many PHP programmers, like myself, who reluctantly
migrated from Perl but who would have preferred not to have been obliged to
do so because they prefer Perl as a language. I blame the Perl community for
keeping their heads in the sand while PHP stole their ground in web development.


I still perfer perl, but for all the reasons you mention I've switched
the web side to PHP. (for the most part, I'd still use mod_perl for it's
speed and power where it's available, I use it with swish-e for my
search page, and a few intranet level things)

Anyone ever use PHP on the web front, but then have PHP talk to a
middle-tier written in perl?

Jamie
--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

Jul 17 '05 #5

P: n/a
no****@geniegate.com wrote:
I still perfer perl, but for all the reasons you mention I've switched
the web side to PHP. (for the most part, I'd still use mod_perl for it's
speed and power where it's available, I use it with swish-e for my
search page, and a few intranet level things)

Anyone ever use PHP on the web front, but then have PHP talk to a
middle-tier written in perl?

Jamie


Case in point, the default Perl 5.8.1/mod_perl-1.26/Apache 1.3.29 which
comes with OSX Panther doesn't even have Perl's print() working under
mod_perl. That's how bad it gets with all these combinations. Sure, I could
re-install from source but I'd have to learn how to un-install the current
setup first AND reproduce what I had = non-trivial. In the meantime, I have
work to do. Perl is fine if you have endless hours to track down module
incompatibilities and futz with your OS all day like a Debian/Gentoo freak
trying to get his hardware working. PHP, to me, is what Red Hat is to Linux
- works cleanly out of the box so that I can be productive. If the likes of
Apache::Template and HTML::Mason still can't get it working with
mod_perl-1.99 and Apache 2 after all this time (how long have we had Apache
2 now?) then I have no confidence at all in using these solutions.

Have you noticed how upgrades of Perl and its major modules are taking
longer and longer between upgrades? Christ, we'll be lucky to see Perl 6
this side of the next decade the way it's going. Reason - it's getting ever
more complex. Throw Apache 2 into the mix and you have the current chaos
with many module developers ignoring Apache 2 altogether. The reason is that
the more modular you make something (Perl/mod_perl/Mason) the greater the
potential for incompatibilities and the slower the release cycle when one
part of the chain has to wait for another to produce a stable version.

Endgame = PHP as de facto webdev language.

gunzip

Jul 17 '05 #6

P: n/a
gunzip <no**@none.com> wrote:
Have you noticed how upgrades of Perl and its major modules are taking
longer and longer between upgrades? Christ, we'll be lucky to see Perl 6
this side of the next decade the way it's going. Reason - it's getting ever
more complex. Throw Apache 2 into the mix and you have the current chaos
with many module developers ignoring Apache 2 altogether. The reason is that
the more modular you make something (Perl/mod_perl/Mason) the greater the
potential for incompatibilities and the slower the release cycle when one
part of the chain has to wait for another to produce a stable version.

Endgame = PHP as de facto webdev language.


Upgrading perl is dicey at best. (Well, thats the case of any language
IMO)

I've had my fill of pulling hair out with mod_perl (mod_bald anyone? :-)
) mod_perl *is* faster than PHP as far as I can tell, but it is very
fragile.

I was just thinking perl could take an example from tomcat / servlet
technology, instead of this whole mod_perl thing. Then, each "perlette"
could be used independant of each other. (separate process)

In the meantime, I suppose one could have a perl process do the heavy
lifting (middle tier) and use PHP to talk to it.

Wish I had the 4 months it would take to design & release something like
servlets for perl.

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

Jul 17 '05 #7

P: n/a
no****@geniegate.com wrote:
I've had my fill of pulling hair out with mod_perl (mod_bald anyone? :-)
You're not the only one.
) mod_perl *is* faster than PHP as far as I can tell, but it is very
fragile.
Exactly. The fact that too many things can so easily go wrong with mod_perl
leads me to the conclusion that its design is flawed. Witness the problems
the mod_perl team are having getting it to work with Apache 2. Then, when
they've exhausted themselves with that one they'll be just in time for Perl
6 when everything will be turned upside down again. I'm not arguing against
improving the language, ie. Perl 6 itself, but if it is still dependent on
mod_perl for performance Perl will be history for most web developers. To
compete with PHP in the web development sphere Parrot will be the deciding
factor. If Parrot can get Perl up to mod_php speed without recourse to
mod_perl then I'd be interested in taking another look at it. Perl 6 also
needs to have something like Template Toolkit bundled in the core.

A tool that can only be used effectively by Apache internals experts (ie. to
avoid "hanging" themselves) is a tool which is practically useless. Mod_perl
gurus love to look down on lesser mortals but that'll be their loss when
more and more potential Perl projects are turned over to PHP. Perl's
dependence on mod_perl for decent performance is it's biggest weakness.

I'm not sure I agree that mod_perl is THAT much faster than mod_php, though.
I was just thinking perl could take an example from tomcat / servlet
technology, instead of this whole mod_perl thing. Then, each "perlette"
could be used independant of each other. (separate process)

In the meantime, I suppose one could have a perl process do the heavy
lifting (middle tier) and use PHP to talk to it.

Wish I had the 4 months it would take to design & release something like
servlets for perl.

Jamie


Jul 17 '05 #8

P: n/a
gunzip <no**@none.com> wrote:
Exactly. The fact that too many things can so easily go wrong with mod_perl
leads me to the conclusion that its design is flawed. Witness the problems
the mod_perl team are having getting it to work with Apache 2. Then, when
they've exhausted themselves with that one they'll be just in time for Perl
6 when everything will be turned upside down again.


Actually, mod_perl does work with Apache 2, however using it is an
excercise in chasing after non-existant documentation, general
hacking and fear of upgrading apache.

I for one don't understand why EVERYTHING has to be embedded in the web
server. out-of-process client/server stuff allows higher scale because
portions can be tasked out to other machines, apache upgrades are less
likely to break everything else and we can use perl where perl is good,
PHP where PHP is good, etc..

I'll admit there is a slight overhead in doing this, but considering
the benefits I think it's a mostly win situation, local network TCP
connections aren't really that slow.

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

Jul 17 '05 #9

P: n/a
With total disregard for any kind of safety measures gunzip
<no**@none.com> leapt forth and uttered:
Reason - it's getting ever
more complex.


You're not wrong. Have you read Larry Walls article on the Perl6
object model over at http://www.perl.com/pub/a/2004/04/16/a12.html?

--
Phil Roberts | Dork Pretending To Be Hard | http://www.flatnet.net/
Jul 17 '05 #10

P: n/a
Phil Roberts wrote:
You're not wrong. Have you read Larry Walls article on the Perl6
object model over at http://www.perl.com/pub/a/2004/04/16/a12.html?

I'm referring really to the ever-increasing dependence on modules to get
things done with Perl. CPAN is fine when you're futzing with your own server
or can ssh with full permissions into your company's server. Anything less
than that and CPAN becomes your biggest liability. Need Template
Toolkit/HTML::Mason? Sorry, we don't offer that "extension". I've heard
similar from ISPs so many times.

Alas many in the PHP community are heading that way with over-emphasis on
PEAR. Few seem to be aware of the drawbacks of over-modularity. Like CPAN,
PEAR may well end-up suffering from lack of quality control. Without that
the foundations of your work become shakier. PHP was designed, as far as I
understand it, to avoid this problem but it could so easily go PEAR-shaped
:-( if it tries to emulate CPAN.

Case in point, should PHP5 decide that it can adapt to Apache 2's threaded
model the larger PEAR has grown by that time, the larger the amount of
potential re-writing/breaking.

gunzip

Jul 17 '05 #11

P: n/a
gunzip <no**@none.com> wrote:
I'm referring really to the ever-increasing dependence on modules to get
things done with Perl. CPAN is fine when you're futzing with your own server
or can ssh with full permissions into your company's server. Anything less
than that and CPAN becomes your biggest liability. Need Template
Toolkit/HTML::Mason? Sorry, we don't offer that "extension". I've heard
similar from ISPs so many times.
That is exactly the reason I seldom used any CPAN stuff for distributed
perl applications. (unless the application expected root access) With
perl, you pretty much have to do all that yourself and create your
own lib so you can avoid the CPAN problem.
Case in point, should PHP5 decide that it can adapt to Apache 2's threaded
model the larger PEAR has grown by that time, the larger the amount of
potential re-writing/breaking.


I personally like java's idea of jar files and classloaders, BUT that
can even be worse than perl if it's overused. A ".pear" (tarball, etc..)
of packages of packages so you could distribute your code using known
libraries seems to be the best defense. (and also the most bloated
because each application may have an identical copy of the same library)

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

Jul 17 '05 #12

P: n/a
no****@geniegate.com wrote:
That is exactly the reason I seldom used any CPAN stuff for distributed
perl applications. (unless the application expected root access) With
perl, you pretty much have to do all that yourself and create your
own lib so you can avoid the CPAN problem.
Jamie


Last I heard Perl 6 is going to have even less in the core so CPAN module
dependency will increase. This has to be the worst move Larry Wall ever made
if he cares about the adoption rate of Perl. Maybe this has been revised
recently?

gunzip
Jul 17 '05 #13

P: n/a
On Thu, 22 Apr 2004 19:41:04 GMT, no****@geniegate.com wrote:
I for one don't understand why EVERYTHING has to be embedded in the web
server. out-of-process client/server stuff allows higher scale because
portions can be tasked out to other machines, apache upgrades are less
likely to break everything else and we can use perl where perl is good,
PHP where PHP is good, etc..


FastCGI looks quite interesting here; it's persistent processes for various
languages outside the webserver, and allows running remotely over TCP or
locally through IPC. Been meaning to look into this a bit more closely; if it
works, looks like it could give many of the advantages of mod_perl without the
headaches.

--
Andy Hassall <an**@andyh.co.uk> / Space: disk usage analysis tool
http://www.andyh.co.uk / http://www.andyhsoftware.co.uk/space
Jul 17 '05 #14

P: n/a
I found this on the Perl 5 Porters list:

<quote>
the perl distribution is already too big. We can't trim it
for backward-compatibility reasons but the core distribution
of Perl 6 will probably include only the modules that are
absolutely necessary to fetch and install the others.
</quote>

This could be taken 2 ways:

1. The Perl 6 core has no core modules/pragmata but there exists a bundle of
standard modules without which would be more or less essential to complete
the installation. If this new set of core modules expands beyond the current
set to make most webdev possible without much else then we have a definite
improvement.

2. Perl 6 cares even less about which webdev tool is popular, leaves
everything but the basics out of the core and leaves the end user with even
more ways to do it. ISPs suit themselves which modules they wish to install
and no-one can rely on modules for distributed applications. Same as we have
now but possibly worse.

OK, Perl is an all-purpose language so maybe we shouldn't expect it to make
decisions about its core based on the same criteria as PHP's. I reckon it
will probably become largely the preserve of sysadmins in the long run, though.

gunzip

Jul 17 '05 #15

P: n/a
gunzip <no**@none.com> wrote:
OK, Perl is an all-purpose language so maybe we shouldn't expect it to make
decisions about its core based on the same criteria as PHP's. I reckon it
will probably become largely the preserve of sysadmins in the long run, though.


Well, sysadmins and maybe big ticket n-server stuff. For average joe
with an ISP, perl is pretty much useless for the web side. Larger
companies that for some reason aren't using Java and have access to the
details of the server(s) can still make use of perl'ish stuff. Dedicated
servers are also useful places for perl.

In Average Joe's world, perl is still good for cron jobs or even CGI
scripts, things that aren't really meant to be hit all that often.
(such as a script that creates a tarball of backup files and sends it
across the browser or something) I would never attempt to use PHP as a
cron process except as a last resort.

One thing perl has that I've never really seen in PHP is the
eval { ... }; exception handling stuff.

Wish it were possible (in PHP) to do this:

eval {
something() or die("Failed at something");
something_else() or die("Failed at something_else");
};
if($@){
cleanup_resources();
die($@);
}
.. continue ..

or even a try { } catch { }
PHP seems to require a special die handler function and a whole lot of
overhead just to mimic exceptions. (even then, the functions generally
don't die() on a problem, so you have to check the return value.)

Ah well.. I'm kinda deviating from modules here. :-)

Jamie
--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

Jul 17 '05 #16

P: n/a
no****@geniegate.com wrote:
One thing perl has that I've never really seen in PHP is the
eval { ... }; exception handling stuff.

Wish it were possible (in PHP) to do this:

eval {
something() or die("Failed at something");
something_else() or die("Failed at something_else");
};
if($@){
cleanup_resources();
die($@);
}
.. continue ..

or even a try { } catch { }
PHP seems to require a special die handler function and a whole lot of
overhead just to mimic exceptions. (even then, the functions generally
don't die() on a problem, so you have to check the return value.)

Ah well.. I'm kinda deviating from modules here. :-)

Jamie


PHP5 has Java-style exception handling (try,catch,finally) so you're in luck.

gunzip

Jul 17 '05 #17

P: n/a
<no****@geniegate.com> wrote in message
news:4PYhc.5147$w96.721861@attbi_s54...
gunzip <no**@none.com> wrote:

PHP seems to require a special die handler function and a whole lot of
overhead just to mimic exceptions. (even then, the functions generally
don't die() on a problem, so you have to check the return value.)


But is exception handling really necessary in web development? In PHP all
resouces are released when the script terminates, so one of the main reasons
to do exception handling is out.

Jul 17 '05 #18

P: n/a
Chung Leong <ch***********@hotmail.com> wrote:
But is exception handling really necessary in web development? In PHP all
resouces are released when the script terminates, so one of the main reasons
to do exception handling is out.


True, however if one were using a database that supported transactions,
things can get messy checking return values. 90% of the population seems
to be using mysql, so the transaction recovery stuff is a moot point.
(Suppose one could set a function up that rolls back the database when
the script terminates or something, but that seems kind of messy)

Also it's handy to check a "stack" of functions for a problem, based on
the success or failure, do something else.

Imagine: // paranoid file editing.

lock original.txt // writing.
copy original.txt original.tmp // allow .txt to be read while working
process original.tmp // edit working copy.
rename original.txt to original.bak, // incase unlink & move fails later.
rename original.tmp to original.txt // Apply our edits, wish for an
// atomic swap($a,$b) :-)
unlock // dubious probably, depends on lock strategy.
unlink original.bak // cleanup.

Any of these steps fail and you might have temporary files lying about
that should be cleaned up. Exceptions are nice for this type of problem.

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

Jul 17 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.