The Superiority of PHP over Perl
Egg Troll
Recently I've had a chance to do some web design with PHP. Previously
I'd used Perl because I'd heard from many people that Perl was the end
all and be all of scripting languages for the web. Imagine my suprise
to discover that PHP was vastly superior! I know this is a bold
statement, but I have solid arguements to support it.
Before I begin, let me just clarify something. I'm not arguing that
PHP is better than Perl in all cases. There is certainly still a use
for Perl. Also, PHP isn't perfect but it does manage to fix many of
the shortcomings I've had with Perl. Here are a few of the things I've
noticed about PHP. Finally, I'm not the most talented Perl programmer
out there. I generally prefer to use the vastly superior Python, but
can use Perl if I have to.
* Ease of use. After about a day I had an excellent understanding of
both PHP and SQL. I was able to get a stable, useable and presentable
website up within 24 hours of reading the basics of PHP. Learning Perl
took me weeks and I'm still not even as good with it as I am with PHP.
I would definitely not recommend anyone new to programming begin with
Perl.
* The OO of PHP is excellent. In my experience, it rivals Smalltalk.
We all know that Perl's OO still needs work (whether or not OO is all
that great is another discussion.) Hopefully Perl will be patched up
so it supports such must-have OO features like introspection,
reflection, self-replication and ontological data-points.
* Outstanding database support. PHP supports virtually every DB under
the sun (although Berkeley DB is missing, oddly enough.) Perl seems
limited to MySQL and PostgreSQL, and its really a kludge for the
later. I've heard that this will be fixed in upcoming versions of Perl
though.
* Speed. PHP is one of the fastest languages I've ever used. While it
won't be replacing assembly or C, its definitely faster than Perl in
almost every case, particularly in regex which has long been Perl's
strongest point. I'm sure there are cases where Perl is equal to PHP,
but I can't think of any at the moment.
* Portability. I can take PHP code off my Linux box and plop it onto
an IIS server, or even one of those new Macintosh servers and have it
run without having to change a single line of code. Try doing this
with Perl! Its as though it was written in assembly, Perl requires
that much rewriting.
* Graphics. PHP comes with a nice little graphics library. While I
wouldn't use its to code the new Doom (VB would be a better choice)
its adequate for most web pages, and should be considered as a
substitute for Flash for certain things. Perl lacks a graphics library
of any kind.
* Data Structures. Under PHP you can create any type of datastructure
you need: Linked lists, binary trees, hash tables, queues, inverse
Reiser-biased recursion trees, etc. Under Perl you're extremely
limited in what you can do. This is because Perl isn't OO (so you
can't create Node classes, for example, usefull in a linked list) and
because it lacks pointers. Some of you may notice that PHP lacks
pointers, but look deeper! Behind the scenes, hidden from the user
pointers are used. Because of this, PHP can support complex data
structures.
Again this is just my experience. I don't mean to offend any Perl
coders because Perl was an excellent language. However, in certain
cases it may behoove one to write the back end in PHP instead of Perl.
Merry Kwanza!
Egg Troll
bd
> Hello Usenet,
>
> Recently I've had a chance to do some web design with PHP. Previously
> I'd used Perl because I'd heard from many people that Perl was the end
> all and be all of scripting languages for the web. Imagine my suprise
> to discover that PHP was vastly superior! I know this is a bold
> statement, but I have solid arguements to support it.
You have crossposted your reply to many irrelevant groups. It really only
belongs in comp.lang.php and comp.lang.perl.misc. Why are you putting it in
a C newsgroup?
--
Replace spamtrap with bd to reply.
To follow foolish precedents, and wink
With both our eyes, is easier than to think.
- William Cowper
cybear
> Hello Usenet,
>
> Recently I've had a chance to do some web design with PHP. Previously
> I'd used Perl because I'd heard from many people that Perl was the end
> all and be all of scripting languages for the web. Imagine my suprise
> to discover that PHP was vastly superior! I know this is a bold
> statement, but I have solid arguements to support it.
>
I like using PHP as a web scripting language, BUT, web scripting is NOT
the only scripting that is done. Perl works well for all my other
scripting language. If a person wants to learn just one scripting
language to do everything, Perl wins.
Martien Verbruggen
Don't respond to this troll.
Martien
--
| Yes; Windows is great for running &
Martien Verbruggen | developing viruses, for instance. It's also
| very popular, but then again, so is the
| common cold. -- Dave Hinz
bd
> (so you
> can't create Node classes, for example, usefull in a linked list)
Why would you need a linked list, when you can do essentially everything
that can be done with a linked list with perl's array? See the
documentation for array slices and the 'delete' function.
--
Replace spamtrap with bd to reply.
Thank you for observing all safety precautions.
Benjamin Goldberg
[snip]
> * Ease of use. After about a day I had an excellent understanding of
> both PHP and SQL. I was able to get a stable, useable and presentable
> website up within 24 hours of reading the basics of PHP. Learning Perl
> took me weeks and I'm still not even as good with it as I am with PHP.
> I would definitely not recommend anyone new to programming begin with
> Perl.
Perl has a long, shallow learning curve. I learned to do basic things
within a day of starting out.
> * The OO of PHP is excellent. In my experience, it rivals
> Smalltalk. We all know that Perl's OO still needs work (whether or not
> OO is all that great is another discussion.) Hopefully Perl will be
> patched up so it supports such must-have OO features like
> introspection, reflection, self-replication and ontological
> data-points.
Perl's OO already supports introspection, reflection, and
self-replication to a degree.
For introspection/reflection, one can use the UNIVERSAL:: methods "can"
and "isa"; also, one can look at the @ISA tree of a class directly, and
the %SymbolTable:: of a class directly.
For self-replication, you have to write a constructor which somehow
supports it. E.g., one could write:
sub clone {
my $oldself = shift;
my %newself = %{ $oldself };
return bless \%newself, ref $oldself;
}
> * Outstanding database support. PHP supports virtually every DB
> under the sun (although Berkeley DB is missing, oddly enough.) Perl
> seems limited to MySQL and PostgreSQL, and its really a kludge for the
> later. I've heard that this will be fixed in upcoming versions of Perl
> though.
Perl supports, through the DBI module, a whole slew of relational
databases. ADO, ASAny (Adaptive Server Anywhere), Adabas, DB2, Empress,
EmpressNet, Fulcrum, Illustra, Informix, Informix4, InterBase, JDBC,
LDAP, ODBC, Ovrimos (aka Altera), PostgreSQL, PrimeBase, QBase, SQLite,
SearchServer, Solid, Sprite, Sybase, Teradata, Unify, XBase, and MySQL.
There are also modules for using CSV files and Excel files as databases.
> * Speed. PHP is one of the fastest languages I've ever used.
> While it won't be replacing assembly or C, its definitely faster than
> Perl in almost every case, particularly in regex which has long been
> Perl's strongest point. I'm sure there are cases where Perl is equal
> to PHP, but I can't think of any at the moment.
Do you have benchmarks on this? In particular, since PHP is generally
embeded in the server (eg, the mod_php apache module), make sure that
the perl script that you compare it to is run similarly (mod_php).
> * Portability. I can take PHP code off my Linux box and plop it
> onto an IIS server, or even one of those new Macintosh servers and
> have it run without having to change a single line of code. Try doing
> this with Perl!
I've never had a problem with this. It's possible to go out of your way
to write *unportable* code, of course, but writing portable code isn't
the least bit difficult.
> Its as though it was written in assembly, Perl requires that much
> rewriting.
Any chance you could show me a perl program which requires such
modifications (other than binmode(filehandle), that is) when moving it
from one machine to another?
> * Graphics. PHP comes with a nice little graphics library. While
> I wouldn't use its to code the new Doom (VB would be a better choice)
> its adequate for most web pages, and should be considered as a
> substitute for Flash for certain things. Perl lacks a graphics library
> of any kind.
What about the GD and ImageMagik modules?
> * Data Structures. Under PHP you can create any type of datastructure
> you need: Linked lists, binary trees, hash tables, queues, inverse
> Reiser-biased recursion trees, etc.
Perl's builtin 'array' data structure can perform most of the functions
of a linked list, and all of the functions of a queue, since it's
implemented as a dequeue (you can perform O(1) push, pop, shift, and
unshift operations on it).
Perl has a builtin hash function.
One can *easily* use hashrefs or arrayrefs the same way that you would
use pointers to structs, in C -- and of course with that, you can build
any kind of tree you want.
> Under Perl you're extremely limited in what you can do.
Pff.
> This is because Perl isn't OO (so you can't create Node classes, for
> example, usefull in a linked list) and because it lacks pointers.
You seem to completely forgotten about Perl's references. These do all
the things that pointers do, with the big bonus of being garbage
collected for you.
See perldoc perlref
> Some of you may notice that PHP lacks pointers, but look deeper!
> Behind the scenes, hidden from the user pointers are used. Because of
> this, PHP can support complex data structures.
Perl's reference types are right up front where users can use them
easily -- this makes complex data structures in perl easy to build.
See perldoc perldsc
--
$..='(?:(?{local$^C=$^C|'.(1<<$_).'})|)'for+a..4;
$..='(?{print+substr"\n !,$^C,1 if $^C<26})(?!)';
$.=~s'!'haktrsreltanPJ,r coeueh"';BEGIN{${"\cH"}
|=(1<<21)}""=~$.;qw(Just another Perl hacker,\n);
Måns Rullgård
/| /| | |
||__|| | Please do |
/ O O\__ NOT |
/ \ feed the |
/ \ \ trolls |
/ _ \ \ ______________|
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ \ __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________
--
Måns Rullgård
m...@users.sf.net
Emmanuel Delahaye
> Recently I've had a chance to do some web design with PHP. Previously
> I'd used Perl because I'd heard from many people that Perl was the end
<snip OT on clc>
Please don't post that stuff to comp.lang.c. We don't ever know what Pearl or
PHP mean...
--
-ed- emdel at noos.fr ~]=[o
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
C-library: http://www.dinkumware.com/manuals/reader.aspx
"Mal nommer les choses c'est ajouter du malheur au monde."
-- Albert Camus.
Murat Ünalan
> self-replication to a degree.
..to a degree. Did you introspect methods (not subs) and attributes
from a give class/package.
> For introspection/reflection, one can use the UNIVERSAL:: methods "can"
> and "isa"; also, one can look at the @ISA tree of a class directly, and
> the %SymbolTable:: of a class directly.
Aaargh... this is mostly not helpfull. Show me how you introspect module
methods (not funcs/subs) and attributes ?! Its impossible.
> I've never had a problem with this. It's possible to go out of your way
> to write *unportable* code, of course, but writing portable code isn't
> the least bit difficult.
I bang my head nearly weekly against my monitor, because *nix-vs-win
compability.
Any statistics from the cpantesters would reveal that. This is mostly
because of ignorance.
Murat
istartedi
Egg Troll <eggt...@yahoo.com> wrote in message
news:4e2f159f.02122...@posting.google.com...
[snip]
go back to Slashdot.
--$teve
Benjamin Goldberg
>
> > Perl's OO already supports introspection, reflection, and
> > self-replication to a degree.
>
> ..to a degree. Did you introspect methods (not subs) and attributes
> from a give class/package.
Every sub in a class is a method for that class. There is no
distinction in perl.
> > For introspection/reflection, one can use the UNIVERSAL:: methods
> > "can" and "isa"; also, one can look at the @ISA tree of a class
> > directly, and the %SymbolTable:: of a class directly.
>
> Aaargh... this is mostly not helpfull. Show me how you introspect
> module methods (not funcs/subs) and attributes ?! Its impossible.
As I said, every function/sub *is* a method.
As to attributes... In perl, modules don't really have 'attributes' --
Unless you consider stuff like $object->{foo} to be an attribute, in
which case you can examine it by, err, examining it (with keys(),
values(), and/or each() on %$object).
> > I've never had a problem with this. It's possible to go out of your
> > way to write *unportable* code, of course, but writing portable code
> > isn't the least bit difficult.
>
> I bang my head nearly weekly against my monitor, because *nix-vs-win
> compability.
What kind of incompatibility? If it's because of [lack of] using
binmode() on those filehandles which contain binary data, then I would
*not* in any way consider it perl's fault -- it's ignorance/stupidity.
You would have the same problems if you wrote your program in C or C++.
> Any statistics from the cpantesters would reveal that. This is mostly
> because of ignorance.
So... when someone writes broken code, and puts it on CPAN, you consider
it *Perl's* fault that the code doesn't work?
Or if you use that broken code *without* looking at the CPAN-testers
test results for the platforms you're using it on, you consider that
*Perl's* fault?
Jan Steinman
eggt...@yahoo.com (Egg Troll) wrote:
> * The OO of PHP is excellent. In my experience, it rivals Smalltalk.
Then you have no experience with Smalltalk! :-)
--
: Jan Steinman -- nature Transography(TM): <http://www.Bytesmiths.com>
: Bytesmiths -- artists' services: <http://www.Bytesmiths.com/Services>
: Buy My Step Van! <http://www.Bytesmiths.com/van>
Murat Ünalan
> distinction in perl.
Nonsense. When is introspect a class, i just want to distinct "methods"
of that class, not helper-functions or just noise.
package A;
sub aMethod
{
my $self = shift;
}
sub printHello
{
print "Hello";
}
printHello is just a stupid function which swims in the A:: package, nothing
else. No method !
> As I said, every function/sub *is* a method.
s.a.
> As to attributes... In perl, modules don't really have 'attributes' --
Nonsense. Perl classes do have attributes.
> Unless you consider stuff like $object->{foo} to be an attribute, in
I do, as my OO-books aren't wrong.
> which case you can examine it by, err, examining it (with keys(),
> values(), and/or each() on %$object).
There is no general syntax for them. This is russian bullets. So you
have no chance getting information you would need. Every hacker
has his own blessed 'something'.
Introspection is good for a lot (generic otf object-mappers etc.), but this
doesn't counts for perl. It is virtually
absent.
> What kind of incompatibility? If it's because of [lack of] using
Lack of passing required tests during installation.
> Or if you use that broken code *without* looking at the CPAN-testers
> test results for the platforms you're using it on, you consider that
> *Perl's* fault?
Yes, perl-community fault. This could be prevented somehow (clean
guidelines, abstraction).
Murat
Måns Rullgård
> > I bang my head nearly weekly against my monitor, because *nix-vs-win
> > compability.
>
> What kind of incompatibility? If it's because of [lack of] using
> binmode() on those filehandles which contain binary data, then I would
> *not* in any way consider it perl's fault -- it's ignorance/stupidity.
Yes, the ignorance of the authors of MSWindows. I believe that if
they would choose to switch to sane behavior regarding line ends, the
only ones that would even notice would be happy about it.
--
Måns Rullgård
m...@users.sf.net
Bart Lateur
>* Outstanding database support. PHP supports virtually every DB under
>the sun (although Berkeley DB is missing, oddly enough.) Perl seems
>limited to MySQL and PostgreSQL, and its really a kludge for the
>later. I've heard that this will be fixed in upcoming versions of Perl
>though.
In PHP, every database has its own interface. In Perl, there's one
unified interface for all databases: DBI. And Perl has palceholders.
>* Speed. PHP is one of the fastest languages I've ever used. While it
>won't be replacing assembly or C, its definitely faster than Perl in
>almost every case, particularly in regex which has long been Perl's
>strongest point. I'm sure there are cases where Perl is equal to PHP,
>but I can't think of any at the moment.
In Perl, a regex is a precompiled primitive. In PHP, it's a string, so
it needs to be recompiled every single time you match anything.
>* Data Structures. Under PHP you can create any type of datastructure
>you need: Linked lists, binary trees, hash tables, queues, inverse
>Reiser-biased recursion trees, etc. Under Perl you're extremely
>limited in what you can do. This is because Perl isn't OO (so you
>can't create Node classes, for example, usefull in a linked list) and
>because it lacks pointers. Some of you may notice that PHP lacks
>pointers, but look deeper! Behind the scenes, hidden from the user
>pointers are used. Because of this, PHP can support complex data
>structures.
There's nothing you can do in PHP you can't do in Perl. Quite the
contrary.
The one thing PHP has over Perl WRT data structures, IMO, is that
"hashes" remain ordered.
--
Bart.
Tassilo v. Parseval
>> Every sub in a class is a method for that class. There is no
>> distinction in perl.
>
> Nonsense. When is introspect a class, i just want to distinct "methods"
> of that class, not helper-functions or just noise.
>
> package A;
>
> sub aMethod
> {
> my $self = shift;
> }
>
> sub printHello
> {
> print "Hello";
> }
>
> printHello is just a stupid function which swims in the A:: package, nothing
> else. No method !
It is a method, no matter how you call it. In Perl there is simply no
distinction between a class method, an instance method and a function
caller-wise. Weren't it a method, you couldn't do the following:
$object->printHello;
But you can also do:
A->printHello;
which shows that it is also a class-method. In both cases there's a
hidden first argument in $_[0] (in the first case it is the blessed
referent, in the second the package name). Only if you call it as
function this argument disappears:
A::printHello();
>> As I said, every function/sub *is* a method.
>
> s.a.
>
>> As to attributes... In perl, modules don't really have 'attributes' --
>
> Nonsense. Perl classes do have attributes.
Debatable. In this case the distinction between class- and instance-data
does matter. A package global could be called a class-attribute while
the things you store in a blessed hash might be considered
instance-attributes. But unlike other languages, Perl allows you to add
attributes from the outside world:
my $obj = A->new;
$obj->{new_attribute} = 1;
$A::another_attribute = 1;
Since you can even add methods that way you can extend a class easily:
package main;
sub A::get_attribute { shift->{new_attribute} }
sub A::get_another_attribute { $A::another_attribute }
>> Unless you consider stuff like $object->{foo} to be an attribute, in
>
> I do, as my OO-books aren't wrong.
But I guess your OO-books also told you that you can't that easily add
or remove attributes. In Perl this is possible since (per default) there
is no strong encapsulation of data. If you want that you can use
closures in which case you get even stronger encapsulation than most
other object-oriented languages.
>> which case you can examine it by, err, examining it (with keys(),
>> values(), and/or each() on %$object).
>
> There is no general syntax for them. This is russian bullets. So you
> have no chance getting information you would need. Every hacker
> has his own blessed 'something'.
You are right here. There is no way to get to the data when for instance
closures are used. That might have been done on purpose to prevent
people from peeking into the object. Yet this is rather uncommon in the
world of Perl: freedom to do whatever you want is preferred in the world
of Perl (even if it is freedom to shoot yourself into the leg).
>> What kind of incompatibility? If it's because of [lack of] using
>
> Lack of passing required tests during installation.
>
>> Or if you use that broken code *without* looking at the CPAN-testers
>> test results for the platforms you're using it on, you consider that
>> *Perl's* fault?
>
> Yes, perl-community fault. This could be prevented somehow (clean
> guidelines, abstraction).
How? Have you ever written a Perl module for the CPAN? You'll stumble over
incompatibility issues a lot without this being Perl's fault. You can't
blame a language that Windows does not know about flocking, can you?
It's an infinite list really. Every Perl module that interacts with the
operating system potentially suffers from these problems in some way.
I'd really like to know how you'd solve that through abstraction or
stricter guidelines.
Tassilo
PS: newsgroups trimmed to c.l.perl.m and c.l.php but follow-up suggested
since this thread is gradually moving away from PHP.
--
$_=q!",}])(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
Benjamin Goldberg
And how does this solve compatability problems for the X million people
who have the current versions of windows? Sure, if they introduced a
new version with sane line endings, that would be nice, but that will
only help those who install that new windows.
Also, binmode() isn't *only* for line-endings. The newest versions of
RedHat Linux have the LANG environment variable set to utf8, meaning
that every program which deals with text needs to deal with utf8
characters, *not* bytes. By default, perl opens files in text mode. If
your LANG indicates that text files are utf8, then perl puts a ":utf8"
encoding layer onto every file opened in text mode -- which is vital if
you're printing text to that handle, but probably disastrous if your
data is binary stuff. In other words, on RedHat, you need to binmode
your filehandles the same as you would on Windows, or else your data
will be corrupted.
Måns Rullgård
> > > > I bang my head nearly weekly against my monitor, because
> > > > *nix-vs-win compability.
> > >
> > > What kind of incompatibility? If it's because of [lack of] using
> > > binmode() on those filehandles which contain binary data, then I
> > > would *not* in any way consider it perl's fault -- it's
> > > ignorance/stupidity.
> >
> > Yes, the ignorance of the authors of MSWindows. I believe that if
> > they would choose to switch to sane behavior regarding line ends, the
> > only ones that would even notice would be happy about it.
>
> And how does this solve compatability problems for the X million people
> who have the current versions of windows? Sure, if they introduced a
> new version with sane line endings, that would be nice, but that will
> only help those who install that new windows.
M$ are usually good at forcing people to upgrade.
> Also, binmode() isn't *only* for line-endings. The newest versions of
> RedHat Linux have the LANG environment variable set to utf8, meaning
> that every program which deals with text needs to deal with utf8
> characters, *not* bytes. By default, perl opens files in text mode. If
> your LANG indicates that text files are utf8, then perl puts a ":utf8"
> encoding layer onto every file opened in text mode -- which is vital if
> you're printing text to that handle, but probably disastrous if your
> data is binary stuff. In other words, on RedHat, you need to binmode
> your filehandles the same as you would on Windows, or else your data
> will be corrupted.
I've never liked redhat.
--
Måns Rullgård
m...@users.sf.net
Kasp
If you don't know about Mr. Egg Troll, may I suggest you to do a google
search on the groups for him.
Let me help you ...click on this link below
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=%22eggtroll@ya
hoo.com%22
You will notice he is a very smart "thread" starter...and never contributes
to what he starts.
I guess he gets a big kick out of it :-)
Word of Advice:
If the thread is started by Egg Troll...ignore it, skip it or
delete it!
--
Perl is designed to give you several ways to do anything, so
consider picking the most readable one.
-- Larry Wall in the perl man page