Phoenix.pm: Best PHP reference book?

[Scott Walters]

On  0, Victor Odhner <vodhner at cox.net> wrote:
> 
> Scott, thanks for the book suggestions.
> 
> Scott Walters wrote:
> > Not to start a flame-war, but if you know and understand
> > Perl, why would you want to "learn" PHP? Just another resume
> > buzzword, you have to use it, what? Perl is already slighted
> > enough for not being a serious programming language, only
> > suited for rank hacks with no engineering discipline and
> > script kiddies (also with no engineering discipline).
> 
> I'm afraid I don't understand what you're trying to say here.
> Is it that you don't like PHP?  Or you don't like Perl?

No, no. I mean what I say - Perl lacks strong typing, protection
levels on methods, has a funny syntax for reading instance data
in classes, provides no fascilities for attribute inheritance - you 
have to protect instance data by manually doing variable name mangling.
OO languages are used for "serious" development work, and most
people who select languages to be used for "serious" development
work don't consider Perl to cut the OO mustard - for very valid
reasons. (Yes, Perl 6 aims to correct these and other problems). 
I'm not just talking about OO either - there are a lot of rough
edges in Perl. I do like Perl, and I have no interest in PHP ;)

> 
> After 30+ years at journeyman level in ALGOL, PL/I, COBOL, C
> and a bunch of less useful languages that I'd just as soon
> not think about (Prolog, LISP, VB, need I go on?), I found Perl.
> I've basically worked in nothing else except some C and a
> couple lines of VB in the past 6 years or so.  Of course
> nowadays I'm doing data entry as my day job, but I'm earning
> more with Perl most weeks.

I happen to like Lisp ;)

> 
> Perl works.  PHP is just, well, a piece of the Perl/Apache
> thing as far as I'm concerned.  I'm working now in a system
> that has some growing CGI response problems -- the pains of
> growing success -- and working in-process (PHP, ModPerl) may
> be part of the solution.  Not the whole solution, mind you --
> excessive database hits may be the real problem, but first
> they have to break up the 6,000 line monolithic library that
> gets loaded by each CGI call.  Um yeah, do you think?  ;-)

[Original reponse deleted]

What I think is of no matter, but...

PHP and Perl are very, very different, and only superficially
similar. Perl has been actively trying to move away from what PHP 
has been actively moving towards. Some novice Perl programmers
that use a tiny subset of the language have reported good luck
switching to PHP because of the superficial similiaries, but
for someone used to the thousands of things that Perl offers, it
is tough to switch. People seem to like PHP for the sloppy simplicity 
that many Perl'ers used to find endearing.

There are some languages out there with very good technical
and philosophical merits - Python is one of them, and I've heard
good things about Ruby and Pike. If you can stomache it, Haskell
and Ocaml pack one hell of a punch.

....but you should make up your own mind on the matter.

As far as the 6,000 line monolithic library problem, my 
suggestions: run FastCGI, or do something similar by writing
a webserver using HTTP::Daemon or whatever. If you use a module
such as HTTP::Daemon, you can write threading code for the
utmost level of memory efficiency and performance - running
mod_perl or PHP, you still have a seperate forked process for
each of a small finate number of processes you're willing to 
spend memory on. People have reported good lucking using POE
(the pulled object environment) and its components - POE was
designed for writing high performance servers. I don't recommend
mod_perl - there are too few cases where it is actually a win,
and it introduces strange and bizarre bugs - even core modules
like Safe coredump it or don't work at all. If you don't mind
the overhead of forking a CGI process, but the overhead of parsing
6,000+ lines of code is killing you, perlcc - the perl compiler -
actually works quite well now (version 5.8.0). Generating a binary
saves perl from having to parse all of the source code each and
every hit. Finally, you may wish to configure Apache to handle static
content requests itself and proxy active content requests to
a FastCGI or threaded Perl server on another port. This gives you
most of the advantages of running Apache and most of the advantages
of mod_perl-like solutions without actually having to run mod_perl.


> 
> So now about those books:  was one of them a really good
> reference, would you say?  Which one did you like *best*?

I haven't read any of them - at all. I'm sorry. Just wanted to 
point out that they were available so that it wasn't dead
silent in this channel, and so you had the chance to evaluate
them yourself.

-scott

> 
> Vic
> 
>