Posted by Jerry Stuckle on 03/15/07 13:24

Jamie wrote:
> In <1173914816.457971.224720@d57g2000hsg.googlegroups.com>,
> "surfivor" <surfver@yahoo.com> mentions:
>> I may be involved in a data migration project involving databases and
>> creating XML feeds. Our site is PHP based, so I imagine the team might
>> suggest PHP, but I had a look at the PHP documentation for one of the
>> Pear modules for creating XML and it didn't look like much. I've used
>> Perl XML:Twig and I have the impression that there is more Perl stuff
>> available as well as the Perl stuff being well documented as I have a
>> Perl DBI book, a Perl XML, a Perl data munging book and so on. Alot of
>> the PHP books seem to be mainly on building sites and connecting to
>> databases, but I haven't checked them all and I have most of the Perl
>> books. One problem is that some of the Perl stuff is hard to get on
>> Activestate Perl for windows, so I may have to try to explain to them
>> why I think it should be done in Perl and why I need a linux login to
>> do it, etc. I'm not that familiar with PHP, but am looking for
>> comments on this.
>
> Seems to me, perl DBI is a bit more intuitive. Last time I looked,
> php didn't really have placeholders (well, it did, depending on which
> version of php was available where)
>

True, I also find perl DBI more intuitive. But both work well.

> This was awhile ago, but.. in mysql, placeholders didn't help much. Other DBM's
> though, like DB2 or postgresql will use place holders to cache a compiled SQL
> statement, (this happens server side) this can really boost performance if you
> have a lot of identical INSERT or SELECT statements that vary only in their
> input parameters. The DBM only has to inspect and parse the SQL once if it uses
> placeholders. This is rather a big deal if you want performance out of other
> DBM's.
>

True, if you're running 1K inserts per second it can make a difference.
For most perl and PHP isn't doing nearly that much. And if you need
the performance boost, a compiled language would provide a greater boost
than just using placeholders.

> Trouble with PHP is that one version is incompatible with the next,
> even along the same branches, 5.2 might not work with 5.1. It's sort
> of hit -n- miss. On top of that the php you use may have been compiled
> with flags the server didn't use or have ini settings that vary. Each
> "php platform" is "unique" with it's own settings. Each version of
> PHP is "unique" in that it may or may not work with your application.
>

Obviously you don't understand PHP very well. I've been programming
since the early 4.0.x and currently am at 5.2.1. I can't remember when
I've had to chance any code for a new release. Use good programming
practices and upgrades are painless.

Now that doesn't mean I haven't rewritten code. But it's been to take
advantage of new features rather than because a new version required a
change.

This is not to say that sometimes changes may not be needed. The PHP
developers are doing their best to clean up what has been a mess of a
language - poorly planned and executed. It's changing, but sometimes
change is painful.

Fortunately perl was better planned and implemented.

> All of this really makes a mess if you want to use other PHP scripts
> from other packages. PHP is like having the rug ripped out from under
> you at every turn.
>

Not at all. I use a lot of different packages. No problem.

> PHP really isn't very good for larger projects. (but then, the same
> has and can be said for perl)
>

Wrong on both count. I've seen both used in some quite large projects.
- one perl project I know about was over 250K LOC, for instance. And
that's perl code - not html.

> Sometimes you can "throw an exception" in PHP sometimes, you can't, again..
> depending on the version and quirks of whoever installed PHP. Perl on the other
> hand, it's a pretty safe bet eval { ... die "BOO"; } will work, this is
> important if you'll be doing any transactions or need to do things
> like break out of an XML parse operation from a callback, but catch
> it in the caller space.
>

Yep, exception handling was added to PHP, so like with any new addition,
you can use it in later versions but not in earlier ones. Gee - you
know, the same thing is true in any product. It's hard to use something
before it was added.

Perl doesn't have this problem as much because it has been around longer
and is more stable. But I suspect the same was true with the early
versions of perl.

> If you need to /consume/ XML, then you definately do not want PHP, as
> there really isn't the same flexibility with getting at the input
> as it arrives. It wants to put everything into $_POST before your
> script can have any say in the matter. This makes it quite difficult
> to parse an input document "as it arrives" (there are other ways
> around this in PHP, but none of them allow you direct access to the
> wire the way perl does)
>

No, that's different implementations. But I've never seen this as a
problem in either PHP or perl. The input document should be arriving
pretty much all at once, anyway.

> Perl on the other hand, allows you to get at the raw input data if
> you need it.
>

Yep, it can be nice at times. But that's one reason there is no "best"
language.

> I've been told that you can purchase extra tools to run PHP in a sort
> of peristent environment, but, in the free cost version it's impossible
> to create say, an XSLT tranformer object and share it with new requests.
>
> In PHP that data needs to be loaded each and every time, tree needs to
> be built for each request. With perl (and FastCGI or mod_perl), you can
> create a heavy object once and share it among requests. (pros and cons to
> this, of course. You can also accidently store other information and create
> memory leaks if your not careful)
>

Yes, this is easier in perl. But as you also note - there are both pros
and cons.

> The "heavy object sharing" lends itself really well to XSLT processors
> or DOM objects that don't change, load once and re-use over and over.
> This can really be crucial with XML processing, as XSLT transformers
> tend to be kind of expensive to create.
>

True, but if you really have to, there are ways around it in PHP. But
if you really want speed in processing, I suggest you implement it in
C/C++. That is much faster.

> PHP has the advantage that it's "template" is fairly standardized (well,
> most people have settled on "<?php ?>" so you don't have a dozen different
> overkill template engines.
>
> Hopefully I've given you enough "perl firepower" but, in my experience, no
> matter how you phrase the above points, people always assume perl is older
> technology and therefore inferior. PHP is modern, popular and therefore
> better:
>
> "Don't try to confuse me with the facts!" - LOL
>
>
> Jamie

OTOH, perl is older and therefore more stable and mature. Newer is not
always better. Each language needs to be evaluated in the context it
will be used. A language which fits well into one project may not fit
well into another.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]