Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Perl Domination in CGI Programming?

Cliff posted more than 14 years ago | from the challenging-the-king-of-the-hill dept.

Perl 432

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?

Sorry! There are no comments related to the filter you selected.

you missed one thing (0)

Anonymous Coward | more than 14 years ago | (#1569016)

i like to use visual basic. its so much better than pearl. with IIS4.0 it works a treat!

Perl is just so damn easy. (0)

Anonymous Coward | more than 14 years ago | (#1569065)

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.

first!!! (0)

Anonymous Coward | more than 14 years ago | (#1569067)

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

perl is speedy (0)

Anonymous Coward | more than 14 years ago | (#1569076)

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...

CGI Programming (0)

Anonymous Coward | more than 14 years ago | (#1569081)

I was wondering if anyone could comment on what advantages perl has over java servlets?

No Perl here. (0)

Anonymous Coward | more than 14 years ago | (#1569082)

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

C/C++ for CGI programming, in a word... don't (0)

Anonymous Coward | more than 14 years ago | (#1569085)

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.

Perl (0)

Anonymous Coward | more than 14 years ago | (#1569086)

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.

Perl dominance... (0)

Anonymous Coward | more than 14 years ago | (#1569087)

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)

--Steve
comments@vrml3d.com

Compiled Perl (0)

Anonymous Coward | more than 14 years ago | (#1569088)

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.

why would you want to waste more time? (0)

Anonymous Coward | more than 14 years ago | (#1569092)

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.

why would you want to waste more time? (0)

Anonymous Coward | more than 14 years ago | (#1569093)

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.

Try REBOL instead of Perl. (0)

Anonymous Coward | more than 14 years ago | (#1569096)

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).

C[++] is compiled (0)

Anonymous Coward | more than 14 years ago | (#1569097)

C[++] (usually) needs to be compiled on the server, which can be inpractical.

There's no reason why one shouldn't use languages such as Python/TCL though.

Re:No Perl here. (0)

Anonymous Coward | more than 14 years ago | (#1569098)

Well Bono, there's a saying around here - Never go out on a limb in computing. After all the above posts it looks like you find yourself out amongst the twiggy stuff... But its your deal, and if you aren't convinced yet then you never, never, will be.

Re:Java Security (was: Re:Java Servlets) (0)

Anonymous Coward | more than 14 years ago | (#1569100)

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 manipulation is easy (0)

Anonymous Coward | more than 14 years ago | (#1569101)

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...

with C/C++ you run the risk of... (0)

Anonymous Coward | more than 14 years ago | (#1569104)

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.

Servlets run on the server (0)

Anonymous Coward | more than 14 years ago | (#1569105)

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.

Consider Python (0)

Anonymous Coward | more than 14 years ago | (#1569106)

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!

C isn't always faster (0)

Anonymous Coward | more than 14 years ago | (#1569108)

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.

Re:PHP more widespread? (0)

Anonymous Coward | more than 14 years ago | (#1569110)

Hi,

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 [rpg.net] (The Inside Scoop on Gaming!)

platform independant (0)

Anonymous Coward | more than 14 years ago | (#1569111)

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...

Definitely use 'C' if you have lots of data. (0)

Anonymous Coward | more than 14 years ago | (#1569112)

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.

Re:Java Security (was: Re:Java Servlets) (1)

henri (189) | more than 14 years ago | (#1569125)

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

PERL is becoming heavyweight (1)

Shaman (1148) | more than 14 years ago | (#1569140)

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.

Sometimes easier is best (1)

krady (2201) | more than 14 years ago | (#1569157)


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.

Re:Java Security (was: Re:Java Servlets) (1)

acroyear (5882) | more than 14 years ago | (#1569176)

I have java turned off in my browser. ... I'm convinced that java is just not stable enough to be something that I can rely on

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.

perl (1)

dynamo (6127) | more than 14 years ago | (#1569178)

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.

Java Security (was: Re:Java Servlets) (1)

mischief (6270) | more than 14 years ago | (#1569179)

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.

--

Re:Java Security (was: Re:Java Servlets) (1)

mischief (6270) | more than 14 years ago | (#1569180)

Uh, sorry. It's getting late and I shouldn't be here. I misread the post and replied too quick... I should leave the office.

--

Compiled Code Is Harder To Update (1)

waldoj (8229) | more than 14 years ago | (#1569190)

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.

Where's the Bottleneck? (1)

Groogroo (9429) | more than 14 years ago | (#1569194)

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?

Perl is a General Purpose Automation Language (1)

dave_aiello (9791) | more than 14 years ago | (#1569197)

My company started using Perl 2 years ago. The reasons we did it are:

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.

Lock in (1)

Trith (10719) | more than 14 years ago | (#1569202)

What if a company calls you and offers you big bucks to write one for apache/UNIX. How well does VB port there?

My reasons (1)

devinoni (13244) | more than 14 years ago | (#1569214)

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.

My reasons (1)

devinoni (13244) | more than 14 years ago | (#1569215)

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.

Perl Vs. C/C++ (1)

Xerithane (13482) | more than 14 years ago | (#1569216)

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 =-

Different languages for different purposes. (1)

Fellgus (16870) | more than 14 years ago | (#1569223)

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.

Tradition (1)

rde (17364) | more than 14 years ago | (#1569226)

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.

You website doesn't need efficiency (1)

rw2 (17419) | more than 14 years ago | (#1569227)

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.

Re:Java Security (was: Re:Java Servlets) (1)

Overt Coward (19347) | more than 14 years ago | (#1569230)

Whatever Java's problems are on the client side, servlets are an entirely different manner. As the name implies, they are run on the server, not the client. The security issues basically go away (other than some of the typical CGI-related issues).

Additionally, server-side Java is extremely stable and portable.
--

Perl vs. C (1)

Basilisk (20668) | more than 14 years ago | (#1569245)

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.

My reasons for switching to Perl (1)

Stephen (20676) | more than 14 years ago | (#1569246)

I've just rewritten the CGI interface for my program analog [cam.ac.uk] in Perl -- it was in C before. Indeed I even learnt Perl to do it. So let me talk about your question in terms of my example.

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.

Perl == speed (1)

trippd6 (20793) | more than 14 years ago | (#1569247)

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 has good text/string handling (1)

cemerson (21094) | more than 14 years ago | (#1569250)

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.

Why perl? (1)

Hackysack (21649) | more than 14 years ago | (#1569253)

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

A lot of reasons (1)

BigWillieStyle (22009) | more than 14 years ago | (#1569255)

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.

perl is a write-only language (1)

Longing (23218) | more than 14 years ago | (#1569259)

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

Is Perl really slower? (1)

Headrick (25371) | more than 14 years ago | (#1569268)

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?

Java Servlets (1)

Whizard (25579) | more than 14 years ago | (#1569269)

Java Servlets are rapidly becoming an excellent alternative to doing CGI. Java Servlets are much more efficient than straight CGI, gaining many of the same advantages that mod_perl does. Rather than a separate process for each CGI access, servlets run as a separate thread for each access, thus reducing system load significantly. Servlets are also started once, and only stopped (usually) when the server stops. This allows you to make (for example) one connection to a database, and share it among lots of different connections to the Servlet.

For more information on servlets, pick up the O'Reilly Programming Java Servlets book, as well as checking out Apache JServ [apache.org] and the JRun Servlet Engine [jrun.com] .

(And really, if you know Perl and C++, Java is but a small step to learn, and provides nice resume fodder. :-> )

Perl could be faster (1)

nufan (26081) | more than 14 years ago | (#1569270)

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.

CPU cycles are cheap these days anyway :) 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.

Some reasons perl is used (1)

rmull (26174) | more than 14 years ago | (#1569271)

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!

Rapid development and strings (1)

Mike Miller (28248) | more than 14 years ago | (#1569272)

I think there are two reasons that Perl is "better" than other languages for CGI scripts.
  1. It was made to work with text. Let's face it, it handles strings faster, better and with fewer lines of code (fewer chances for bugs) than most other languages. The regular expressions and trivial use of variables in print statements (along with other features) simplify, which in turn increases programmer productivity and reduces bugs.
  2. It is quick and easy to modify. In the current era of websites (and even more so a few years ago) websites are constantly in a state of flux, being redesigned and modified on a monthly, if not weekly basis. Therefore, you want a language that is easy to write and prototype in, because the marketing (or whoever the 'suits' are) dudes are constantly going to be saying things like "we should use frames" or "I want it to look like...". By using a language that is faster to program with, you can play the what-if games for them easier. These are not absolutes, but I think in general they tend to hold for a lot of the cgi scripts out there.

    - Mike

Why not C/++ (1)

jeffcuscutis (28426) | more than 14 years ago | (#1569273)

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?

Perl lets me get things done... (1)

Cranial Dome (28458) | more than 14 years ago | (#1569274)

...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.

Re:perl compiler (1)

PigleT (28894) | more than 14 years ago | (#1569276)

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).

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 /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!

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.

why not use ASM? (1)

mistabobdobalina (29109) | more than 14 years ago | (#1569278)

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?

Re:Some reasons perl is used (1)

webweazl (29283) | more than 14 years ago | (#1569279)

Another reason perl is such a widely used cgi interface is the fact that it is not compiled. This makes it very easy to move your cgi's from machine to machine with little to no changes. Ever tried to compile C/C++ on a ftp only acount ?
This is the biggest reason that I use perl, i move projects from machine to machine as clients move around and if I compiled C/C++ everytime they moved it would be all I do all day.

CGI Programming (1)

Sxooter (29722) | more than 14 years ago | (#1569281)

Performance on CGI is far more dependent on whether or not the web server is forking for each CGI request.

I.e. if you write a .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 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.

Network bottleneck (1)

Priestess (30745) | more than 14 years ago | (#1569288)

The main reason I write CGI in perl is that, as far as performance is concerned, execution speed isn't the bottleneck to getting a good delivery time. Yes, perl is slower than C but the network tends to be slower than either. It doesn't matter that much if you can get the results quickly and efficently if you just have to wait while those results go over a 33kbps connection to a modem somewhere anyway.

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.

Pre.........

perl has infrastructure. (1)

BIFFSTER (31667) | more than 14 years ago | (#1569291)

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.

Perl string handling (1)

Scrubby (33099) | more than 14 years ago | (#1569293)

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.

Why did I use Perl? exec() and text handling (1)

edremy (36408) | more than 14 years ago | (#1569301)

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.

  1. Write many, many lines of C code to parse the equations
  2. 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

C++ for speed? (1)

gorilla (36491) | more than 14 years ago | (#1569302)

CGI is inherently slow. It's got to fork a process, usually write data cross the pipe, the program has to decode the data, process it, write some data back across the pipe, the webserver has to read that data, perhaps do some more processing, and eventually write it to the browser.

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.

Portability (1)

Calexico (38510) | more than 14 years ago | (#1569303)

I've used C++ with CGI and had good results. But C++ is far less portable than Perl is. My C++ code has been platform-specific and non-portable. This works fine in certain situations. But often I need the same functionality to span servers from a variety of vendors (Sun, IBM, and MS) and there Perl makes a lot more sense.

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.

Perl had the 'early mover' advantage... (1)

costas (38724) | more than 14 years ago | (#1569304)

...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 [php.net] . 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.org] . 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

Re:No Perl here. (1)

sirinek (41507) | more than 14 years ago | (#1569311)

Bono.... You didn't specify what kind of things your CGI scripts do, so I can't do as good of a job as I'd like downplaying your reasons for not using scripting languages for CGI. ;)

But I do know that there are things now such as mod_perl and FastCGI which attempt to relieve some of the shortcomings of perl for CGI by not having to invoke a new instance of the perl interpreter each time your script runs. I'd check out the apache docs, or go to http://www.fastcgi.com

Bill

Re:you missed one thing (1)

NullGrey (46215) | more than 14 years ago | (#1569316)

Ahem... You're kidding, right? I can just imagine what a nightmare that would be (although there are a lot of people out there that do that). Slow webserver that never stays up, huge, bulky, slow CGI's, and, when you get an error, call up your admin:

"Hey, can you walk over and hit 'Ok' on that exception violation?"

I have run DOS batch files for CGI under Apache for NT. Nothing serious, just seeing if it could be done.


+--
stack. the off .sig this pop I as Watch

perl compiler (1)

nevroe (48688) | more than 14 years ago | (#1569317)

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.

Portability (1)

TheTomcat (53158) | more than 14 years ago | (#1569321)

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.

Why you would use Perl (1)

chown (62159) | more than 14 years ago | (#1569328)

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.

Time to market vs Performance etc (1)

phurley (65499) | more than 14 years ago | (#1569334)

Consider a few important factors:
  1. You can probably develop it faster in Perl
    • a. CGI.pm is _very_ good
    • b. Regular Expressions are useful
    • c. DBI is a useful generalization
    • d. CPAN is there for everything else
  2. CGI applications run on one (or a limited number) of servers. You can easily (compared to updating many clients), juice up the server box(es)

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

PHP (1)

mbyte (65875) | more than 14 years ago | (#1569335)

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 [php.net]

Re:Java Security (was: Re:Java Servlets) (1)

rcromwell2 (73488) | more than 14 years ago | (#1569343)


He's talking about Java on the server side, not applets. Applets are only just a small part of what Java can do.

Likewise, Perl can be used for things besides CGI, such as Tk applications, or command line utilities.

I think Perl Sucks! (1)

hajo (74449) | more than 14 years ago | (#1569348)

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!

Re:Why not C/++? overhead (1)

apocalypse_now (82372) | more than 14 years ago | (#1569355)

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

CGI, Perl and Python (1)

smoondog (85133) | more than 14 years ago | (#1569358)

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 [eparka.com] is written entirely in Python with only a bit of javascript....

-- Moondog

Web Apps and Deadlines (1)

DoctorPepper (92269) | more than 14 years ago | (#1569370)

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.

Go Go Gadget CPAN... (1)

Mark F. Komarinski (97174) | more than 14 years ago | (#1569381)

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.

CGI usually doesn't need efficiency. (1)

Ichoran (106539) | more than 14 years ago | (#1569390)

For me, it comes down to using the right tool for the job. If I want to get a CGI script up and running quickly--and I'm not going to have thousands of users pounding on it at the same time (I wish)--then I use Perl. It lets me finish the job quickly and move on to something more interesting.

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.

Perl is fast enough + database access much easier! (1)

jdwtiv (107586) | more than 14 years ago | (#1569393)

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.

Perl hits a sweet spot (1)

MarcelLevy (107618) | more than 14 years ago | (#1569394)

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).

portability (2)

Yarn (75) | more than 14 years ago | (#1569395)

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.

Dynamic Versus Static Programs (2)

Christopher B. Brown (1267) | more than 14 years ago | (#1569400)

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.

Unfortunately, you lose some abilities:

  • The ability to change a script "on the fly" whilst debugging, and have the change automagically deployed. With C++, you have to make and then go through whatever installation process is required to deploy the change.
  • Scripting languages [hex.net] like Perl [perl.org] and Python [python.org] provide built-in operators for doing all sorts of text manipulations.

    With web applications, what you're largely manipulating is text, [hex.net] 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.

Re:PERL is becoming heavyweight (2)

jCaT (1320) | more than 14 years ago | (#1569402)

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.

Depends on what you consider efficient.. (2)

Thomas Charron (1485) | more than 14 years ago | (#1569403)

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..

Why scripting languages (2)

jd (1658) | more than 14 years ago | (#1569406)

Some thoughts of my own. (Due to cutbacks, readers of the thoughts will need to donate the 2 cents.)

  • 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.
  • 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.
  • As others have said, string handling in C/C++ is virtually non-existant.
  • Scripts run in their own enclosed shell. Binaries don't.
  • 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.)

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.

Re:perl compiler (2)

extremely (1681) | more than 14 years ago | (#1569407)

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 =).
--

Re:Tradition (2)

Evangelion (2145) | more than 14 years ago | (#1569408)

Freaky.

I was just browsing The Quotations Page [starlingtech.com] and came across...


"Tradition is what you resort to when you don't have the time or the money to do it right."

-- Kurt Herbert Alder

Slow systems, time-critical code (2)

Pascal Q. Porcupine (4467) | more than 14 years ago | (#1569413)

I used to run the Hobbes Archive [nmsu.edu] . For those who aren't in the know, it's an OS/2 shareware archive. It contains about 3.5 gigs of software in several thousand files with an incredibly-deep directory structure. For it, I wrote my own custom database engine for keeping track of the files and generating the HTML. The average search takes 5-6 seconds depending on system load (it used to only take 3, but the archive has grown signifigantly since I wrote the engine).

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.

Lack of speed (2)

SheldonYoung (25077) | more than 14 years ago | (#1569421)

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.

Choice (2)

debrain (29228) | more than 14 years ago | (#1569422)

I've been in several big scale projects requiring language decisions. And there are certainly places where Perl is just great; the string regular expression engine, and interpretation of on-the-fly generated code, make many things that are borderline multi-person projects, relatively simple one-person projects.

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.

Choice (2)

debrain (29228) | more than 14 years ago | (#1569423)

I've been in several big scale projects requiring language decisions. And there are certainly places where Perl is just great; the string regular expression engine, and interpretation of on-the-fly generated code, make many things that are borderline multi-person projects, relatively simple one-person projects.

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.

PHP more widespread? (2)

Hew (31074) | more than 14 years ago | (#1569424)

According to the Apache Module Report [e-softinc.com] at E-Soft Inc, PHP is more widespread than Perl as an Apache Module. These figures [php.net] at www.php.net might be interesting as well...

C may not increase performance significantly (2)

Sajma (78337) | more than 14 years ago | (#1569429)

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 [photo.net] for info).

Perl is good at massaging text (2)

iso (87585) | more than 14 years ago | (#1569432)

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 is king for a reason (3)

dlc (41988) | more than 14 years ago | (#1569437)

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 [cpan.org] ).

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

Use the best tool for the job (3)

shawnhargreaves (66193) | more than 14 years ago | (#1569438)

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 :-)

Your real question (4)

Suydam (881) | more than 14 years ago | (#1569439)

It seems that your real question pokes at something deeper. Mainly, why do web-folk use an interpreted language for their applications when it would be faster to use a compiled language like C.

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?