Slashdot Mirror
Perl Domination in CGI Programming?
at0m asks: "Perl seems to be the language that most people use for CGI programming. But is there a good reason for it? Sure, it's easier to use Perl than a lower level language, but programs would be more efficient if C/C++ were used. Programmers don't sacrifice this efficiency when programming applications, so why is it the standard to use a higher level language for CGI, when one wouldn't use one for other programs? I've been using Perl for all my CGI projects, but for my next one I'm contemplating using C++ to make it more efficient. did I make the correct assumption?" Most CGI apps prefer development speed over the complexity inherent in C/C++, which is why Perl and other scripting languages are used. Your thoughts?
i'll get him to upgrade all his mission critical systems to Win2K advanced server release candidate 2, and run my apps on IIS5.
BZZZZT!
Hooray I'm an idiot Anyway, I'm an idiot, and I thought I should tell you all I'm an idiot
What the hell are you talking about? IIS is faster than Apache, can do more things. Scales a lot better and has nicer features(transactions, components, sessions etc). Go find me one major website that uses apache.
Who cares? Who still programs in CGI? I'm a profressional web developer, and I haven't used CGI in years. CGI is slow, old, outdated, and lacking a lot of features. ASP, Cold Fusion, or related products are the up to date versions of server-side processing. What language is used for CGI is a moot point. The questions should be, who still programs CGI?
There is a perl compiler. Read chapter 6 of programming perl or lookup the O module.
lot of people complaining about perl and try to use c++ as a slimmer solution, should look at www.boutell.com/cgic this was a very good, intelligent solution when it came out, and I have been using it for years now with no problems. Sometimes the things other people already thought of do not need re-creation. We dont need someone to write an entire new program to interface to shell scripts. If you want shell scripts to work fast, use shell scripts. You can use perl to write stuff, but then translate it back to shell scripts after. Or write it in Cgic, or C. We are (speaking philosophically, as usual) constantly looking for an easier way to do something and often end up going around the mountain to get next door. If you travel far enough in a striaght line eventually you will return to where you started, but sometimes, just taking one step sideways or backward can save an entire trip around the world.
i like to use visual basic. its so much better than pearl. with IIS4.0 it works a treat!
Specifically, perl is compiled to a bytecode like java at run time, or beforehand with mod_perl, perlexe, Velocigen, or perhaps a few other tools.
Well, you can call it interpreted if you want but if you do then so is java.
- true object orientation
- very good multi threading
The biggest advantage of Perl would be the huge number of available modules for just about any conceivable task. These days I'm not so sure, it looks like Java has come a long way in terms of available modules.If I had had to learn C, I would not be producing useful work yet. Given the shortage/expense of C programmers, our clients simply would not have these sites were it not for the existence of scripting languages.
use C/C++ for my cgi. A while back, I decided to try it...it made the server very happy indeed. It took a while to make a "standard" parsing routine that worked well in c/c++. I also wrote a few parsing routines. Now I can make a very tiny cgi app that runs 10 times faster then the perl equiv, and does not use 500K-1Meg of space to load a perl interpreter.
where did you see that perl is the language that most people use for CGI??? You'd better look around and see how much C,C++, ASP or Java are used for CGI or servlets... The only reason why there are still people using perl scripts, is that it's easy to find already written perl scripts for specific tasks in the unix world (file upload handling, guestbooks...) and that they can be checked quiet easily by ISP.
I do believe this has to be one of the most ignorant things I've ever seen on slashdot. I can't even begin to respond.
Shocking. . .
...do what I did, steal the best ideas from perl and make C libraries to implement them. Now I can write fast C-based CGIs as easily as in Perl:
/*get formvar*/
...
char * filesys = NULL;
char **hesPtr;
list * fsList;
char * fsType;
cgiToStr(&filesys, "filesys");
hesPtr = hes_resolve(filesys, "filsys");
fsList = split(*hesPtr, " ", "", 0);
fsType = listShiftData(fsList);
The survey conducted by esoft is based on the popularity of each apache modules compared to one another. To use PHP, one has to compile as an apache module or as independent CGI. The former is much more polular i think. But mod_perl is not needed in order to use a perl cgi. You just need it to avoid some overhead.
Just because PHP is more popular than mod_perl among apache modules does not mean PHP is more popular than Perl.
1) check errno, 2) interfacing to the cgi "variables" is trivial in C, 3) printf("error, please contact the webmaster
);
wtf?
Has anybody tried OmniMark instead of Perl? It supposedly has killer text processing and builtin XML handling.
I was wondering about the memory requirements for this stuff. So you can have just one process running perl and that process will handle all the requests? That would be awesome. Or would you need 10,000 copies of perl in RAM if you had 10,000 simultaneous requests?
Have you ever actually used PHP? PHP has a lot of advantages over perl, and I'd love to know why you feel perl is more sophisticated... PHP was designed for web programming. Perl was designed to be a general purpose scripting language. I can do stuff faster in PHP, the syntax is much like C which I am familiar with. PHP has lots of web specific functions that make most of the CPAN modules irrelevant. PHP has a clean API so that I can easily add custom C routines to it. PHP even has perl style string handling and regular expression capabilities. Let's see, what else... PHP has automatic resource deallocation so I don't have to worry about my mod_perl variables hanging around from hit to hit. Much much more. And with PHP4, PHP has native session support, and compile and cache design like mod_perl does. I could go on... The big advantage to me is I can look at a chunk of PHP code and tell what it does... So please, share with us why mod_perl is so much more powerful than mod_php???
Less and less important will the speed at which programs run in the future. Processors are getting so fast they can handle more and more. Five years from now will it matter if your code is not as fast as possible? I doubt it.
IMHO PERL has many good points.
1) you can write something that works very quickly
2) when you are asked to make modifications, you can also modify the script quickly
3) its performance is acceptable
Nowadays it's much easier and affordable to buy
a faster machine than to hire a new programmer...
and you must be SO DAMN FAST.
Your management wants everything up'n' running ASAP (and possibly sooner).
And the speed benefits of C/C++ aren't that much. You can use mod_perl and be even faster than C, because the bottleneck is CGI anyway
As far as I can tell, ASP is a Microsoft (boo!) proprietary thing. Go look up how Microsoft is faring against Apache in Market share. ASP, Visual Basic, Active X is a Microsoft dead end. The source is not open, there is only one vendor, they'll let their guys develope to a change in the API, then tell everybody else much later. You can't port a Microsoft program anywhere. Nope, stick with the open standards: apache, cgi, perl, c, c++, linux, unix, bsd, etc.
Java is not a spayed C++.. It's got a cleaner OO approach, it's got a wider range of standard libraries, and it's quicker to develop in. Perl is an abomination for anything but string manipulation and linear, functional scripts. Perl 'OO' programming is a hideous joke played on unsuspecting saps who think they can develop maintainable, clean OO systems in Perl, which is impossible for anything of any complexity. Hell - VB is OK for short scripts, but anything over 3 lines is where you run into trouble.
I also find Perl very hard to read. However, I also find that Tcl/Tk is much better for my needs besides easier to read and write. I do most of my programming in Tcl/Tk including CGI scripts (with cgi.tcl).
I've programmed in Pascal, C/C++ and x86 assembly but doing text manipulation with those languages is like moving a sack of rice grain by grain. Perl, is a payloader/dump truck combo.
Take a look out at apache.org and read about mod_perl. Also, I get better database connection/query time using DBD's than I do using something like Rougewav.
PHP 4.0 already supports AOLserver, thus you can run the multithreaded AOLserver with embedded PHP module. The advantages of AOLserver and PHP combined make for an extremly attractive package.
This is why you should use languages in which both compilation and RAD are possible simultaneously: Lisp. Or to some extent: Smalltalk.
Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
I thought that the original quote was "Those who do not understand Lisp and condemned to reinvent it poorly"...
PHP may be more widespread than mod_perl, but it's certainly not more widespread than Perl running as CGI. It's the defacto standard on any platform. mod_perl rocks... our site does 40M hits per month and 60 DBI hits per second all day long every day... 0 downtime. Nice. phil.
As regards very high level languages and speed, there is no reason why a high level language has to be interpreted, except that most high level language implementors are too lazy or more likely don't have the resources to make a proper compiler. As someone already noted, Common Lisp manages to provide a very high level language which in almost all implementations is interactive AND compiled to efficient native code. I also understand there are good interactive ML compilers out there.
I have to agree. Web-programming is mostly trivial excercise. I too would probably program something else if I was any good in programming. Perl/Servlets/SQL/http - anybody can do those.
Give us good objects! Perl OOP is ultraclunky, and trying to use it you can just that it was kind of tacked onto the side of Perl. It's a like a nightmarish version of what C++ is to C. I realize that part of what makes Perl so attractive is that you can just slam code together, not really worry about specs or .. functions, variables - anything - but as web apps get really complex (as they are starting to now) people are going to want a little better organization. If you've been in a CS program in the last, oh, say, 20 years, you'll know that procedural programming ain't where it's at.
Kill that idiot mantra "TMTOWTDI". Larry Wall's lingual fascination really shines through in Perl. Like English, there are (too) many different ways to say whatever you want. There are (too) many different ways to say whatever you want, like English. To say whatever you want, like English, there are (too) many ways. Get the point? This comes much to the dismay of anyone who has ever tried to understand a Perl program they didn't write. Being able to write a control statement any one of fifteen different ways isn't necessarily a virtue. It's a pain in the ass to comprehend, and it's a problem that endemic to an industry like web design where four different designers will give you four redesigns in two years.
Aw, man . . . And I thought that my skills were something to be proud of. You mean picking up _Learning Perl_ and producing a CGI script a few days later doesn't make me a guru? Damn.
-same source code for Unix and what's the other OS?
-talking 'bout the OS, it's written in C !!!
-hugely adaptable, yep, got that too
-outstanding string and text stream manipulation, got that
-documented - got that
-lot's of developers.
-it's easy and fast to write code in 'C'.
Welp, looks like C is tied with Perl on those criteria.
It's not that Perl sucks, it's that people use Perl for things they have no business using it for. I've been guilty of it myself, I admit. For parsing a logfile it _is_ the best choice. For a complex user management system it is not. For instance - which is better? Code something in Python, a superior language in every way for anything other than simple text processing, but which no one around my job knows or uses? Or Perl which sucks tremendously for any largish system in terms of maintainability? It's a tough call. It's the same thing with Visual Basic - it's really OK for some stuff. But do anything complex with it and you're shooting yourself in the foot later down the line if you have to maintain it. The way I decide whether to use Perl is whether I decide to use OO. If I use OO principals Perl is pretty much out. If not, Perl is fine.
Its all about flexibilty
Dynamic error handling/processing in C? I don't think so.
Well developed/tested CGI.pm in C? I don't think so.
use CGI::Carp qw(fatalsToBrowser) in C? I don't think so.
there are more...time is just short...
but this is still java level performance - it just doesnt touch compiled code
You need mod_php to run PHP, you don't need mod_perl to do perl. PHP runs as a CGI just like perl... Unlike perl though, it was designed from teh ground up to seamlessly build as an apache module as well as a cgi (and with php4, as an NSAPI module, ISAPI modules, etc etc). A lot of large ISP's run the cgi for security reasons, but most people with their own machine choose to run mod_php for performance reasons. I don't know why the perl folks don't do this, seems like there's a lot more perl cgi than perl php out there. But PHP has the advantage of being the exact same thing whether it's a cgi or module, unlike Perl where you have to worry about additional things with mod_perl (i.e. php has much better automatic resource deallocation). And PHP supports perl style regular expressions for those who use perl because of the string handling capabilities :)
I write HTML, SQL, OpenGl, GTK, etc... always using C. What's the point of learning a weaker scripting language as Perl when you know C?
Dude, you don't ever talk back to Randal Schwartz. Do it again and I'll issue a fatwa against you.
Ayatollah of slashdot, signing off.
If compiling a kernel is the only C code you've compiled, I can see where your comming from. But C code, particularly small apps, is near instintanious. And yes the compiler would have to be on the system, but so does the interpreters for higher level languages.
What's Jakarta? I thought Oracle 8i gave you everything you'd need. Why should I add Jakarta on top?
Any professional C programmer worth their salt would be able to write (if thay dont already have) the string processing routines in less than an hour. As well as with the vector processing and hash tables, that as well should be almost a no-brainer. Their is even built in functionality in the C++ STL for those things, if you dont have your own routines. All of my routines for these are ANSI C++ compliant, completely portable, not a "third party non-standard library". And as for perl for DB's, I think a lot of people on here that are heralding perl as the solution for DB's arent aware of high performance databases, where overhead simply isnt acceptable.
C++ is type-safe & completely extendable. I could take the std::string & add my own functions to it. Being "typeless" is not necessarily what you want all the time. For instance, I wouldn't use PERL strictly in an eCommerce site. Though if I was doing a guestbook then I'd use PERL. Of course I've seen PERL used to process data faster than SQL :). Basically BCP'd it out...wrote a three-line PERL script to change the data, and bcp'd it back in. Took like 30 minutes total versus hours. Like most ppl would (should) say... use the right tool for the job.
So many people think a language is not object oriented simply because it does not cram object orientation down your throat. I was considering converting to python for a while, but I realized that it was actually easier to do everything that python does in perl (with fewer lines of code).
The thing that really convinced me to stick with perl was when i went to hear Guido speak at a python user group. I asked him if there were any plans to add extensible syntax to python (so i could implement my own switch statement since he doesn't seem to like switch statements). His answer was that he didn't want to add extensible syntax to python because it would be too hard and it would encourage people to write bad code.
I like perl because Larry & Co. don't seem to have many preconceptions of the Right Way to Code (maybe they do, but they don't force it on you). Show me any other language that was designed from the beginning simply to be useful rather than to prove something about how you should think. I don't like people telling me how I should think and behave. I'm open to suggestions, but in the end the choice should be mine. Perl gives me this choice, so I'll stick with it for now.
Okay, if I was a good programmer, I wouldn't be working on web sites (which probably explains the huge number of security holes in CGI), so if I can use something as easy as Perl, I will. Its just the path of least resistance and so much easier to debug.
Perl has better support for regular expressions, parsing, and string manipulation than any other language or tool in existance. This becomes extrememly important when converting data on the fly, from text files, other formats (such as XML), from databases, or from any other thing you can think of.
Hah! You haven't tried Omnimark. Omnimark has much more powerful regex capabilities than Perl. If you know anything about mark-up Omnimark is perfect for the job. And, the best thing--Omnimark is free and runs on Linux, Windows, and UNIX!
Hooray I'm first Anyway, not being into programming CGI I was unaware that you could do CGI in c++, and I thought CGI was supposed to be a script anyway, which is why you would use a scripting language like Perl
Did I understand you right when you said that C++ has more overhead than perl? just wondering. You might want to do your homework just a little bit more.
Take a look at the Popular Perl Complaints and Myths doc compiled by Adam Pisoni and docs to get you started with mod_perl at perl.apache.org
Far from it. I'm amazed (more like quiet
admiration) people can actually write
programs with it.
I suppose it gets easier after a while, but
why spend the time?
You'd think so. After all, we all know that compiled code is (almost always) more efficient than interpreted code. But, there's also another factor. I call it the "give someone enough rope, and they'll hang themselves" factor.
I've seen some incredibly elegant C++ code, and I've also seen the most obfuscated, convoluted garbage possible. Now, it's certainly possible to write obfuscated code in Perl as well, but C++ actually invites programmers to add unnecessary complexity. It takes discipline to avoid this.
Perl permits rapid prototyping of relatively simple tasks (but, would you write a compiler in it?) that are relevant to Web-centric applications. Thus, it serves a niche, and does so well. Such applications can then be recoded in a compiled language for a performance gain.
C++, OTOH, does not natively support things like regular expressions, strings, and pattern matching. There's more "work" to be done to code a Web-centric application in C++, even if a suitable library might minimize such efforts. With more work, comes an increased likelihood of making mistakes. While an experienced programmer might be up to the challenge, and deliver code with a performance advantage, such programmers are rare. The built-in support for such facilities means that Perl allows more to produce functional code than might otherwise be possible.
So, do you want fewer, more efficient Web apps, or more, less efficient ones?
The funny thing is, that when most people produce "acceptably" efficient code that's "good enough", there's less of a need to produce more efficient code - the market will accept the sloppy stuff. This serves as a market disincentive to use C++.
In Liberty,
Rene S. Hollan (posting anon.)
2. You don't "write CGI". It's a set of protocols. It's already been written.
3. It's obvious you haven't spent 10 minutes with Perl.
In most web applications, there are not enough hits to the site in order to merit the increased development time of C++...the speed of perl scripting is actually very good...plus there are tons of modules that people have written to speed development further...
Just because it's not expensive or difficult to use doesn't make it valueless. Unless of course you're into empire building and then of course you'll need to create a budget item by consuming more and more resources.
I would have to dissent on the large project argument... where I work we use just under a million lines of perl to run everything... we have some C, but if something breaks it just takes too long to fix, and too long for new features. Perl scales pretty nicely, and newer verisons of Perl are getting better and better at all it's weaknesses. What do you gain from C? speed. In todays age of barely sub-gigahertz processing I'd rather trade a little speed on a perl program for insane maintenance time/budget in huge projects in C
Riddle: Why can't Perl 5.005_62 run under PalmOS yet it's already available for the Psion Series 5?
Well, hold on here. I hate VB, too. But for a small application, what in the world are you doing compiling it to a standalone executable?
The proper Microsoft web solution for smallish apps is ASP, or server-compiled VB embedded in the web page (much like PHP).
I still don't like that solution very much, mainly because VB is still an ugly language. But let's at least be accurate, here.
For larger apps, VB executables (or, more likely, ISAPI applications) make more sense. But they're typically 300K+ (still bloated, but what do you expect?)
Anyways, just wanted to set the record straight.
I was wondering if anyone could comment on what advantages perl has over java servlets?
I refuse to use Perl for even moderate-use CGI - too much overhead, in my opinion. I even avoid use of ksh (formerly csh) scripts for CGI unless under duress. All my CGI's are written in C, no questions asked. In my opinion, it's just faster.
Bono Vox, bono@vox.org
well, there is a C bytecode interpreter that is interactive and runs CGI C shell scripts. it is called EiC (www.anarchos.com/eic).
Unless you and all of your website visitors have T3 internet connections, the difference between perl and C/C++ will be almost nothing compared to the delay caused by the connection from the client to server. So the execution speed doesn't make a bit of difference. If you are concerned about server load, programming CGI scripts in C or C++ is still the wrong way to go. You will need some system such as mod_perl, Fast_CGI, NSAPI, ISAPI or some other non-CGI solution. CGI is the problem, not perl.
I prefer speed of development. I don't need all the complicated things in C++, although when I do, I use C++. It just depends on your needs.
wow, i think i actually got first post, not that I care. Anyhow, I agree.
probably one big reason that they don't write many CGIs in C/C++ is that it's too powerful. Admins want users to have the ability to write CGI, but they don't want them to have the kind of control over the system that C/C++ can provide.
What would be nice is a C/C++ compiler than compiles things to a byte code and runs it on a VM, similar to the way java works. Then it seems like it might be easier to control what the script does.
Has anybody retargeted a C compiler (such as gcc) to a virtual machine (such as the Java VM, possibly with a customizeable sandbox)
--Stevecomments@vrml3d.com
What I've wished for for a long time is a compiled perl. As far as I understand, the perl interpruter compiles the code then executes it each times, and this is where the inefficiency occurs. I know perl is a scripting language to maintain with portability, but why could there not also be a compiled version? Having scripts still distributed in script format, then compiled on the target system or just interupruted. The best of both worlds. Or even a byte-code level compilation would be an improvement. Anyhow, that's just my dream for the future of perl.
Would you mind clarifying this statement?
Code from bad programmers is hard to read - whether that's Perl, Python or C code.
I disagree. Things like the implied $_ can make for messes.
A language like Pascal, for example, is much harder to abuse at the "micro level" than perl is. Why else doesn't Pascal have "compaction" contests?
(BTW, I am NOT a Pascal fan.)
if you have already chosen the CGI-mechanism, that is, to start another process to serve an HTTP request instead of handling it in an already running server process, you have already lost a lot of performance. writing it in C or C++ instead will shave off some overhead, but it still is an inefficient mechanism. if you are going to write it in C anyway it is not all that much harder to create a server module than it is to create a CGI program. in fact I would say it makes a lot of things easier. (of course, there are things like fastcgi where the CGI script does not terminate between requests but I can't say that I know a lot of people who use it.) also, I think people choose Perl and CGI because it is less challenging. there is lots and lots of code that can be so...er...borrowed out there.
if you have already chosen the CGI-mechanism, that
is, to start another process to serve an HTTP
request instead of handling it in an already
running server process, you have already lost
a lot of performance. writing it in C or C++
instead will shave off some overhead, but it still
is an inefficient mechanism.
if you are going to write it in C anyway it is
not all that much harder to create a server module
than it is to create a CGI program. in fact I
would say it makes a lot of things easier.
(of course, there are things like fastcgi where
the CGI script does not terminate between requests but I can't say that I know a lot of people who use it.)
also, I think people choose Perl and CGI because it is less challenging. there is lots and lots of code that can be so...er...borrowed out there.
If you can help educate the guy, do it. If not, why parade your arrogance?
I like PHP partly *because* it offers Perl Compatible Regular Expressions! Just buy the Llama book and work through the examples, you won't regret it...
http://www.rebol.com is the site. REBOL is a nicer language to pick up than Perl. It is also interpreted like Perl but it feels a bit more lightweight. One possible minus for using REBOL is that it is relatively new so nice-to-use libraries might be scarce (http://www.rebol.org has archive of user maintained scripts).
There's no reason why one shouldn't use languages such as Python/TCL though.
REBOL is a rather cool net-centric scripting language designed to replace PERL/C++. It will be bundled with RedHat 6.1
Java on the client side and Java on the server side are two different animals. Use your brain before typing next time cock goblin.
C++ string class is flexible and easier than C. Perl may be a bit more easier than C++ in terms of string manipulation but I prefer shell scripting style rather than Perl...it just look too much like Basic. Perl string manipulation is fast...
I think what you mean to say is that Perl was designed in such a way that it is easy to write code that is difficult to read. A good coder will write code that flows and is easy to read. A bad coder will write stuff that looks like a train wreck in any language. But yeah... it's a little easier in Perl.
Heck I can write crap in C too...
**(int *)g(x, *struct z) ? q(s) : r(**(char *)e)
The bottom line in most cases is the coder not the language when it comes to readable code.
Has anyone picked up development of Grail, that browser project written completely in python ?
It was surprisingly fast, as far as I recall - and it had a "PVM" (not really - the whole thing was python interpreted, but the applets were thoroughly sandboxed)i.e. python applets!
I'd rather write in Python than Java any day...
Now if there was a Python Netscape plugin...
Also - there is a Tcl/Tk Netscape plugin. I don't know whether I'd rather write my applets in Tcl/Tk, but some people would...
with C/C++ you run the risk of bringing down your whole web service (unless you have lots of time to spend testing, or are a particularly gifted c hacker). Safe interpreted languages are much better for the kind of rapid application development/deployment that is typical of web services. If you're *that* concerned about performance I'd encourage you to investigate alternatives to CGI, pooled database connections etc.
I think you are confusing applets (which run on the browser) and servlets (which run on the server). Servlets generate HTML and the resulting output can be read by any browser that renders HTML. Whether or not you have Java enabled on the browser doesn't make any difference.
Of course there are server security issues also, but that's an other issue.
The rapid scripting ease of Perl, tight C++ integration bits that need compiled speed, Object oriented so ltos of code reuse. readable code (unlike Perl).
Check it out!
While Perl may be the most popular, the company that I work prefers code to be written in Python. Python is so much easier to read that Perl that when a new guy is brought on board, he doesn't have to try to decipher all that Reg X :) Python's CGI module is as good as, if not better than Perl's (IMHO)
Perl was designed with the purpose of processing text at lightning speed; therefore, this is the one thing where perl can signifigantly outperform C. Take a palindrome program for instance. This is a one-liner that every perl programmer knows; however, rewrite it in C as efficiently as possible, and it's a 30 liner at least. Run the two, and the perl version will run faster; therefore, you may not gain much at all by rewriting your CGI in C.
The biggest advantage of perl (at least why I use it) is that it is interpreted (ok, it's alot more fun and easier to do string manipulation too :). Most places I've been hosted allow you to upload compatible C/C++ binaries but I'd rather not deal with keeping around a system just like my ISP's just to make binaries. With perl as long as you've got the path to perl right you're ok.
I think because PHP ships as a module, and Perl as an executable, that's the difference. You need mod_php to run PHP, you don't need mod_perl to do perl.
So, the use of the module doesn't really say much about the actual use of languages.
Cheers,
Sandy
sandy@rpg.net
http://www.rpg.net (The Inside Scoop on Gaming!)
i just switched hosting services, from NT to (thank god... or, more appropriately, my boss) redhat, and switching the cgi's over was a snap... changed the directories that things pointed to, changed the perl path, and i was done! if i wrote them in C, i would've had to muck around in the code, make sure nothing was platform dependent, recompile, and spend the next 2 weeks killing bugs...
If you're processing a lot of data, definitely use 'C'. Well written, optimized, compiled 'C' beats the crap out of anything else ('cept *maybe* asm). If you've got to zip through ten megs of vector data to create a custom gif/jpeg/png, then 'C' is the answer. If you're writing a random quote program, use Perl.
Look, perl is for people that can't handle 'C'. It's just a scripting language: csh + some of the stuff in 'C'. Object orientationists, minimalists, Visual Basicers, novell/microsoft sysadmins etc. have been writing 'C' obituaries for 20 years. It's not going to die and is the *BEST* tool for writing programs. PERIOD. Linux is written in 'C'. Apache is written in 'C'. Gnome is written in 'C'. What more do you need?
Most of the preceeding arguments can be summed up like this: PERL is cool cuz it gots easy string handling.
Look, if you get confused by C's string handling, then, yep, Perl is for you. But *IF* you can handle the power, 'C' is for you!
Writing compiled VB COM components and accessing them from IIS on NT is a much more powerful solution; tests have proven superior scaleability as well.
What's really great about Vignette's (www.vignette.com) implementation of Tcl is that it utilizes caching of rendered pages. That is to say, once you have built the html from you database queries (Sql calls to any major database vendor), the page can be cached on the web server's doc root so that subsequent requests for the same page don't need to hit the back end or even the Tcl interpreter. It's the solution that some of the most trafficked sites on the web use: zdnet, cnet, playboystore.com, landsend.com, time.com, fortune.com, compaq.com, etc. etc. The strength here is caching and a rapid application development environment. Not to say Perl can't also do these things, but as a commercial product, StoryServer is a pretty powerful web development platform. sjohnson|at|smart.net
I would have to say that ever language has it's own advantages.. CGI/Perl - Everyone has it and it's very affordable to do something in a short period of time. Portablility is great, nearly every ISP that a client will host with can handle the perl CGI provided the machine has the power. CGI/C-C++ - Works great if you can code C/C++. What's not so great about this is that your binaries will need to be compiled per machine when switching from development because you never know what type of server your site will end up on. ASP - Quick, easy, supports COM/DCOM/ActiveX. Great programming tools when you want powerful results with little development time. I've taken some large projects and turned them into nothing when using ASP with COM/MTS to intergrate with existing desktop apps. JSP/Applets - The future of web development! This approach to programming is great. It comes from a OOP language and can do everything that is needed. The power of strings here are AWESOME. Everything you'd want is here. Lets not forget the JDBC which is becoming the defacto standard for databases. Only draw back is that Application Servers for mods to web servers are still more or less in development or cost money. Each approach has it's own advantages, but if you can't I start working with JSP/Servlets because of the power that exist with them. Justen Stepka Developer Web Programmers, Inc.
Thousands of lines of code in Perl? You're making a mistake. You may not believe me now, but you're making a mistake unless maybe it's 90% text processing code. Python is a much better choice for code of any real complexity. So is Java.
Perl _is_ compiled.
Actually, perl itself is a demi-compiler, but Perl is compiled.
Why did you even bother posting such an asinine topic on Slashdot? Come on.
Faster then C++. Hmm .. bytecode is faster then true interpretation but can't even come close to compiled code. Look at Java ...
Perl is ugly and just like you said, is fine for creating some sort of script but betting large application on Perl is recipe for disaster.
I agree with you 100 percent my brother.
You have to remember that a programming language is just a tool. It aids oneself when implementing a solution to a problem. Different problems can be solved in different ways. So different programming languages are geared towards solving different types of problems.
Python is a good language for medium to large cgi scripting. Perl is great for a small scripts. However, once you write up a large app in python it is a bit tough going back.
Well, you asked a few questions, so this is really the simple answers.
Perl seems to be the language that most people use for CGI programming. But is there a good reason for it?
CGI scripts mostly just perform text manipulation, since Perl is so good at text manipulation it is an obvious choice. The second big advantage for Perl is CPAN... there are Perl interfacces to everything on there. So even if your CGI script has to do more than text processing, chances are, that code is already written for you and all you really need is the code to glue it together.
Sure, it's easier to use Perl than a lower level language, but programs would be more efficient if C/C++ were used.
The simple answer is due to one thing, network lag. When executing a CGI script, execution time is orders of magnitude faster than the network can pump the data out at. So the network is the bottleneck.
As network speeds increase, you might reach the point where execution speed was the bottleneck, however until then you should use whatever tool is best for the job. Since CGI scripts do a lot of text processing, Perl is a natural choice.
Programmers don't sacrifice this efficiency when programming applications, so why is it the standard to use a higher level language for CGI, when one wouldn't use one for other programs?
The bottleneck with a local application is execution speed, so to speed it up, you make it more efficient. That aside, some applications are written in interpreted languages. As computers continue to get faster, this will become less and less of an issue.
I've been using Perl for all my CGI projects, but for my next one I'm contemplating using C++ to make it more efficient. did I make the correct assumption?
In a word, NO. You will not see increased speed, which as I understand was the sole reason you wanted to try C++.
Perl is the better tool for CGI programming over C/C++. Perl is _the_ choice tool for text manipulation - manipulating text with C is like trying to shuffle cards while wearing boxing gloves. Perl is interpreted and therefore doesn't need compilation (faster turn around time and ease of debugging and program life cycle maintenance). Perl is a simpler language with less chance of making syntax/logic/memory errors. Finally, the bottleneck in CGI programming is the CGI gateway itself. If you're getting slowdowns, switching to C/C++ will not improve the situation because new processes are spawned for each simultaneous execution. You can get around this problem by using mod_perl, or upgrading your hardware/bandwidth ;-) You can also switch to java servlets. Having said all the above, C/C++ is the choice tool for building regular (non-cgi) applications.
Your argument may be true for the special
case of a T1-connected PC running a simple
web site, but as the bandwidth increases and
the web site gets more sophisticated, you will
find that indeed perl does slow you down.
We run a server farm of about 75 production
boxes, and we regularly exceed 50Mbit of
traffic (more than a T3). The web site is
somewhat complex, with over 100,000 lines of
perl code behind it, and every page view is
served under mod_perl. At the busiest times,
the load average on the boxes exceeds 15,
but there is certainly still plenty of
headroom available on each box's network
card.
Basically, it all depends on your setup. For
us, the combination of perl, mod_perl, and
Apache has been fabulous. But if you need
a little extra performance, writing your own
Apache modules in C may be the only way to go.
um, maybe you should read a bit about Servlets before posting...
Servlets are serverside only, you have no control over what the server is using to build the page your are seeing.
henri
wow,
when i wrote the response no one else had posted anything, by the time i hit submit you got pounded...
sorry bout that.
henri
> I think that perl sucks. I did a quick poll here
/. thread about Perl readability... "Perl doesn't kill code... PEOPLE kill code."
> at the office and the only people that like Perl
> are People that do NOT come from a 'traditional'
> programming background. Typically a webmaster,
> sysadmin etc... These are people that need
> something quick and dirty.
>
> The day they'll ask me to maintain PerlCode I'm
> quitting!
Then I suspect you're office is in the minority. Here at our office, Perl is the tool-du-jour. Sure, we can do everything in C/C++ that we can do in Perl, but it takes a heck of a lot longer, especially considering how many platforms we have.
Just because Perl is easily used for something quick and dirty doesn't mean that's all it's used for. Readability of perl code is *entirely* the results of the abilities of the programmer. Perl is a very forgiving language, and that means that while it's easier to write great code, it's also easier to write horrible code.
Like I had said in an earlier
On the subject of the topic at hand, I was under the impression that a lot of the disadvantages of Perl compared to C/C++ (forking to run a CGI, time to interpret/compile the script before running) are taken care of by mod_perl (as noted in other threads). mod_perl, combined with the ability to create web applications much faster in perl would lead me to believe it's well worth it.
WWJD? JWRTFM!!!
> To me the biggest speed disadvantage Perl has to
> C/C++/whatever is that it's interpreted and not
> compiled, but what little people realise is that
> there is a perl compiler out there
As far as I know, the way perlcc works is to compile the bytecode, and then embed the bytecode into a mini perl-interpreter. You may get a speed increase out of not byte-compiling, but that still wouldn't take care of the speed hit from forking and such.
I suspect a mod_perl solution will still be faster than perlcc...
WWJD? JWRTFM!!!
I currently maintain a project which has about 30k lines of perl code, all of which has been developed with very strict coding guidelines by professional (ie., not the 'Perl for Dummies' readers) programmers, and because of my experiences with this project and many others, I have to object to your characterization of Perl.
Perl is a tool, like any other, and can be misused like any other. Professional programming is an art, not an assembly line job, and some artists are more passionate about the artistry of their creations than others. Your suggestion that no one should use Perl just because some people create heinous Perl code is tantamount to suggesting that no one should paint pictures anymore just because your third grade cousin turns out finger paintings of "Mommy and Daddy" that look more like Roschach tests than human figures. If you don't like Perl, there is, of course, no one holding a gun to your head, and you're free to choose another language. I suspect you will find that the same principles apply to those languages, too.
If you really wish to understand Perl, and want to learn to use it professionally, I'd suggest that you look for examples outside of the crap you have apparently had dumped in your lap. Like with any language, there is much reward to be gained by transcending that first 'scripting' stage of Perl; rewards which are only accessable to those with more than a passing interest in it.
Oh. One more thing:
Anyone that writes Perl code that will have to be maintained should have those two lines (or their analog) somewhere in their file. They will eliminate about 90% of your maintainability problems.
I actually wrote a CGI with the full VB 5 once. It sucked horribly of course but it worked...
There are a lot of things other than CGI that can be used on HTTP servers -- most servers have either their own scripting language, or C API. The problem with most of those things is that most of scripting langages are limited, and most of C API are either complex or unsafe (run in server's address space and can cause all kinds of trouble if program misbehaves). I have designed my own API for fhttpd, trying to avoid both problems, and IMHO the result is usable.
Contrary to the popular belief, there indeed is no God.
Herbmaster wrote:
If you spend a majority of your time on a project waiting for it to compile rather than writing code, you either have a really slow processor or a really small project.
ajs replied:
I just compiled GNOME from scratch, including glib, gtk+, ORBIt, all of the other support libraries, GIMP and a number of other applications. It took all morning and some of the afternoon. I have a six-month-old machine with 64MB of RAM. Would you care to re-think that statement?
And how many mornings and afternoons do you think it would take you to code GNOME from scratch? Sounds like you're backing up Herbmaster's comment, not undermining it.
When you write a perl script, it should still work after your ISP changes servers. That's a big problem when you aren't in charge of the server. It could change at any second and you need to be ready.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
>> The performance bottleneck is bandwidth, not
......
>> performance. Usually, it's the speed of
>> someone's modem, or the crowded internet
>> backbones that slow down a web-page's
>> performance. Using a faster language isn't
>> going to help that, so typically web-folk go
>> for the easiest solution.
> I've had people tell me this before. This
> assumption can be an illusion. While it's true
> that you are limited on a per connection basis
> in many cases, it's also true that the number
> of requests that can be processed at a given
> instant in time is also a bottleneck at that
> instant. So, if you expect to be
> processing large volumes of hits in a finite
> window, it's important to have an optimal
> solution. This point seems to be frequently
> ignored or forgotten. What does this mean?
>>
>> Well, assuming you have the bandwidth,
I see what you are trying to get at but the point is that you *rarely* have the bandwidth yourself. Once you have maxed out your connection that's it. You can't go any faster by saving CPU cycles. Servers still have much more CPU power than bandwidth. The original poster's arguement still holds true.
Another point I want to make is that things like DB speed can also have a big impact on DB centric CGIs. This reduces any gain from coding in a lower level language too.
--
Simon.
Perl does a lot of things well. A lot of things do specific things that Perl does better.
Reasons why Perl is dominant:
Using C or C++ for CGI scripts will not give you the performance gains you might think. We are no longer talking about mega-applications which are highly CPU-bound. This goes double if you make sensible use of the built-in functions in Perl, which are themselves written in C.
Rather, you are more likely to come across one of these bottlenecks:
In real life that means: the amount of runtime that could be saved by writing the script in a compiled language is dwarfed by other factors - notably the effort of context-switching an entire program in and out every time the script is called. This is a fundamental problem with CGI, and a big one if you want all or most of your site to be dynamic.
So where do you turn from here? Well, chuck CGI and build the scripting language into the web server. This isn't as painful as it sounds. The obvious one is mod_perl for Apache - but Perl, though cool, is BIG and you do not necessarily want a half dozen copies of it resident in memory at all times.
My favorites - and I use these all the time these days, are:
Don't be put off by the name! AOLserver used to be called Naviserver, until the company was bought out by you-know-who. It's a rock-solid web server that I've been using it for years. Its embedded scripting language is Tcl, which is not fun to debug, but is extremely elegant once you are used to it.
There are others, but speaking from my own experience these two have allowed me to turn entire sites dynamic that would not otherwise have been possible - usually hobby sites that are running on old and donated hardware.
Dave
--
Perl is portable. Show me another good language that allows me to write a web-based app or cgi and easily move it between a Mac OS, Windows NT, and unix server in practically no time at all...
Not to mention that perl is almost always available for cgi, very important for people who maintain sites on like a dozen different server configurations.
Yeah, perl has it's disadvantages, but it's advantages usually outweight them.
...end of transmission...
In taint mode, Perl does data flow analysis, tracking what data either come from or are influenced by outside, untrusted ("tainted") data like environment variables and file contents--thus CGI form data. And any attempt to use tainted data to create files or spawn processes is automatically prevented.
Other languages could have taint modes, but they don't. So I recommend using only Perl for CGI.
It seems that to do anything useful in PERL these days I have to have 15 CPAN extensions which balloon the running size of PERL to ridiculous sizes. PERL has becoming increasingly utilities-centric around here, and we are forsaking PERL for Pike and PHP on the web server. Even mod_perl is monstrous.
...Steve
- It will not be running any software besides the web site for security reasons
- It will have a T1 connection to the internet.
Given those constraints, you can pretty easily saturate the network with Perl and a Pentium 100, let alone a $1000 server with a Celeron 400 in it. So, there's no performance problem or impact on other applications.sigs are a waste of space
I think the key point is that it doesn't matter whether it's a Perl CGI, a VB WinCGI, PHP3, JSP, or some highly tuned proprietary C++ application. Badly implemente code can kill a site.
The point is language selection is the least of your worries in terms of performance. Pick whatever makes the job easiest so a) the code won't be as likely to be screwed up and b) you'll have more time to fix the screw ups that are made.
sigs are a waste of space
Development aside. How can perl be easier on servers?
Same work done in less cycles, requiring less memory, the only issue is fork() exec() delay, but that is a server design issue.
You could load the CGIs into the server context as a library, saving the fork() hit. Clearly this is not a good idea from a stability point of view, however it isn't any worse than mod_perl and it would run at full compiled speed.
The fork(), exec() hit is pretty tiny anyway.
Sorry, you just hit one of my favourite peevees. You cannot cut startup time by 1000% unless you can get negative startup times.
CL has several advantages over both Perl/Python and C/C++.
Like Perl and Python, Lisp provides an interactive environment. You can make changes to a running program without having to restart it. Plus, modern Lisps give you a real garbage collector, not a simple reference counter like in Python (although newer versions of Python may have a better GC).
Like C/C++, Common Lisp is compiled. Unlike C/C++, CL allows you to call the compiler interactively---again, you never have to restart your program. Compiled Lisp code is about as fast as comparable C or C++ code. In fact, most interactive environments compile code on the fly as you type expressions in!
Like Python and C++, Common Lisp also provides a robust and rich object system, called CLOS. I haven't done much with CLOS, although I like the idea of multiple inheritance and the ability to dispatch methods based on more than one object (Lisp methods and generic functions can dispatch on any of their arguments).
Unlike C and Perl, Lisp is pretty clean, syntacticly. You never have to remember operator precedence or any of the funky variable naming rules. Lisp is case insensitive, although it is pretty easy to override this.
Several Lisp environments are available, both commercial (Franz, Harlequin) and free (CMU Common Lisp). There's a complete web server written in Lisp, the Common Lisp Hypermedia Server. If you want to learn more about Lisp, check out the Associate of Lisp Users and browse through the section on tutorials and books (a good book, by David Lamkins, is called Successful Lisp).
Not all is happy in Lisp-land, though. There's no archive network like CPAN or CTAN, so you'll have to go digging when you want a regexp package (although I can tell you to look at SCSH for that). While commercial Lisp environments from Franz and Harlequin are available on Windows, the only free Lisp I know of that has been ported to windows is Clisp, which "only" has a byte-compiler (like EMACS). CMU CL, the best free Lisp around, only runs under UNIX. I also don't know of an equivalent to mod_perl that embeds Lisp in Apache, although if you use CL-HTTP this isn't an issue. Still, Lisp may deserve your attention. As old as the language is, Lisp is still years ahead of its time.
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
I'm proud of my Northern Tibetian Heritage
It's true that Perl has a lot of intrinsic features geared toward the mainpulation of text. However, C++ has a lot better support for constructing new library features that integrate nicely into the language. With suitable classes and templates, you should be able to manipulate text just as easily. (Getting your hands on, and deciding what is suitable is another matter). The standard C++ string class already hides the clumsy storage managment chores associated with classic char * strings so you can do stupid things like add two strings together using + without caring how the memory is managed: the objects take care of it. A string class like that could be extended to have features such as the ability to snarf whole files, do regexp substitutions and whatnot. Problem is that it takes a lot of expertise to develop a good library.
The primary (only?) advantage of perl is that the extended support for text mangling is intrinsic to the language. Wherever perl is used, the perl coder can use the same skills to do the same basic tasks. You don't have to learn yet another class for doing regex substitutions. You could make the argument that a good interpreted language is better than a score of poorly designed C++ classes.
What about robustness? How do you handle out of memory conditions in a perl program? Part of the perceived ease of programming in perl is that perl programs don't do sufficient error checking. C is also easy to use if you don't bother with the little details, like handing null returns from malloc() or error indications from fprintf(). What if a memory allocation request fails inside the perl interpreter? Can the script recover, or will the whole thing just die at some arbitrary point in the execution? In C++ you can use exception handling to implement a sensible strategy for such conditions and construct fault-tolerant programs without littering them with explicit conditional checks everywhere. It's often not acceptable for some low level module to turf the program in response to an error. Bad C and C++ programs are peppered with calls to exit() which make them difficult to extend or incorporate as subsystems into a larger fault-tolerant application. In Perl, this is the modus operandi. Not everyone writes fault tolerant C++ programs, but the support is there if you want to use it.
I don't buy ease of use arguments in favor of Perl. The ease is largely a myth perpetrated by people who use it to write compact utility programs that don't have to be robust against failures. There is a very low startup cost to making such programs with perl, and they can be written tersely, so it looks deceptively easy. But try maintaining any significantly large perl program. Programming is more than just stringing clever operators and subroutines together. That is really sub-programming; solving a small subproblem that is part of a larger whole. Perl falls down when it comes to engineering that larger whole. Features like classes and function prototypes are pathetic in perl; it's painfully clear that they were horribly hacked in as an afterthought.
About your reference to slashdot: would slashdot be so slow if it was written in C++? Those delays can't be entirely network related.
What does slashdot do anyway? It's basically a glorified BBS. In the 80's, kids used to write predecessors to slashdot in BASIC (the kind with line numbers) with a dash of machine language. These things had e-mail, discussions, voting booths, user profiles with preferences, anonymous cowards, etc.
I was speaking purely in the context of compiled C code vs mod_perl, which is what get's rid of the parsing and bytecompiling..
-- I'm the root of all that's evil, but you can call me cookie..
I don't think Slashdot or Freshmeat or Deja or Valueclick or IMDB would be the same with PHP instead of mod_perl.
I am pretty damn sure that freshmeat runs PHP...
The performance bottleneck is bandwidth, not performance. Usually, it's the speed of someone's modem, or the crowded internet backbones that slow down a web-page's performance. Using a faster language isn't going to help that, so typically web-folk go for the easiest solution. The easiest solution is to use an interpreted language. The reason is listed in my first bullet point.
I want to preface this comment by saying I a not picking on you in particular, your comment is well thought out and a good argument. I feel that the bandwidth argument is only a half truth though.
While the user may not see much difference in the performance of a C module extension and a perl module extension, your server will. CGI's put a very heavy load on the servers that run them. If you write your CGI to be efficient, you will be able to run more concurrent accesses on a single system.
More and more I'm seeing people that don't think about the resources that they use in programs and how they affect the overall system performance. This is the reason that even though the hardware speed has increased tremendously in the past few years, many new versions of applications don't go any faster.
This type of thinking is bad for the industry in general. The good news is that not all software suffers from this. gcc for one is much faster now than it used to be, even on the same hardware.
In short, think about not just how fast your single application will run, but also the effect it will have on the overall system conditions.
--
Mike Mangino Consultant, Analysts International
Mike Mangino
mmangino@acm.org
The reason that I don't know the RE syntax for C is that I don't use it very often. I tend to do extremely low level programming, like Solaris STREAMS modules and kernel programming, you can't do this in perl.
I don't want it to look like I'm getting down on PERL, it certainly has its uses. I used it a fair bit at my previous job. I have some complaints about PERL but that doesn't belong here. I was simply saying that there are some misconceptions about C/C++. The reason that you know the PERL RE syntax is because you use it every day. I know the Solaris DDI interface well. That doesn't make it the best tool for CGI (obvious again, I know)
In too many Slashdot threads, people say X is faster than Y, without really looking about the design. Where I work, we are currently saturating some machines due to a poor program design. The tools they used were incredibly fast, but the design stunk and we are paying the price now. While the comment The speed is based on the quality of implementation is an impossible generalization and remarkably obvious, you would be amazed how many people forget this when writing real world code.
--
Mike Mangino Consultant, Analysts International
Mike Mangino
mmangino@acm.org
Hmmm, I see a real bias in the comments. Dare I risk being flamed and suggest ISAPI and C++? OOh! A Micro$oft solution!
... linking the web to an ODBC data source is trivial. If you're a good C++ programmer then it's relatively easy. The only thing that I haven't liked is constantly starting and stopping the web-server to unload my ISAPI Extension DLL, and then having to re-attach to the running process in *another* instance of MSVC. But that's just a small amount of extra time that my boss is willing to pay for!
It seems that most people's responses are about CGI and how C++ is no more efficient than Perl because the bottleneck is the process fork. ISAPI takes a different and practical approach in solving this problem, and is alternative to Java Servlets.
I know this because I was asked to use ISAPI Extensions for the project I am currently working on. I could have recommended an alternative solution, but we were already hitting a SQL Server DB running on NT, and we already had an IIS web-server. It seemed silly to me to have another web-server and another DB... Micro$oft technologies work best if everything is Micro$oft. Mixing technologies causes problems, and I'm also a firm believer in a consistent development approach to keep things simpler and easier to maintian across a team. We have deadlines and no time to consider a 100% change to something else!
Anyway. ISAPI Extensions are trivial. They have better performance than straight CGI. The framework is straight forward (I'm no guru with when it comes to Micro$oft technologies such as MFC, ATL, ODBC, etc)
The bottom line is that there is more to consider than just a straight choice between Perl and C/C++. Do you even need to use CGI? What platform or web-server are you on? Who are the clients that you're targetting? What do have to do on the backend? Databases? If you're a consultant, what environments are the other projects of your employer being developed in? Somebody might have to come and maintain this after you leave, so consistency is good.
...say this:
That's a fine followup post. It's pertinent, clear, concise, and cool. Thanks.
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
Sounds like you are volunteering to give up a large portion of your paycheck to your new customer.
Are you?
If not, how do you expect him to pay for all the up(down?)grade costs?
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
I started with PHP last spring and really like it. Previous to that I did a lot of Perl stuff. When it comes to server side, basic types of stuff, php3 is really nice.
I use it a lot in semi dynamic web sites where the managers don't want to learn html. Separate the header stuff, the body and the footer and just and watch the fun begin.
I also think that slamming between php and html is handy for some web sites. I love for loops such as : HTML CRAP . I know there is perl stuff for that too, but php is really quite nice.
I love perl. I love php. I find perl has a lot of more powerful features that I miss in php (good regex setup is one thing, php's pseudo perl regex's are a pain), but for cheap and fast html, I can't find better than php.
Plus, with PHP4 it will be compilable which means less of my day wasted fixing "webmasters" "improvements".
heheh.... my php code got wacked out. Oops.
I've built and deployed several commercial sites in the last 3 years and currently I do intranet application design for a large telecommunication company, so I have some little experience in this.
I started development on my projects in Perl and moved to C++. Frankly, if you have a good string class and a lib to provide functions such as argument parsing (I wrote my own) I see no advantage to Perl for CGI at all.
IMHO, Perl is a great write once, read seldom language. Unfortunately the real-world model of web development is write it, change it change it change it as the client and the user community's expectations evolve. A properly designed and structured C++ code set is much easier to maintain in this type of environment.
Recently, I've been using PHP3 for the more simple pages, and reserving C++ for the heavy duty work. PHP is a great big hammer for the routine form processing or query results display and I highly recommend it in those situtations. However, I won't go back to Perl in any case, and I'd recommend you don't go there yourself.
---------
confined though we are,
infinity dwells within.
--------
Confined though we are, infinity dwells within.
I find that most things I want to do with CGI benefit greatly from Perl's fast, simple text handling. The need to roll your own versions of the standard Perl text mangling functions really puts me off.
That said, I did reimplement a pretty big Perl CGI in C a while back, in part for speed but mainly because it had to go in with a C based backend suite and the developers didn't know Perl and so couldn't support the old CGI.
Perl doesn't do it that way exactly. It compiles
the entire script into bytecode and then
executes that. True interpretation is
significantly slower.
For every problem, there is at least one solution that is simple, neat, and wrong.
For reasons beyond my fathoming (ie. Microsoft legacy lock-in), our firm uses Active Server Pages (ASP).
Basically server-side CGI in Visual Basic.
Quite why a server-side programming language has to be "visual" is beyond me. Also incomprehensible is why it takes two pages of ASP to do what PERL does in two lines.
It's a bunch of arse, I tell you.
But if you think that's confusing, what REALLY got my goat is that some idiot company came up with a way of serving Microsoft ASPs from UNIX! I don't know what drugs ChiliSoft are on, but I don't want any.
--
Andrew Oakley - www.aoakley.com
> This would be the equivilent of not only
> programming it all in C/C++, but building it in
> as an Apache module.
Well, not quite. "Compiling" a perl program consists of compiling it to byte code, a preparsed format which the perl interpreter can execute much quicker since it doesn't have to parse syntax on it. So, C/C++ code will still be faster that perl code in many cases, however modperl does eliminate the need for reparsing and bytecompiling which are probably the most signifigant issues with start up time.
1) Complexity. Most desktop apps are much more complex than your average cgi. Granted there are some anomaly cgi's that you may consider doing as a java servlet or somesuch setup because it is more complex.
2) You own the code. It's nice to use an interpreted language because it's easy to change without a recompile. And due to the fact that most CGI's are only running on a handful of machines at most, having to recompile everytime you want to bugfix is annoying.
3) Mod Perl. Mod perl cgi's are faster than C cgi's, and are easily built from freestanding perl cgi. The execution speed to ease of use ratio is in mod-perl's
4) Hardware is cheap. If you are getting enough hits on your mod-perl machine where the cgi is becoming a bottleneck, buy more hardware. At that point your making enough money from ad banners to afford it.
5) Security. Although I would venture java as the safest CGI language, you run an extreme risk of buffer overflows unless you make sure you're memory management is secure in CGIs. Since perl has garbage collection, that is not an issue. Howerver, you still have to worry about user input being interpreted as code, but that is easily remedied with taint, as well as CGI.pm's various quoting methods.
...and any other reasons I left out.
You're a bit overoptimistic about the re module's performance; current Perl versions have all sorts of optimizations that the underlying PCRE library doesn't have yet. But this also makes the Perl regex engine's code very hard to understand, and effectively impossible to divorce from the rest of the Perl interpreter. (I'd love to see someone prove me wrong and create a perlre.a, but it seems unlikely to happen.)
Yeah, too bad that instead of "taint mode", Java is stuck with an incredibly sophisticated security model. Java security can allow fine-grained control over I/O based on who who wrote the code, who invoked it, where it was loaded from -- pretty much anything.
Perl does data flow analysis, tracking what data either come from or are influenced by outside, untrusted ("tainted") data like environment variables and file contents
How quaint.
P.S. For those hitting the reply button to rant about "Java Security Bugs" please read up on the difference between server-side and client-side Java, the difference between JavaScript and Java and don't forget to start your post "I'm and idiot..."
Among programmers still clever enough to learn new techniques, there are several "CGI" methods that are rapidly eclipsing Perl:
- ASP. Yeah, it's Microsoft and it's not too scalable, but it's easy and fast to write and comes with some decent visual tools. Great for small-to-midsize web sites and web site prototypes.
- Java Servlets. This technology is explained at length in other posts.
- PHP. Fast, flexible.
- Python. OO, easy to learn.
I think there have been some great posts outlining Perl's shortcomings, so I won't reiterate them here. Are there a lot of sites using Perl? Yup. How many new sites are going to be Perl-based? None that I've seen.Do people actually use CGI these days? I've been a professional web developer for four or so years, and it seems to me, at least, that traditional CGI scripting is pretty much dying off if you don't count small scripts people create for their homepages and such.
:-))
I used to do Perl and CGI's but that came to an end (except in some projects where I have to build on an old code base) over a year ago; these days, Java servlets and application servers, PHP, ColdFusion, StoryServer, Zope etc are pretty much the tools that I see being used (on Unix side of things, I'm not well-informed about the things NT developers use these days.) It all comes down to three things: ease of development, ease of maintenance and performance.
Perl is a quick language to develop small hacks in, but larger scale projects are a different story. An old-fashioned CGI is just way too slow for pretty much anything; I'm not sure about the performance of mod_perl vs. servlets, though. For ease of development, developing scripts from ground up can't compete with a nice application server where you can count on the product to handle DB connections, persistence etc for you.
And for smaller projects, products such as PHP and ColdFusion offer in many cases an even shorter development time than Perl.
Of course, YMMV; my views might be somewhat colored by my rather intense dislike of Perl (mind you, I hate Java too, and that is my primary development language these days
// Juri
Geez, why does no one ever seem to get that for building big web sites where you're going to re-use stuff, the only way to go is to have an approach whereby you decouple presentation logic from business logic? Then you can go ahead and use asp (for microsoft people), jsp (for java people, but face its, its basically the SAME thing), or some other component technology.
Embedded scripting languages like PHP for instance tend to one-up Perl on most of the points you make:
- Rapid Development - Perl was designed as a text processing language. That makes it great for CGIs. But PHP was designed...for scripting web pages, so most of the stuff you are gonna do in a web page, is therefore quite easy. I find it much easier to add code to a web page, than to add HTML to a perl script. Particulary as web pages get more complicated. And editing stuff is MUCH easier than in Perl.
- Performance - Perl is fast enough for most things. If you run mod_perl, performance is good for higher loads. But PHP is fast out of the box. mod_perl is quick, but you have to be anal about your code and there all sorts of gotchas.
- Text Processing - well, ok, PHP is not quite even with perl here, but it's acceptably close.
Really, embedded languages are the way to go for most things.I just tested a mildly complex Perl regex on 2 MB of text, 300000 words, in RAM, on my P133; it found 900 word matches in 1.34 seconds. Your described "prototype" of grepping through files on disk really doesn't have anything to do with Perl.
If your script were written in Perl, running it with mod_perl would be easy. Once the script is persistent, you won't have to read the 2 MB file into RAM every time it runs. That will be the big speedup.
Perl's regex engine is also extremely fast. If you're doing any kind of powerful expression-matching in C, I guarantee perl not only would make the task easier to write and maintain, but would run it faster too. And if you're not doing powerful matching (prefix searching? full name searching?) Perl has other tools that will be just as fast as C: hash tables in RAM or in a simple database; b-trees; even a built-in module to find all unique prefixes from a list of words (Text::Abbrev).
I'm not sure what you mean about "parsing binary databases" as opposed to "text databases." Perl has not been a text-only language since roughly version 2. If you're talking about the difference between a linear and binary search, consider that Perl's hash tables are going to be faster still. If you're talking about storing data in a format native to your language, rather than as one big text string, Perl does this excellently as well.
I think you should look more carefully at including Perl in your toolbox.
Jamie McCarthy
Jamie McCarthy
jamie.mccarthy.vg
No way python/tcl are just as good for that purpose as perl, after all if there were any good everyone would be using them, right?
Perhaps Python, though some people prefer to choose whether or not to program in OO. And Tcl doesn't compare: bytecode-compiled Perl and Python blow it away in execution time as well as (IMAO) syntax and features. I prefer Perl because most of the scripting I do involves regexes, and Perl has the best regex support of any language yet developed on this planet or any other that I know of.. In fact, it is only over the last 6 months that I've tried my hand at any other perl5 features besides the expanded regex set and 'my' and 'use'...
No way there are some instances where speed of program is more important than speed of development.
There certainly are. However, for general CGI programming, speed of development is far more important than speed of execution. Typically for perl modules, any execution-critical routines are actually coded in C or assembler and simply interfaced to Perl. If it's not execution-time critical, then why be concerned?
Not like costs per gate are going up...
Your Working Boy,
It is weak in areas such as GUI development
you mean in terms of the development environment, or creating GUI applications? Because I always considered PerlTk actually pretty easy to understand and utilize, and it's cross-platform...
Your Working Boy,
I agree. It is difficult in C or C++ to do regular expressions easily (at least for me).
Now, the main reason that I love perl is that it is easy to whip something up for a CGI (demo or production) and not have to worry about seg faulting when strtok() is used incorrectly or you try to pop a token off of the end of a string and it isn't there. Perl complains, but doesn't drop core.
Plus, up till now, there wasn't an API for MySQL (I may be wrong - I know that one for C++ was released). It is a lot easier to interface perl with MySQL (Or Oracle for that matter) and not have to use an embedded SQL like oracle provides. There is just something about having to null terminate a character array after doing a select that I just do not like.
Joseph W. Breu
That kinda depends on the complexity of the web application, and the nature of consistency you want with the page layout and all that.
:(.
A recent JavaReport article did quite a good bit of descriptions on how you can use a servlet as the front to the sets of services underneith, which can be servlets or jsp pages, depending on which is more appropriate.
I personally grow tired of digging through java to find html tags in order to change the page layout (or at least i did when i was building CGI in C/C++). Server-Side includes helped a bit, but when i got an embedded scripting form (w3-msql), I much preferred it. I suppose I'd be more interested in PHP for my solutions if i hadn't already latched onto JSP. I also prefer JSP for its portability. I can take the Jakarta engine pretty much anywhere. I can't guarentee I can get PHP working on a windows box. I CAN guarentee I can get Jakarta working, as long as I can put the JDK (or just JRE) on the box.
One definite drawback w/ JSP is that it prefers only writing text. It only gives you access to a "Writer" object, and not the OutputStream. This means that if you want to generate an image on the fly (say, a hit-counter that returns a "gif", like early perl code used to do), you HAVE to use a servlet, or bypass the Writer and go dig out the OutputStream object from the Servlet context. This is technically a standards violation, and isn't portable
Also, the Tag Library part of the new standard is to address the issues of separation of logic from presentation (a common thread in ALL the J2EE products). The logician creates the tags, the presentor creates the web pages that know how to access them. The tags remain as behind-the-scenes java classes that the presentor doesn't need to know about. Does depend on a clean black-box interface design by the implementor, which can be a rarity. Many programmers can build an application. Few can build good libraries.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
An even better solution is the extension of servlets called JSP -- Java Server Pages. In this case, you (like w/ an embeded scripting language like server-side javascript or w3-msql), write HTML with embedded java code, and the JSP engine translates that into a java servlet (or in gnujsp's case a "Template" instance) w/ html embeded as "out.println()" instructions.
The current standard now has support for "tag libraries" where the JSP programmer can write html/xml-like tags to support doing the "logic" of the page, then the presentation guy can use the provided tags, in combination w/ html, to do the layout and make it look nice/consistent. the presentation person doesn't need to know any java at all.
Links on jsp
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Meaningless to this discussion. Applets and stability are the product of the browser's implementation of the JVM, which yes has a reputation for being rather crappy.
What we're talking about here are SERVLETS -- instead of CGI, a java process takes the form data (or does the reading of a database) and generates the html that the browser sees. To the browser, like w/ c/c++, perl, python, whatever, all it sees and knows is html (maybe with some javascript thrown in, depending on the nature of the web application).
This is all contained/managed within the web server.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
another link:
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
I coded exclusively in C/C++ for many years, until I taught myself perl and CGI. The first things I fell in love with were the use of hashes as a built-in data type. Then the simplicity of the scalar-array-hash data model, and it's power. I am not a strong data typing fetishist. Perl is by far my favorite language. For nearly anything, it is worth it to me to be able to rapidly develop and evolve my code, magnitudes faster than C/C++ for the same application.
I think the strongest reason for the success of Perl is CPAN. If C/C++ had a _single_ worldwide library of free modules, all of which were open source, with no arguments amoung programmers as to which was _the_ archive, it would be much easier to use for every application. If I want to do some complicated thing in perl, I know that almost every part of the task will have already been implemented in perl by someone and it will be up on CPAN. All I have to do is write the glue code, and the occasional module myself. It is this community spirit that keeps perl so easy to use.
Perl is the best language for my programming needs. It's fast enough, incredibly easy and reliable, conceptually simple (meaning the solution to a problem in perl doesn't usually stray far from the description of the problem), and widely used and supported.
C/C++ has it's uses, but surely not anything involving string manipulation, and html is written as a string.
I have java turned off in my browser. While it's a good idea in theory, unfortunately it's one of the recurring issues that you see in the security world. Plus the fact that having Java turned off has increased the time inbetween browser crashes greatly. I'm convinced that java is just not stable enough to be something that I can rely on, and the benefits I get from having it turned on are generally only little widgets or flashy addons that take ages to load and don't add much to the functionality of a site.
--
Everything I know in life I learnt from
CGI.pm makes simple CGI's trivial and complex CGI's easier.
Perl is very much based in manipulating text. It slices and dices and makes fries out of any text you give it, meaning it is great for programs that use strings of characters. Now, what does the web depend on? Text! So, the obvious choice for writing a web-based program (like slashdot's posting, for instance) is a powerful text based language. Perl fits the bill nicely.
Posted from the wireless couch.
Perl is probably the most widely used language for CGI because of the lemming effect. If it had to do with effeciency of the resulting code, perhaps a compiled language like C or C++ would have been used. (though as others have pointed out, interpreted languages like Perl and Python will be just as fast as C or C++ for things that spend most of their time doing string processing) If rapid development was the goal, then there are other languages (like Python) that are arguably easier to write in than Perl. Perl is the most popular now because it was the most popular before.
Perl was the first language to become popular for CGI. Python didn't exist at the time CGI first appeared (AFAIK), and the web was young. Enormous commercial websites didn't exist, so efficiency wasn't a huge issue. CGI writers were mostly just trying to do "cool stuff", not develop large maintainable systems, so ugly but relatively easy to write Perl code was perfect.
Because virtually all of the early CGI scripts were written in Perl, Perl became the de facto CGI scripting language. Now most CGI programs are written in Perl simply because that's what everyone else does. If you go to the bookstore and look for books on CGI, most will be the Perl variety. Do a search on Google for "cgi script" and the first link has "Free Perl CGI Scripts" in the description. There are even some servers where they'll only let you have CGI scripts if they're written in Perl. People think "Perl" when they hear CGI.
This is a vicious cycle of course. The more popular Perl is for CGI, the more first-time CGI writers assume you need to use Perl, so the more popular it becomes. Perl is to CGI as MS Windows is to computers. Newbies think that's what they need to use, because of sheer numbers. The typical CGI newbie doesn't know you can use anything other than Perl, in the same way that the typical PC newbie doesn't know that their PC can run an OS other than Windows.
For the record, my first CGI program was written in Perl. I was going to write it in Rexx, but the server I was going to use only allowed Perl. All of the CGI programs I've written since have been written in Python (and they typically run on machines where I am root).
MS isn't the only one who has superfast extensions to their web server. Apache has had loadable modules for a long time, and these modules are within the Apache program proper, meaning there is no forking hit for using them.
In addition, one of these modules is mod_perl which, as several other people have already pointed out, is a superfast way of implementing applications on a web server - no fork hit, no exec hit, etc.
I've written a bunch of CGI scripts for my job, and all of them have been in perl. I've written code for classes in other languages, but perl rules the roost in cgi for the following reasons:
Now an argument can be made that other interpreted languages have a lot of these advantages (python springs to mind), but I don't know of any that are as fast as perl, or have as large a base of existing code. It's interesting that in the original CGI demo by NCSA, they use C for their scripts, but everything else that I've seen is in perl. In short, I'd recommend C only after you written it in perl and determined that execution time is a significant chunk of the total latency. The rules of thumb in UI design are:
hope this is helpful,
--sam
--sam
Any technology distinguishable from magic is insufficiently advanced.
In your competitor's systems!
But still...there are ads for web development in COBOL.
*sigh*
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
I'm still trying to get my head around your argument... Because a *grep* was slow, you assumed that a well-programmed perl script would be too?
I'm flabberghasted! I've written several indexing systems in perl, and although they might not be as fast as highly optimised assembler (and why not? 8) ), they do the job for hundreds of simultaneous users on relatively low-spec machines (486 DX66/32Mb) without any fuss.
It sounds to me that the biggest bottleneck you have is disk I/O. Of course, you might have written some flashy indexing code, but from what you've described, you haven't. You don't store your indices in memory? You reload and process every directory index every time you make a query? That's bonkers (to say the least)!
I've probably got completely the wrong end of the stick, but the solution you've described to your problem is misguided at best. Let's face it, you don't see many farmers ploughing their fields with a plough hooked up to the back of a porsche!
Read my online journal: http://chris.carline.org
I prefer Perl for CGI because it's not compiled, and therefore easier to update. Especially because I don't know who will be maintaining a client's site after I'm done with it, or I don't know precisely what environment that it will be run in. (Which may require a re-compile.)
It sounds minor, I know, but it makes a big difference to me and my clients.
It's called "code reuse." Unless you're actively learning how to program, why on earth should you do it all yourself -- unless of course you're convinced you can do it better than anyone else?
I can do lots and lots of useful things, without having the need to pull in a single module. Now, try to do anything useful in C, without pulling in a single library.
Sorry, but I don't get the "virtue" in this. I'd *much* rather use a library or module or whatever of tested/debugged/optimized code written by someone else than spend my time doing it all over again.
I'm not badmouthing Perl here at all; the fact that so much can be done in it is a strength. My point is that I'd rather not waste time reinventing the wheel.
DFL
Never send a human to do a machine's job.
So write it as an Apache module. Database connections aren't going to be any slower in C++, and if you can keep the database connection open in Perl you can obviously do it in C++ too, hmmm?
DFL
Never send a human to do a machine's job.
The point: Perl's compilation ain't machine code, and it ain't assembler. It's certainly fast -- but let's not pretend it's anything other than what it is: an interpreted language.
And that puts it at a disadvantage, performance-wise, against C++/C code which is as well-optimized as the perl interpreter.
Having said all that, I work with interpreted languages all day, and I would not even consider trying to re-implement those programs in C++ or C -- not until I was convinced that I could do it faster/better than the interpreter -- which is *highly* optimized for speed.
The obvious tradeoff here is in development time. Perl's here and ready to use, and it's easy -- so why not use it? On the other hand, I suspect it wouldn't be hard to come up with scenarios where someone might want to do CGI in a language like C++ or C -- in spite of the extra development time required.
DFL
Never send a human to do a machine's job.
In my estimation, the true bottleneck in CGI programming isn't the speed of the underlying language. It's actually the fork-and-exec caused by the webserver process invoking the program.
Also to be considered is the wonderful innovation that is mod_perl, which makes scripts run like Jesse Owens. That removes both Perl's time-consuming compile-and-interpret phase AND the fork-and-exec bit.
Finally, we've reached a phase in the universe where programmer time is much more expensive than processor time. Perl was designed for munching and formatting text, and so it's very time-efficient from an implementation standpoint to write text mungers in Perl. Most managers and economists would point out that that, more than any other factor, contributes to the magnificent proliferation of CGI scripts in Perl.
Or maybe it's part of Larry Wall's insidious plot to take over the world. You never know, do ya?
Here are some actual figures, not just speculation, from our web sites. See if you think these are heavyweight or lightweight.
mod_perl with raven ssl is about 14 meg a child process
mod_perl without raven ssl but same application is about 8 meg a child process
Of course process size gradually increases overtime (due to caching by embperl) so we kill processes using the cleanup handler phase at 20 meg.
We are certainly trading development speed and ease for code size/runtime speed. But, we are aware of doing this, it didn't just sneak up on us, and for what we're doing it's the right choice.
development.lombardi.com
I had initially prototyped an earlier version of the search engine in csh using grep. [...] The average search took well over 3 minutes. Completely unacceptable. Granted, csh isn't the fastest thing around, but the script wasn't using anything which PERL could have done better (it was just iterating through a bunch of files and running grep on them).
You're very much mistaken there. Every time the you called 'grep' in your csh prototype, yet another process had to be forked off. If 'grep' was called separately for each of several files, a significant performance degradation results.
In Perl, however, you would be searching each file directly from within the same CGI process. And if mod_perl is used, even the forking of the CGI process is skipped.
Definitely an apples to oranges comparison!
--
"Merging into heavy traffic at near light speed!"
"Merging into heavy traffic at near light speed!"
"Our inertial mass ever increasing!"
Works on both UNIX and NT with no changes,
Scripts can be written to render Web pages, or automate tasks at the operating system level,
Adapts to a huge number of tasks due to the availability of a wide variety of tested and well documented modules,
Outstanding string and text stream manipulation capabilities,
Documented in print and on the Internet better than any other scripting language,
Large base of developers, and
Rapid cycle time, due to lack of formal compile / make step that is normally present in C, C++, and Java.
There are a number of other, more esoteric reasons why Perl is a good choice. It's hard not to adopt the Larry Wall Programming Philosophy (there's more than one way to do it) when using Perl. As a result, Perl has given me a healthier respect for the strengths of other environments.
I would not use Perl at the exclusion of all other programming languages. But, if I had to learn CGI programming over again, I would definitely choose to learn how to do it in Perl, at least until I got to a basic level of competency. Once you get to that point, you can make informed decisions about the strengths and weaknesses of the other languages / programming environments that you know for the tasks at hand.
-- Dave Aiello
mod_php might be more popular than mod_perl because mod_perl is more sophisticated. I bet there are more VB programs in the world than Perl programs. Does that mean we should use VB for advanced stuff? I think not. Programming is not about popularity. Programming is about getting the job done. PHP is fine for web-designers-turned-programmers, but I wouldn't want my hands to be that limited, so I use mod_perl on my website to get twice the power at half the price.
I don't think Slashdot or Freshmeat or Deja or Valueclick or IMDB would be the same with PHP instead of mod_perl.
If you want to see whether Perl "sucks" or "rules" compared to other languages, use the "count hits" option of Altavista to count how many times each phrase appears. You'll see that Perl has a better "rules"/"sucks" ratio than almost any other CGI language. :)
I think everyone's pretty much covered the speed-to-production and ease-of-programming advantages to using Perl, but I'm suprised no-one mentioned using 'perlcc'. :)
To me the biggest speed disadvantage Perl has to C/C++/whatever is that it's interpreted and not compiled, but what little people realise is that there is a perl compiler out there (comes as part of the source distribution I think, but for some reason my Redhat 6 box didn't have it installed.. odd). It seems to me that if everyone who was concerned about speed compiled their scripts they'd have a lot less to complain about. I know with some Interbase/SQL scripts I was working on last year I got a fair speed increase by compiling my scripts, especially on our old P150s.
-- sudo.ca
I think FastCGI is a Very Good Thing, a thing that gets much too little attention. It's an efficient, generalized, language-neutral, networkable means of doing CGI-type work without forking.
What if a company calls you and offers you big bucks to write one for apache/UNIX. How well does VB port there?
The server side language should be determined by your constraints. Generally, one wants to minimize cost. If you're paying (or charging) $100+ an hour for programming work, the most expensive component is not hardware, but programmer time, so you're better off using an interpreted language that's fast to deploy than a compiled language that requires more care and planning. Perl can be a good choice here.
For more complex projects, long-term maintenance issues arise. Perl code is notoriously difficult for anyone other than the author to make sense of. I recommend Java for those type of projects but there may be some rationale for using C or C++. Again, it should boil down to economics. Is it cheaper to throw more hardware at the problem or to make the code more efficient?
There are a number of reasons that I use Perl day-in and day-out for writing my CGI programs ... But the #1) reason is: REGEX ... Let me list the reasons here:
/blah/ ... It even gets worse for replacing when you then have to start doing substring calls off of the index values returned to let you do a replace on the text within the block. Not nearly as nice as: s/blah/ ... And don't even mention trying to do a global search and replace. I had to write one search and replace program once that stripped all occurances of X from a web page and replaced it with Y (Where Y could be shorter, OR longer than X). I had to write this in C, because of security considerations. Well all of the code to do this ended up taking over 100 lines of code, error checking, buffer allocation, etc. In Perl this is: s/X/Y/g; SO much simpler, easier to debug, and to maintain.
.o's laying around ... and on top of that, if you want EVERYONE to be able to compile your program and not have to worry about if everyone has their environment set correctly, or knowing off hand what libraries need linked in, then you are going to have to make a Makefile, and make sure that it is working correctly, and keep it sitting around as well. Not nearly as clean as a couple of .pl files or so ...
:)
1) REGEX (wait a minute, I said that already) - Most every CGI that I write spends 95% of it's time doing REGEX stuff. It's taking input from the user and parsing it, it's parsing text from files, and it's sticking it all back together. Yes, I know what you are going to say - You can use the GNU regex library to do regex in C/C++ as well. Yes you can, but not nearly as simply/nicely/easily/etc. If you have ever used those libraries, you know what I am talking about. Creating your regex, setting all the flags/options, compiling the regex, then calling for matches. It's a royal pain versus:
2) Cross platform / Mirror sites. When you have mirror sites, Perl is a BIG BOON! Otherwise all of your mirrors will have to recompile your scripts for their machines every time you change them. And what if a certain C library has 'variations' on different platforms (A certain Solaris memory manipulation routine comes to mind). Heck, the ability to develop on Linux or NT, and then copy the program to Solaris and it 'just works' is great!
3) Maintainability - Yes, I said that - Perl is easier to maintain for me in a multiprogrammer situation. Now, not in the sense you are thinking, but in the sense of multiple people needing to be able to make changes. In Perl, your program IS your source code. You've got one file (or maybe a couple) sitting there, and they run. If a different programmer has to go make a change to the code, they can head right in, make the change, and know it will work. If you are programming in C, chances are that only your EXE is sitting in the CGI directory, and not the source. So they need to find the source. If you DO want to put the source right beside your EXE, then it looks horrible, because chances are that you will have a couple source files, plus unless you clean up some
Ok, guess that's it for now, I could keep typing, but I better get back to the Perl script I am writing
The multithreaded Netscape Enterprise
Server also provides NSAPI which lets you write much more efficient applications than CGI. The interface is a C callback so that dictates the language that the NSAPI application is written in : C or C++.
-- Julien Pierre http://www.madbrain.com/blog
There is a *significant* distinction between C and C++. If a CGI that is heavily reliant on string manipulation is written C, then yes...there may be some unintentional inefficiencies in the C code that may result is poorer performance. But with C++, where a string *class* is used (where member functions that perform string manipulation are highly optimized), I'd be willing to bet that it could equal or better anything PERL could do.
CGI programs are usually accessable to the world which makes them easy targets for hax0rs. If you want to write your program in C you have to either double-check every line of code to make sure there are no buffer overflows, or put it up as-is and keep your fingers crossed.
With Perl's automatic bounds checking, along with the "-wT" option and "use strict", you can avoid most stupid mistakes that people make with C.
Performance isn't much of an issue, as mod_perl can make Perl CGI programs work faster than the compiled C equivalent by eliminating the overhead of starting another process.
When it comes to language support, I have not seen anything to imply that Perl has more CGI-relevant modules than other languages. Perhaps more programs already written.
I find many other languages that have similar capabilities when it comes to parsing, string manipulation, regexps etc. I do not think that Perl's features (although good) is the reason for it's success - many other languages have the same features.
I think that in this respect, Perl is a bit like Windows (no further comparisons implied) - people don't use it because they know (if?) it is good, they use it because everyone else does.
Its not insignificant in large scale applications. The overhead of starting a new process, creating any database connections necessary, doing whatever processing necessary, closing the database connection and destroying the process is pretty significant when compared to keeping an interpreter and set of scripts in memory. Its also easier to pool database connections in the interpreted model.
Left shift 1 for e-mail...
The power of perl is:
1) Regular expressions
2) Variable interpolation
3) eval
4) Associative arrays
While you may find objects providing these sorts of things in C or C++, I doubt the implementation will be anywhere near as clean as Perl.
Perl was designed to handle the sorts of things that are often required in CGI programming. Processing text and like is done with much greater ease in Perl than in any other language I have seen.
While C is not as high level as Perl, it is certainly very high level. C++ is also a very high level language.
C encourages a structural approach to programming and is good for projects requiring a fine level of control over many things. It provides a good balance between low level control and high level abstraction.
C++ encourages an object oriented approach to programming. Object Oriented Programming has shown to be effective in reducing the complexity of very large projects, but has not been proven a superior method for smaller systems.
Perl is in a class of its own. Although full-blown development rarely happens in Perl, it is quite commonly used in CGI programming and many other scenarios for good reason.
I would stick with Perl. Performance issues are of little concern in this case. One might argue that assembly language is the best solution to everything, as it is quite low level and very fast. We all know that there are many more variables in the equation than that.
If your CGI follows a Parse-Calculate-Print pattern as opposed to a Parse-Fetch-Print pattern, you can use Perl where it makes sense to (ie the "parse" and "print" parts) and C where speed is important (ie the "calculate" part)
:-)
Herein lies the beauty of XSUBs.
http://www.perl.com/pub/ doc/manual/html/pod/perlxstut.html
This is how many of the most useful CPAN modules are written. The "high level", perl code calls your C routines to do the heavy lifting.
Plus this approach forces you to componentize your software in a smart way, making it easier to give back to the community by publishing your work on CPAN
I do work in C, C++, and Perl as well as several other languages. But when it comes to CGI scripts, big and small. Perl is definately my favorite choice.
There are actually several reasons for choosing Perl. Text processing is infinately better in Perl than in C or C++. And if you notice, most of your work done in CGI programs are processing text. In some sort or another. Like this form I'm filling out right now.
Another reason is that great CGI module (which I seem to only use param from) which makes handling most CGI related things trivial, and allows you to do real work. Oh and don't forget the
print\\"END_OF_BLOCK"
Being able to send preformatted text like this is very cool, it eliminates most of the messy print statements in Perl as well as other languages. It's also much nicer to read because formatting is very clear.
END_OF_BLOCK
Anyways.... Don't forget that you don't have to compile perl. That way when you make you quick change it will be updated immidiately. I've forgotten to compile my C and C++ programs so many times it isn't even funny anymore.
I do work in C, C++, and Perl as well as several other languages. But when it comes to CGI scripts, big and small. Perl is definately my favorite choice.
There are actually several reasons for choosing Perl. Text processing is infinately better in Perl than in C or C++. And if you notice, most of your work done in CGI programs are processing text. In some sort or another. Like this form I'm filling out right now.
Another reason is that great CGI module (which I seem to only use param from) which makes handling most CGI related things trivial, and allows you to do real work. Oh and don't forget the
print<<"END_OF_BLOCK"
Being able to send preformatted text like this is very cool, it eliminates most of the messy print statements in Perl as well as other languages. It's also much nicer to read because formatting is very clear.
END_OF_BLOCK
Anyways.... Don't forget that you don't have to compile perl. That way when you make you quick change it will be updated immidiately. I've forgotten to compile my C and C++ programs so many times it isn't even funny anymore.
They both have their advantages, but when it really comes down to it, Perl is much more practical to use.
I do quite a bit of web development, and have used both C and Perl to do so.
The main advantage of Perl over C is the string parsing and manipulation. Regular expressions, and general string functions in Perl are much easier than in C, also they are more stable. With C it is quite easy to screw up a dynamic string and cause the program to crash, with Perl the memory is handled internally, so there are no problems associated with a crash. Perl is also an interpreted language, so it is completely cross platform, where C is also cross platform, but requires a compilation for each platform it is to be ran on. Even though Perl is interpreted, it is much quicker than other interpreted languages, such as VB, Java, etc.
-= Making the world a better place =-
Dacels Jewelers can't be trusted.
This is just the age old question:
What language should I use? A compiled one, or an interpreted one?
Of course each language has its pros and cons. But for this argument, but we now have a network layer to deal with. Because of the network overhead in every request, the interpreted language has another pro. It'll be up to the reader to determine why.
The second chapter in this fascinating book demonstrates the development of an application to create a Markov Chain. What is really interesting is that they do it in C, C++, Java, Awk/Sed, and Perl.
The complete program in C is around 180 lines of code and is also the fastest. The next fastest program is the Perl version (faster even than compiled C++) and is only 18 lines of code.
On small programs, such as most CGI's are, there is really not much of a performance hit but there is a HUGE development time hit using some other higher order languages. Knowing which tool is right for the job is sometimes almost as important as knowing how to use the tool.
In Soviet Russia, hot grits put YOU down THEIR pants.
An advantage you might get out of using C++ is that tight loops may compile down into much faster code than you would get with Perl.
Most of the CGI programs that I've written don't even have loops.
With things like mod_perl and such, the speed at which you application executes is secondary to its maintainability. Development time is FAR more costly than a fast server. Perl requires no compiler (you know what I mean), there is a large user base and it's pretty easy (and fun) to learn.
--
*Condense fact from the vapor of nuance*
I like C. But it's *not* really a good string manipulation language. You can work around this somewhat (I have a very nice library of self-allocating strings), but it's still not the natural way the language interacts with the world it's in. This is why perl is so popular for string-oriented tasks.
;)
I'm sad that no one's mentioned Icon, another very string-oriented language.
Anyway, my advice would be, don't worry about performance, worry about writing your program and getting it running. Once it *actually runs*, and *works correctly*, and *then* you have a performance problem, *that* is the time to look at optimization, whether it's pre-compiling perl, or recoding in a "faster" language.
Still, 99% of the time, efficiency is a false win.
Oh, and BTW, there's no such language as "C/C++". C is a language. C++ is a language. Well-written code in one is unlikely to even compile in the other. (And no, C++ is *not* a superset of C.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Habit is all I can come up with. Speed certainly isn't the issue... except for a few specific areas (eg. graphics engines). In my experience, the only issue with VHLLs and speed is the interpreter start up time. The answer to this would seem to be the same as it would be for the web... an application server of some sort (kind of like emacs does with gnuserv).
Python (my favorite VHLL) is great for this kind of development. For my apps, I follow this outline in my performance tuning (assuming I've already written the app in python):
This is what rapid application development is all about.
--
"A society that will trade a little liberty for a little order will deserve neither and lose both."
"It is better to die on one's feet than to live on one's knees." - Albert Camus
I have used all three of Perl, C/C++ and php3 for developing Web application and I don't really prefer one over another. I'd use Perl for simple, low-load scripts where text parsing is useful. I'd use php3 for database integration because it's so easy to integrate into html pages (without having to print("...") the entire page). Finally I'd use C and/or C++ for jobs where computation and complex algorithms are needed. For example, I'v recently written a rather complex calender script in C++ -- I wouldn't enjoy having to write the same thing in Perl.
-larsch
In this months Income Opportunities it is recomended that you have access to your web maintainner at a moments notice becouse you can't wait a few months to make changes to your pages.
Where as application programmers are expected to be months even years between releaces web develupers have to make changes quickly.
Annother problem to face is portability. C is portable but not portable enough. C code made for Linux might not work on Solarus and most certenly will not work on Windows NT.
Finnaly Perl has simply been around for a while. Other languages like TCL and Python while nice do not have the years of CGI scripts.
It's easy to download a program for Linux just FTP Unix code and it should work out of the box. This is due to how long Unix has been in use for networking. Even when Linux was new code for it dates back to the foundations of the Internet.
It's also easy to find apps for Windows as it's easy to port Dos apps to Windows and Windows runs Dos apps this gives Windows access to apps predating Windows. Also Dos can run CP/M apps (Under emulation) and it's easy to port CP/M apps to Dos so in a round about way Windows users have access to apps dating back to the 1970s and the days of S100s.
In pritty much the same way it's easy to find Perl CGI code. Perl has been used for CGI for so long there is much more CGI perl code available than there is CGI code for anything else and reinventing the wheel is also going to create unwanted delays.
When I test perl code on my system and then upload it to my web site it should work but with C code it should NOT work unless my webprovider uses exactly the same system I do and I sereously doupt thats the case.
I don't actually exist.
When I program in C and C++, I always worry a stray pointer will bring my program crashing down. In Perl, I can use an undefined variable, or call a function I expected to be autoloaded ... but in practice, I'm far less likely to see these kinds of bugs once I've done a sane amount of testing. (Put another way: An equal amount of testing gives me more confidence in a Perl program than the "equivalent" C or C++ program.)
P.S.: I've yet to overflow a Perl string. Wish I could say that about C char arrays....-(
Stupid job ads, weird spam, occasional insight at
I suppose one reason is that the Prevailing Wisdom is that "cgi is written in Perl". Look at any tutorial and that's what they'll say, and the reason is that they were told that "cgi is written in perl".
I write in Perl because it's a new language for me; it's enough like C/++ that I don't have to be arsed learning a completely new syntax, but it offers enough (in the form of regexes) that I still need to devote a fair number of brain cycles to the problem.
Another reason just occured to me: you can write one-line Perl programmes to automate boring stuff without the need to make executables; a #!/whatever will suffice. It makes sense to continue with the same language. It makes sense to me, anyway.
In the CGI level anyway.
The reason that C/C++ is choosen for efficiency is because large programs require it. It would be surprising to see a large program written in perl and running as a cgi. Commonly Python is substituded where scripting is required or C++ is used for a compiled language. Perl is harder to maintain than either of those for large programs.
What perl excels at over those two choices is text processing and that it typically a small part of a large application.
I think the sweet spot is:
Use perl for small, stand alone or simple database lookup cgi's
Use Python for any cgi, but especially more complicated ones
Use Python/C++ (via CORBA or another comm enabler) for larger applications
The Python/C++ combo is especially appealing since it breaks the binding between your application and the web. You can test without the complexity of the web being involved. For that matter you can build different front ends (like we've done) for Java, Python, web based on the needs of the end user community.
We have portions of our code that has all three of those front ends, but because the business logic (or in this case, physics logic) is in the C++ CORBA server, the front ends are a few dozen lines of fairly trivial code.
The original question pointed out that most application programmers use C/C++.
Well, they're unlikely to use Perl because it probably won't be installed on the client. Also the GUI toolkit is not as sophisticated as the C/C++ GUI toolkit. The customer would be able to view the source code. Also Perl for Windows hasn't been around that long.
The wonderful thing about the web browser is that it is a GUI toolkit written in C/C++. You can write the rest of your code in perl on a web server (since everything is networked nowadays).
That's why I think it would be great if the forms interface of the browser was enhanced to contain many more widgets to make it possible to write a VB-style interface in HTML. All this energy on making sure the fonts look nice amoung browsers is of comparatively little importance compared to what could be done if we got a few more HTML objects we could play with.
Alexium - open source software and articles for web publishers
The Apache mod_perl module does all kinds of fun insane pre-compilation and caching of Perl for you automagically. You can write Perl modules or CGI to be run in the Apache::Registry wrapper which will be compiled once and cached by Apache until you run it again. This keeps systems running slick and smooth, and is largely what Slashdot uses to the best of my knowledge. I've deployed it on a somewhat large scale myself for totally dynamic content, and it has worked great. Just about every page of a specific portion of my site is generated on the fly with information users have authenticated with and corresponding information from an SQL database with very little performance loss. I couldn't be happier!
You can find mod_perl information in a number of places, including perl.apache.org.
---
Tim Wilde
Gimme 42 daemons!
Firstly, perl was a very good tool for unix sysadmins.
Unix sysadmins tended to be a) young and b) dominate the ISP industry.
IN other words, the people in the position to write CGI stuff were the unix sysadmins. they could, easier than someone else, understand the integration between everything. So, naturally, they used whatever tools were handy to do CGI scripts. (I hate the term, btw. CGI defines an interface between the web server and the program. There is really no such thing as a 'CGI script'. It is a program that conforms to the CGI.)
So, naturally, all the original documents about how to deal with CGI were perl examples.
So everyone did it in perl.
Now, you ahve a path of least resistance. The perl tools are already there, and perl is an easy language to use.. so.... everyone uses it.
I think PERL is used mainly because it is easy to work with. Those who complained about spagetti code should know the time tested rule:
I've seen 40 page (laser printed, word wrap on, 8pt courier) functions written in C at major financial companies. I won't name names but the one in particular has a name synonomous with "Faithful" Investments...
If Grandma can be hacking code in Perl and creating cgi's on the fly - more power to her. She certainly won't be doing the same in C++. I might give Perl a looksee now that I know how easy it is.
--Pete
Ah, the cluelessness of the average slashdotter strikes again. You have no fucking clue what you are talking about. Perl code gets compiled before it's executed. Just like C. The difference is, there's no separate compilation step. Perl compiles at several thousand lines/second, and the compilation step is usually hardly noticeble. With mod_perl, you even skip this, except the first time.
Spreading FUD about Perl is as useful as Microsoft spreading FUD about Linux.
-- Abigail
I don't know. You tell me. If they are as good as Perl, then why aren't they used more? Or is there some secret Perl advertisement campaign going on?
No way there are some instances where speed of program is more important than speed of development.
There certainly are. I never denied that. Keyword is of course some.
I'd follow that argument I'd conclude that windows is better than linux - after all, everyone uses windows. Can't be that everyone is stupid, can it?
I'd say the majority of computer users is way better off with Windows than with Linux.
-- Abigail
Yeah, yeah, yeah, and NT is much more secure and stable than Linux.
Don't spread FUD. Code from bad programmers is hard to read - whether that's Perl, Python or C code. Code from good programmers isn't hard to read (unless they want to), provided you know the language. Don't expect to be able to read Perl code if you don't know the language; don't expect to understand C code if you don't know C either.
Perl isn't harder to read than any other language.
-- Abigail
Care to tell us in which firm you work? I'd like to avoid ever ordering from a firm that has unfounded narrowmindness.
There are a lot of reasons not to like Perl. There are a lot of reasons not to like C. There are a lot of reasons not to like Lisp. Any language has lots of reasons not to like them - most reasons are quite subjective. I don't care if you like a language, or hate it. But if you are going around shouting "I think Perl suck", and don't give any reasons, then I think you suck.
Or perhaps you once tried Perl and it was too difficult for you.
-- Abigail
That is an interesting question, but hard to give a single answer. It depends. On the size of the project, (amount of code, number of programmers), and how much can be invested in training.
Perl would not be my first choice - but for some projects, Perl might be good anyway. C wouldn't be an obvious choice either - unless the nature of the project more or less demands it. I'd look into Eiffel, Ada, Java and Python. And maybe even Lisp or ML. It all depends on the project, and people involved.
-- Abigail
Indeed, you are not a Perl guru. If you were, you would know that the performance "hit" isn't that bad at all.
-- Abigail
Really? How many chomps do you need in your program that it no longer acts on $_?
-- Abigail
Sure. All people using Perl are idiots, and would have been better off using C/C++. After all, CPU cycles is all that count, never mind I/O, network traffic, databases, the availability of modules, maintenance and development cost. They're all irrelevant. CPU cycles! CPU cycles! Close your eyes to everything else.
CPU cycles are cheap. A few weeks of saved programming costs can buy you a very nice and juicy machine. Perl develops a lot faster than C or C++. And many times, the CPU time of a CGI program is irrelevant anyway. Many programs are I/O or network bound. Who cares if your program runs in 30ms instead of 200ms if you have to wait half a seconds for each of your 20 database queries?
As for putting C++ in the same class as C when it comes to speed; please read Kernighan and Pikes book of earlier this year. In a comparison between various languages, the only language to beat Perl in speed was C. Perl was significantly faster than C++.
One thing that Perl has, and C doesn't, is buildin security. Not only is there taint mode, that doesn't allow you to use untrusted data to do something potentially dangerous, but when is the last time you heard of a security hole because of a buffer overflow in a Perl program? Unfortunally, examples of that happening in C are all too common.
In general, Perl isn't as fast as C. But in many cases, it's fast enough. And the other benefits Perl gives you, and C doesn't far outweight that.
Having said that, I'd be delighted if people stopped thinking "Perl!" when they hear CGI. Let some other community deal with all those luser programmers flooding c.l.p.misc and #perl.
-- Abigail
Personally, I like using C for CGI. There are some very nice libraries out there for CGI programming that makes it all easy. (ie. Jemtek).
On the other hand, Perl _is_ far more popular. One reason, I think, is because one can download Perl code and use it, while unless someone was using a C interpreter (and who in their right mind would), all C CGI is compiled, and thus unreadable. This makes it out of reach for most beginners, or for someone who wants specific functionality that is already popular enough to just go out and grab from a script archive or homepage.
And to repeat: Perl is much better at strings and is easier to test; C is faster, but also more likely to core badly.
I guess the question is, what sort of application are you talking about? Analog itself has to be blindingly fast, so C is the obvious choice. But its CGI interface isn't of that type. Speed -- or efficiency if you prefer -- really isn't an issue. So C loses one of its big advantages. I guess a lot of CGI applications are of this type.
Instead, it has to take some small amount of user input, munge it around, and spit it out again. That's exactly the sort of thing that Perl is perfect for. Converting my application from C to Perl, I saved an enormous amount of code length. Again, I guess this is typical of many CGI applications.
Of course, one has to be very careful about security in CGI applications. I think it's swings and roundabouts here. Both languages have similar theoretical problems. But some dangerous things are easy in Perl, and thus probably get done more readily. (E.g. backticks instead of system(), open("|...") instead of popen()). This is a worry: but weighed against this is Perl's -T mode, and its ability to check input for safety very quickly with regexps. In either language you have to know what you're doing here and be very careful to apply it!
And finally, you shouldn't underestimate Perl's readability. Whether in an open source or a closed source model, one day other people will want to maintain your code. Readability is good.
In summary, I'm far from a Perl expert, having written exactly one thing in it. But for my application, and I suspect for the majority of CGI applications, efficiency wasn't the key constraint. Ease of writing and maintaining was.
11.0010010000111111011010101000100010000101101000
Perl, when used with apache and mod_perl is almost as fast, if not as fast as a C++ program. It may be even faster if connecting to a database! Think about it for a moment.
Mod_perl: Its just cool. You have one perl "thread" for each HTTPD thread. It keeps every perl script cached as in a pre complied state. Perl is not a normal interpeted language. It is actually compiled to perl byte code then interpeted. After "compiled" it is very fast. Also, every "compiled" script is cached in memory.
DBI/DBD: This is what you use to connect to a database. It does very neat things when used with mod_perl. It keeps database connection's open, so when your perl script comes along asking to connect to a database, If one is already open, but not being used by another perl script, it is given to you. This can cut 5 seconds of connect time off your perl script.
Perl language: You can script some pretty hairy stuff in one easy to read line of code. I know 90% of the stuff I do would take 20+ lines of code that I do in one... Some things in C/C++ are not practical to code. All I can do in C/C++ is "Hello World", but with perl I can do that with 1 line of code instead of 2-3! Perl will cut your development time by 2/3.
WARNING: I could be completely wrong. This is only what I have read. I use perl to get sys admin jobs done on NT and Unix, most with CGI front ends, but I haven't used it for a cgi with a high hit rate, so I can't say I can prove it.
-Tripp
Perl is more expressive, but Python is legible.
Umm....
Perl is interpreted and C/C++ is compiled.
If you don't know what that means... The perl Interpreter reads line by line and compiles the code on the fly (remember BASIC?) this is much slower and much more CPU intensive than a pre compiled binary app.
A compiled app has already ben reduced to machine code and needs not be "compiled' during execution.
This is why C/C++ would be the choice for anyone with performance on thier mind, and if they had the time.
Sorry man I don't controll the aliens.
The reason I use Perl for CGI script is just that Perl makes text and string handling (which a large proportion of CGI scripts want to do) very easy. Plus it has interfaces to everything else you might need.
C++ makes things a bit easier than C with std::string, but it's still nowhere near Perl for ease of use.
Please, do not run production code with -w!
Test it with -w, OK, but do not leave it with -w when deploying to the site... All you "achieve" this way is increased probability of crash, while the code would run just fine without -w. The actual behaviour depends on the error handling you use for CGI, but the risk of crashing due to warnings increases anyway.
And yes, "use strict" is your best friend.
[[Sure, it's easier to use Perl than a lower level language]]
:)
"Easier" is really not the right word. It's:
-Faster. (time to market!)
-More maintainable (1,000 lines of mediocre Perl code is easier to maintain than 20,000 lines of good C++ code)
-More flexible. (Shorter turnaround time on new features)
[[but programs would be more efficient if C/C++ were used.]]
You're talking about an environment that adds MASSIVE overhead already. (HTTP) Several seconds of latency between you and the user is not uncommon.
Now, let's also consider where most web apps spend their time... If you are using mod_perl, most of your time is *not* based in Perl. It's in your database, or waiting for I/O.
If you aren't using mod_perl, then you add the overhead of spawning a process, loading the Perl interpreter, loading and parsing your code, and then you go to execute it. (where most of the time is spent in the database, or waiting for I/O)
We have a VERY complicated web application (>70,000 lines of Perl) where I work. A web based e-mail system with a pluggable user interface.
Our "main" page (where you view the contents of a folder) uses at least 15,000 lines of that code via libraries and such...
It also takes less than half a second to come up. Why? With mod_perl, the overhead of having a huge codebase goes away. And we've got it down to 1 SQL query. Our biggest performance hindrance was when it used multiple database queries. But it's much better now.
[[when one wouldn't use one for other programs?]]
Other programs aren't developed on Internet time. At my last startup, I learned one painful lesson: Time to market is the SINGLE MOST IMPORTANT THING. It doesn't matter how cool your idea is, or how cool your implementation is, if you have half a dozen better funded competitors. Their products could suck but with more money than you for marketing, they're gonna win.
[[did I make the correct assumption?"]]
If you aren't in a startup, then that is entirely up to you. If you are in a startup, I'd bet money that it is the wrong decision.
Jon Frisby, Sr. Software Engineer,
Personal Site (MrJoy.com)
MrJoy.com -- Because coding is FUN!
IMO, the best answer to this question, is not to think of the question as "why perl in CGI?" and more as "Why perl at all?"
True, perl tends to run a bit slower than say C or C++ or even Java in certain applications. It's certainly slower than coding the whole CGI application in ASM. At least that would be conventional wisdom.
There is an excellent article on Why perl? at http://perl.oreilly.com/news/importance_0498.html Written by Tim O'Reilly and Ben Smith.
The article makes a number of points, but one of my favorites is that when coding in perl, it's easier to write a good (fast, stable, secure) application than it is in a lower level language, the article goes on to make the point that well coded perl can infact run FASTER than poorly coded C or C++.
And (for most CGI developers I know) it's certianly easier to write good perl than it is to write good C++.
The article is a good read, but granted I'm heavily biased as a frequent perl coder.
--A
Think of how many millions more buffer overflow exploits would exist if CGI was mostly done in C/C++? It is hard enough to get systems and server coders to behave and not write unchecked strings into fixed length buffers. Imagine how hard it would be to get less gear headed individuals to do so. The last thing the web needs is a thousand more gaping holes in CGI scripts.
-Paul
"Life is life." --Laibach
I think that it's a combination of things.
1) String parsing, regex capabilities
2) Quick development time
3) Generally CGI's are not _that_ huge, so there really isn't as much code to execute anyway
4) Bandwith is generally the biggest problem over the internet, not code execution time.
I think a lot of the larger web apps are programmed in C/C++, but for general use a 200 line perl script will execute pretty darn quickly and probably not noticeably slower than the same (probably > 800 line) program in C.
see this analysis at radsoft:
benchmarks
Tom
While I like many of the reasons given for using Perl over C/C++ for CGI, the best reason for me is DBI. I don't know any database-access API for Unix that I can use to access such a wide variety of databases. I certainly don't know about any that are portable to other OSes if necessary.
David Corbin Promote Freedom - American Liberty Foundation
perl is very easy to write, but it's difficult (for many) to read someone else's perl code.
The only reason I use perl over c or c++ for cgi is that it's a lot faster to write, and you can easily do string manipulation.
A lot of companies use Python nowadays, but I don't know much about that, or how it compares speed-wise to perl and c/c++
:P
I'm mostly a C programmer and do not write Perl programs, but I very often have to modify Perl CGI's made by others, and everytime the thing frightens me!
Perl is very useful for small programs, but I think that as long as the attitude of writing poorly commented code and there is no effort for, at least, some style guidelines, non-Perl specialists will avoid this, still very useful, language.
The "you can do it in many ways", according to me, is becoming a sort of "do it the fastest way", which is not good for maintainance...
This is a lone request to all Perl programmers!
Firstly, a CGI program is far easier to develop in Perl; there are standard modules for just about everything, CGI interfacing, database access, socket programming, just about everything a CGI program needs. Its fantastic regexp support is also a great boon, Perls implementation of regexps beats every other serious language hands down.
:)
Secondly it is extremely quick to develop CGI apps in Perl. The lack of a compilation step cuts down the development cycle and there are hundreds of free scripts you can cut 'n' paste from.
Thirdly, Perl's garbage collection means you don't need to worry about memory leaks from your million hit per day CGI programs.
Fourthly, when running under mod_perl it is very very very very very very speedy, especially compared to standard CGI scripts. A mod_perl script wil beat, hands down almost any C program that uses standard CGI. Of course, C programs can be written to use the Apache API, but I would rather use 'use Apache::Registry' than try and navigate a large and complicated API.
Finally it is a very portable language, almost all programs are portable across Linux/BSD/Solaris/NT/Unicos etc with very very small changes. As soon as you start using any high level functions in C you soon get bogged down in #ifdefs. These are nasty
--
--
My sometimes helpful blog
CGI _IS_ THE problem, not perl. When using mod_perl module instead plain old CGIs you do get a big server-side performance boost.
My company, Panoramic Feedback, uses C for our CGI. You can see it in action on our site's demo.
Although I've seriously flirted with PERL, C is more familliar and faster when it comes to execution speed. That's important on the web, where your CGI speed is constantly compared to static web pages.
One major downside is there's not much in the way of C CGI code floating around, so you have to do it yourself more often.
The words "backticks" and "time-critical" cannot seriously appear in the same sentence if you"'re talking about CGI. Using backticks will spawn a new process, a costly operation that you want to avoid if you're really concerned with performance.
If you actually have code that runs faster in C than Perl, then write a XS wrapper for it.
Embperl
-
sig sig sputnik
Java Servlets are rapidly becoming an excellent alternative to doing CGI. Isn't CGI (common gateway Interface) a protocol/standard? Cause a Java Servlet is still a CGI-like program, it just doesn't use Perl. I think too many people think CGI == web-based Perl.
Yes, CGI is a protocol/standard, but servlets don't use CGI. They use hooks into the webserver, similar to mod_perl, NSAPI, etc. A CGI script could be written in Java, but I believe servlet implies that the app is not using CGI.
I've had this same discussion with my colleagues several times. I've been told by several other developers that they develop apps in C/C++ but choose Perl for CGI because with things like mod_perl it is in actuality the same if not faster than C/C++ CGIs. Because the C/C++ executable needs to be loaded and forked it is slower than the Perl program, which I've been told can be configured to stay in memory already lexed and parsed (and perhaps even compiled into some intermediate object code?) Anyone have any stats or ideas that disprove or confirm this idea?
For more information on servlets, pick up the O'Reilly Programming Java Servlets book, as well as checking out Apache JServ and the JRun Servlet Engine.
(And really, if you know Perl and C++, Java is but a small step to learn, and provides nice resume fodder. :-> )
Depending on your string-handling needs, perl, especially with mod_perl, may be faster than an equivalent C/C++ program. This is because with C/C++ you're going to have to either write your own routines or use the library regular expression calls, which can vary across platforms in speed. A simple perl script is faster than the system version of grep on some unices. I don't know how something like libpcrel, the perl compatible regex lib, stands up against perl but that might be a factor.
:) Perl is portable and developemnt is much more rapid than with C/C++. It's stupid to use low-level languages for anything but the most time-critical stuff that's expected to have all sorts of load.
CPU cycles are cheap these days anyway
1. Perl has a _great_ CGI module.
2. Perl is very good at proccessing text. (valuable when doing web programming)
3. C/C++ tend to crash much harder than perl does. A minor bug in perl may be catastrophic in C++. As bjarne stroustrup said, "C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow away your whole leg!"
4. Perl is fun!
See you, space cowboy...
- Mike
String manipulation. It is just much easier to do with perl or any other scripting language than C. Since a web page is text, this just makes it easy to manipulate and build dynamic web pages. Also, development is much faster using a scripting language. Look at slashdot. Would it be as far along as it is if it was written in C?
...without taking too long to do it.
I use Perl simply because it's easier for me to program in than C or C++. With just a little effort, I can screen and process user input from forms, interact with MySQL, return HTML to the user, etc. There are probably a lot of folks out there like me who wouldn't get as much done without Perl as I do with Perl. For low volume sites, the performance trade off is more than offset by Perl's utility.
Other people have mentioned that Regular Expressions aren't native in C/C++, which is correct, but there are regular expression packages. You may have to say re_compile(re); re_execute(re,str); or whatever the syntax is, but it can be done relatively easily. The fact that it is not built in does not make it slower.
// and other perl-isms for matching and manipulating regexps in relatively greater detail.
You do not know what your C functions are for regexps?
I, and every other perl hacker out there can tell you about =~ and
Thanks for agreeing with my point - it's time to implement that I was talking about, not performance increase as a result of using C, and compared to having to get out the manpages to look up your regexp functions *let alone* the depths of ODBC's SQLGetInfo() call, you're imposing a far greater workload on the poor coder. For a probably-not-vast increase in performance.
The speed is based on the quality of implementation.
Impossible generalisation, but remarkably obvious.
I suggest you try out a few non-C things for a change.
~Tim
--
Rushing on down to the circle of the turn
There is a perl compiler but depending on how you compiled your perl installation you get either a static (*LARGE!*) binary or a dynamic one (shared library loading overhead).
/way/ easier - you're flinging regexps around with mere punctuation all in one line; not even tcl gets close, having to call functions to do regexp matching. And as for C or C++... eek. Excessive curly-brace overload!
As a general rule you really don't want to be fork()ing a new process (especially involving loading a binary off disk) for *every* hit to a dynamic page. That's partly why some of the NT benchmarks shine, because people are using ASPs (basically, DLLs) using ISAPI instead of real CGI. This is analogous to mod_perl, where the perl interpreter stays up for more than one hit (IIRC).
Of course, the main reasons for using perl is that string manipulation is
Also, apache is modular, perl is modular. You want php3 scripting, easy done. You want perl, also easily done. You want perl modules to access RDBMS behind the scenes, very easily done. (Likewise php, for that matter.)
Trying to incorporate that sort of thing into C or C++ might result in a speed increase of execution, but if you're still loading entire binaries off disk each time, it's not likely to be that significant and you've got to crank out the whole API for your backend RDBMS (ie CT-lib for Sybase Open Client, ODBC for ODBC access, OCI for Oracle, whatever) which is a large development investment overhead for stuff-all performance increase.
~Tim
--
Rushing on down to the circle of the turn
" when you see a statement in C or Java, you can figure out what it
means and it can only mean one thing. Not like Perl... *shudder*
Personally I think Perl should be considered a "non-rewriteable"
language"
1) you are reversing an implication here: if one thing can be expressed in 10 different ways, it doesn't mean that 1 statement can mean 10 different things.
so i wonder how you arrive at your statement that in Perl the same piece of code can mean different things; I generally find Perl code clearer than C code
2) aren't you confusing conciseness with unreadability? no wonder 3 lines of Perl are harder to understand than 3 lines of C: they typically do more work than 30 lines of C
3) everyone has to get used to different coding styles, even in C; Perl's many ways to express the same meaning make it more difficult to understand a person's coding style, but it isn't all that hard in the end;
i mean sure C/C++ are easier to code in but ASM is much more efficient, and as we all know processor power must be conserved at all costs!!! seriously, isnt it obvious why you should use an interpreted (Perl, Java ) language versus a langauge that requires memory management for web development?
-- your knees hurt, don't they?
I am writing a large application -- thousands of lines of code -- in Perl and the people working on it are all CS types (BS/MS in CS). They all were trained to think that the only way to write complex apps is using C/C++.
After working with perl for a few weeks, they all love it. We are producing maintainable, modular code much faster than we would with C/C++.
In my experience, language is mostly irrelevant to code quality. An undisciplined, untrained programmer is like a teenager with whiskey and car keys. They'll write bad perl code, bad C code, or bad eiffel code.
The term "powerful language" is often thrown around when talking about C. Perl is also a powerful language because it empowers the capable, traditional programmer. Give it a try -- you won't want to go back.
Performance on CGI is far more dependent on whether or not the web server is forking for each CGI request.
.cgi program in C++, and force the server to fork for every instance that someone hits the program, you will be much slower than if you write a module in just about any language.
I.e. if you write a
I would strongly suggest writing some simple benchmarks to compare what you want to do in C as a CGI, C as a module, Perl as a CGI, Perl as a module, embPERL, FastCGI etc... (and PHP4/Zend.)
You will likely find that PHP4 keeps up with almost all of them, and provides a strangely C like (and perl like as well. hmm) environment to code in.
Plus PHP now includes session management, something I'd hate to have to write in C by myself not that PHP seems so good at it.
Perl, however, is still the duct tape of the internet for the reason that many programmers know it, and it produces robust code easily and quickly.
If you use FastCGI, the perl scripts are loaded and interepreted once, then executed as binary from then on, removing the performance advantage C would have as a module (mostly) and preventing forking.
If you're more comfortable with C, or writing a truly large application, I'd strongly recommend writing your own custome modules in it.
--- It is not the things we do which we regret the most, but the things which we don't do.
A great many CGI programs collect some information from the user and use that to form a querey for some backend database or application server. In this case, the performance of the CGI itself is not really significant.
Please mod the above comment up. This is not just senseless holy-war-ism; the original poster *asked* what is better for CGI than Perl, and the above post points to a well-acknowledged advantage of python. (not that there aren't disadvantages).
Preferential Voting: easy as 1-2-3
If the CGI is going to be hit really hard, lots of concurrent users, then the extra load on the server might become important. Just remember that half your processes are just going to be waiting around for TCP packets half the time anyway
Perl's string handling is second to none as well of course. Any of the languages with good string handling are going to reduce problems with buffer overflows etc. You'll have to be a lot more careful using C.
You could try looking at some of the FastCGI plugins or even just find a perl compiler (I assume there is one?) both of which make perl quite a bit more efficent and still let you develop quickly and have all those lovely regexps.
Here, here.
Developers forget just how important it is to be able to maintain code. It is a third the battle (1/3 design, 1/3 dev/coding, 1/3 maintenance). Requirements change, environments change, etc. There are tons of reasons why you have to go back into the code and fix/change it. Not to mention bug fixing. If your code is spaghetti, fixing one bug might introduce 10 others.
In my experience, I have found it in my best interest to write clean code, comment heavily, etc. so that I can _leave_ a project! After I have developed something, I don't want to stick around to maintain it. I want to hand that over to somebody else and get on with developing something new.
The trick to maintenance is structure. Sure you can impose structure on an unstructured language (i.e. code guidelines on top of Perl), but your life will be much easier if you just pick a structured language in the first place. The compiler is a much better guidelines watchdog than a piece of paper that your developers are supposed to read.
Perl does what the majority of CGIs need, and does it really well. In the most common cases, CGI data is pased in, the data is parsed, manipulated, formated into other text, and then other text is returned to the user. When it comes to text manipulation, you won't find a better language than Perl. Period.
Perl also has a lot of code already developed that is easily re-used. Two prime examples: CGI.pm & DBI.pm. Granted I don't do a lot of C development, but I haven't heard of C libraries that come close to functionationaly & flexibilty. (Granted you're less likely to see it in C, since it doesn't support OOP, but you might in C++.) If this is what you're looking for, Perl is a damn good answer.
Keep in mind the way a CGI works is data is submitted, processed, and returned. CGI isn't really appropiate if you want to do constant, real-time updating of some sort data. You could the page constantly reload, but that's a cheap hack at best.
Applications, on the other hand, do a lot of other things. Not that I would say all over them are entirely optimized, otherwise 4GL languages, like PowerBuilder & Visual Basic, would not be nearly as popular. However, some of these other languages are stronger at supporting other other actions, most notably GUI interaction & a WYSIWYG-ish development enviroment.
C/C++ are really strong at processing things quickly. If you really need to scale at a cheap rate, you may want to take a look at them. From what I understand, Altavista and a few of the other larger site use it instead of CGIs and Perl (or any other language). Most of the time, for most of the applications, that's not needed.
In fact, I think you could safely say, develop in Perl, and then tune to C when you need to. But the best thing to keep in mind is that if all you know how to use is a hammer, then everything looks like a nail. Every development language or process, is a tool, and each developer simply needs to understand which tools he should have in his box and how to use them.
-Bill
SlashSig Karma: Excellent (mostly affected by moderatio
When you write a CGI in perl, you almost always use the CGI module. You don't have to worry about coding regcomp and regexec calls, you don't have to deal with manually allocating memory. You just write your code and are done with it instead of having to continually reinvent the wheel. (Personally, I believe that my time is far more valuble than the computer's.)
perl is one of the few actual examples of code reuse, FWIW.
A co-worker of mine and I were having a friendly and laid-back discussion about the virtues of restrictive languages (especially Java) versus laissez-faire languages (especially Perl). I was arguing for the more restrictive languages and my friend for Perl. My arguments were largely based on the same maintenance arguments that you make in your post.
Not that you can't write easily maintainable Perl or poorly maintainable Java, it's just that the philosophies of the languages are different. Larry Wall will be the first to tell you that he designed Perl to build quick and dirty programs. He didn't want the language to get in your way of getting something done. (This is not to say that Perl hasn't since developed into a language capable of developing large applications, just that it was designed for a different purpose.
The classic example in my mind is that you can have Perl take an action on a "default" variable. The statement chomp; drives me nuts. Sure it's convenient to not have to specify what you are chomping. But if you put enough of these kinds of statements in a row it quickly becomes hard to tell which variable is being acted upon.
It's perfectly easy to know what is going on when you write the program. But six months later when someone is trying to fix a bug or trying to expand the functionality it can become maddening.
This not to say that I don't use Perl. I think that Perl is great. But I use it as a scripting tool not as an application building tool. For me, it's a great way to get short tasks done. My rule of thumb is that if it take more than two screenfuls of code you should think twice before using Perl. Sometimes I'll break the rule. But when I hit that third screen I'll stop myself and decide if a Java application (or Servlet) might be a better choice.
Using Perl is well worth the efficientcy lost because of its string handling capabilities. CGI is string handling, and would be a nightmare without Perl.
And don't forget one of my favorite reasons: maintainability, esp. by thirs parties. It's *much* easier for me to hand off a piece of generalized Perl code than something finely crafted in C/C++. I'm willing to take a performance hit for not being responsible for maintaining a Nightmare Code Base from Hell -- lots of pointer magic and memory voodoo that made sense once, but now...
There are times when it's important to have fast running code, but perl offers features that you _really_ want (i.e. text processing routines). I'm no perl guru, but I understand that perl is compiled on the fly when you run it, which incurs quite a performance hit.
Has there been any thought/work on making a regular ol' compiler for code where you can't take the performance hit that the normal perl cycle takes?
-zook
I looked at Perl, and was pretty much turned off. All those importated libraries/modules just to get basic web and database functionality. Needlessly complicated, IMHO. PHP has that stuff built in. (I can live without built in graphing :).
Plus, Perl is pretty slow. PHP is considerably more efficient in my experience (based on 3 Ultra2s running Apache 1.2x). Mod_perl is faster, but the memory requirements are large to say the least, and it's a pain to get working. To me, PHP is a much more readable and human language. Not so much random garbage.
I'm a PHP fanatic.
- Scott
------
Scott Stevenson
Scott Stevenson
Tree House Ideas
Why don't you print <<END
...
END the page?
What's the difference between switching to HTML (or JavaScript or SQL) via Perl multi-line strings and switching to PHP from HTML code?
I've got a CGI (online testing program) which reads in a text file which contains one or more equations. It generates random numbers for the input and then outputs the results of the equations.
I had two choices.
- Write many, many lines of C code to parse the equations
- my $result = eval $specialpart[1];, where specialpart is the equation stripped from the text file.
Given the ease of doing this + the great string handling routines in Perl, it wasn't a hard choice.Eric
"Seven Deadly Sins? I thought it was a to-do list!"
Writting CGI apps in C++ will not gain you much speed, and it definatly slows down your development process. Therefore, if you're going to do it in CGI, you might as well do it in perl.
Also, if I'm hitting some C/C++ API, I'd rather use raw C/C++ than try to write the Perl module. It's one less level of indirection.
...when the Web took off back in '95 or abouts, Perl was a robust, well-understood language with tons of ready, freely available scripts to process enormous amounts of text. And since HTTP is text-centric, it was a natural first choice for CGI implementations. But I doubt it is any longer.
;-)
The Web and the technologies around it have matured enough to enable us to use custom-made tools for Web applications. For straight Web-only applications I'd go with the very impressive PHP4. For deployments that need to be tied in to a larger infrastructure (DBs, legacy code, uncoventional hardware), my personal choice would be the Apache Java Tools. Apache JServ, Apache Cocoon, and soon, Apache Jakarta should cover all your needs.
Both PHP4 and Apache Java have session management, pre-compilation to portable byte code, platform independence, and work well with most popular DBs (JDBC covers more of them though).
YMMV. As one of my ole engineering profs says: "50% of successful engineering is picking the right tool for the job" or something like that
n
Why wouldnt this strategy work for the scripting tongues? In Topaz there is already a project to rewrite perl from scratch. Its possible (though admittedly a bit of a pipe dream) that the engine could be written to be retargetable to other VMs (eg Squeak's, or (more unlikely) Javas). And then, why not allow the front end to interpret python, tcl,...?
Actually perl is probably one of the biggest stumbling blocks for such a project, as (among other things) the syntax is so wacky.
Anyone involved in writing those languages care to comment?
-Baz
(BTW: my 2c on the original argument is that you should look at what actually needs optimized before worrying about perl,C,php,ASP as a web language. I find the bottleneck is usually in the DB; consequently the number of coders here who already know perl and can code rapidly is a major factor. C loses due to long debug/test cycles for memory management. This shouldnt be true, and I know C hackers will say they dont suffer from this, but in the real world I've seen it many times)
I once asked a similar question of a guru and recieved the following answer:
For most intents and purposes, Perl will be faster than C. Not in the theoretical world where code is perfect, there only C can win, but in the real world, where there are only so many people who know how to implement a good linked list, and where there are only so many people who can be bothered doing association via a hash rather than simply traversing a two dimensional array, perl is going to win 7/10 times because it makes the proper method the easiest to use.
If you are an excellent C/++ programmer, willing to go out and download good hash, list and algorithm implementations (or write them if you think you can beat the efforts of a couple of PhD's) then sure, you're going to outperform perl in every single facet. If you're doing raytracing, or calculating Pi, C will leave perl sitting in the dust, but for the majority of web applications, written by the majority of programmers, Perl wins out. Big.
You can't win a fight.
First, I don't think it's fair to criticize any language on the basis that it's possible to write bad code in it. You can write bad code in any language, and this fact has been proven over and over again by programmers all over the world. There's far more bad code written in Perl and C++ than there is good...
I think Perl is often a great choice for whipping up small programs such as CGI. Perl has less of a learning curve than C++, and it provides a lot of good functionality (especially for text manipulation) that makes it possible to accomplish quite a bit in very few lines of code.
However, there's nothing about the C++ language that prevents you from getting a lot done in very few lines of code... you just need the right class libraries backing you up, and having a good mind for software design won't hurt either. In Perl, you get a lot of useful stuff "out of the box", whereas in C++ you need to go "shopping" for class libraries. ANSI C++ includes the STL (Standard Template Library) but it really only covers a portion of the re-usable functionality you'll likely need. For example, it doesn't have regular expressions or socket communication classes. No big deal, just figure out what you need and go get it... C++ is a very popular language for application development, so there's been a lot of effort spent developing class libraries for it.
I think the aspects in C++ that make it hard(er) to learn are largely those that make it a far better choice for large applications. Once you get over the learning curve, you can really appreciate C++ for all the power it gives you. C++ templates are very powerful (though I think they're overused). It's also a full-featured object-oriented language, and I'm very religious about object-orientation, especially for large applications. Yet it's not a pure OO language (which motivates some criticism), so you have the freedom to do things in a procedural style if you see fit.
Another issue that's relevant in large projects is debugging support. Is there such a thing as a Perl debugger that even approaches the power available in a modern C++ debugger? For example, debugging multiple execution threads, setting conditional breakpoints, etc.?
Anyway I'm really glad Perl exists because I think it does fill a void -- it enables the rapid development of small programs without requiring a huge up-front investment of learning time. But I cringe when I see people talking about how Perl is the ultimate language of all time, because I wonder how many ill-fated, large Perl projects are being started on the basis of this hype. Perl is worthy of praise, but remember it's not always the right answer.
The original news post suggested using c/c++ over perl for cgi programming, supposedly because c/c++ is lower-level and thus more efficient. Other posts here have already shown that's not true, so I won't repeat those arguments. I'll just say that c/c++ is not very well suited for cgi programming. It's string handling is weak, which is one place where perl excels, and string handling is extremely important to cgi. Also, efficiency is not quite as important to cgi as it is to productivity applications or other genres.
With that in mind, let me offer another alternative: php. You've probably heard of it, but I'll list a few advantages. It's incredibly easy to learn. The syntax is very similar to c, but it's a scripting language, so it's as quick to get started with as perl. It has very well integrated database support. Note that the database modules, which is where efficiency is most important, are written in c. For info, check out http://www.php.net
(BTW, I'm not associated with them in any way, I just started using php recently, and I'm very impressed at how easy and powerful it is, especially in database connectivity.)
The original news post suggested using c/c++ over perl for cgi programming, supposedly because c/c++ is lower-level and thus more efficient. Other posts here have already shown that's not true, so I won't repeat those arguments. I'll just say that c/c++ is not very well suited for cgi programming. It's string handling is weak, which is one place where perl excels, and string handling is extremely important to cgi. Also, efficiency is not quite as important to cgi as it is to productivity applications or other genres.
With that in mind, let me offer another alternative: php. You've probably heard of it, but I'll list a few advantages. It's incredibly easy to learn. The syntax is very similar to c, but it's a scripting language, so it's as quick to get started with as perl. It has very well integrated database support. Note that the database modules, which is where efficiency is most important, are written in c. It's string handling is mostly as good as perl's. (I haven't used perl much, so I might be a little off on that, but it is superior to c's.) For info, check out http://www.php.net
(BTW, I'm not associated with them in any way, I just started using php recently, and I'm very impressed at how easy and powerful it is, especially in database connectivity.)
arrgh.. very sorry for the double post. someone please moderate it down (this post's parent)
Since both are "free" in both senses, I take it that by "price" you mean something very specific. I switched some scripts over from mod_perl to PHP since they were doing some pretty simple things, and my performance is *much* better now. Maybe on larger and more complex tasks, mod_perl might catch up and surpass PHP, but for lots of things PHP beats the pants off of it.
No argument about power, but give PHP time =)
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
The 'whatos' software, that works out what Operating System a remote machine is running on, is also written in Perl.
If it's a big database intensive project, performance could easily be the bottleneck.
Speaking as one who writes a lot of database intensive Web interfaced systems, the technology you use to bridge between the database and the Web still doesn't have a very big hit on performance. As I've said above my testing shows that compiled C performs best (of the technologies I've tested) for CGIs, and by a substantial margin.
However, I personally prefer to use Java Servlets, for reasons of code reusability, portability, and most importantly, code readability. And the reason that I feel that the (relatively) poor performance of servlets doesn't matter very much is that the real performance hit is in the database engine. The largest proportion of the time responding to any given response is the database engine doing it's stuff.
Using servlets I save time on starting the servlets (because they're permanently loaded) and setting up database connections (because they're permanently open in a pool, and it's only if there aren't enough in the pool I need to create another), and this saves more performance than the minor relative inefficiency of the JVM costs. Of course you could achieve similar benefits with mod_perl, but in my opinion Java still scores for code readability.
I'm old enough to remember when discussions on Slashdot were well informed.
However, one thing is abundantly clear: starting new processes for CGI is hugely expensive, and the larger the binary you have to load to start the process, the more expensive it becomes. The PERL interpreter is huge, and consequently, run as CGI, PERL scripts perform comparatively very badly. THe situation must be very different with mod_perl, but I haven't tested this.
Mind you, this is not really a reason not to use PERL if you like it. Unless you have shedloads of bandwidth or run your website in a 386 box, or are doing some really complex backend processing, your CGI performance is not going to be your primary bottleneck.
I'm old enough to remember when discussions on Slashdot were well informed.
I'm not sure what the currect status of it is, but I remember hearing something about a perl compiler that the perl team has been working on. Often, there are many advantages to interpreted languages, like allowing very dynamic changes at runtime, but a perl compiler would allow static perl scripts to run directly as compiled code, and not need to be interpreted, something which could speed up a lot of cgi sites which constantly use the same perl scripts over and over (hmm... /.)
This would give developers the quickness that perl offers, and the runtime speed that compiled languages offer.
Correct if I'm wrong about perlcc please.
You don't need a Python Netscape plugin! Any browser that supports Java can run JPython -- the Python interpreter for Java. With this you get full access to the Java API, from the comfort of the excellent Python language. JPython applets look just like Java applets from the user's perspective only they're written in Java. With the advent of JPython, Grail is not really necessary.
I think the main reason we use interpreted languages is portability.
I've done some cgi work where the servers have been Solaris on sparc, and my in-house test machine was Linux x86. It was a darn-lot easier to ftp the script and chmod it than to try and re-compile it every time I fixed a spelling mistake.
The host was also a little paranoid about letting it's users have shell access, which would've been convenient, but I managed with ftp. I can't imagine what a pain it would have been to run some script to compile my CGI rather than just transfering it.
Perl is standard. I can write perl code on a windows box, and have it running on a linux box within minutes (stupid linefeeds stripped, of course), so, I imagine THAT's why the industry leans towards interpretted languages.
Fairly simple:
First off, I trust them (the perl developers) to be able to handle strings smarter and more efficiently than I can -- they've been developing perl for 10 years. I don't have so much confidence that I think I can develop something better very quickly.
Lots of modules to do stuff I need to do -- rapid development.
I find perl far easier reading than I do C (for example) -- it's easier for me to maintain (at least, when I write the code).
Most of the disadvantages of perl can be "fixed" using various available utilities (FastCGI, mod_perl, just buying extra RAM [which really is more cost efficient than me spending a ton of time developing a new string handler library])
Fast learning! Lots of documentation, all very well organized. If I don't know how to do something, I can learn in a hurry with perl. C is not so easy.
It's more fault tolerant than C/C++. I make lots of mistakes when I code (I'm not perfect by any means). I can find them and correct them far faster with perl than C.
*shrug* Perl has built in handling of strings and good memory management. With C, I have to find or write another good library to help.
Perl just makes things simpler, and it's trade-offs make it more useful than not for my requirements.
I've had the occasion to consider this question myself over over the last year or so. I am an experienced C/C++ programmer, but I find that I can write CGI scripts at least 3 times faster in Perl than in C/C++.
One reason is that I don't have to spend a lot of time debugging nit-picky pointer and off-by-one errors. Another is that Perl's string replacement syntax makes it very easy to loop through a template HTML file and replace placeholders with results.
Perl's ability to return an array of arguments from a function is also very convenient. And I can have dynamic data structures without the nightmare of malloc induced memory leaks.
I also prefer Perl becuase there is a vast library of freely available modules for doing network type things. I had to write an online mail sender this summer, and finding an SMTP module made everything much simpler.
There is plenty of freely available C code as well, but it's usually not in library form, meaning that you have to spend time pulling it out of some other program, integrating it into your own, and debugging.
Lastly, if some part of your program really needs to be done efficiently, you can write an XS module in C.
All that said, I really think Perl is one of the butt-ugliest languages around. I think that Larry Wall desperately needs a computer science course. But I can't get around the fact that it's damn convenient.
-Loopy
To bastardize Tigger's quote:
The most wonderful thing about mod_perl, is that mod_perl is a wonderful thing!
Mod_perl (I believe this is how it works) associates an instance of the perl interpreter with each httpd child precess, meaning no forking, and fast excution. Because of this, for small programs, mod_perl is actually quite a bit less resource intensive then C or other compiled languages.
Blessed are the pessimists, for they have made backups.
I have seen a couple of CGI packages out there for Ada. Ada is the most strongly typed language there is, much more than Java.
I have used the packages and ran some CGI using them on NT seemingly well.
There is an GNAT compiler for Linux available, but I have not tried it.
Using this combo would be good for XML applications...
EC
EverCode
The main reason something like this may not exist in all web servers is that people are used to using scripting languages for web jobs. I think C++ can do just as good a job in many cases, and given the above, yes, it WILL run faster.
Also, because several people have mentioned regex as a perl assert, I must mention that it's super trivial to use regex.h for that. It is, afterall, what many of the current regex implementations are built on. :)
The main asset perl has are the already written modules and libraries such as PHP or various and sundry other things found on CPAN. If C++ had such as extensive set of free classes to use, I dont think there would be any contest.
Development time in Perl is considerably less than it usually would be in C/C++, and it's also a lot easier to gauruntee portability. Basically any operating system your a web server runs on will be able to run your perl script, given the fact that it has a perl interpreter. This is especially important if you're doing CGI scripting on a web server that you don't necissarily administer or have a whole lot of access to other than to upload your files. You don't have to compile perl, and there are very few cross-platform portability issues. Not to mention it's awesome string handling stuff that's built right into it, which is of course extremely handy for most CGI applications.
Therefore, I think I should.
IMHO there is no competition for WebObjects.
There is a steep learning curve at start, but I think there is no other environment that will give you such a rapid development (for larger projects) and such maintainability.
There is an online Python/Perl phrasebook if you want to compare the two languages in action. A lot of the information is based on Tom Christiansen's Perl Data Structures Cookbook, as well as help from the two languages' respective creators, Larry Wall and Guido van Rossum. It shows how you'd accomplish a wide array of pretty common tasks in each languages. It's ample fodder for clear-headed analysis of all-out flameage...it's your pick.
I'll have to agree with the site's author: Python wins for readability, approach to OOP, the blessed absence of $, @ and % characters in front of variables (never liked 'em in Basic) and the homage to a great comedy act (and the convention of using "eggs" and "spam" instead of "foo" and "bar" in code examples). Perl wins for its better handling of regular expressions, quoting and having lots of people who know it. They're quite similar and becoming more so, especially since the re module in Python has been changed to be quite similar to Perl's regular expression functions. Performance is pretty close.
It may boil down to the language the alpha geek prefers or the project already uses, if you drain religion from the argument...but what fun would that be?
When writing CGI, I write time-critical or process-intensive tasks in C and shell out in Perl using backticks. This gives me the speed and 'cleanliness of code' that I need while allowing me access to all of Perl's wonderful hash-and-smash text munging to handle the output.
Learn from your parents' mistakes: use birth control.
I think Applets have hurted Java a lot. First, people think Java==applets and second, Browsers JVMs implementation are awful.
---> Did you know Linux stands for Linux Is Not UniX ?
I make my living writing C++ code, and I love the language. But picking the right tool for the job is always important. Many (most) web based projects are very dependant on time to market and in this regard Perl is very impressive. That having been said if I was working with a bunch of people who talents I did not trust on a large project - I would not pick Perl.
Just my opinion, and worth what you paid for it.
pth
My name is not spam, it's patrick
Home Automation & Linux -- now I know I'm a geek
I think perl is not easy at all ... those string-manipulating scares most newbies. (Regular expressions ? what the hell is that ? :) I think (IMNSHO:) that PHP is a lot better. It is a mix between Basic and c++. The best argument PRO perl is, that it runs nearly anywhere, and is installed on most webservers. PHP is easier, faster, less memory-intensive, and will soon be compileable to some p-code. (PHB's just LOVE that feature ! Most of them hate the Idea of selling your source code :) Check it out at http://www.php.net
Compilation-time differs significantly, depending on how tight different modules interact. IIRC, in general, going from X to X*2 MB of code means a larger time-factor for C++ than for C.
If we stipulate roughly one test compile every three hours (not that improbable, I think).
However, in a project of any size where aggregated compile time matters, the regression tests probably would consume even more time, so...
Me, I load the source code into my development environment, develop and test-run and use compile-and-reload just prior to profiling.
http://www.chamas.com/hello_world.html
That web page is maintained by Joshua Chamas, and originated in some discussions that began on the mod_perl mailing list. A page related to it was featured on Slashdot a month or two ago.
I'm by no means an expert, but here's my very rudimentary understanding of the situation:
Most CPU cycles spent on CGI stuff are not so much spent on crunching the data as they are moving the data around and communicating with the webserver. For this reason, things like PHP, ASP, mod_perl, and custom written Apache modules have been developed to plug directly into the webserver's guts. This avoids the overhead associated with forking a separate process to do the computations, opening a pipe to communicate between the webserver & the CGI process and the general cost of loading another program.
However, if you've got a webpage that needs to do something like compute Pi to the 10,000th digit every time a user hits it, then the CGI overhead will be dwarfed by the computing power required to generate the page. For this, it would make more sense to write an Apache module in C.
Why not write everything as a C Apache module?
Because writing a Perl Apache module isn't significantly slower, although it is significantly easier, more expedient, has better database connectivity and is less painful to maintain. But then again, I'm a professional mod_perl programmer, so maybe I'm a bit biased.
There are other scipting languages that are just as effective as perl (or similar, I dont' want to start a flame war with perl die-hards) but python produces some of the most readable code.
In fact, its had for novice programmers to produce unreadable python code (although they can do so). Its string manipulation is quite effective, and natural, and it is possible to implement complex structures just as quickly in python and in most other languages.
Democracy isn't about no one telling you what to do. It's about everyone telling you what to do.
At the corporation where I work, we frequently choose script over compiled code for a myriad of applications. Since we have 24x7 systems to maintain, rapid error recovery is vital. If I get a call at 2:00AM and drive in to the office, when I identify the offending program, I want to be able to fix it on the spot without having to dig up a particular development environment. With script, Vi or notepad is all I need to solve the problem and get back to sleep.
The complaint with script of course is speed. In comparison to compiled code, it dogs. In our environment we do worry about performance tuning, and look for obvious inefficiencies like everyone else. But the simple reality is: "Too slow? Buy a bigger box". In the grand scheme, hardware is cheap, people are expensive. Therefore, we script. It gets the job done and frees us up to get to other projects.
is to write your next application in both Perl and C++, and see which one is actually faster. If your task includes a lot of string manipulation, then perl's built in code may indeed be more efficient than you can manage to accomplish with your own C++.
Then, if C++ is faster, and you *need* the code to run faster, go with it.
-I go to Rice, so figure out my email address
>As far as being a huge executable, take a look at the binaries produced by some of
>the Microsoft Web solutions (ahem, VB, ahem) and we'll talk about huge executables.
>The Tcl binary is about the same size as the Perl binary, and many complex C
>programs end up being very large also, once you incorporate regex parsing routines,
>CGI libraries, and image processing libraries.
First, VB sucks.
Second, I had to write a script in VB (Did I mention VB sucks?) and the execuable came out to be 32K, which I think is probably some sort of minimum size for a VB exe. I dunno how big the scripts you write come out to be, but as far as a MS proggie is concerned, that's pretty small.
Third, VB sucks.
I've considered learning perl, but until I actually have something to write, (preferably something I get paid for) there is actually little motivation to do so. I agree about the lack of string manipulation and parsing functions in C/C++, although I'm curious about the poster who claimed strcpy is a slow function. The implementations I have seen follow like this:
void strcpy(char* dst, const char* src)
{
while( *dst++ = *src++ )
;
}
which does not seem like alot of overhead to me... This is actually quite similar to the implementation of at least one OS strcpy function that I looked at. Most of the other string manipulation functions are as similar. The biggest problem with them is that many people don't get the whole pointer thang. And for those that do, the code is still extremely prone to bugs.
As far as the general subject of the thread, I have to agree with many of the other posters, use whatever tool is appropriate at the time. And judgement of "appropriate" includes any time it takes you to learn the languages you're considering. It also includes time it takes you to reload the ENTIRE development enviroment because your bug caused you to parse past the end of a string and this caused the development enviroment to crash. (Did I mention VB sucks?)
>>>>>>>>> Kvort
-Don't mind me, I'm personality-deficient and mentally-impaired.
I was unclear. My application was not of the web, but just a kludge to so some specific things on a machine that has my company's software installed.
:)
Admittedly, I know next to nothing about web server apps, other than writing some VB forms for a program that connected through a MTS Server to a MS-SQL DB. Phear that sh^Htuff. The clients REALLY liked MS. Other than that, I'm perfectly happy writing apps that sit on a user's machine and chug happily away by themselves.
So, yes, I was talking out of my arse. And despite many years of practice, I'm still not very good at it.
>>>>>>>> Kvort
-Don't mind me, I'm personality-deficient and mentally-impaired.
And it goes back to why dynamic, typeless, languages are used.
1) Instantaneous Feedback. With Perl, you edit the "document" (script), click reload, and see the effect immediately.
With C/C++, you edit, compile, relink, maybe even "restart the server" and if it crashes, it's debugger time. C/C++ sucks as a language for doing DatabaseText transformations ala Perl, Python, TCL, and 4GLs.
2) A syntax that freely intermixes HTML and script code.
What's better:
<tr><td>$firstname</td><td>$lastname</td></tr>
or
out << "<tr><td>" << firstname << "</td><td>" << lastname << "</td></tr>"
I would argue that a document that is mostly HTML, with some script fragments is far more editable and managable than a C/C++ source file that is mostly "printf" code with HTML interspersed. With some editors, you can even
edit the HTML containing Perl/ASP/Cold Fusion/JSP/Python code and see it mostly visually.
3) great for DatabaseText transformations.
Perl blows away C/C++ in processing strings, slicing and dicing arrays, and doing Hashtable tricks. Anything even remotely close in C/C++ requires a third party non-standard library, and a syntax which still isn't as compact.
The vast majority of CGI apps run DB queries and
convert the dataset to a text or HTML representation.
With scripting languages, it is much easier to perform the query, and write the template that dumps the output.
CGI apps are *NOT* dominated by CPU performance. The biggest bandwidth is memory and I/O. Except in rare cases, compiling a CGI won't get you as much performance as simply adding more ram, more threading, and more I/O bandwidth.
Why Perl? Should be "Why scripting" Answer? Fast, safe development, economical syntax, easy to debug, can blend with markup languages better.
Cold Fusion is yet another example of something tuned to do one thing (DB->HTML transformation).
The ability to simply "reload" to see you changes, even forced me to recode Java Servlets as JSP pages simply because my development speed was multiplied x 10.
To recap: 1) a development model that allows instanteous feedback (click reload)
2) The ability to deal with documents, and embed code, rather than the other way array.
3) superor handling of datatypes and more compact syntax.
The problem with scripting of course, is that it is brittle from a maintainance point of view. As a project gets larger, there is less code reuse, no way to verify usage of reused code (type checking), and a tendecy for developers to "cut-and-paste" code fragments in a slap-dash attempt to get something to work.
The performance bottleneck is bandwidth, not performance. Usually, it's the speed of someone's modem, or the crowded internet backbones that slow down a web-page's performance. Using a faster language isn't going to help that, so typically web-folk go for the easiest solution.
I've had people tell me this before. This assumption can be an illusion. While it's true that you are limited on a per connection basis in many cases, it's also true that the number of requests that can be processed at a given instant in time is also a bottleneck at that instant. So, if you expect to be processing large volumes of hits in a finite window, it's important to have an optimal solution. This point seems to be frequently ignored or forgotten. What does this mean? Well, assuming you have the bandwidth, let's say an optimal implementation can support 50r/s versus 30r/s (these are numbers pulled from my back pocket). Assuming these numbers, that means that you are able to respond to 60% more requests in a timely manner. This directly reflects quality of service. For some web sites, it's critical to keeping their customers happy. Another way of looking at it is that you can grow in volume 60% more before you have to upgrade hardware which can be realized as a cost savings. It's important to remember that this counter does not address the ease of implementation. Which, for some, is thee deciding factor.
I see what you are trying to get at but the point is that you *rarely* have the bandwidth yourself. Once you have maxed out your connection that's it. You can't go any faster by saving CPU cycles. Servers still have much more CPU power than bandwidth. The original poster's argument still holds true.
Another point I want to make is that things like DB speed can also have a big impact on DB centric CGIs. This reduces any gain from coding in a lower level language too.
You seemed to of ignored the primary focus of this thread and then reiterated my own point with a more specific example. I clearly stated that it was based on the assumption that bandwidth is available. I was specifically thinking of situations whereby, real work was being done via a web interface versus simply generating dynamic pages to paste the current date and time on it. In the event that the work being done is non-trivial, suddenly the CPU:bandwidth ratio changes significantly.
In short, it really doesn't matter if the work unit is DB centric or analyzing geographic data from memory mapped files. The point is, this is an area that tends to be ignored/forgotten, or simply overlooked in exchange for ease of implementation. This fact, usually ignores the best tool for the job.
I think that perl sucks. I did a quick poll here at the office and the only people that like Perl are People that do NOT come from a 'traditional' programming background. Typically a webmaster, sysadmin etc... These are people that need something quick and dirty.
The day they'll ask me to maintain PerlCode I'm quitting!
Hajo Monogamy: Belief so strong that millions of people end perfectly good relationships in order to start a new one.
If you are stuck maintaining Perl code, my advice is simple: "Read the Camel." You'll be surprised at how much easier it becomes once you do it.
Seastead this.
I am a professional web developer too and we do all our work in Perl/MySQL/etc. . I love going head-to-head with competitors suggesting ASP, Cold Fusion, Java servlets, yada yada yada. We blow them out of the water on price, features, and low maintenance costs. Now folks who do work in PHP can cause a few problems. Depends on the nature of the job.
We just finished writting a 3.5k line data acquisition system using Perl / CGI.pm / Apache / GNUplot for the Navy. The system acquired over 80 channels of temperature data over a RS-485 bus and allowed operators to monitor, display and archive data via a web interface. Writing this software in C++ or Java would have taken several times longer to deploy. For this application Perl was an excellent choice.
As someone mentioned above language choice is irrelevent to software quality.
"Look, if you get confused by C's string handling, then, yep, Perl is for you. But *IF* you can handle the power, 'C' is for you!"
This is funny. C provide a small basic set of string manipulation facilities. If you do any work with strings in C you tend to develop a set of personal string library functions.
Perl is for people who know when to select the right tool for the job.
It show by example - Why Perl.
Thank You
Perl is gentler on servers than C/C++ are. The require more computational power, plain and simple. It may not be much, but it is there. And when you have a server than is simultaneously serving up, say, 10,000 scripts, it can really add up.
--
Matt Singerman
Matt Singerman
http://matt.vegan.net/
While Perl is far better for parsing and regular expressions PHP3 is much nicer and closer to C than perl also it is a server side languague which makes it noticably faster and the database intergration is great compare it to the database intergration of Cold Fusion.
-
But I am not the only one that thinks that this is a great languague the estimated amount of servers using PHP should hit 1,000,000 this November which is a dramatic increase from the less than 80,000 when I started using it June 1998.
Conclusion: Don't stop using Perl but use PHP3 as well you will find them both usefull for different situations, if you visit dtheatre.com a good 20%+ of the first page is Perl generated and the rest is PHP3.
------------------------------------------
Movie News - "Entertainment news, bitch!"
Freshmeat does run on PHP3 as well as other sites such as Digital Theatre. Don't get me wrong I respect Larry Wall and all the perl team (and Randal L. Schwartz author of stuff I read :)) but....
-
While Perl is far better for parsing and regular expressions PHP3 is much nicer and closer to C than perl also it is a server side languague which makes it noticably faster and the database intergration is great compare it to the database intergration of Cold Fusion.
But I am not the only one that thinks that this is a great languague the estimated amount of servers using PHP should hit 1,000,000 this November which is a dramatic increase from the less than 80,000 when I started using it June 1998.
Conclusion: Don't stop using Perl but use PHP3 as well you will find them both usefull for different situations, if you visit dtheatre.com a good 20%+ of the first page is Perl generated and the rest is PHP3.
------------------------------------------
Movie News - "Entertainment news, bitch!"
I'm not a big fan of Perl, I actually use python most. Although Python is far from perfect I find that it is much easier to read and debug than Perl. It is also more powerful, IMO, in terms of graphics support and the ability to write large applications easily. My site eParka.com is written entirely in Python with only a bit of javascript....
-- Moondog
Take a look at http://www.zope.org/ for an examplei kler/perl.html
of what can be done with Python. Zope is a good example of a large scale project done it Python.
Python makes it easy to develop large, distributed
application projects on the Web. A paper titled
"What's wrong with Perl describes some of the flaws of Perl which will eventually cause it to
loose out to Python. http://www.stud.ifi.uio.no/~lmariusg/download/art
Calling the complexity of Perl a powerful feature
that makes it better than Python is like calling
a gasoline engine superior to a Jet engine because
it has more parts. Tools are best applied based
on how well the perform a function. Perl's initial advantage was the great regular expression capabilities it supported. This capability was
added to python in the re module. Some may say
the Python implementation is better because an
expression is a first class object in Python.
better example to give as a replacement for CGI.
I won't reproduct their documents here. Go to
http://www.zope.org/ for the details.
Very cool stuff can be done using Zope capabilities such as XML-RPC
CGI scripts are rarely written with a specific web server or a specific platform in mind. Compilable code, such as C, or C++, is so unportable, because of all these "extensions" OS and compiler vendors insist on providing, that you would end up with more #ifdef's than actual lines of usable code, to get the same portability.
Not true. The C code is perfectly portable, only the binaries aren't. Unlike Perl scripts I've come across which require Perl 5.xxx installed to run.
CGI scripts often need tweaking, even after deployment on a live server. For a script, you just go into the cgi-bin directory, edit, save and you're done. The changes are now live. For compiled code, you obviously need to throw in the compile & link time, too, which is non-trivial.
First, you should never change the live site directly. Preferably you should have Development, Staging and Live (but just the first and last if on a budget). You make the changes on the development server and then migrate the changes to live after proper QA. Compile and link time is trivial. It would take me nearly the same time to compile and link a 1,500 line 1MB cgi as it would for you to save your Perl file.
As others have said, string handling in C/C++ is virtually non-existant.
True in the generic sense. On the other hand this is what makes C/CGI so fast. You tend to write string handling optimised to the case in hand as opposed to using a generic string handling routine.
Scripts can be used by anyone, and the interpreter is typically not that big. Compiled code requires sufficient privilages and disk space to install the compiler & libraries, which can be gigantic, and may be directory-specific. (eg: ld.so.2 prefers /lib. Installing it in your home directory can prove entertaining.)
Scripts tend to contain more generic code since they are usually 'borrowed' in the first place. C programs tend to be more targetted which makes canibalising them more difficult
Given the choice, personally I would use C for CGI (using RCS or CVS for very careful source control) and Perl for knocking up one off data processing scripts (eg deduct 20 credits from everyone in the database that lives in France). In reality I'm looking forwards to the day servlet based sites aren't dog slow. Then I would shift to that technology.
Phillip.
Property for sale in Nice, France
Ok,it seams to me that his argument is compiled vs. interpreted. let's take a look at this:
C++ is a compiled, object-oriented language. While this is good for application programming (i stress APPLICATION, not systems), how often do you need OOP when doing CGI forms and stuff? Also, C++ has very high overhead compared to C or Perl, especialy if your not going to take advantage of the features in the base language.
Perl is an interpreted language, which is alot easier to code in than C or C++, and has a faster development time, and when you are dealing with development on the internet, which as we all know, evolves so much from day to day, the faster the development time, the better. Plus, the fact that Perl is faster to code in lets you change it alot faster. And true, while Perl is generaly thought of as a scripting language, what about the perlcc compiler? compile your Perl code, and it doesn't need to be interpreted every time it's accessed.
It seams to me that this guy just wants to be weird at the price of sacrifising the best tool for the job to the daemons of stupidity. must have NT at home...
bsDaemon
dfree@inna.net
Interesting: I do this for a living, writing Perl CGI scripts (on a Linux box, incidently).
There's much to be said about Perl. Its syntax is totally confusing, and the OO implementation is a laugh. C++ is truly elegant, compared to it. As a programming language, I prefer C/C++ over Perl.
However, for CGI scripts the story is somewhat different. Perl is excellent to write relatively small programs that work with text. And with HTTP and HTML, you only work with text and small programs. The CGI interface gives you parameters as name/value pairs, another strong point of Perl.
PHP is not an option either. The whole idea of HTML (and later, CSS) is to seperate content and layout. It's kinda silly to merge content and code. PHP is nice for the incidental webmaster who makes an extended MRTG site with it, but as soon as you work with professional designers who tend to move things around a bit, PHP no longer works.
As for C/C++, it's much more cumbersome to work with texts than it is with Perl. And I don't fancy writing CGI-scripts in (c)sh, tcl, expect or awk. (Emacs anyone?)
With the right libs from CPAN, you can work with template HTML files and CGI Perl scripts that fill these out. The designer makes with the templates, the programmer writes a scripts that does the filling out.
If speed is such an important issue, why the heck would you put it on the WWW anyway? I don't suppose many of us will be building number-crunching sites.
Well, just my 0.02 euro worth.
- Peter
Add Java stored procedures in Oracle 8i to Java Servlets, JSP and you have the most consistent and productive environment I can imagine. Then add Jakarta and Web Applications (WAR Files) and .. well, things are going to get interesting.
I don't know about any other web app developers, but I use Perl of it's ease of use and speed of development. Most of my jobs have rediculous dead lines imposed (mostly by people who don't know what they're doing anyway). I couldn't get them finished in anywhere near the deadline with C or C++. We did experiment with C++ Builder 3 and a group of VCL components called CGIExpert by Lars Åkerman, and they are generally very good. The only problem you run into is the size of the executables. On our web servers, the performance difference between the C++ Builder apps and the Perl Apps isn't great enough to warrant the extra time required for the edit, compile, test cycle. We are planning to implement PerlEx (we're running Netscape Enterprise Server 3.62 on winNT (not my choice!)), which should give us a nice boost in performance.
No matter where you go... there you are.
As a web developer, I've used both ASP-IIS and Perl/PHP-Apache and as much as you anti MS people would hate to hear it, IIS isn't really all that bad.
However, that does not make IIS better than Apache imho. A few of the things that bug me with IIS is the VBScript language (Face it people BASIC on any OS sucks). There isn't any STDOUT/STDERR basic handles, its almost impossible to begin doing low level server stuff w/o paying $150 for a seperate module which in the end is very very irritating to clients who wan to know why their paying an extra $400 for extra modules. I tell them its because their running IIS, use Apache on Solaris/Linux and it'd be much cheaper (and stable.)
But, I find that its much better to take everything with a grain of salt and move on, I need money to live so I'll work on whatever contract pays the highest, IIS, Apache, Java, Netscape, whatever -- If it pays well, then I'll do it.
But if it was up to me, then Apache/PHP Please : )
Why? Because Perl increases *my* efficiency. I can code faster, and the end result is shorter and easier to understand that code written in other languages. That's pretty important to me. And my customers are happier if I deliver ahead of time.
This is no accident. Perl was deliberately designed to achieve this. And it does, at least for me.
I have several other reasons to code in Perl:
- Your only limit is your knowledge.
- Everything is Open Source.
- Most of the hard work is already done and wrapped up in free modules written in Perl (with source).
- Perl regular expressions are a secret weapon that you can use to slain many ugly monster problems.
- Many nifty features are being added to Perl, without making it much bigger or slower.
- Is very portable (Microsoft gave money to enhance Perl in Windows).
- With Perl, it is easy to generate code in any other programming language.
The only problem: you need *lots* of practice to become a Perl master.For those interested, that long journey is more enjoyable if you understand the Perl culture (here it is, as explained by Larry Wall):
http://www.perl.com/pub/c onference/1997/wall/keynote.html
Let me quote a paragraph from that speech:
Finally, I believe that any language essentially should be out of control, because no one person or institution is capable of controlling a language (or a culture, for that matter) without destroying it. Living languages are always a cooperative effort, and I want Perl to be a living language.
I think that's another reason to use Perl: It's ALIVE.
One point for Perl: say you got a homepage at some ISP who lets you do CGI. You can't tell what machine he's using, so you need platform-independent stuff... so use Perl. (you might as well use shell scripts... - as long as the server is Unix :) )
But then again, if it's your own Linux box, why not use C? I did that myself, seems somewhat more secure to me...
Things change radically when using mod_perl. The thing really flies, and basically gets us rid of the "perl is too slow" argument.
If perl is too "slow" for you (because, granted, there's maybe too much of a chore to write a full perl program when all you want is a quick dump of a table), give PHP a try. This thing is impressive, it has great performance and I dont think I ever developed web applications faster than I do with PHP. Again, by the time you're finished firing up your ColdFusion or ASP fancy visual IDE, the average PHP dude will already be rolling out a working solution.
Perl isnt that bad in my view. The point is, that any of the Languages you named (C and Java) actually have the same problem.
When I started C programming I did exactly what those "Perl or Dummies" guys do in C. I wrote Spagetti Code without reasonable coments just to get it running somehow. After a while I had to rewrite all my code and I learned hard what a good coding style is.
Now I also do Perl programming, and acctually I can use it much like an interpreted C with some nice additional features. I know, that there are other ways to do that, but why use them? If I get code by someone who did Pascal or sh programming before I can figure out what he ment, if he did it propperly. Can you figure out uncommented newby spagetti code in C?
What Im trying to say is that most languages share that problem with Perl. Still Perl is a nice and easy way of writing code for typical CGI scripts as long as someone with experience is writing the code. If the code is written by an unexperienced newby any result in any language may be awful.
The real problem you are facing is that there are too many newbys around writing CGI scripts. They start by having seen Frontpage once in a shop and begin to write websites with it. Then they grow into a job and have to do something dynamically because the Big Boss whants to have a chat on the Homepage.
I suggest to welcome those guys as hopefully good programmers in future. We should take them by their hands ant leed them to good code.
Christof
The reason I use Perl for CGI (though I'm moving towards PHP) is because there are hundreds of modules that already have much of what I need in it. CPAN makes finding these modules easy, and I can install them in just a few minutes. Many of the CGI scripts I wrote tied together a Postgres database, Remedy server, some funky time functions, and CGI. There's a module for each of those. Make my code probably 1/2 the size it would otherwise.
-- Ever notice that fast-burning fuse looks exactly the same as slow-burning fuse? I didn't... (Edgar Montrose)
#!/usr/bin/perl -w
use strict;
Anyone that writes Perl code that will have to be maintained should have those two lines (or their analog) somewhere in their file. They will eliminate about 90% of your maintainability problems.
The above seems to be an admission that the language syntax does make a big difference as to how maintainable the code turns out to be, which was his original point.
(Sure, you can write easily maintainable code or spaghetti code in any language, but it's easier in some languages than others.)
- The 'development loop' = type ':w' in vi; click reload in browser.
- Power and expressiveness - once you've had a car with power windows, it's hard to go back to manual cranked windows. Grep (the function, not the program), Map, and regexps eliminate much of what I would have coded in C.
- CPAN: everything you need under one roof. And in my experience, the quality is uniformly high.
These are the anti-perl arguments which keep popping up:- "It's a mere scripting language."
- "Compiled code is faster"
- "Perl is OK for small things, but comes up short for big, object-oriented team-built apps."
Just my 2c worth. Perl is like abortion, gun control, and vi vs emacs. People will love or hate it for very personal reasons, and not switch because of something they read onInterpreted languages have generally been less powerful. People tend to imagine a correlation between the pain/complexity of the development cycle and the value of the resulting code. Microsoft especially seems to encourage this thinking with their glittery IDE. Richard Stallman first pointed out the problem of the "mere scripting language" mentality in his essay describing the genesis of EMACS.
As many have pointed out, bandwidth usually chokes a web server. But assuming you've eliminated the CGI process creation hurdle via mod_perl or equivalent, and that you're accessing a database to generate the pages, I think you're more likely to bottleneck in the database.
On my web server, the heavy lifting is done by Apache, mod_perl, and MySQL. The DBMS stores the data, which is why the Perl code is fairly small and doesn't have complex data types (other than those from used modules). When someone talks about object-oriented programming for the web, I tend to wonder if he understands the power of the DBMS.
As far as I can tell, ASP is a Microsoft (boo!) proprietary thing
ASP is not only proprietary (as near as makes no difference), but it's also not a competitor for Perl, as it isn't a scripting language. ASP is an environment to run scripting languages in, not a language itself. ASP is closer to doing what CGI does, than it is to being a scripting language.
ASP's most common scripting language is VBSCript, followed by JScript. Now both of these are (shall we say) less-than-optimal as languages, but they're fine as a thin glue layer between COM objects and HTML responses. If you _need_ much more processing here, then you ought to be fattening up the back end services, not trying to do it with a scripting language.
My web site's database smarts are built in the finest-crafted hand-tweaked low-level code money can buy -- I use SQL Server (or Oracle). Can anyone really say that for heavyweight back-end performance of a complex task, they'd favour a piece of a scripting language knocked up in a weekend, compared to a proper database engine which has had gazillions spent on it ?
Perl and ASP ? no problem - use PerlScript (or RexxScript) and you get all the session state management stuff from ASP that you don't get from CGI.
I love ASP - I just wish I didn't have to host on NT to get it.
Don't get me wrong, I love SlashDot as much as the next person, but what frustrates me about the majority of the posting that goes on here is the level of unfactual ranting.
Just because we are techno weinies doesn't give us credibility.
Really, what does three hundred posts on why product X is better than product Y really do when the people touting product X only know about product X and feel justified in down talking product Y without stated justification? Maybe my assumption that those people don't know about the product they bad mouth is premature, but when they only post about why product X is better do we really see anything different from them? All these kind of posts do is take up space.
If you want to contribute, how about some benchmarks and some information that shows that you are versed in both sides of the issue. We see the same thing with people saying how Windows programming sucks compared to Linux programming. Well how many of these people on either side of the debate have used both Extensively? These, in my opinion are the people who should be posting. Sorry to pick on you anonymous coward, but I'd had enough by the time I'd read your post.
If you are concerned about server load, programming CGI scripts in C or C++ is still the wrong way to go. You will need some system such as mod_perl, Fast_CGI, NSAPI, ISAPI or some other non-CGI solution. CGI is the problem, not perl.
Why is C/C++ the wrong way to go? Why mod_perl? Why is CGI the problem? I could just as easily go ranting about how Visual Basic is just as credible and usable, and then continue with why its not CGI, its the TCP/IP Suite. These words are flash factor when not qualified and they don't really mean anything.
p.s. I do know what they mean, just trying to make a point. Random Task
"I can hoist a Jack. I can lay a track. I can pick and shovel too. I'll do anything you hire me to." - John Cash "Legen
If you meet a lot of html/website types you'll notice that a scripting language, such as perl, makes far mor sense to them than anything that is compiled. I'm serious! I guess that is just what happens when you are forced write in a clunky markup language for long periods of time.
If I need to do anything complex, I'll write it in C. Usually, for me, this involves calling a C program from Perl, but I have no moral objection to using C++ if I really need that level of performance.
(I do exactly the same thing with Java; if I need a quick graphical widgety app or applet, Java is the way to go. If I'm trying to perform image deconvolution as fast as possible, it's back to C or even Fortran....)
I suppose that there is some danger in allowing Perl to become so much of a standard that everyone automatically uses it for CGI scripts regardless of the speed required. But I have difficulty imagining a CGI script that really requires the type of heavy-duty information processing that Perl is not good at. Mostly, Perl just calls library routines to do the heavy work, and those can be just as fast as any compiled language.
Well, you all have comented about why not C/C++, since C/C++ will result in faster ( and more reliable?) code?
One of the first points to argue is: What are your needs?
You see, Perl is perfect for small needs. I know many experienced people have developed many things in Perl, but I don't think Perl's structure would fit a larger project, but it has a wonderfull string manipulation capacity, and yes, RegEx. Also to add to this, Perl runs on many systems as a Interpreted language, so, the same code will run almost equaly in many cases on many OSs, from NT to Linux ( includding Netware - and if Netware has Perl support, I wonder if my HP48 wouldn't). Then, if Perl is such a wonderland, present everywhere in the net, why do we still think of C++ and Java? And yes, Lua? First of all, as I mentioned, Perl is perfect for small needs. It can solve particular problems and an experienced programer can, in no time, write a small CGI to do a particular feat. But I found out it's troublesome to work with Perl in larger systems with larger teams. Managing a project done entirelly in Perl is a cumbersome activit.
So, even if Perl is nice and easy to learn, and in no time you can do your own CGI in Perl, I try to keep in mind you will want to switch to C/C++, Lua or Java if you have an experienced team in a bigger project. Mostly, mixing Java Servlets and C++ native code for really intensive operations. Or even switching to PHP or ASP if you are in lead of a novice team, not much experienced in programing, wich I discovered these can be trained easilly to use PHP and ASP, but not that easilly in Java or Lua.
So, in a few words, they all have their places in the world. If Perl is present everywhere, it's due to it's qualities, but Perl isn't suitable for larger, more complex projects, and that's when C/C++, Java and Lua are allways present. Perl is everywhere simple solutions are needed, but with the growth of the web as a work enviroment, and the popularization of thin clients working with browsers, you will see a spread in the use of Java, C++ and other options.
Hope I didn't bore you with my speech. Perl is not hell on earth as a programing language, even if I allways felt it lacks some structure. But it has a place and suits perfectly some needs.
See you all...
When measuring efficiency, you have to look at the server, network latency, and even the speed at which the browser can parse your page. (I have a cgi-script that will generate 2000+ rows in a table in a couple of seconds, but the browser takes 30+ seconds to let me look at the table)
Does it really matter if a c++ executable can run the same query in 1.5 seconds instead of 2 seconds if it takes 30 seconds for the brower to show the page?
Accessing a database in perl/java is much easier than using the c api. (I don't know if there are nice c++ api's for databases yet, but doing dynamic SQL in c is 1000x more difficult than anything else I've seen) With so many developers wanting to store large amounts of text/information in a database, you want to be able to get at that data the most efficient way possible.
A few years ago I took on a new project and resolved to write the fastest CGI app I could, using C to access the Solid DB API. Forget Perl and its fuzzy crutches, efficiency is what counts, right?
Yes, it was extremely fast, until the graphic designer plopped in his nested-table layout and slowed everything down to a crawl on the client's ancient Mac. That's when I learned that server efficiency is but one of the factors that go into a web app. If you are serving very fast clients on a very fast network, then you should consider optimizing the server apps. But even then mod_perl, PHP, or ASP still stand a fighting chance against a C/C++ CGI.
The fastest path I can imagine is using the web server's API directly, and that should be done only after careful planning and consideration (and throwing hardware at the problem).
Perl is amazingly portable, without having to recompile. This is more important than anything else.
Additionally, its readable in executable form, you dont have to dig out the source should you wish to change anything.
-Yarn - Rio Karma: Excellent
Personally, I think the primary reason why Perl is used so often for CGI is because of it's text manipulating abilities. It seems a lot of the CGI out there today has to work with text, forms, HTML, etc.
Now that's not to say there aren't libraries out there for C/C++ which provide similar levels of power for text manipulation, but by default when doing things like parsing text, you will tend to be working on a much lower level than perl.
Now there is a question of optimization. You can do some things to Perl to make it run faster using mod_perl or FastCGI, but they have limitations. Mod_perl unfortunately has no concept of suexec so it's not real ISP friendly. FastCGI requires code modifications which make it a bit undesirable.
The overhead of starting a copy of perl and parsing the perl script every pass will take a real toll on your machine if you can't use mod_perl or FastCGI. You could even 'daemonize' your perl CGI to boost performance, but that adds quite a bit of complexity for simple tasks.
In these instances, it would be wise to use C, C++ or ObjC.. or even Java w/ the new Java compiler. If you have a banner ad rotation script or some other little program which gets called a lot, writing it in one of these languages will not be much more complex than writing it in Perl.
Really, unless you are doing a lot of text processing, C, C++ and ObjC aren't all that much more complex than Perl and I would recommend using them in place of perl.
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
I know a lot of people that think C is too lax. Only one way to do something? Are you kidding me? while() vs for() vs until(). Arrays vs. pointer manip. Pointers alone can cause severe headaches if not used properly. Want more examples of problems with C and readability? It is only recently that basic C standards have been widespread that C has become more readable. Java is slightly better in that it is strongly typed, otherwise it mimics C to a great extent.
I could show you some C code that is still in use that uses the K&R style of C. And I've had other programmers ask me why the params were not in the parens of the function name.
Ok, I love C. I love Java. I love Perl. Each has it's good points and bad points. Each can be used to write horrible horrible code, or very elegant pretty code. You hit the nail on the head saying that it is the programmer's fault and inexperience. Also the people that hired them. Perl can be maintainable with some standards. C can be very ugly and unwieldy without them. Granted Perl is the most flexible, but since we as an industry moved away from languages that have a forced structure there has always been a problem with maintainability. And it has been up to the shop to enforce some types of standards.
--
?
And which is a reason why it might be preferable to use a language like Lisp that can compile to machine code, thereby providing the best of both worlds:
If you're not part of the solution, you're part of the precipitate.
Unfortunately, you lose some abilities:
With web applications, what you're largely manipulating is text, which means that having the language oriented to that is extremely valuable. Furthermore, since there are powerful, well-optimized operators built-in to these languages, the interpreter disadvantage is significantly diminished.
If you're not part of the solution, you're part of the precipitate.
It's entertaining that nobody has brought up Java, The Language of The Internet, as an option... for a while, that was all anyone could think of.
If you're not part of the solution, you're part of the precipitate.
Are you meaning that Perl scripts have a higher overhead? If this is the case, mod_perl takes care of alot of those concerns, where the perl script itself is actually executed from memory, and not simply loaded from disk. This would be the equivilent of not only programming it all in C/C++, but building it in as an Apache module. I WOULD, however, like to see a writeup comparing the overall processing, etc, of a native C based CGI program, vurses that of an equivilent program in Perl, with AND without mod_perl..
-- I'm the root of all that's evil, but you can call me cookie..
I like perl, but I have to take issue with just about everything you said.
Interpreted languages (like Perl and Python) make it easier to develop things in a hurry because you can make changes without re-compiling.If you spend a majority of your time on a project waiting for it to compile rather than writing code, you either have a really slow processor or a really small project. A much more relevant measure of rapid development is how quickly people can make the project work. If one person is working on a project, and can write perl code efficiently, that's great. Perl does not especially promote code readability. If a larger group of people is working on a project and they spend a large amount of time just figuring out how each other's code works, that's a problem. C does promote code readability which may be desired in such cases.
The performance bottleneck is bandwidth, not performance. Usually, it's the speed of someone's modem, or the crowded internet backbones that slow down a web-page's performance.Or not. It depends enitrely on the application. If it's a big database intensive project, performance could easily be the bottleneck. Look at, say, slashdot. Slashdot runs on several machines and the load is still huge. When I read slashdot from school it's painfully obvious that it's the database which is slow, not the bandwidth. I don't have to explain to you that it's an issue of both latency and throughput. The program is latent and the page download is throughput, and most of the server-side processing has to be finished before the bandwidth-intensive moving can even begin. If you're making a cgi project which will run on a quad-athlon, and only have several modem users (you WISH you were so lucky), sure, the speed of the language isn't going to make a difference. If you have to buy nice hardware that just raises the price of the project.
I'm not a smorgasbord.
Having said all that, I wrote a simple CGI text database search engine in C, and it works just fine. Not one line of Perl in it, compiled code all the way. I had the benefit of knowing something about the machine it was to be installed on, so I didn't run into a lot of the roadblocks that I've outlined above. But most people, for most CGI scripts, won't.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Because you have to fork a process, that's why.
The time to execute a CGI isn't just the runtime of the program. It's time to run PLUS setup/teardown costs. In a CGI context, this means forking a process, which is an expensive operation even in Unix.
If processing time is a serious concern, then you should be using some built-in web server mechanism for processing - mod_perl, PHP, Java servlets, or even a multithreaded server rather than Apache (AOLServer, or even IIS (although NT will find other ways to screw your performance)).
And then there is reliance on external resources. For example, many web servers are actually selecting from a relational database. Your "efficient" C/C++ program can't easily share a connection, so it will have to start up and tear down yet another connection to your RDBMS. VERY expensive. Compare this to a multithreaded server that pools database connections and doesn't have to fork anything to share them out. See where the performance goes?
Remember, 90% of the time, the performance bottlenecks are not where you think they are. And they are rarely in well-written code, regardless of the language used to write it. Bottlenecks tend to be in things like disk and network I/O, RDBMS engines, excessive swapping, excessive forking, and other infrastructure issues.
Meditate on this, grasshopper, and learn.
---
Maybe that's just the price you pay for the chains that you refuse.
Hand me that airplane glue and I'll tell you another story.
This archive runs on an ancient RS/6000, about the processor equivalent of a 486/66. And it doesn't have much memory, either.
I wrote the entire engine and interface in highly-tuned C++. Because of the requirements of the search, it must go through every single file's entry in the archive (or at least under the topmost directory specified). I made extensive use of the nature of UNIX filesystems for the actual database (each directory has a file index called .file.idx, and builds a recursive search index called .search.idx which contains the current directory and all search indices of lower directories). If I had done things a bit more intelligently I could have probably kept a single .search.idx cached in memory instead of having to reload it on every search (which is painful, since the toplevel directory's .search.idx is something like 2 megs now), but the fact remains that it still goes relatively quickly, particularly considering the nature of the search and the antiquity of the machine it's running on.
I had briefly considered PERL, but I quickly shot that idea down for several ideas:
1. I had initially prototyped an earlier version of the search engine in csh using grep. (This was before I wrote the new database engine; the old, flaky, always-dying-and-losing-whole-file-databases one made it so one basically had to just parse the 00index.txt files anyway.) The average search took well over 3 minutes. Completely unacceptable. Granted, csh isn't the fastest thing around, but the script wasn't using anything which PERL could have done better (it was just iterating through a bunch of files and running grep on them).
Mind you, the C++ I used was incredibly low-level. I used it basically as C with objects; no STL, no inheritance, etc., because I didn't need them, and didn't want the overhead (though in hindsight, if I had used an STL vector instead of rolling my own dynamic arrays it would have been the same speed and involve a lot less bugfixes).
But basically, what I learned from the example of the csh search engine: Parsing text databases slow. Parsing binary databases fast.
Which reminds me, I still need to ask Dave Rocks (my boss at NMSU) if I can GPL the engine source. I'm sure it'll do someone else some good; not everyone out there wanting to run a file archive engine can afford the overhead of SQL. Hobbes had plenty of bandwidth for its purposes (10Mbit) but 32 megs of RAM and an ancient RS/6000 just aren't enough for anything SQL-based...
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
I've been making my living with Perl and CGI for almost three years. That's an eternity in Web-time, so I guess I'm qualified to comment on a few things.
/much/ shorter. If Fred Brooks is right (the number of lines of code a programmer can produce in a year is approximately constant, regardless of language), this is a big one. Things that might take thousands of lines in C are only a few hundred lines of Perl.
First, the question of 'Perl vs. C' isn't as simple as picking your favorite language. Remember that software engineering is as much a resource juggling act as anything else. The resources in this case are most often CPU time, your time, and your customer's time.
Ways Perl saves your (programming) time:
1) The huge library of utterly standard software on CPAN. If you feel you are re-inventing the wheel, sifting through CPAN for an hour or so will usually turn up a well-supported module that solves the problem. CGI.pm started life this way; now it ships with every new version of Perl since 5.003.
2) Programs are
3) It will likely run anywhere, on NT or Linux or OS/2 or whatever. Perl has come much closer to the ideal of platform independance than Java just because it's out there in use and solves the problem one disaster at a time, not with over-designing and hard sells.
4) It's nice to have taint-checking built in. This is not something I have ever observed in C. I almost never use eval, but this can save you a lot of security breaks. Perl itself also does not rely on static buffer lengths for user code, and so you don't get those nasty buffer overruns. Oh, sure, you can write C so that it doesn't have buffer overruns - but in Perl this power is automatic.
Ways Perl can save your customer and CPU time:
5) Perl (and also PHP3, and even ASP) all have the advantage of super-fast support inside the web server via an extension module. This avoids the problem of forking off a new CGI program, loading Perl, loading the Perl program, interpreting, etc. Let me tell you from personal experience - the difference is night and day. For anything that gets more than a few hits a day, DON'T use straight CGI. Use mod_perl, FastCGI, or whatever. This also saves you server bloat, because that interpreter and program are shared by ALL CGI calls on the server.
6) For the things that Perl is good at (string handling), it's not going to be slower than C. Think of Perl as the 'glue logic' and the C libraries under Perl as the things that actually do the processing. Fortunately for you, a large part of every WWW app is string handling - even just reading the parameters from the user's Post or Get. You'd end up implementing half of Perl's string handling functions anyway just to do this part in C.
7) For the things where Perl is legitimately slower than straight C, it is possible to extend Perl in C. This lets you use C for your math-heavy library, a new fundamental data type (like matrices or complex numbers), or want to call a system library like Motif, Tk, or libcrypt.
8) Shorter programs are easier to change when the customer decides that they want to do something else. Since it is almost impossible to get a good spec out of a customer, it is much better to have a short prototyping cycle. The prototyping circle in Perl is much shorter than C, so you can get more feedback from the customer in less time. This increases the probability the customer will like the finished product. You can still do it in C for the final step if you feel you must.
And now the bad news.
Perl's power of expression is also its problem. There are so many different ways to do things, and many of them are very, very ugly. Badly written Perl is the worst thing in the world to maintain - OK, maybe not quite as bad as badly-written TCL, but pretty bad.
Perl will tolerate sloppiness. It takes some time to get competent enough with Perl that you don't need the sloppiness to make things happen. Experienced Perl people should be able to read each other's code; it's the bloody amateurs (eg almost everybody) that you have to watch out for.
As a result, it's very easy to have 'write-only' Perl code. If it becomes necessary to maintain it... well, time to start over.
This is really the only bad news, however. So it's basically 'pick your poison'. Do you want to get bit in maintainence, or in any of the half-dozen other ways that Perl saves you time? No language is going to be perfect, and this is the trade-off you make in Perl.
Therefore, Perl is much more suitable for me because it lets me get the project finished to the customer's satisfaction in less time. You can easily document it all (and minimize the maintainence hit) while the site is up and making money - as opposed to having the customer on the phone screaming at you that the project is late.
In the end, you have to choose for yourself. Decide if you have the time to get good at unravelling spaghetti Perl, or if you'd rather spend your time debugging spaghetti C.
Like he says, there's a lot of text processing in CGI prorgams. How would you handle a standard regular expression in C or C++? -- you'd call a subroutine. Once Perl gets into its regular expression subroutine, it's running C itself, not interpreted Perl, so there is no speed difference. Same with a lot of other Perl code -- hashes? You'd just be calling subroutines in C to generate keys and manipulate the hashes. String manipulation? People who use strcpy and strcat are probably writing slower code than Perl has built in, because it tracks the length of strings, and allocates in chunks, so it doesn't need as much realloc as some lazy C coders write.
There is more memory overhead, and there is the compilation overhead, but using mod_perl helps bunches here.
--
Infuriate left and right
Q: If Perl's so hot, why hasn't it been ported to the PalmOS?
A: Because it's a resource hog.
I've had people tell me this before. This assumption can be an illusion. While it's true that you are limited on a per connection basis in many cases, it's also true that the number of requests that can be processed at a given instant in time is also a bottleneck at that instant.
This cant be stressed enough. I used to run a webserver with about 1000 virtual hosts, about a hundred or so of those which were high traffic, complex, sites that were big moneymakers for us and the respective customers. A badly written CGI essentially would kill performance for ALL servers on that machine so we were very in tune with what our boxes could do at any given time, and when it came down to it, it was NOT bandwidth defining the performance of the servers. They were slow becasue of poorly written or badly implemented CGI's. They did not discriminate against languages either. Bad code in C is just as slow as bad code in Perl or bad code in TCL or bad code in sh.
-Rich
I read some comment from web guru Philip Greenspun that claimed Yahoo Stores' backend code was written in Common Lisp. Just a fun bit of trivia. :-)
cpeterso
We generally had two browser choices: Lynx or Mosaic for Motif. Most of us ended up downloading and compiling the browser ourselves. Sometimes we had to hack the code to make it compile under SCO. Typically we were the system administrators and we wrote a lot of Perl anyway.
So when we needed to choose a CGI language, perl was obvious. of course back then, we weren't doing transaction processing on our web sites we were writing phone lookups and simple query screens, but perl was it.
Then others started to get onto the web, and they asked us what we used to write CGI. We said "perl", so the learned perl.
Now it's 1999, we're so far removed from the time when there was a registered servers list at NCSA and there were only 1500 servers registered.
Webmaster, and web developer are full-fledged job titles, not just more cool stuff your system administrator knows how to do.
Perl for CGI came from the early adopters of WWW who were already using perl for their other tasks.
My Heart Is A Flower
Between the time to develop, the bandwidth constraints, and the library functions you'd have to do some very specific profiling to show a C++ or C programming significantly out performing a perl script for typical CGI applications and a lot of that can probably be offset by the fact that you can embed python and perl interpreters into apache which cuts the startup time for your scripts (by as much as 1000% in some cases, or so I've heard) since they don't have to spawn an interpreter and start it up.
Say that the C++ program was twice as fast (probably not, but assuming it was) how many hits would you have to get to saturate enough of your server capacity to justify porting your perl to C++? Processors are remarkably cheap compared to bandwidth anymore. Maybe if you run yahoo or infoseek or something it is justified to code all your CGIs in C or C++ but I think the typical web server can easily get away with perl or python.
This is my signature. There are many signatures like it but this one is mine..
Unless you have a unusual web-based application, you are much better spending the time optimizing the architecture than the implementation language. CGIs take such a fraction of time, assuming you're not doing something silly, that even if they're dog slow they'll still flood your network.
The the web means most of the time is spend handshaking and transmitting. Try to eliminate those as much as possible, because they're even more critical for people on a modem. For those same people, a script that takes 2 seconds to run loads as fast as a 4KB GIF.
I believe you should use the highest level language possible that will let still execute quickly enough. Perl is used because it is fairly high-level while still executing quickly enough.
Higher level languages are usually more maintainable and make for easier implementation. This is almost always vastly more important than how fast the program executes.
Invest the extra time you get buy using a higher level language, like Perl or Python, into coming up with an efficient architecture. It'll pay off in a big way.
But it makes sacrifices. You can't beat C/C++ and assembler for having the ability to do things the way you want them done. For one project, an automated reasoner, the code was designed down to a bitwise memory manager. This simply wouldn't be possible in Perl. But we did make a web interface to the automated reasoner using Perl, thus decreasing our overall cost, in terms of development time and effort. And in particular, frustration. We also modularize the project into Perl and C/C++ parts, making debugging, documentation, and reviewing (and reuse) much better.
The best part about Perl was the documentation -- O'Reilly's books by Larry Wall et al., was superb. We bought the two books they publish (the "Cookbook", and the "Programming" guide), and were sufficently versed in the language and architecture of the interpreter to make robust, straight forward, and complex manipulation programs. Not very good for an automated reasoner (it'd probably take longer than the end of the universe to prove pigeon hole), but great for converting output between syntatical equivalents and testing validity (relatively trivial compared to generating a proof).
I think every language has it's place. I'm keen on the diagonal languages (C/C++, Perl, etc.), rather than the orthogonal languages (Python, Java, etc.). The diagonal languages let you do things in many equally correct interpretations, whereas the orthogonal reflect single best interpretations. Perl is the living epitemy of a diagonal language, which is part of it's beauty, and one of the reasons I like it so much, but diagonal languages are more difficult to understand the second time you try and work on it. :)
Like everything, there's reason to choose one language over another, and like everything in the real world surrounding choice, there's no perfect solution. Even COBOL has it's place.
But it makes sacrifices. You can't beat C/C++ and assembler for having the ability to do things the way you want them done. For one project, an automated reasoner, the code was designed down to a bitwise memory manager. This simply wouldn't be possible in Perl. But we did make a web interface to the automated reasoner using Perl, thus decreasing our overall cost, in terms of development time and effort. And in particular, frustration. We also modularize the project into Perl and C/C++ parts, making debugging, documentation, and reviewing (and reuse) much better.
The best part about Perl was the documentation -- O'Reilly's books by Larry Wall et al., was superb. We bought the two books they publish (the "Cookbook", and the "Programming" guide), and were sufficently versed in the language and architecture of the interpreter to make robust, straight forward, and complex manipulation programs. Not very good for an automated reasoner (it'd probably take longer than the end of the universe to prove pigeon hole), but great for converting output between syntatical equivalents and testing validity (relatively trivial compared to generating a proof).
I think every language has it's place. I'm keen on the diagonal languages (C/C++, Perl, etc.), rather than the orthogonal languages (Python, Java, etc.). The diagonal languages let you do things in many equally correct interpretations, whereas the orthogonal reflect single best interpretations. Perl is the living epitemy of a diagonal language, which is part of it's beauty, and one of the reasons I like it so much, but diagonal languages are more difficult to understand the second time you try and work on it. :)
Like everything, there's reason to choose one language over another, and like everything in the real world surrounding choice, there's no perfect solution. Even COBOL has it's place.
According to the Apache Module Report at E-Soft Inc, PHP is more widespread than Perl as an Apache Module. These figures at www.php.net might be interesting as well...
/cj
I'm surprised nobody has mentioned taint mode.
If your script is running with an assumed user id because of a setuid bit, Perl will prevent the script from calling certain system facilities (notably the shell) with any values which are derived from the cgi's parameters directly or indirectly. There are some loopholes, but by in large this makes it tougher to monkey around with a cgi, espcially if you don't know its internal structure.
This alone is probably worth the price of admission.
My own limited experience with monkeying around with a few different scripting options is that it's just plain faster to get things done in perl. Partly this is the language, and partly this is because there are so many tools for the language that are widely known and well thought out (cgi.pm etc.).
Perl does certain very commonly useful things like pattern matching and hashing very quickly. In terms of runtime speed, once you factor in other kinds of overhead, I don't think most people would get much speed improvement from C++, and that only after a lot of effort. Of course, there are undoubtedly lots of exceptions to this.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
If you spend a majority of your time on a project waiting for it to compile rather than writing code, you either have a really slow processor or a really small project.
I just compiled GNOME from scratch, including glib, gtk+, ORBIt, all of the other support libraries, GIMP and a number of other applications. It took all morning and some of the afternoon. I have a six-month-old machine with 64MB of RAM. Would you care to re-think that statement?
And it goes back to why dynamic, typeless, languages are used.
1) Instantaneous Feedback. With Perl, you edit the "document" (script), click reload, and see the effect immediately.
With C/C++, you edit, compile, relink, maybe even "restart the server" and if it crashes, it's debugger time. C/C++ sucks as a language for doing DatabaseText transformations ala Perl, Python, TCL, and 4GLs.
2) A syntax that freely intermixes HTML and script code.
What's better:
$firstname$lastname
or
out " " "
I would argue that a document that is mostly HTML, with some script fragments is far more editable and managable than a C++ source file that is mostly "printf" code with HTML interspersed.
3) great for DatabaseText transformations.
Perl blows away C/C++ in processing strings, slicing and dicing arrays, and doing Hashtable tricks. Anything even remotely close in C++ requires a third party non-standard library, and a syntax which still isn't as compact.
The vast majority of CGI apps run DB queries and
convert the dataset to a text or HTML representation.
With scripting languages, it is much easier to perform the query, and write the template that dumps the output.
CGI apps are *NOT* dominated by CPU performance. The biggest bandwidth is memory and I/O. Except in rare cases, compiling a CGI won't get you as much performance as simply adding more ram, more threading, and more I/O bandwidth.
Why Perl? Should be "Why scripting" Answer? Fast, safe development, economical syntax, easy to debug, can blend with markup languages better.
Cold Fusion is yet another example of something tuned to do one thing (DB->HTML transformation).
The ability to simply "reload" to see you changes, even forced me to recode Java Servlets as JSP pages simply because my development speed was multiplied x 10.
One thing to consider is that CGI scripts impose a large delay in processing just because they have to fork off a process. Whether you use C or Perl may not matter if the time to invoke the script is significantly longer than the actual processing time. Perl is easier to use and faster for development (as mentioned by others), so it's better than C for scripting. Also, Perl is interpreted (rather than compiled), so bug fizes and patches are far easier to deploy. btw, you ca improve performance by abandoning CGI scripts altogether and looking at processes that use web-server threads (check out Philip and Alex's Guide to Web Publishing for info).
While I sympathize with your problems with spaghetti code, and I agree that obfuscation is laughably easy in Perl, I think your criticism is misplaced here.
Perl is a tool, and like all tools can be misused. Specifically, Perl is a powerful tool, and so it can be really misused. :)
I spend most of my working day writing Foxpro code, and if you think Perl is bad for spaghetti code, try maintaining old foxbase code. The language is huge, and old, and has at least two distinct ways of doing things. Plus, older versions of the language were weak on parameter passing, causing older code to look like one long rat's nest of case and while statements, instead of using functions.
However, the only real problem is as always, when comments are LEFT OUT. FoxPro is a powerful data manipulation language, and like Perl, has its place in the tool box, and can be cryptic, but clear code can be written if the programmer a)knows what they are doing, and b)takes the time to let the future code reading programmer know what they were doing with comments.
Don't blame Larry for creating a powerful tool just because the world has an "everyone can be a programmer" mentality right now, and Perl (and ahem all the M$ languages) is one of the languages being touted as such.
Packers (see the Progammer's Stone articles here at /.) write bad code, language independantly. Perl can and is used correctly, and can be commented. Most people just don't bother. A lot of people have the idea that it is somehow more "elite" to write difficult to read code. A professional programmer knows that efficiency while desirable, is overshadowed by maintainability, because you lose money when you have to spend 4 hours figuring out what 100 lines of code does.
As for cutting and pasting code from a book, that will get you in trouble in ANY language. Progamming is not about cook book solutions, but problem domain definition, and problem solving.
To sum, If a person is writing bad code, blame the person, not the tool.
We are agents of the free
Try some (or all) of the following-
1. #!/usr/bin/perl -w
2. learn the funky stuff- it exists for a reason.
3. use strict;
4. don't hire dummies, demand examples of their code.
5. #!/usr/bin/perl -w
use strict;
6. always define your needs up front and work out your algorithms on paper before coding.
7. #!/usr/bin/perl -w
use strict;
use diagnostics;
this seems like a bit of a silly question to me. i've used both Perl and C (or C++) in my CGIs, but it entirely depends on what you're trying to implement.
Perl is phenomenal at working with text, and it's dead easy to write. you don't have to worry about what type of information is stored in your variables (strings, ints, etc) and Perl does the conversions for you if you need to work with variables of different types. CGIs, historically, did a lot of work with text -- inputing forms, searching text files and dynamically creating HTML.
if you're working on a huge, complex CGI that would be highly speed dependant and necessary to thousands of users, then use C. if not, use Perl (or whatever else fits your program best). in the past, CGI scripts were (generally) simple routines for very specific tasks. as they become more complex, Perl may not be the best answer.
it's a simple case of the best tool for the job. use whatever language works best for you.
- j
--
"The only guys who might buy [the Apple iBook] are the kind who wear those ludicrous baggy pants with the built-in rope that's used for a belt. - John C. Dvorak, PC Magazine
Perl people take pains to point out that Perl is not a CGI language. It is a language. It is weak in areas such as GUI development, but for networking, database work, or many other things it is a good, solid application development language.
It is no longer, IMHO, the best web development language - if all you are doing is web development, PHP will probably serve you better. The reason people are using Perl, is because the same skill set can be applied in so many places. Since starting work at COLT (EU telco/ISP) I have used Perl for:
1. A few one liners to sort out a messy archive of documents left on a machine
2. Automated admin of Security Dynamics ACE server (a one time password system)
3. Writing an idiot-proof menu driven program for updating ipfilter rules on Solaris boxen
4. Writing an interface so that Veritas Netbackup logs are written to a database.
5. Writing a NOCOL client to alert if an Oracle database goes down for some reason.
Perl is simply a good language for doing these kinds of tasks and many others. Those familiar with Netcraft may be interested to know that their survey software, which polls 99.x% of every web server on the web _every month_ is written in Perl (Highly modified version of LWP). Not a lightweight app.
Goldman Sachs use Perl extensively to manage their mission critical databases.
Perl may be a good CGI language, but it is more intersting, and provides greater benefits when used as an application language.
-----
While I imagine equally optimized code would find
this claim perfectly true, Perl gives you a lot
of optimization for free, optimization that's
hard to do in C. Things like hashing and
good string support are not inherent in C, and
many developers would just use C-strings as-is
and linear associative arrays, and in the case
of strings need to write quite complicated things
to do good text manipulation, things that very
often are slower than Perl's internal string
implementation (and often buggy too). So...
Yes, Perl has added compile time and interpretive
penalties, but often the better algorithms that
you end up writing in Perl will end up faster
than in C, and so there are many times Perl will
turn out much faster unless you're really taking
a lot of time to optimize your C.
For every problem, there is at least one solution that is simple, neat, and wrong.
The -w line turns on optional run-time warnings. That is not a change in syntax, it is like adding a lot of debugging code all over the place. It does not change the syntax
/g match is not something that is widely known, but if you have to take parsing to the next level it is utterly invaluable!
Using strict does change the syntax - it turns off the really flexible "Guess What I Mean" features. Yes, Perl has a lot of those. Yes, they are dangerous. They are fine in short scripts, but not in long ones.
However when 2000 line C programs turn into 75 line Perl programs, maintainability is assisted. Overly verbose syntax, and overly low-level syntax, both are the cause of much grief. There is a trade-off, and for what I do Perl gets it right.
And yes, explore some odd corners. Looping over a
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Although many people point to the ease of writing Perl as the primary reason it is on top for CGI programming, there are many other reasons. I would imagine that topping this list is the fact that more people know and use Perl regularly than most other languages, since it is such a flexible and portable language; when people start writing CGI scripts, Perl is a natural for them.
Perl has tons of freely available libraries and modules that encapsulate almost every bit of functionality that you could ever want. Anything that takes more than a few lines of code has probably been done and encapsulated before. You just need to get it (CPAN).
Perl is a very expressive language, more so than most other languages I've seen or used. Because of this, people get very attached to Perl and what it can do.
Perl has better support for regular expressions, parsing, and string manipulation than any other language or tool in existance. This becomes extrememly important when converting data on the fly, from text files, other formats (such as XML), from databases, or from any other thing you can think of. Grabbing raw data and parameters from the URLs and from POSTed scripts is easier in Perl than in most other languages, due to this support.
What people usually bring up as downside to using Perl as a CGI language are not specific to Perl, they're specific to CGI. "Perl is a huge executable," they say, "and it is expensive to run a Perl script." But most of the overhead comes from the webserver forking a process, not from Perl itself. Yes, Perl scripts can become bogged down with tons of modules and libraries, but so can any language that has the capability to use libraries. As far as being a huge executable, take a look at the binaries produced by some of the Microsoft Web solutions (ahem, VB, ahem) and we'll talk about huge executables. The Tcl binary is about the same size as the Perl binary, and many complex C programs end up being very large also, once you incorporate regex parsing routines, CGI libraries, and image processing libraries.
darren
(darren)
Most of the work in a CGI script consists of reading in template HTML files, substituting a few variables in them, and writing out the results. More complex work may involve a few more sophisticated text substitutions, a bit of database access, and perhaps traversing a few internal data structures as well. In all these cases, the work is being done inside library functions rather than in your code: when you call printf() or look something up in a hashtable, the performance is controlled by the implementation of that library function, rather than any code that you wrote yourself.
:-)
:-)
As your calculations become more sophisticated, the balance shifts. If you are writing a CGI for generating fractal images or raytracing a 3d model, Perl would indeed be a stupid option (and in fact this is when you might even find C to be too highlevel, and prefer to start twiddling those bits around in asm). But if you profile something like the comments.pl that generated this page, I suspect you will find that only a tiny percentage of the time is being spent executing the loops and conditionals written by Mr. Malda, and the vast majority inside the I/O routines, string handling, hash lookups, and regexp functions, that were written (in C) by Mr. Wall
Also, higher level languages decrease development speed and make things easier to tweak. Since websites tend to be in continual development, and new features are required on internet time, this is a major win. In conventional application software it may be a useful tradeoff to spend an extra week coding in order to double your execution speed, but if you know you are going to have to change this program a fortnight from now, that suddenly starts to look much less sensible
I think i can shed some light on this. There are several reasons which I'll outline below.
- Rapid Development - A typical software project might last for months before hitting the shelves. Most web projects have to be spec'ed, built and online in a matter of weeks. Interpreted languages (like Perl and Python) make it easier to develop things in a hurry because you can make changes without re-compiling.
- The performance bottleneck is bandwidth, not performance. Usually, it's the speed of someone's modem, or the crowded internet backbones that slow down a web-page's performance. Using a faster language isn't going to help that, so typically web-folk go for the easiest solution. The easiest solution is to use an interpreted language. The reason is listed in my first bullet point.
- Much of CGI scripting consists of text-prodcessing. A high percentage of CGI programming can be summed by saying "Fetch. Parse. Print". Since Perl, Tcl/Tk, and Python have built-in, powerful pattern-matching and text-processing routines, these specific languages lend themselves nicely to web-app design. This might be less true as a whole than 2 years ago, but I know personally that I'm still doing an awful lot of $x=~s/blah/blahblahblah/g; in my web programs. Can't do that any easier than in perl/python/tcl.
In the end, it comes down to whether or not you'll get a noticable benefit from using something that runs faster. I think that for 99% of web-apps, you don't get enough of a speed increase by switching to C/C++ so people just don't even bother testing them out.Werd.
Not that I have anything against Larry, but his TMTOWTDI (There's More Than One Way To Do It) philosophy has made it way too easy for people to write really awful spaghetti code in Perl. Much more easily than in any other language. In Perl, precisely because of TMTOWTDI, you can have four scripts that do exactly the same thing and look completely different! ARGH!
And that is the "danger" of using Perl for CGI, and this is the situation I think the "web programming" industry is in - everyone and their grandmother can pick up a "Perl for Dummies" at the local bookstore and, without any concept of "proper programming practices" (i.e. don't write spaghetti code, try to comment at least what's not immediately obvious, stay structured so you can make changes easier) can start banging out CGI code and since Perl will take just about anything, nobody knows the crap that's running until it comes time for that burger-flipper to leave this job and move on to the next.
I've been given Perl CGIs to try to figure out why they're breaking that are 100's of K in size and 1000's of lines of Perl code and took 10's of megs of core and way too much time to execute. When they were written, the author literally cut-and-pasted from any source that looked vaguely like it would do something like what they wanted their script to do and just left all the extra cruft in and kept just appending to the existing code any time they modified the scripts with thousands of lines of code doing calulations the results of which were just being overwritten by later lines of code. Perl being Perl didn't care, but when it came time for someone else to figure out what the damned thing was doing - forget about it.
Yes, I occasionally write stuff in Perl, but I don't use any of the funky streamlined grammatical constructs that make the code horrendous to try to read through if you go back and have to maintain it, which also means that I don't usually gain a whole lot by writing my code in Perl except that I can be sloppy and it doesn't care, which IMHO is A Bad Thing. If possible, I will rewrite the thing in C or as a Java servlet, which just makes it much easier to maintain since there's ONLY ONE way to do it in those languages and you have to do it THAT WAY; when you see a statement in C or Java, you can figure out what it means and it can only mean one thing. Not like Perl... *shudder*
Personally I think Perl should be considered a "non-rewriteable" language; kind of the programming equivalent to a CD-R. Once the program is out there and has been running unmaintained for a while, don't even think about modifying it! If you need to do something else, write a new program because it'll probably be faster than trying to figure out what you did with the old program, and will almost certainly be faster than trying to find out what someone else has done in their Perl program.
In small shops where a piece of code might have to be banged out for something quick-and-dirty and never looked at again, do it with Perl. If you're going to try to write something that will need to be maintained and changed and worked on by many people, you either have to make sure those people are going to be VERY CAREFUL and VERY RESTRAINED in their programmin, or just don't even do it with Perl - it will quickly become unmaintainable.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!