PHP Modules?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Mike

    PHP Modules?

    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
  • Jan Pieter Kunst

    #2
    Re: PHP Modules?

    In article <46cdc619.04042 10947.411fbd45@ posting.google. com>,
    csdude@hotmail. com (Mike) wrote:
    [color=blue]
    > 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?[/color]

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

    JP

    --
    Sorry, <devnull@cauce. org> is een "spam trap".
    E-mail adres is <jpk"at"akamail .com>, waarbij "at" = @.

    Comment

    • Brendan Donahue

      #3
      Re: PHP Modules?

      Mike wrote:
      [color=blue]
      > 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[/color]
      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.

      Comment

      • gunzip

        #4
        Re: PHP Modules?

        Mike wrote:
        [color=blue]
        > The "strength" behind Perl is in its modules; are there modules
        > available like that for PHP?
        > Mike[/color]

        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::Templat e
        or HTML::Mason. Well, Apache::Templat e doesn't work with Apache 2 so that
        limits me to the G5 running Apacha 1.3.29. When I tried to install
        Apache::Templat e 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








        Comment

        • nospam@geniegate.com

          #5
          Re: PHP Modules?

          gunzip <none@none.co m> wrote:

          [color=blue]
          > 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.[/color]

          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

          Comment

          • gunzip

            #6
            Re: PHP Modules?

            nospam@geniegat e.com wrote:[color=blue]
            > 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[/color]

            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
            incompatibiliti es 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::Templat e 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 incompatibiliti es 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

            Comment

            • nospam@geniegate.com

              #7
              Re: PHP Modules?

              gunzip <none@none.co m> wrote:
              [color=blue]
              > 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 incompatibiliti es 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.[/color]

              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

              Comment

              • gunzip

                #8
                Re: PHP Modules?

                nospam@geniegat e.com wrote:
                [color=blue]
                > I've had my fill of pulling hair out with mod_perl (mod_bald anyone? :-)[/color]

                You're not the only one.
                [color=blue]
                > ) mod_perl *is* faster than PHP as far as I can tell, but it is very
                > fragile.[/color]

                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.
                [color=blue]
                > 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
                >[/color]

                Comment

                • nospam@geniegate.com

                  #9
                  Re: PHP Modules?

                  gunzip <none@none.co m> wrote:[color=blue]
                  > 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.[/color]

                  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

                  Comment

                  • Phil Roberts

                    #10
                    Re: PHP Modules?

                    With total disregard for any kind of safety measures gunzip
                    <none@none.co m> leapt forth and uttered:
                    [color=blue]
                    > Reason - it's getting ever
                    > more complex.[/color]

                    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/

                    Comment

                    • gunzip

                      #11
                      Re: PHP Modules?

                      Phil Roberts wrote:
                      [color=blue]
                      > 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?
                      >[/color]
                      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

                      Comment

                      • nospam@geniegate.com

                        #12
                        Re: PHP Modules?

                        gunzip <none@none.co m> wrote:[color=blue]
                        > 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.[/color]

                        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.
                        [color=blue]
                        > 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.[/color]

                        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

                        Comment

                        • gunzip

                          #13
                          Re: PHP Modules?

                          nospam@geniegat e.com wrote:
                          [color=blue]
                          > 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[/color]

                          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


                          Comment

                          • Andy Hassall

                            #14
                            Re: PHP Modules?

                            On Thu, 22 Apr 2004 19:41:04 GMT, nospam@geniegat e.com wrote:
                            [color=blue]
                            >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..[/color]

                            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 <andy@andyh.co. uk> / Space: disk usage analysis tool
                            http://www.andyh.co.uk / http://www.andyhsoftware.co.uk/space

                            Comment

                            • gunzip

                              #15
                              Re: PHP Modules?

                              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

                              Comment

                              Working...