Criticisms of CGI I have encountered thus far

[surf]

This is what I have found:

1. PHP is more secure and runs faster.

2. If you write a remarkably clever set of CGI scripts,
clients and people can easily steal the code especialy
during some trial period when they try out the scripts
before buying. That's what somone told me anyway.
This person was advocating ASP.

3. perl doesn't keep persistent database connections open.
I guess mod_perl does, but is there an easy way to do this with
regular perl ?



Any good websites on this topic, please point me to them

Thanks

 

[xhoster]

This is what I have found:

1. PHP is more secure and runs faster.

Both of these would depend on the comparative competence of the php and
Perl programmers and administrators.

2. If you write a remarkably clever set of CGI scripts,
clients and people can easily steal the code especialy
during some trial period when they try out the scripts
before buying.

Don't give them the code, but run it on your own server. Better yet,
don't deal with thieves.

That's what somone told me anyway.
This person was advocating ASP.

3. perl doesn't keep persistent database connections open.

Perl keeps them open until you close them, or they go out of scope,
or perl exits.

I guess mod_perl does, but is there an easy way to do this with
regular perl ?

If mod_perl is not considered easy, then no, there is no easy way to do
this in a CGI-like context.

Xho

 

[J. Gleixner]

This is what I have found:

Why are you asking about CGI here? CGI's can be written in perl, C,
Java, Fortran, or almost any language.

1. PHP is more secure and runs faster.

2. If you write a remarkably clever set of CGI scripts,
clients and people can easily steal the code especialy
during some trial period when they try out the scripts
before buying. That's what somone told me anyway.
This person was advocating ASP.

Doesn't have to be even remotely clever.

3. perl doesn't keep persistent database connections open.
I guess mod_perl does, but is there an easy way to do this with
regular perl ?

Nothing to do with perl, it's up to the system to support those things.
Apache with mod_perl, or PHP, or ASP, or other systems may/may not
support it, it's not intrinsic to the programming language.

Any good websites on this topic, please point me to them

There are a lot. Use Google and educate yourself and when you have a
question about perl, feel free to ask.

 

[Juha Laiho]

1. PHP is more secure and runs faster.

- security: depends more on code than on language; however, past
versions of PHP have made it pretty easy to pollute the application
namespace, thus making a good variety of attacks possible; on Perl
side, there's the sad legacy of Matt's scripts
- speed: more on mode of execution than language; PHP is more often
embedded in the web server, whereas perl is more regularly offered
only via CGI mode of execution (no persistence for the scripts,
each request run in a separate external process)

3. perl doesn't keep persistent database connections open.
I guess mod_perl does, but is there an easy way to do this with
regular perl ?

Again, mode of execution is the key here. It's hard to persist anything,
if the mode of execution is that the server process finishes after
each request. Running regular perl applications under mod_fastcgi could
be an option.

But as said already, this discussion is not on topic in this newsgroups.
Check the comp.infosystems hierarchy, you might find something more
suitable in there.

 

[Tintin]

This is what I have found:

1. PHP is more secure and runs faster.

You can write insecure code in any language. Do a search on PHP
vulnerabilities/exploits and you'll find plenty of references.

2. If you write a remarkably clever set of CGI scripts,
clients and people can easily steal the code especialy
during some trial period when they try out the scripts
before buying. That's what somone told me anyway.
This person was advocating ASP.

Meaningless statement. ASP's can be written in VB or Perl or a variety of
other languages.

 

[Dr.Ruud]

Jamie schreef:

PHP is fine for smaller things though.

Especially when written well:
http://shootout.alioth.debian.org/debian/benchmark.php?test=pidigits

PHP 28x (slower than D), Perl 173x.
(see also my Perl #3 that is 83x, mainly by less call-overhead)


Perl/PHP shootout:
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=perl&lang2=php