develooper Front page | perl.advocacy | Postings from October 2001

Re: php vs perl again (reposted - original post was incomplete)

Thread Previous | Thread Next
Jim Smith
October 25, 2001 18:54
Re: php vs perl again (reposted - original post was incomplete)
Message ID:
On Wed, Oct 24, 2001 at 04:56:19PM -0500, Scott T. Hildreth wrote:
> Well I'm not a web developer, never used mod_perl, there is 
> the article on describing how they built e-toys with 
> mod_perl.  I think at the time it was the 3rd busiest web site
> at the time.  I don't know if the hardware even compares, but 
> you can take a look, if you haven't already.  

Just to throw some fuel on the fire >:)  I recently started working on a
paper and developed the following little tidbit based on my experience
using PHP and Perl, among other languages.  It's painfully evident which
ones I don't have a fair amount of experience with, but would anyone like
to add to the data? :)

I personally don't think speed of execution is everything.

Comparison of languages:

Description              C  C++  Perl  Python  Tcl  Shell  PHP  Lisp Forth

Namespace management     N   Y    Y                   N     N          Y
File-scope globals       Y   Y    Y                   Y     N          Y
Regular expressions      N   N    Y                   Y(1)  Y          N

OOP support              N   Y    Y      Y            N     N(2)       N
Run time code mutability Y   Y    Y                   Y(3)  Y     Y    Y
Extensive lib collection N   N    Y                   N     Y(4)

Closures                 N   N    Y             N     N     N     Y    N
anonymous subroutines    N   N    Y             N     N     N     Y    N
automatic code creation  N   Y    Y             N     N     N     N    Y

memory management        N   N    Y      Y      Y     Y     Y     Y    N
string support           N   N    Y      Y      Y     Y     Y          N
run as machine code      Y   Y    N      N      N     N     N     N    Y

 (1) Limited to argument completion and switch statements.
 (2) PHP support for objects is not much different than C++ support for
 (3) With heavy wizardry.
 (4) Not quite extensive, but it's getting there - PEAR is only a year or
     so old.

What do we mean by the descriptions?

Namespace management:
  This means we can have our own set of symbols without colliding with
  identifiers from other libraries, files, or programs.  This is denoted by
  the `namespace' keyword in C++ and the `package' keyword in Perl.

File-scope globals:
  Globals that are not visible outside the current file.  This is supported
  by the `static' keyword in C/C++ and the `my' keyword in Perl.  This
  might also be the default state of variables in Shell, with variables
  visible outside of files requiring `export'.

OOP support:
  This requires the following items:
      Namespace for the object methods/definitions
      Operator overloading
      Inheritance, preferably multiple-inheritance
      Polymorphism - same method name but appropriate function

Run time code mutability:
  The running program should be able to modify and/or add to itself.

Extensive lib collection:
  This requires a central repository from which code may be downloaded or
  otherwise obtained.  Examples: CPAN, CTAN.  If Freshmeat were exlusively
  C/C++ and was authoritative, it would be considered for C/C++.  All the
  Unix utilities didn't count as an extensive lib collection for shell.

  These are subroutines that capture the current lexical environment in
  which they are defined, even though they may be used outside that

Anonymous subroutines:
  These are subroutines with no names.

Automatic code creation:
  This implies the compiler/interpreter (as appropriate) can create code as
  needed.  C++ satisfies this with templates.  Perl with AUTOLOADs.

Memory management:
  Allocation/deallocation of memory is automatic.  The programmer doesn't
  need to worry about this.

String support:
  Are strings a fundamental data type.

Run as machine code:
  Does anything actually get interpreted at run time or is it pure
  machine?  Forth qualifies because in the traditional implementation, the
  interpreter is just a `jump engine' that follows pointers to the actual
  machine code that does stuff.  No `figuring out' is done at run time.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About