Justtechjobs.com Find a programming school near you






Online Campus Both


php3-list | 2000051

Re: [PHP3] PERL QUESTION:alive or dead? From: Alex Turner (musicmaker <email protected>)
Date: 05/08/00

Actualy I said that FCGI was horrible. FCGI or Fast CGI I have taken to be
the mechanism where you wrap the Fast CGI wrapper around a static CGI
programm like a perl script or a C program to make it persistent to the
apache thread. The problem with this is (at least in perl or Java) is
that the size of the Interpreter/Run Time Engine/VM and quality of garbage
collection etc... means that each apache thread+language ends up
swallowing your machine unless you are quite carefull. And in C all to
oft people take a program that was designed to exit, and make it an FCGI
and behold.. memory leaks spring forth! CGI or Common Gateway Interface
is just a protocol by which the server talks to an application, but in the
case of php it's buffered if you will by the application engine, and in
the case of php quite nicely so you rarely have the same problems that you
do with writing normal CGI in terms of speed (although C CGIs are pretty
nippy), and the issues you get with Fast CGIs.

What I really meant was all things have their place, and everything in it.
Use the best tool for the job. There are occasions when a simple static
CGI is all you need, however there are times, and these are perhaps the
most prevalent of times that you need something a bit better, which is
where php comes in.

The ease of a CGI makes it attractive, but the speed doesnt, therefore
things like PHP, and ASP, ColdFusion attempt to bridge the gap by
providing a mechanism between the web server and the CGI that is
persistent and doesnt eat your machine for breakfast, (although ColdFusion
will try realy hard on a bad day). The problem with this is that it's
another layer that can go wrong... and too many layers, like too many
cooks, can often spoil the broth (as we discovered with ColdFusion). This
is one reason I have picked PHP. If it goes wrong, get what, I can take
out my spanner, and find out where it went wrong and fix it. Thank
goodness for free software!

Although TBH, I havent seen it actualy go wrong yet, which is one up on
the other application engines I've mentioned, and also therefore why I'm
going to take a bet on it and hope it pays off.

When it comes to writing powerfull applications in Perl... There are too
many people who beleive you can write a powerfull application without the
-w directive, and 'use strict'. The number of scripts I have seen that
are powerfull applications but are also a nasty mess of putrid scum
sucking code is remarkable. The one bigest reason I actualy like Java is
because it _forces_ OO on you, and you do at least have some modicome of
thought towards data encapsulation. It seems that you stand a much better
chance of comming out the other side of a Java project with something
coherent that you do with Perl. However like Vidyut said, Java has some
compatibilty issues amongst other things, speed, garbage collection, poor
threading and others.

anyhow... just my $0.02

So far, I am impressed with PHPs speed, and stability, and ease of use.
It seems like it was written by people who actualy care about how well it
works, unlike most commercial app engines. Like I already said, thank
goodness for free software!

Alex T.

On Mon, 8 May 2000, Vidyut Luther wrote:

> Ok since everyone has said something.. I should too :)
>
> Perl is good, perl is great.. i'd come up with a catchy rhyme.. but i'm
> not talented in that area.. anyway.. I've been doing perl + php for over a
> year now.. to say perl is dead, or should be dead is quite wrong.. perl is
> not a scripting language by itself.. it's just that it's so easy to write
> a powerful application in perl.. people don't realize that they wrote an
> actual program..
>
> People say perl is not Object Oriented.. thats true... but the only
> difference between perl and java in terms of object orientation is that
> Java forces OO on you, even to write a hello world, you need to write a
> class, and a constructor and all the usual OO stuff.. whereas in perl
>
> #!/usr/bin/perl
> print "Hello world\n";
>
> does the trick..
>
>
> Alex said that CGI in general should be dead.. I think he's a little
> confused with the terminology as everyone is :).. Here is a pretty simple
> explanation of what CGI is.. taken from Top 10 Perl myths by Simon Cozens
>
> you can find the url @ :http://www.perl.com/pub/2000/01/10PerlMyths.html
>
>
> "CGI is just a protocol - an agreement that a web server and a program are
> going to talk the same language. You can get Perl to speak that protocol,
> and that's what a lot of people do. You can get C to speak CGI, if you
> must. I've written programs that talk CGI in INTERCAL, but then, I'm like
> that. There's nothing Perl specific about CGI."
>
>
> I think Alex meant that loading an executable or an interpreter everytime
> a script is called should be gone.. which is true.. hence mod_perl.. but
> mod_perl and php are still using cgi :).. just a technicality ..
>
>
> Ok enough about perl.. Lets talk about Java...
>
> Java has a great caching mechanism... I want it in php or perl.. aside
> from that.. bah humbug :).. Java has the potential to be great.. but like
> Alex said.. Sun needs to stop trying get be the ball hog.. and let others
> develop Java too.. the thing with Java is that even though theoretically
> it's platform independant.. you notice some quirks when say
>
> Programmer develops app using IBM's JIT compiler, and IBM's JDK..
> user a is on a windows box, but using MS's excuse for a JVM.. and user b
> is on a solaris box with Sun JDK 1.1..
>
> now because of the different stages of development, and internal quirks of
> the three different JVMs.. bugs and anomalies arise..
>
> with Perl.. except for changing the paths (if you use absolute paths in your
> scripts).. you don't need to do much to port a simple perl program to
> windows or mac or solaris.. perl is perl. you could have an older version
> of perl or newer.. but most of the time the differences aren't as huge as
> the JVMs.. unless of course one box has perl 4, and the program was
> written in perl 5.. might find some quirks there.. :)
>
>
> Also unless you're a good java programmer, if you develop something using
> Microsofts Visual J++.. you lose the platform independance.. :) why do you
> think IE does java so fast ? :)..
>
> On Mon, 8 May 2000, Alex Turner wrote:
>
> >
> > Perl... Java... PHP, C and others...
> >
> > Perl it seems to me is heading the way of java, only worse. The number of
> > modules in perl that we have used from CPAN that had memory leaks is
> > amazing, FCGIs are horrible, and mod_perl is worse still. Only problem is
> > Java is as slow as molasses and eats memory for breakfast, only the good
> > programmers dare to write Apache modules in C, and PHP is an application
> > engine, and many people simply don't like application engines (although
> > I'm not included in that group) given the track record of ColdFusion and
> > ASP. People have to use something, and until the perfect solution comes
> > along (and of course Oracle think that 8i is - although they should know
> > better given the price tag), people will continue to use the one thing
> > that they can rely on... The thing that they know. As the saying goes:
> > better the devil you know than the devil you don't.
> >
> > Although personaly I am better my job on PHP right now, so I'm really
> > hoping it works out!! ;)
> >
> > Alex T.
> >
> > Oh, and btw.. I think that perl should die, it's a lame animal thats
> > really only good for scripting IMHO - which is what is was originaly
> > designed for. If you want threads, use real threads etc...
> >
> > On Sun, 7 May 2000 php3 <email protected> wrote:
> >
> > > Addressed to: Dean James <sacramone <email protected>>
> > > php3 <email protected>
> > >
> > > ** Reply to note from Dean James <sacramone <email protected>> Sat, 06 May 2000 21:07:59 -0700
> > > >
> > > > Is Perl gonna be a program language of the future (and past), or is
> > > > its days numbered??
> > > >
> > >
> > > Perl is not going away any time soon, but its days as the default way to
> > > create dynamic web pages has passed.
> > >
> > > It is still viable because of all the cool non-web things you can do
> > > with it. The web had not even been thought of when Larry Wall started
> > > on Perl, (1986) and I have a feeling that even now there are more
> > > non-web Perl programs out there. (I get to count every little
> > > throw-away script some sys-admin once wrote to save himself some typing,
> > > right? :)
> > >
> > > I don't think Perl is dead yet, but CGI should be! The idea of running
> > > a CGI program for each web request should go the way of the hitching
> > > post. (You know, the place where you tie up your horse when you go to
> > > town.) The only reason (IMHO) for CGI versions of a program is when you
> > > need to run as a specific user. Almost everything can be done by nobody
> > > in a PHP module or a mod_perl program, and it will run MUCH faster than
> > > having to spawn a new process for each CGI program that is run.
> > >
> > > I will spare you my opinion on Perl vs. PHP, but you see which mailing
> > > list I read...
> > >
> > >
> > > > now, at my work, they praise java blah blah blah
> > >
> > > When you consider all the in-fighting in the Java camp, I'd be more
> > > worried about the death of Java than Perl. Seems to me I just read
> > > something about a new disagreement between IBM and Sun on Java, and
> > > Microsoft has been doing everything possible to contaminate or kill it.
> > > As long as Larry Wall, or someone else is interested, Perl will survive.
> > >
> > >
> > >
> > >
> > > Rick Widmer
> > > Internet Marketing Specialists
> > > www.developersdesk.com
> > >
> > > --
> > > PHP 3 Mailing List <http://www.php.net/>
> > > To unsubscribe, send an empty message to php3-unsubscribe <email protected>
> > > To subscribe to the digest, e-mail: php3-digest-subscribe <email protected>
> > > To search the mailing list archive, go to: http://www.php.net/mailsearch.php3
> > > To contact the list administrators, e-mail: php-list-admin <email protected>
> > >
> >
> >
> > --
> > PHP 3 Mailing List <http://www.php.net/>
> > To unsubscribe, send an empty message to php3-unsubscribe <email protected>
> > To subscribe to the digest, e-mail: php3-digest-subscribe <email protected>
> > To search the mailing list archive, go to: http://www.php.net/mailsearch.php3
> > To contact the list administrators, e-mail: php-list-admin <email protected>
> >
>
> 

-- 
PHP 3 Mailing List <http://www.php.net/>
To unsubscribe, send an empty message to php3-unsubscribe <email protected>
To subscribe to the digest, e-mail: php3-digest-subscribe <email protected>
To search the mailing list archive, go to: http://www.php.net/mailsearch.php3
To contact the list administrators, e-mail: php-list-admin <email protected>