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?
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.
--
?
Bytecode is an implementation technique for interpreters.
Well, you can call it interpreted if you want but if you do then so is java.
Yes, they both are interpreted languages.
BTW, there is a real perl compiler in the latest release. It's just experimental.
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.
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.
hah! that's a good one. If you have to install 15 cpan "extensions" as you call them (I think you mean perl modules), whoever wrote the code is module-happy. It also depends on what you're trying to do... if you want database access, you have to have DBI. If you want to do CGI's, you better have CGI.pm. If you want to turn on your coffee maker, you better have some X10 perl module. I'd like for you to point to a language that has small code size, is as fast as perl, and has EVERYTHING built in that perl can do with a module. Yeah, I thought so. Besides, installing a module is as easy as perl -MCPAN -e install DBI.
As for mod_perl being monstrous- did you pull this out of your ass, or are you just plain stupid? mod_perl couldn't be any easier, and it makes using perl CGI's in a high traffic environment a viable solution.
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.
I've seen this a whole lot and I have to respond.
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.
This is just plain wrong. You don't have to load the binary off disk any more often than you have to load the script off of disk. The OS (assuming something somewhat intelligent) will map often used binary files into a shared data segment, the same way you don't have to load large dynamic libraries every time you use them. This means that if you use the binary a lot, it will be in memory.
There is a large difference in speed between well written PERL and well written C for most things, the problem is that it is difficult to find good C programmers to do this type of work quickly. C was not designed to be a RAD like language.
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. The speed is based on the quality of implementation.
In shops where CGI's are written in C, they probably already have extensive backend libraries, which speeds up development.
I personally use PERL for quick RAD type stuff, but if I'm going to have to maintain it or I want it to scale, I'll use C. (Note, I am not a web or CGI programmer, but a UNIX consultant. I use C because it is strongly typed and easier for me to work with, YMMV)
In closing, when you start talking about speed, check your facts and know what you are talking about. If you compare the execution speed of well written PERL and well written C, C should win every time. When you include development and testing time, the results may differ.
--
Mike Mangino Consultant, Analysts International
Mike Mangino
mmangino@acm.org
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)
You're wrong. The perlcc (CPAN->B::CC) makes
an optimised pre-byte-encoded binary.
In effect it saves you the startup parse step and allows you to make a "compiled binary". The CB is
just a copy of the parse-tree bytecode, loader and
the perl lib. It still has a full compile and
interpet engine and still interpets the bytecode tree. It can still "eval" perl code so it has to
have a full compile engine still.
mod_perl takes the same route by caching the post
parsed code for speed gains and disk load avoidance.
Perl offers easy prototyping and quick evolutionary programming (twiddle with live code =).
--
$you = new YOU;
honk() if $you->love(perl)
I was just browsing The Quotations Page and came across...
-- Kurt Herbert Alder
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.
grep (blahblahblah) `find (topdir) -name 00index.txt`
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
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
My advice (which with $1.50 will get you a cup of coffee)
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!