Which CGI Language For Which Purpose?

zpengo asks: "The blessing and curse of CGI is that there are dozens, if not hundreds, of ways to accomplish any given task. All languages have certain strengths and weaknesses, and there is no "best" CGI scripting language. I'm wondering what the community has learned about CGI languages through their experiences. Which languages go best with which tasks? (Also, are there any less-known languages that work well for particular circumstances?)"

Comments

What about the children?

[Anonymous Coward]

Interesting points. But I feel that while PHP may be a good language, it has origins that I feel are somewhat suspect and disqualify it from any serious use in my web applications.

What, for example, is the name supposed to imply?

That this language is so far removed from reality that nothing will affect it?
That this language will give you feelings of strength, power, and invulnerability?
That this is a "supercharged" web scripting language that will stop at nothing to achieve whatever delusional whims you set out for it to accomplish?
That this language will put some real "rocket fuel" into your dotcom enterprise, even more so than, say, small investments from an angel? (Which would be "angel dust", no?)

Let me ask you, then - what kind of message does this send to our children? I have a twelve year old daughter who wants to be a webmaster, and she came home from school the other day and asked me about PHP. What am I supposed to tell her? That it's ok to use it professionally, but not recreationally? Only if you're putting up a website? Please -- we all know that that's the long slide towards addiction, a mad quest for the drug, and finally going broke and living under an overpass with a 40 oz. bottle of Old English, begging money from passing strangers and carrying on extensive conversations with crows, pigeons, and skinny, mangy rats.

Somebody needs to take a hard-line stance against this language and make sure that it spreads no further. Why can't people use sensible, wholesome languages such as Perl, Python, ASP, and TCL?

Next time, before you go and create a scripting language with dubious moral intent: think about the children. Please.

Like Perl and Java Servlets--Love PHP

[Anonymous Coward]

I've used Perl before--it works well for highly functional pages where you may need to do tons of regular expressions. It doesn't scale very well though, even with mod_perl. And the object model isn't quite as elegant as in other languages. Java servlets scale well, but Java is such a clunky language for text processing that I only use it for middleware applications (usually database related). JSP has the same problems. PHP has, IMHO, the best combination of a great object model, great scaleability, and great templating. You can write elegant code and still not get pissed off when your designers request yet another interface change (It's so easy!) AC

Re:Like Perl and Java Servlets--Love PHP

[gid]

• However, PHP, even well-written PHP. will never be as fast as a well-written mod_perl handler, for the simple reason that mod_perl handlers are compiled once and live in memory for the life of the Apache server (parent) process.

This is fixed in php4, using the zend engine. It automatically compiles and optimizes your php4 code.http://www.zend.com

I write php for a living, and love every minute of it, it's a dream to code in. I've yet to run into any problem that I can't solve. I hear people bitching about perl all the time, granted most of those people bitching are people that have gotten used to php already.... :)

---

Re:Like Perl and Java Servlets--Love PHP

[Roundeye]

However, PHP, even well-written PHP. will never be as fast as a well-written mod_perl handler, for the simple reason that mod_perl handlers are compiled once and live in memory for the life of the Apache server (parent) process.

Fixed in php4. Next?

You want to modify how the URI gets translated into a filename? You can't do that in PHP.

Yes, you can. I'm beginning to think you haven't used PHP.

You want to customize the authentication process? Nope, you can't do that in JSP.

That may be true in JSP (I haven't tried it), but in PHP it's a cakewalk (can you tell which side I'm taking?).

For anything other that generating output, you have to use either C or mod_perl.

I'm thinking you're smoking something. I consider socket communications, DB access, mailing, LDAP/SMB/PAM access, and the ability to run any executable in reach... a bit more powerful than just producing output. Don't know again about JSP (did I mention I don't use it?) but PHP can do these, and I'd grudgingly admit you can pull off the same tricks with ASP if you know where the right hooks are.

And the beauty of the whole thing is -- yup, you guessed it, it runs at memory speeds -- no filesystem accesses (unless you write them in specifically), no scripts to stat, no logic/HTML combination to parse.

This is a bit of a red-herring. Everything that doesn't need pre-processing will run at memory speed (or the closest approximation thereof since you ignore paging/swapping/etc. in your discussion, which is fine as we aren't holding an operating systems seminar here) as long as it has everything it needs. Talk to a database? Open a socket? Open a file? Run an outside script? The point about compilation is essentially dead-on (which is why the Zend engine for PHP is a Good Thing(tm)). If you're really pressed for time/memory however, right your own mod_* for Apache.

Most of this is merely for the sake of argument though -- I've been a Perl zealot for years. Now I do a lot of presentation in PHP, and save Perl for the heavy lifting. I optimize THE HELL out of my perl though, and use mod_perl when possible. I hate the thought of JSP (what an abortion) and so don't use it, and ASP is of course "right out".

Re:Like Perl and Java Servlets--Love PHP

[jfrisby]

This is false. Apache with mod_perl runs at the same speed as Apache -- the combined speed of your computer, network connection, disk, etc. Yes, you can write slow mod_perl stuff (if you use it as glorified CGI), but mod_perl itself has no such limitations.

The real problem is memory overhead. Our mod_perl processes can reach 20-30MB each. But then again we have 70,000 lines of Perl code...

-JF

Re:Like Perl and Java Servlets--Love PHP

[jfrisby]

FFT calculation, and graphic generation, for example are not going to go fast no matter what.

In web applications, such complex calculations tend to be the abnormal case.

All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with.

Absolutely false. There is a great deal of overhead to forking and execing Perl. And mod_perl does MUCH more than merely eliminate that overhead. mod_perl gives you the ability to do things like database connection caching and provides access to Apache internals giving your script more information and more control.

I've run all sorts of comparisons between java and perl, and for small - medium sized scripts, compilation is barely noticable.

My company has 70,000 lines of Perl code. Compilation time is significant.

The slowest parts tend to be in database reconnections, forking off seperate processes to do simple operations like file grepping, finding, etc.

First off, nothing will compensate for poor code. If you are using mod_perl, you can cache database connections. Forking a process to grep a file, or find a file -- that's ludicrous! It can be done trivially in Perl.

but I found that the same algorithm would run incredibly slowly in a java-servlet world because of the un-optimized string parsing in Java.

There are regex engines for Java that provide much of the performance and flexibility of Perl.

But if I redesign the java-system so that it uses a truely optimized 'parser' then I can get better performance than even in perl.

Of course. And there's probably a better way to do the Perl version too. There's *always* a more efficient way of doing something. And there's always a less efficient way.

The only problem is that you have heavy context switching, as opposed to the light-weight context switching of a threaded model ( such as java-servlets).

Apache 2.0 addresses this issue allowing a hybrid solution. (Multiple processes with multiple threads)

Another issue with process segmented workers is the redundant usage of memory and thus the propensity to Virtual memory thrashing. You, of course, always want to put more than enough memory in a server, but you also would like to cache as much of the web site as possible. If you were to scale to 50 workers, your memory contension would be well beyond that of a CPU-cachable range.
Much Perl code can be pre-loaded into the parent Apache process allowing it to be shared among processes. Thanks to the joys (grr) of copy-on-write, it gradually gets unshared -- a fault of Perl intermingling code and data -- but tuning process lifetime can alleviate this.

For small-scale operations ( Apache-Front-end, HTML-rendering, Business-logic, database-back-end ), where the business-logic is minimal, you can use mod_perl with apache and have the DB on another computer and you have plenty of scalability. To my understanding this is exactly slashdot. It is when business-logic becomes comparible in resource requirements to the other elements that perl really falls short.

My company handles 2,000,000 page views per day. Most of that is our web-based e-mail client. (heavily customizable/cobrandable!) We're growing at as much as 40% per month. We handle 1,500,000 mailboxes. We use Apache, mod_perl, and MySQL. With careful design our system ust keeps getting faster and faster.

It's hard to farm out CPU cycles to other machines or CPU's.
That depends on how well you designed your code. We have no such difficulties. I believe we have 11 web servers handling our e-mail client, 6 or so handling our message boards product, and a handful serving our search and chat products. (Both of those are in Java -- but receive trivial usage thus far...)

And if your logic serializes access to data ( via DB row/table locks ) then the ability to finish business logic computation really starts to stand out like a soar thumb.

That problem really depends on your RDBMS. MySQL is not well suited to such situations, but Oracle and DB2 handle them fairly gracefully.

Perl just doesnt show up in the enterprise model, or even the real service model beyond the simple form entry services like slashdot.

I must take exception to that statement. My personal site, my previous employer (BrainPower -- now out of business unfortunately), my present employer (Everyone.net) all use(d) complex business logic rules and all have found Perl to perform quite well when properly managed.

A web based e-mail client does not classify as a "form entry service." Our inter-company communication/integration protocols are also Perl based with great success.

Java was designed with all of this in mind, they just don't always achieve their goals completely.
If you can get over Java's screwy I/O model. No asynchronous I/O? Come on! One should not be forced to take on the overhead of threads for synchronous or multiplexed I/O. It's become a pain in the neck for our search product. We have to spawn 20 or more threads to do a meta-search. That's all well and good until you have a thousand people doing it at the same time!

I'm really tired of hearing the "Well [x] is a great toy for small companies/sites/whatever but when you want real power and performance use [y]." That argument has been used by Sun and Sco to describe Linux, by Python, Java, and other language advocates to describe Perl, and in many many more cases...

I stand by my experiences. BrainPower: data mining application. MrJoy.com: Customizable news and community site. Everyone.net: Cobranded, web based e-mail, community (message boards), search, and chat. With much more on the way.

2,000,000 page views per day and growing rapidly.

-JF

Re:Like Perl and Java Servlets--Love PHP

[the way]

It doesn't scale very well though, even with mod_perl. And the object model isn't quite as elegant as in other languages.

I think others have covered the mod_perl debate reasonably well already, so I'll cover the object model issue.

Many people seem to confuse the minimal number of additional keywords for OO in Perl 5 (mainly the bless keyword, plus a few magic variable names), as being an indication of patchy support for OO.

I strongly suggest reading Damien Conway's Object Oriented Perl; I bet you wouldn't keep these beliefs about Perl after reading it. Conway is a computer science professor who has spent a lot of time with C++, Java, Smalltalk, etc, and he shows how Perl allows a marvellous OO design without the inflexibility and complexity that these other languages display.

Perl provides encapsulation, (multiple) inheritance, polymorphism (both interface and inheritance), and persistance. It also allows operator overloading, and reimplementation of basic types (using 'tie'). Many CPAN packages are available to simplify creating common object types (e.g. Class::MethodMaker).

Personally, I've used mod_perl to create a large, complex, fully OO web application, and I loved every minute of it. Because it's a "Swiss Army Chainsaw", you can quickly prototype functionality as basic CGI scripts, and it's then a piece of cake to incorporate them into the mod_perl app when you're ready.

Re:Like Perl and Java Servlets--Love PHP

[dlc]

• [Perl] doesn't scale very well though, even with mod_perl.

This is false. Apache with mod_perl runs at the same speed as Apache -- the combined speed of your computer, network connection, disk, etc. Yes, you can write slow mod_perl stuff (if you use it as glorified CGI), but mod_perl itself has no such limitations.

mod_perl scales very well -- Boston.com serves a few million pages a day using Apache/mod_perl. It's all about how you write your Perl.

But, I will give you this much -- if you run CGI scripts under mod_perl, they do not run nearly as fast as they would if you wrote mod_perl handlers, though they still run much faster than CGI.

How can you dislike the JSP way of doing things, but like PHP? They use an identical model. PHP suffers from many of the same problems as CGI (logic and HTML combined in the same place, etc), but the speed issue is definitely not one of them. However, PHP, even well-written PHP. will never be as fast as a well-written mod_perl handler, for the simple reason that mod_perl handlers are compiled once and live in memory for the life of the Apache server (parent) process. There is no file to read every time it gets called. Plus, PHP (and CGI, and JSP, and servlets) have the limitation that they can only produce output. You want to modify how the URI gets translated into a filename? You can't do that in PHP. You want to customize the authentication process? Nope, you can't do that in JSP. You want to modify the environment for all the other handlers? Not is ASP, you can't. For anything other that generating output, you have to use either C or mod_perl. And the beauty of the whole thing is -- yup, you guessed it, it runs at memory speeds -- no filesystem accesses (unless you write them in specifically), no scripts to stat, no logic/HTML combination to parse.

You are right about Perl's object model, though.

darren

Cthulhu for President!

Re:Like Perl and Java Servlets--Love PHP

[Scouras]

>Java is such a clunky language for text processing

Perhaps the Gnu Regular Expression Library for Java would be of some use.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Learnin' from each other's knowin,

Re:Like Perl and Java Servlets--Love PHP

[maraist]

Sorry, but this isn't my experience. Perl is interpreted with very few optimizations. There are a good number of important calculations and operations that just do not work quickly in perl no matter what you do. FFT calculation, and graphic generation, for example are not going to go fast no matter what. Obviously, these types of modules should be found in C-compiled perl-module forms since they are so high profile ( though freeking gif image support has resently been discontinued ). But you should also be able to find these C front-ends in most any scripted / CGI-friendly language.

All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with. I've run all sorts of comparisons between java and perl, and for small - medium sized scripts, compilation is barely noticable. The slowest parts tend to be in database reconnections, forking off seperate processes to do simple operations like file grepping, finding, etc.

You get past all of that with PHP and java-servlets though, so everyone is really on a level playing field. PHP even makes use of perl reg-exs ( though I'm not sure if they use the same optimized engine, even though they have compatible syntax ). It really comes down to the advantage your language has to your type of solution. For example, I have created a very powerful web templating system in perl which takes HTML and imbeds them into other HTML files all the while emulating both static-HTML and perl-CGI ( really just a glorified extension to Apache::Registry and Fast::CGI ), but I found that the same algorithm would run incredibly slowly in a java-servlet world because of the un-optimized string parsing in Java. But if I redesign the java-system so that it uses a truely optimized 'parser' then I can get better performance than even in perl.

I don't have numbers to back me up. But assuming a multi-CPU configuration, ( perl-threads still being considered beta ) a well designed java-solution will outperform a mod_perl solution ( especially since java-servlets can transparently span multiple computers, either by resource pooling, or through RMI segmentation / pipelining of the logic ). You can achieve this sort of distribution in perl ( I've successfully tried ), but it is non-trivial and not a logical attribute of the language.
Thankfully though, mod_perl gives you the advantage of running multiple independant, concurrent perl-proceses in each Apache-worker. Thus you can make use of multiple CPUs at the process level. The only problem is that you have heavy context switching, as opposed to the light-weight context switching of a threaded model ( such as java-servlets ). You really notice the difference in a thread-optimized OS such as Solaris and associated [uSPARC] hardware ( where the CPU can thread-swap between instructions ). At this point, one file goes out to the DB while one reads from CGI parameters while two or three fight for raw computing horsepower.
Another issue with process segmented workers is the redundant usage of memory and thus the propensity to Virtual memory thrashing. You, of course, always want to put more than enough memory in a server, but you also would like to cache as much of the web site as possible. If you were to scale to 50 workers, your memory contension would be well beyond that of a CPU-cachable range.
Apache will soon be multi-threaded, and perl is making serious strides to make it's threading both safe and portable. 5.6 has a nice multiple interpreter model which works nicely for global variable consistency ( it's main purpose is to emulate forks on win32 machines ). This combination could bring perl almost back up to par, in terms of scalability, as java-servlets. But it is yet to be seen.
For small-scale operations ( Apache-Front-end, HTML-rendering, Business-logic, database-back-end ), where the business-logic is minimal, you can use mod_perl with apache and have the DB on another computer and you have plenty of scalability. To my understanding this is exactly slashdot. It is when business-logic becomes comparible in resource requirements to the other elements that perl really falls short. It's hard to farm out CPU cycles to other machines or CPU's. And if your logic serializes access to data ( via DB row/table locks ) then the ability to finish business logic computation really starts to stand out like a soar thumb.
As we move back into the world of server-based computation ( java-applets and client side web-apps never really took off ), this sort of massive business-logic will become increasingly important. Serious apps are still done in C ( or C++ if you're into extending your code ), but more and more are done in java in order to give you platform flexibility. Perl just doesnt show up in the enterprise model, or even the real service model beyond the simple form entry services like slashdot.
I'm not saying you can't do magical things with perl ( I've already proven to my company that you can. TCP, forks, and threads are your friends ), but the technology does not easily afford you to do this. Java was designed with all of this in mind, they just don't always achieve their goals completely.
I hope enough of you read this and find value in my experiences. I am not an authority, just a power user.
-Michael

Re:Like Perl and Java Servlets--Love PHP

[flibbertigibbet]

CGI bash shell scripts. Hands down.

I run a site with 10 trillion requests per day with ncsa httpd and a 386 dx 40.

PHP

[mosch]

Well, actually the regexes can be as good as perl's if you use the perl compatible regex stuff on compilation.

As for database support, it's very thorough though I'm having a little trouble getting PHP4.0 to compile against Solid 3.5. Of course I've only put an hour or so into it, including download time.
----------------------------

Be careful of PHP; separate code and layout.

[Chouser]

I've said it before, and I will say it again: Do everything you can to separate the program logic (the code) and the HTML layout.

Why:

• The people who originally build, or later fix, the HTML may very well be different than the people who work with the code. The skill sets are almost completely different, but if you let the two comingle, you will require the maintainers be proficient in both skill sets.
• If the look of your site changes but the code and the HTML are entangled, it can be very easy to break program logic while trying to make visual changes.
• If you ever hope to support multiple natural languages, you're going to want your program logic to reside in completely different files from any of HTML or visible text.
• Clean application design and clean web design are almost completely incompatible. If you try to find a compromise between them that lets you alternate between code and HTML, you will get a result that is bad design for both targets.
• Future content formats (such as XML) might be nearly trivial if you can keep the layout (currently HTML) seperate from the code.

How:

• Avoid those seductive solutions that encourage embedding code in HTML. This includes PHP, EmbPerl, ASP, and others (Zope?). Since this question is about CGI, you're already on the right track to avoiding these.
• If you must use one of the above, work very hard to separate the code anyway. Put as much of your code into separate files as you can, and then just "#include" (or equivalent) the appropriate HTML file.
• Use technologies that encourage this separation. My current favorite is HTML::Template, a perl module. This in itself may be a good enough reason to recommend perl as a first choice for most CGIs.

So in conclusion, I would recommend perl along with HTML::Template. This also allows for future migration to mod_perl instead of CGI, giving you a performance upgrade path. Although this is obviously not the best solution in all cases, it very often is the best, and is very rarely the worst.

--Chouser

Separate code and layout

[Chouser]

I've said it before, and I'll say it again: Do everything you can to separate the program logic (the code) and the HTML layout.

Why:

• The people who originally build, or later fix, the HTML may very well be different than the people who work with the code. The skill sets are almost completely different, but if you let the two comingle, you will require the maintainers be proficient in both skill sets.
• If the look of your site changes but the code and the HTML are entangled, it can be very easy to break program logic while trying to make visual changes.
• If you ever hope to support multiple natural languages, you're going to want your program logic to reside in completely different files from any of HTML or visible text.
• Clean application design and clean web design are almost completely incompatible. If you try to find a compromise between them that lets you alternate between code and HTML, you will get a result that is bad design for both targets.
• Future content formats (such as XML) might be nearly trivial if you can keep the layout (currently HTML) seperate from the code.

How:

• Avoid those seductive solutions that encourage embedding code in HTML. This includes PHP, EmbPerl, ASP, and others (Zope?). Since this question is about CGI, you're already on the right track to avoiding these.
• If you must use one of the above, work very hard to separate the code anyway. Put as much of your code into separate files as you can, and then just "#include" (or equivalent) the appropriate HTML file.
• Use technologies that encourage this separation. My current favorite is HTML::Template, a perl module. This in itself may be a good enough reason to recommend perl as a first choice for most CGIs.

So in conclusion, I would recommend perl along with HTML::Template. This also allows for future migration to mod_perl instead of CGI, giving you a performance upgrade path. Although this is obviously not the best solution in all cases, it very often is the best, and is very rarely the worst.

--Chouser

Re:Separate code and layout

[Frodo]

Avoid those seductive solutions that encourage embedding code in HTML. This includes PHP, EmbPerl, ASP, and others (Zope?).
Actually, PHP never "encouraged" embedding code in HTML. It just enables it. You can do it and you can avoid it. For the latter approach use "templates" mechanism, which, for example, is a part of PHPLIB, though I don't like their implementation too much. Seems to be analogous to HTML::Templates from the standpoint of functionality.

Remeber, PHP is a tool, tool can't determine it's use. It is the programmer who tells the tool how to work.

Re:Using C++, but open to (constructive) suggestio

[X]

Java can do this for you. It will let you talk to CORBA (and COM). It uses JDBC which is basically a Java equiavalent to ODBC (indeed there is a JDBC-ODBC bridge). Java is fairly easy to learn for C++ people.

On top of that, if you get in to J2EE then you reach the level were you don't have to worry about the database at all, where your own objects can be distributed, and where you can embed Java into web pages.

Seriously, give it a whirl.

APL: Largely Not An Option

[Christopher B. Brown]

One might want to generate web pages as sets of array operations in APL.

Unfortunately, ISAP - Information Server Auxiliary Processor from Dyadic Software offers APL integration only with MSFT IIS, and does not run them as CGI programs.

On the other hand, German speakers might find something useful at Sergy Alpin's JUMP page

I hear rumor that NIAL, an APL with with a Lisp-like syntax, offers the ability to run it in CGI apps...

So, for those that feel the need to write web apps using reduction operators, preferably without ever using the diamond operator ( looping! ), it seems rather likely that there are some options available. Perfect for making use of that IBM 360 you picked up on eBay...

I somewhat think I'd rather do my APL reduction work by way of the Common Lisp (reduce #'whatever-function whatever-list) function, mind you....

Graphics

[slim]

Everything I've read here so far (at lazy +2 threshold, mind) discusses the common case of CGI scripts which generate HTML.

That's all very well, but the CGI interface allows you to generate any kind of MIME type you like.

Some of the CGI scripts I'm happiest with are written in GNUPlot, and display PNG graphs of live data.

I guess GIMP's Script-FU can be used for nifty CGI scripts; also NetPBM.
--

Re:Some language, any language

[Tommer]

Apache JServ worked like that the last time I tried to use it. There is a little 'stub' module in Apache that talks to a multithreaded handler running in a JVM. However, I found JDBC and the JVM in general to be unstable and sluggish.

ColdFusion also runs as a separate process, but for some reason you can only run one of these servers on each machine. Ick.

Re:coldfusion--ick...

[Tommer]

I'm not surprised to hear that it's possible to run multiple coldfusion processes. There's no good reason for it to be difficult. However, the documentation said it's impossible. I'd hate to hack together a multiple-coldfusion-server *nix system then try to get support for it. :)

an ex-Perler now using Python

[acb]

For a long time, Perl was my language of choice.
Its regular expressions are excellent, and its syntax is very nimble. However, there are various design flaws (such as lists not being intrinsically nestable without using a lot of ugly reference kludges). Perl's object orientation is somewhat of an afterthought. Also, because of its flexibility of syntax, Perl encourages unstructured coding.

A few months ago I looked at Python, and after going through the tutorial, I was hooked. It really is a much more elegant language for programming. Also, it has a first-class collection of classes and utility functions.

These days, I use Perl for writing short text-processing hacks and the like, and Python for anything larger, which includes most CGIs.

Thinking outside the box

[msuzio]

Another thing to consider: does your app (and all the supporting functionality) really have to run via CGI? I alluded to this in my first couple posts (gee, I guess maybe I've hit on a topic I like to talk about ;-) ); if you want to get creative, you can write a dedicated server process that handles the major points of functionality, things like:

- updating the order database
- communicating with distributed objects
- handling file conversion (we do this with TIFF -> GIF and TIFF -> PDF translations for a couple online systems we've written)

This system is written to be fast and to provide core services. It takes your best programmers to write it, and you test the hell out of it.

The front-end system can run anywhere, via any Web server, written in any language. So long as it can connect to the dedicated server (via URLs or a simple socket-based communications method), it can do simpler processing and the generic request/response cycle.

Your more junior people can easily handle writing the front end then -- they just use the API to the server, and handle the tasks of the presentation layer.

This means speed is less of an issue (the optimized server handles it, and can even act as a transaction processor or middleware), and the parts of the system that change most (the presentation and navigation) are easy to code and do not affect the underlying business logic.

Sometimes it helps to be creative like that, it's solved a lot of problems for us. Your dedicated server can even be as simple as something like Apache+jserv with some simple servlets that are accessed via URLs and return an XML document as a response. This also helps when you eventually want a more distributed, load-balanced system. Have too many image conversion requests? Add another dedicated box for that purpose, and made it part of a round-robin DNS scheme.

CGI Languages

[msuzio]

My comments on languages and their usefulness in Web programming (I have to make this short, but I've been doing this for a long time now, so email me if anyone has questions and wants my humble opinion)

Perl
Awesome language. Great library support (stellar, really) and very easy to learn. Stick to good programming practices, avoid the dark side, and you can do a lot with it.
For anything beyond trivial apps, mod_perl or a similar accelerator is definately needed.
Object oriented programming is fairly nice; it allows OOP without being strictly wedded to it, and it has very powerful introspective and adaptive features (closures, ability to interrograte and modify the symbol table so you can actually *add* methods dynamically as the code runs. Wow. Allows multiple inheritence if you really need it).
Database programming via DBI/DBD is very well supported.

Java
Another good tool. A very nice OO syntax, strict exceptions to insure a robust system, and an architecture for using it with a Web server (Servlets). Add to that JDBC (which is well supported, and not hard to use or learn). Also add introspection and built-in RMI.
I haven't used Enterprise Java Beans at all yet, but I like the concept. Implementations seem fairly weak and non-performant so far, however.
I would prefer Java over Perl in cases where I needed to have a distributed system that might talk to other systems I didn't code or have ability to modify. In Java, CORBA and RMI are pretty easy to use, and EJB support will probably be well worth having in the somewhat near future.
Java is a lot more inherently performant than Perl, although the difference between jserv and mod_perl is not all that huge in our tests.

Bad points of Java: the compile cycle bites once you're used to Perl (edit and run). It also is a tad too strict (again, once you're used to a more free-wheeling approach in Perl).

Tcl
Phil at photo.net loves this. He uses it in AOLServer, which handles embedded Tcl (somewhat like mod_perl?). It has the same sort of benefits as Perl (no compile cycle, loose syntax and ability to do things more than one way, several libraries), but I personally never liked Tcl all that much. I wouldn't rule it out, though, check out photo.net.

C/C++
As usual, use this for maximum speed. Despite any claims people might make, Java is even in the best of cases not as fast as C. However, C is not going to be the fastest language to develop in, and since speed to market and ability to adapt are often key in Web programming, I tend to not consider C or C++ a good choice. The lack of a lot of external support or common specs hurts C and C++ -- I'm not aware of a server-independent API for "embedded" C code (like Servlets are for Java, for instance -- code that runs with the Web server persistantly or on some other persistant server). C could be great for implementing a separate server process that front-end scripts connect to from the Web server. Imagine a mod_perl front-end that connects to a server written in C -- this could be pretty fast and have a lot of flexibility.

Just throwing ideas out. Maybe this answers some part of your question??

Oh yeah, speed of text processing!

[msuzio]

Duh. Forgot some good points.

Perl is great for two other reasons: text processing in general is great (the language was built to do that as it's first design goal!), and regular expression support is first-class.

Given that most Web programming is pure text-processing work, Perl has a big leg up there. Java lacks simple text processing (it can do it, but the code is more verbose and harder to write), and C, although fast, has little text-processing built in to the standard library (other than scanf, strtok, and other functions I'd love to forget ever having learned ).

So yeah, another win for Perl. Text processing is easy to code, and fairly well optimized, given that it's the core of the language. I also find DBI/DBD easier than JDBC!

So, to reiterate, my preference is:
Perl, Java, C, C++

But choose wisely! Pick something you feel competant to program in, something that addresses your needs of speed and complexity, and something that is maintainable!

As an aside, I skipped all those "code in page" paradigms: ASP, PHP, JSP. I just cannot pursue those sorts of paths, because in all my experience, the need to totally separate presentation and code is pretty strong.

"Hey, you got code in my HTML!"
"Hey, you got HTML in my code!"

Not a nice mix :-).
(As an alternative, we use a templating language with XHTML + XML that our code can "fill in" values in and branch around conditional text.
Home grown, but very effectively for our purposes)

Apache C module

[raph]

mod_virgule, the engine behind Advogato, is written as an Apache C module, a fairly unusual choice for server-side scripting. My experiences with it have been very positive, as have been the other sites that use it (Skolos, a discussion forum for sexuality issues; Jabber.org, the Jabber developer's website; and a couple of others in the works). Advogato has been slashdotted several times now, and the load meter barely moves. That's one of the really nice consequences of programming in C :)

There are a few reasons why mod_virgule was a more pleasant programming experience than your usual CGI script in C. First, Apache's pool mechanism lets you use memory without having to worry about freeing it. It's almost as convenient as using a garbage collected programming language. Second, the Apache module API contains a lot of functions for regexps, tables, lists, and so on. These are the most important features of Perl that are lacking from raw C. It's nice to be able to write code in C that has a bit of a Perl "feel".

Finally, mod_virgule uses XML extensively in the backend, using Daniel Veillard's excellent libxml for parsing and handling. The use of XML makes the code for the site a lot cleaner.

So, I suggest that you not reject C out of hand just because it has a reputation for being more difficult or time-consuming to program than your more popular interpreted scripting languages. For what I was trying to do in mod_virgule, it turned out to be an excellent choice.

Re:The list

[drix]

The fact that you are all but forced to run ASP in NT is not a valid reason to hate it. ASP is a very capable interface, and it allows for pretty much any language to be embedded in it. Just because the server your running on might BSoD does not mean ASP is bad. On the contrary, it's one of the few innovative and functional things to come out of Microsoft in the last few years. I daresay it is better than PHP in a lot of respects. Not tying you to a single language is one of them. ASP is a bit slower, but there is a lot of developer support for it, and it is a lot easier to write complex web apps using ASP than in PHP or Perl or C or any combination thereof.

--

Python or Perl

[TimeHorse]

Well, to preface my bias, I've no great love for Perl and am a Python-head tried and true.

Now, what you choose SHOULD be based on your server. Although in this case I'm of the Linux mind, I do see MS IIS or whatever as a valid if somewhat more buggy variant on the web-server landscape. Apache is still the best server out there if you want real POWER over you system. So, the first question you have to ask yourself is what platform you will be using. In the Win32 world, you have a lot more choice than most realise because there is not only ASP, as simple Microsoft Scripting language (though I personally abhor it) and the Microsoft Internet Classes for both MFC and COM. One thing you have to watch out for though is depending on the client browser's platform. Relying too much on Win32 could completely alienate Macintosh users, never mind *NIX. However, there exist Win32 ports for both Python and Perl so whichever you choose you should be safe in developing for the target server platform. I personally give extra points to Mark Hammond's WinPython UI. Also note that Zope has been ported to Win32 in case you decide to go the Python-Zope route. More on Zope later.

The beauty of CGI is that it only runs on one or a small number of machines so you have complete knowledge of the architecture on which your CGI will run. Such is not the case for UNIX Shell Script [sh, bash, or *csh], and except for the smallest of Web applications, Perl is typically just as good. Such is not the case with JavaScript or VB Script or even the state of the Java VM of whoever is your client. One thing I will say though is if you're sure you'll have a small client base, you can safely rely on your clients all running the latest version by forcing them to get it from Sun periodically. However, if the client base is large, this is prohibitive. Not only will you get more complaints from people regarding the frequent updates, but also you'll have a greater chance of introducing bugs because the users are not properly updating. The alternative is to stick with the AWT 1.0 distributed with most browsers and suffer all those nasty bugs with a lost of nasty kludges.

Anyway, so I've brought up Java, and now let me relate it to CGI. Basically, the question is, who plays better with Java: Python or Perl. I think given JPython alone Python can take that match, so if your client base is small, or you can suffer all the kludgy bugs of the nasty Java VM distributed with most web browsers, and you want to distribute some of the work over the clients using Java, Python is the way to go.

Next I want to discuss text processing. Text processing tends to be a big part of web development and thus having a good parser is a major benefit. In this contest, Perl wins hands-down. There is no better language for text parsing I know of, and not even Snowball can out-perform Perl in this respect. However, Python 1.6, now in Beta, is supposed to introduce UNICODE Regular Expression matching narrowing the gap between the two languages quite a bit.

Now for size, each language can serve a different need entirely. For small-scale applications, Perl is easy to hack and quickly get your programme out. However, once you know Python, you can code at comparable speed. The Python advantage comes out in the large-scale project. Since Python is a strictly-syntaxed language as opposed to the more free-form Perl, it is typically much easier to understand for the new programmer or developer. It is much easier to debug Python code than it is Perl. However, a skilled programmer in either discipline will code the same application in near comparable time, the training a Python coder to use Perl or a Perl coder to use Python is usually pretty easy to do, though the time to train in a small application may not make it worth it. As a rule of thumb, the larger the project, the more of an advantage you'll get out of Python. Also the more hands you need to develop a project, the easier it will be to co-operate with Python, as the code is easier for an outsider to understand.

Now both Python and Perl have a byte-code and many many libraries, so there is little advantage with either, though perhaps because of the longer life I think we can give reusability over to Perl. After all, more people have been developing Perl than any other CGI language over time. The same goes for third party support, such as connecting to a database. One advantage I think Python has though is the ease with which one can convert Python code to ANSI C++, my personal language of choice. With the Python / C++ combination, one can develop prototypes quite easily and quickly in Python, then slowly move each component over to C++ for speed. [Yes, you could move to ANSI C too, but why would you want to when good C++ code can be just as fast and is a lot easier to understand.] To be sure, you can do the same thing with Perl but the languages [Perl and C++] don't convert as well and the interface, as will most things Perl, is rather kludgy.

Now, there is one issue with web development that neither Python nor Perl do address well, and that is remote development. Typically to do remote development, you have to either SSH / Telnet to the server and do your work there, or more typically run a web server locally and synchronise files from time to time as needed for each version. However, with a tool like Zope, you can do all of your development remotely without having to use ftp or telnet. Plus, Zope is built from Python so you can extend it with packages and external methods written in Python quite easily. The downside to Zope is that for package development it is very tedious to use. The problem with Zope is that for every change you make to a package structure, you need to restart Zope for it to recognise the changes. This can be tedious in the extreme. Another possibility is Microsoft Visual InterDev, which relies heavily on Microsoft components and architectures. I don't recommend it for anything but the most Win32 of circumstances. There is also Web Objects, which can make development very simple but the price / performance ration is usually out of the range of all but the most corporate of servers. However, none of these give the true Web feel of a good CGI script and there is no substitute for the usefulness of Python or Perl.

In conclusion, I'd say you could use either language for just about any web application, but certainly for pre-existing libraries Perl is your best bet, and for long-term development you should go for Python. Whatever you choose, I wish you luck and hope that I can in even a small way have been some help.

Be Seeing You,

Jeffrey.

Re:CGI and ASP

[fatboy]

You can escape quotes by using "".

example --

response.write "This is a ""test""."

I have found the most frustrating thing about vb scripting under asp is the syntax.
Such as

response.write "This is a line 1." & vblf _
& "This is line 2." & vblf _
& "This is the last line"

I like php3 and perl. You can do this...

print ("This is line 1.
This is line 2.
This is the last line");

With that little ; you know where the end of the line is. It makes tracking down syntax errors _ALOT_ faster.

ASP does have some nice real world features to it that make things easy, such as formatcurrency(). I hate having to write a function to format a number as currency.

On the other hand, I _LOVE_ how php3 will assign values to variables that posted to a page. No more request("variable") or request.cookies("variable"). You get $variable.

I have to program asp at work, but I love php3 :)

I don't buy the difference as being that big

[tilly]

If you want computations, I agree that Perl's native calculations are not the fastest. Use PDL or Math::PARI or some other extension.

As for mod_perl and multiple CPUs, that is no problem. Apache is designed to have multiple child servers running in parallel. Different children get different CPUs and so mod_perl will scale across CPUs. If you want single requests to multi-thread, this is not good. If you want to have multiple people using the site at once, this is quite sufficient.

Of course this has issues on operating systems like Solaris that do complex things to try to optimize threads. But when Linux can do a process switch faster than Solaris does a thread switch on identical hardware, I have to wonder whether those complex things are worthwhile.

Now redundant memory usage is a real problem, and a big one. mmap helps (a lot) on this, but this is a big loss for Perl. No, it won't be solved soon. But then again Perl has always taken the view that memory is cheap, and indeed it is getting cheaper and faster. So it probably isn't that big of a loss either.

Another big loss is clustering. Java solves that better than Perl does. Perl is dependent upon the OS. Of course the direction that Linux is heading is very clustering friendly, Apache has pressure to do likewise, so again you can act as if that it is not Perl's problem.

So yes, I agree with quite a few things that you said, but I don't think that it reflects badly on Perl.

Cheers,
Ben

Don't underestimate the power of builtins

[Lazy Jones]

Java is fast enough for many things, but many implementations are still slow (e.g. FreeBSD's stock JDK 1.1.8), especially at tasks for which other languages have extremely fast built-in functions (while for a Java solution, Java code has to be written). For example, try to sort a string array quickly in Java (not uncommon for text processing such as for HTML) and then compare with perl's extremely fast and elegant sort() function. Also, Java's strings are Unicode strings, so they occupy twice as much memory as Perl strings (interesting if you're caching lots of stuff and for some reason don't want to store everything as byte[] - what a kludge).

The builtins (esp. those of PHP3) also save you a lot of typing. The great advantage of Java Servlets (over mod_perl and PHP3) at this point is, that it's so easy to share data among Servlet threads, so they are much more memory-efficient if used correctly.

The answer is simple

[Syberghost]

The answer to the question "which CGI language is best" for a given task is practically the same as the answer to the question "which gun is best for a gunfight":

The one you know.

More specifically, the language you know well enough to write the required program.

If you're struggling to make it work at all, it won't work well.

Now, if you're wanting to know which languages you should LEARN, we're headed into religious war territory, but here's my opinion:

Perl and Java.

Between the two, you have enough options to do anything, including compilation with processor-specific optimizations, and you'll find more documentation than you can shake a stick at. You can practically close your eyes and grab a book at random from your local book store, and have a reasonable chance it's about one or the other.

--

languages

[willhelm]

Most of the CGI that I have done either revolves around string munging or database access. Some of it involves running as root (ick!). For this Perl rocks. Apache with mod_perl is very cool. Very little you can't do with that combination.

Some of the CGI that I have done is intensly complicated and involved a well thought out design and implementation. And it involved a bunch of people working on the same project--so it needed to be easy to read and object oriented. For this Python is really good.

Some of the CGI that I have done needed to run fast and I had canabalized it from other places. This is pretty much entirely in C. C is good, but takes too long to write.

Hyper Builder

[Azul]

I would like to invite you all to check out Hyper Builder, at http://bachue.com/hb. It is a very simple "scripting language" that allows you to solve many of the typical web-development problems very easily.

It has a system of modules (which can be loaded dynamically at run time or compiled into the interpreter). This works kinda like Server Side Includes where the tags are mapped to callback functions in the modules.

HB comes with a standard set of useful modules. Some examples are the SQL module (currently supporting MySQL and PostgreSQL), the Wall module (to make bulletin boards, guest books, etc), the polls module (with lots of code from Pollera, a standalone application for making polls on the web), the Perl module (to embbed Perl code in your pages), the access counter module, the authentication module (which can authenticate against different backends) and many other. They allow you to do things such as set/read cookies, show input from HTML forms, print the system time, show the output of system("commands"), send email, show/write files, etc., very easily.

You can also combine all those different modules very easily. It's kinda messy to combine all the different Perl scripts you just downloaded and have them show all their output in the same page. You end up editing different scripts to have them print the HTML the way you want and use something like Server Side Includes to tie them together. With HB it's natural to do things such as placing a message wall under the poll and allowing only registered users to vote (you are using the walls, polls and authentication modules here). And just in case you can't find a module to do what you are looking for, you can always go create it in C or Perl.

HB can run as CGI (useful when recompiling Apache is not an option and performance is not that important) or as a pthreaded application server that a Apache module provided contacts via a TCP socket (increases performance greatly and lets you run the application server and web server on different machines).

You can take a look at some examples of what can be done with the standard modules at http://bachue.com/hb/ex/examples.cgi/. The source code for all of them is provided in http://bachue.com/hb/ex/examples.hb.

One big advantage of HB over other systems such as PHP, Servlets, ASP, Perl, C+CGI and Zope is that it is very easy to maintain big sites designed on it. For example, showing an access counter usually goes like doing <counter src="file" inc="1" show>. In all the other languages, you usually have to open the file, lock it, read the counter, increase it, write it, close the file (unlocking it) and print the counter. Since everything is so easy to do, sites are very easy to maintain.

Anyway, I strongly recommend it for your web development.

Alejo.

Disclaimer: I'm the current maintainer of HB so I might be a little biased.

Did I miss something?

[Kismet]

My favorite CGI scripting Language has got to be POV-Ray. But I've heard that BMRT and RenderMan are the best, all around. :)

Oh, you mean the other CGI.

The Zend optimizer

[sammy baby]

For those of you who care about such things: the Zend optimizer for PHP is free as in beer, not speech. Please refer to http://www.zend.com/zend/optimizer.php

Most Obscure CGI Language: RPG IV

[RobertEdwards]

On an AS400 of course.

I am not making this up.

Yeah, it sounds nutty to me to.

Re:Don't use Java

[Raul Acevedo]

Nobody uses Java as a CGI.

People use Java with servlets and/or JSP, which starts up the JVM once, so the JVM startup time argument is irrelevant.
----------

perl is fast enough

[PotatoNO]

One if the things i'm often asked is if perl, an interpreted languange, is fast enough to handle large amounts of hits. I always point them to slashdot as an example of why perl works even in large scale situations. The important thing is to write good code, no matter language it is in. Things like fastcgi or persistant php can help relieve some of the forking/init overhead, but other than that its on the programmer to make sure its quick.

Re:PHP - how to avoid mixing code and HTML.

[Skapare]

So how do you code a loop in these "fast templates"? Oh, wait... you code the loop separately in the macro and just drop in the template referring to that macro to position its output. Yeah, that's it. Scatter the code around in pieces so I have to jump around from file to file to see what the hell you are really doing. That's not unlike having a bunch of function calls. But I don't think the boundary between separated chunks of code should necessarily be forced to be aligned at syntax class boundaries.

The whole issue of code mixing is just a special case instance of the long time argument about whether separation or consolidation of code is the better choice. And each has its advantages and disadvantages. The difference here is that we are fixating on a boundary between steps that are each optimally coded in different languages.

The solution I generally use (and there are exceptions to this, too) is that if the modular element is (or can be made to be) a re-usable piece of code, then it should be separated (e.g. make the template) but if it is just a component of the current object (page) it should be consolidated. For example, if I have a menu of actions generated from what permissions a user actually has rights to do, it may be re-useable (if more than one page would have the same menu) or not (if each menu set on each page is different). One option is to make it like a function call if I can pass arguments to it (but I don't see how you might propose a syntax to do that) such as giving it a list of menu items appropriate for this page for it to actually output those the user has permission to do. Of course, once you do that (add argument passing systax) you're moving back to mixing code because you're going back to programmer, rather than layout, syntax.

Personally, I'm not opposed to mixing code at all. I can read HTML, and PHP, or even C, equally well. My C code typically has tons of printf calls generating large blocks of HTML anyway (though I am working on encapsulating re-useable chunks of that into separate functions or classes). There is the question of which way is the best way to mix code (assuming you can be convinced that mixing is allowed). Should I just have HTML in output statements, or should I integrate the syntax as ASP and PHP do? I am currently planning to explore the latter with C/C++ as the basis language.

Using C++, but open to (constructive) suggestions

[bunyip]

Much of my CGI work has been done in C++, not because it's fast, but because I'm familiar with it and I can access everything. I have programs that call CORBA services, access databases and make system calls, all running on NT.

I'd like to use a scripting language to do this, but couldn't find something with ODBC, CORBA and the other pieces I need. For example, a particular CORBA interface may not have been tested with Visibroker, which is what I have, and I didn't want to spend a week figuring out how to compile/link all the add-ins I'll need.

Invitation - if somebody has a better way to integrate all this stuff, please let me know.

/bin/sh is it

[MeanGene]

Easy, portable, small interpreter, decent facilities.

CGI is the most improperly-used term on earth.

[mindstrm]

Really. Seriously.
CGI stands for 'Common Gateway Interface'.
It defines the INTERFACE between the web server and the 'CGI application' (meaning, an application using the CGI interface).

I'm SOOOOO tired of hearing about 'cgi languages' and 'cgi this' or 'can you write cgi scripts?'

Hey. I bet a lot of people who write 'cgi scripts' use a pre-built library to actually implement CGI, and couldn't actually write the CGI parser if they had to. (okay, I'm exaggerating a bit.. but hey...)

In other words.. there is no such thing as a 'cgi language', only software that implements the CGI interface spec.

Re:CGI is the most improperly-used term on earth.

[eMBee]

well, 'cgi scripts' does make some sense, since to me a 'cgi script' is a script that works with the cgi interface.

however, i'd like to add, that the cgi interface is outdated imho, it requires that a new process is started for every call to a 'cgi app' which is very expensive.
today there are much better things like mod_perl, mod_php ... or other servers that are easely extendable, like roxen, which allows for easy integration of your code with modules that others have written...

greetings, eMBee.
--

Re:CGI is the most improperly-used term on earth.

[Wah]

... is a script that works with the cgi interface.

wow, a Common Gateway Interface interface? :)

That's almost as bad as the W2K boxes that proudly proclaim it is "Built on NT technology." NT, IIRC, stood for "New Technology."

--

Re:CGI is the most improperly-used term on earth.

[gothic]

It defines the INTERFACE between the web server and the 'CGI application' (meaning, an application using the CGI interface).

I don't mean to sound sarcastic, but the 'CGI Application' is a script, therefor it's a 'CGI Script' ...Make sense? You write scripts in languages that implement CGI, and you write it for the sole purpose of being on a webpage, and going through CGI. Therefore, it basicly becomes a CGI Script in name.

It's kinda like 'Coffee cup' ...The cup isn't made out of coffee, but that's what the name *technically* implies. It holds coffee, so it should only be called a 'cup containing coffee' .. Never a 'coffee cup', or a 'cup of coffee'. Welcome to the American language.. =]

Re:CGI is the most improperly-used term on earth.

[daninja]

...having recently dethroned object oriented (the former most improperly-used term on earth).

The ongoing code vs. presentation argument

[JohnZed]

Man, people get DAMN religious about this one. I totally support back-end components, because they increase the readability/maintainability of code and enable code re-use. However, I CONSTANTLY hear about people taking this to unnecessary extremes.

For instance, I really enjoy working with JSPs. The "purists" complain that they encourage you to put code in HTML, but, damn it, there are times when you need code in HTML, such as loops, if/else logic, and tiny utility functions. Forcing all of these into the back-end components ends up putting too much presentation into the logic, so the components lose their generality.

If you constrain your Java-writing to the syntax you learned in the first week of "Teach Yourself Java in 21 Days" (i.e., don't do any serious coding, and don't import packages other than your custom components and java.util in most cases), you'll be in good shape. Why use a separate macro system (as I used to do before I switched to JSPs), which will simply force you to learn another syntax? Just don't go making frickin' SQL queries from your JSPs, either!

By the way, I do recommend Resin from caucho.com if you're interested in JSPs. It handles some cool things, like database connection pooling (very important!) for you and, coolest of all, it supports JavaScript as a for JSP development. Just as serious Java coders shouldn't have to go learn some other macro syntax to code pages, web designers should be able to use a language familiar to them, which, in almost all cases, is JavaScript.

--JRZ

arghhhh

[rm -rf /etc/*]

Every time, every single time this comes up at least 20 people ALWAYS ALWAYs ALWAYS say PHP is bad because you embed the code in the html. Let me clue you in since you apparently don't bother to research this stuff. When it comes to outputting html from php, IT IS ABSOLUTELY NO DIFFERENT THAN PERL. Read it again for the first time. Perl offers you what? Templates, print, requires, and functions to seperate content from layout. What about php? Templates, print, requires, and functions. Woah, perl is so much better! Oh, don't foget that php can actually be used from Java Server Pages to seperate content and layout...

Hmmm...

[toofast]

I hadn't thought about MySQL, but It would make sense. I use mod_perl on a 200Mhz site and it's never sluggish, no matter how many CGI requests it gets. Thanks for the insight.

Perl is fast enough, but not for Slashdot

[toofast]

Slashdot uses Perl, but have you noticed how slow Slashdot is? Not to flame, but Slashdot is getting real slow, and it's not because of bandwidth. I get 64ms ping times to Slashdot. But Perl, even with mod_perl, is sluggish, no matter how many BogoMIPS you throw at it.

I do love Perl though, and use it a lot on my own websites. But when the websites get too many hits, Perl can't scale the traffic.

The list

[angelo]

If you are running IIS: ASP
If you are looking for something easy: Python or PHP
If you are looking for speed: PHP4/Zend Optimizer
If you are looking for flexible: Perl
If you are looking for good XML compatibility: Perl/Java applets/PHP+expat
If you just want to make headers/footers for a common theme: SSI/XSSI

Now, I don't know about most webmasters, but the three I see most often are Perl, PHP, and ASP. I have to admit, ASP is great for connecting to databases, as long as you grab someone else's code. PHP has built-in ODBC connections, and Perl has modules for it.

Perl seems to have the most free scripts written for it, followed by PHP. ASP seems to show a strong commercial following, which is not a surprise.

If you know C, PHP is easy, and Perl is as well. PHP is a bit more strict than Perl. Perl has more than one way to do things down to an art.

ASP is OK, but if you have a choice, stick to plain HTML. We have a phrase when it comes to ASP in our office. The phrase is "what were they thinking?" and it applies to anything from the choice of VBasic, to Management's deciscion to implement it in the first place.

I prefer PHP, for its flexibility, it's portability (moreso under version 4) and its ease of use.

Re:The list

[Alakaboo]

Why does ASP/VBS suck so much?

It's a scripting implementation of a visual implementation of a language that Microsoft stole from someone else who should have had it terminated while it was still in the womb.

Let's look at the basics:
1) It's dot-syntax, in a way that it's far more like JavaScript than Java. dot-syntax languages make sense until you get about five levels down, then it's just confusing. (parent.frameA.location.form['a'].options.index.go atAss.com.dot.dotdotdotaAAHHH!!!!)
2) There's about five ways to do everything (like Perl) except none of them work (unlike Perl). I spent about three hours trying to figure out how to do a query back in Visual InterDev 1.0. I tried the online help example. I tried the other online help example. I tried the example out of the book. I tried the example online. I tried an example out of a newsgroup. None of them work! Finally I wrote my own using an average of one line from each example. That worked. But only for 'select' statements.
3) The tool (Visual InterDev) sucks. And it's expensive.
4) The operating system (Windows NT) sucks. And it's expensive.
5) The webserver (IIS) sucks. And calling for tech support is expensive.

But out of all of these, one reason stands out:

6) THERE ARE BETTER SOLUTIONS!!

</rant>

Alakaboo

How can you blame perl for slashdot's sluggishness

[jslag]

It is true 1. that Slashdot uses mod_perl, and 2. that Slashdot is pretty slow, but why do you assume that #1 is the cause of #2? How do you know that the mod_perl processes aren't idling and waiting for the database to respond, which would be mySQL's fault? Or maybe the problem is that (as far as I can tell) a proxy isn't being run between user requests and the heavyweight mod_perl apache servers? There are a ton of things that can slow a web site down, and there isn't enough information available to us regular Slashdot readers to tell what piece of the process is to blame.

Perl Isn't always the answer

[ravenwing_np]

...it is just the answer most of the time. I have found perl to be useful for quick prototypes of server behaviour and good for little hacks. Once the main ideas are flushed out, it is time to implement the code in C if you really care about speed. I'm old school, so I like working with C.

Perl and Java are good for things that use databases. Maybe python too. Lisp is good for algorithms. C is good for speed. VBASIC is useful for windows dependant stuff.

Avoid shell scripts. Use safe_perl, safe_python or the equiv. Use lots of ASSERTS in you C if you do that. Watch for NULL obects in Java. Let someone else warn you about BASIC-like languages. Then use the language you are most comfortable with.

JavaServer Pages, or Java-based Web applications

[scode]

JavaServer Pages (for smaller stuff) and full-blown Java based web applications (with, for example, Enhydra (www.enhydra.org)) for anything large.

Why?

* Java is fast (and please, don't start dissing Java because it's not natively compiled). Java executes much faster than, say, perl, ASP or PHP. The inital overhead in displaying a JSP is larger than invoking a perl script (assuming you're using mod_perl), but that's not because Java is slow, it's because of all the features the servlet/JSP runner implements.

* Java is OO. IMO, this is a great advantage, although I guess many will disagree (especially here on /.).

* Java is very much suitable for writing anything from small hit counters to large-scale web applications. The reason for this would be obvious to anyone who has programmed Java for a while. I personally can't imagine writing anything large in perl.

* Java is cross-platform.

* Java is a GC:d language (this argument doesn't apply "against" perl of course).

Q1: What problem are you trying to solve?

[sohp]

Your question boils down to Which languages go best with which tasks? That's an excellent place to focus.

If you are doing classing CGI, you first task with every request serviced will be to get the query params and the host environment. Look for a language that provides good facilities for that. Perl's CGI.pm is a good example, Here's how simple it is:

use CGI.pm

$q = new CGI;
@querykeys = $q->param();
foreach $key (@querykeys) {
print $q->param($key);
}

I'm sure fans of other languages can come up with similar languages.

Most, if not all, CGI handling will involve some text manipulation. There are few arguments that Perl is king of that domain.

Will you be doing any database accesses or otherwise responding to the request with persistent data? Look for a language that supports some kind of useful DB interface.

Do you need to maintain session state? You'll need a language that provides facilities for easy cookie handling or URL mangling.

The only language I know that meets all these criteria for straight CGI is Perl. If you are willing and able to go to the next step beyond CGI, look at Java servlets and JSP.

Re:Don't use Java

[SuperKendall]

What would you need regexp support for in the course of normal web programming though? It seems like most of the use of regexps would be for filling in templates to return - in Java you could simply build up a nice template engine (there are some free ones and some app servers come with them built in) and probably have an easier time filling templates with anything you like.

There are regexp packages for Java, and it's true they are more cumbersome to use than the ones in Perl, but I think that because of general support in many areas regexps are normally used you really don't need to use them as often even to support a very generic system.

Re:Some language, any language

[plunge]

IF I understand the question: yes PHP can do persistent connections. Only when running as a ISAPI module though, not when it's used as a CGI/external call (i.e. only when you aren't using a *NIX with Apache or other server with proper ISAPI support)

Re:I disagree

[plunge]

I think this might have a lot to do with MySQL- many people reading isn't anywhere near as big a deal as everyone posting, since the way MySQL does table locks significantly slows things down.

Re:What I believe

[plunge]

Hold on everyone- he's done tests!

Re:Incorrect!

[plunge]

What the heck are you talking about "incorrect"- you basically just repeated what I said. I just put the word ISAPI beofre "module." Let me say that again- it has to be run as a module for persistent connections to work. It cannot do them when run as a CGI, as many windows users have to.

REXX

[Atomic Frog]

Yah, why not Rexx? It's just as easy, if not easier, than Perl. It's available for just about any platform (OS/2, Linux, AIX, WinXX, OS/390, Amiga)... and you can do funky platform dependent stuff too if you want.
Want a short tutorial?
http://www.slac.stanford.edu/~bebo/rexx/title.ht ml
http://www.networking.ibm.com/icserver/pub/icswp g42.htm

Ask Slashdot

[DonkPunch]

Dear Slashdot, what "Ask Slashdot" question would be most likely to generate a flamewar?

1. What editor should I use?
2. Which window manager should I use?
3. What license should I release my code under?
4. Which programming language should I use for _____?
5. Which Linux distro should I use?
6. Linux or GNU/Linux?
7. Big-endian or little-endian?
8. Buy or lease?
9. Boxers or briefs?
10. Blonde, brunette, or redhead?
11. Paper or plastic?
12. Ginger or Mary Ann? (Ladies: Professor or Gilligan?)
13. Tastes great or less filling?
14. How many licks does it take to get to the Tootsie Roll center of a Tootsie Pop?
15. Star Trek, ST:TNG, Deep Space Nine, Babylon 5, or...?
16. Shaken or stirred?
17. Color or monochrome?
18. Frames or no frames?
19. Country or western?
20. Walk or Don't Walk?
21. Dr. Drew, Dr. Ruth, Dr. Laura, or Dr. Suess?
22. Joystick, mouse, or keyboard?
23. Cooperative mode or Deathmatch?
24. POP3 or IMAP?
25. Hex, Octal, or binary?
26. WHAAZZZzzzzzUUUUUUuuuuP?
27. Troll or Flamebait?

(Sorry, I got a little carried away.)

PHP - how to avoid mixing code and HTML.

[at-b]

Why, oh why?

For some bizarre reason, people in this thread keep insisting that the best choices for web scripting languages are those that don't mix the actual code (aka the 'logic') and HTML code.

And of course, they have a point. Unfortunately, they then argue that PHP is a poor choice because you have to mix PHP logic and HTML code in pages, (usually ending in .php3 or .php or whatever), which leads to obfuscated code, poor maintenance, and difficulty in separating the coding bit from the designing bit. And indeed, that's a bad thing, since your average interface designer will understand very little about those odd DB calls in the page, and will want to concentrate on getting his DHTML to display right.

So, PHP is a bad choice, right? Wrong.

Most people here seem to be completely oblivious to the fact that PHP3/4 can use the FastTemplate.class, which is (for Perl people out there, just another module) used for just that purposes - creating templates that don't have any PHP code in them. Instead, they have XML-like PHP calls in all the right places, and nothing else.

Example: Let's say Slashdot was coded in PHP, using Fast Templates. I haven't looked at the Slashcode lately, but I'm guessing that at the top of the page, it references your currently-used login name, and displays it. If Slashdot were coded in PHP, it could either have

get_current_loginname() ?>


or whatever. PHP code, right? Ugly. Don't want to mix code and HTML. So instead, we're using Fast Templates.

{DisplayCurrentUsername}

And that's pretty much it. You can predefine dynamic rows, blocks, whatever, and play around with variables inside them, but you simply use { } to denote a dynamic Fast Template call, and that's it. The entire code side is then handled by another fast template code file, call it index.php or whatever you want, where the defined { } variables are defined and coded in PHP. Which means full separation of code and HTML. When your designers start messing with the page, all they have to do is to remember to insert very short, simple calls like the ones above wherever they want to have them. They can even use font tags or any other mean of design to change the { } output in any way they wish, so the entire design part is up to them, and the coders don't have to worry about Netscape4x backwardscompatibility, etc.

And btw - Fast Templates really are fast. With the upcoming PHP4 Zend optimizer, tests have shown 100%+ speed increases over ASP, and it's all free, and well-documented. PHP has great database interaction modules, and for a site like Slashdot (or, to use an example that actually uses PHP, Freshmeat) there is no faster solution that PHP+mySQL. Many of the sites out there that have filenames ending in .tpl are in fact PHP template sites. No obfuscated code, and clear separation of form and content - isn't that what modern web coding practices should be about?

But of course, if you do choose that path, you will have to explain to your boss why that critical project came in way under budget, and much faster than expected. Won't that be just horrible? :-P

Alex T-B

Some language, any language

[Russ Nelson]

I'd like to see a persistent scripting language which is a first-class peer of the server process. Yes, I know you can do this with Apache if you load enough modules, but I view that as cruft. Has anyone started over again to create a threaded server which can hold a database connection open without the complexity of, say, Zope, or mod_perl?
-russ

Re:Some language, any language

[qohen]

AOLServer (www.aolserver.com) is a free, "one-process-with-threads" web server whose strength is that it keeps open database connections that you can get a handle to as needed, so you don't have the usual overhead of spawning new processes, etc.--using the TCL API you'd say something like this:

set handle [ns_db gethandle]

Using ns_db with other arguments you then get to do your queries/inserts/etc (simplifying just a little):

ns_db $handle "select * from table"

ns_db dml $handle "insert into table (field1, field2) values ($value1, $value2)"

Then, when you are done, you just release the handle:

ns_db releasehandle $handle

Each AOLServer process can hold 8 database connections open.

AOLServer 2.3.3 is free, non-open source. AOLSerer 3.0 is free and open source, thanks to the efforts of Philip Greenspun and company.

Philip has written an intro to AOLServer that was published in Linux Today, it is now available in two parts here:

Part 1

Part 2

A quick quote from part 1: "AOLserver runs as a single Unix process. You can deliver the 20 dynamic pages per second of our example without your server having to start any new programs. If those pages need to connect to Oracle, they simply ask AOLserver to let them use an already-open connection from a configurable pool. Note that this ability to pool database connections is a consequence of AOLserver's one-process-with-threads architecture. With a process-pool Web server such as Apache, nothing stops you from linking in the Oracle C libraries. Your Apache server can then function as an Oracle client. However, there would be no way to share a database connection among Apache server processes. What's the bottom line difference? A site like http://photo.net can serve 700,000 hits per day, to about 120 simultaneous users at once, with one AOLserver process holding open eight connections to Oracle. That's a total of nine Unix processes (one AOLserver, eight Oracle). With Apache, providing the same level of service from photo.net would require 120 Apache server process, each of which held open two connections to Oracle: 360 processes total.

Another dividend from the single-process architecture of AOLserver is that you can cache stuff in AOLserver's virtual memory. For example, consider the Bill Gates Personal Wealth Clock (http://www.webho.com/WealthClock). It gets as many as two hits per second at peaks. Yet it relies on invoking CGI scripts running at foreign Web sites where they probably wouldn't appreciate getting hammered by my server. The solution is to cache the page in AOLserver's virtual memory. Again, this is something you could do with a process-pool server such as Apache but you'd be gradually building up 120 separate copies of the same data. "

Part 2 shows how to use the "ns_db" command that I mentioned above in some detail.

P.S. Philip Greenspun developed a great open source toolkit that sits on top of AOLServer called the Ars Digita Community System (aka the ACS) and wrote a book about it that is well known as a must-read for web-heads. It is on line for free, complete with all the photos:

Philip and Alex's Guide to Web Publishing

P.P.S. There's a version of the ACS available that uses the open-source Postgresql database, if you don't want to pay for Oracle: Open ACS (they have a working beta but are waiting for Postgresql 7 to come out before making an official release).

Only dynamic content, BTW

[Russ Nelson]

I'm only interested in dynamic content, by the way. For static content, we have Dan Bernstein's publicfile server. Small, fast, secure.

It depends on what you want to do.

[segmond]

This is a very "stupid" question. It is just like someone posting on slashdot and asking what language do I use for database, or game programming and so forth. There is no one simple language to use for CGI programming, you use the best language for the job. CGI is a gateway, thus the langauge is irrelevant. For example, I had to write a CGI script to query a remedy server and submit to it. The only remedy API I knew of was C, so the entire CGI was done in C. In another project, I just needed to do a very small job, I did it in PERL. So when I am doing CGI, what I care about is what I am working on, if you are generating HTML pages a lot from your CGI, you might prefer PERL and Python.

THE CGI Language

[NullGrey]

Perl's good, shell's good, PHP's good, but it's hard to beat...

MS-DOS Batch Files!!! Yah, baby!

Also, look into writing your CGI in COBOL.

Re:CGI and ASP

[CrayDrygu]

Let's take these in reverse order...

No way to escape quotes in a string??? Are you kidding me?

Yup, whoever told you that was kidding. Just use two quotes in a row. The string > becomes:

"He said, ""Why me?"""

ASP is good for really small projects, but trying to do something involved with it is so frustrating.

I'm not going to argue with this, but I will say that it definitely can be done. So far, the worst thing I've done with it was Tic-Tac-Toe. Or here if you want to see the source.

Correction to parent

[CrayDrygu]

The string > becomes:

Whoops, somehow forgot I can't use angle brackets... that should read:

The string <<He said, "Why me?">>

Lesser known CGI Language? How about Ada?

[EverCode]

You cannot get anymore obscure than using Ada for a CGI app. Here is the packages for it.

Ada is the highest level language there is, even above Java. The military uses it the most.

If you need strong data-typing and easy code management, Ada is a good route to go. There are compilers for many platforms.

"...we are moving toward a Web-centric stage and our dear PC will be one of

Lisp

[alispguru]

Seriously. There's a good chance you've already visited a web site running Lisp, and didn't know it (Yahoo Store for one). Lisp's forte is extreme dynamic content that requires persistence or cross-session communications.

Check out any of the following:

SIOD - A small, easy-to-extend Scheme interpreter that can be used to do CGI.

AllegroServe - This is a small Common Lisp based web server which can sit behind Apache or do it all itself. They have a very nice mapping between Lisp lists and HTML that makes dynamic content generation a breeze. The source is currently implementation-specific, but it's LGPLed and available at Sourceforge.

CL-HTTP - If you want to do dynamic content and don't want to learn HTML, this is what you want. Query processing and page generation are buried behind deep and powerful abstractions. Long learning curve, but worth it for really complex stuff.

There are others, but I don't have the links handy right now.

Re:With all due respects...

[Phrogman]

There is nothing which prevents you from reading in template files when designing using PHP3, in fact its a piece of cake to do, and I am using it in at least one area of my current project. You can do anything you want to do in PHP that you can do in Perl with regards to includes, functions, templates etc.

There is even a group currently producing some sort of meta-scripting language for templates that is used with PHP - although I know nothing more than that about this project (Personally I think it is unnecessary because PHP is already so easy to use that it hardly needs an even simpler scripting language dropped on top of it).

Perls advantage is that it offers greater flexibility in the methods you can use to construct your script than PHP does. PHP's advantage is that someone else coming along after you can very easily determine what your script is doing - which is a different matter with Perl.

Its probably comes down to a matter of personal preference. Both are excellent scripting languages, both have strengths and weaknesses, both have their advantages in specific situations. I personally prefer PHP because I find it easier to understand, suited to my needs, and capable of rapid development.

PHP

[Phrogman]

If you are building webpages I think the best tool is undoubtedly PHP. It has all the power of perl (with the exception of regexes which are not as evolved) and it is far faster to develop in, and probably to learn as well.

It supports multiple different databases, including mysql, postgresql, as well as any ODBC compliant db.

Version 4, due to be released this month I believe (its currently available as RC1) offers an optimizer (available at Zend.com), and will come with a compiler as well.

It easily integrates directly into your HTML code. It is multiplatform, and its free.

Its main advantage is the ease with which web applications or websites can be developed. I am currently working on the software for the backend support of several websites, and using PHP I am able to develop this application very rapidly. Far faster than I might be able to do with Perl.

Obviously for those who already know Perl, they will be able to develop just as effectively in that scripting language anything that can be done in PHP. But for the new user seeking to learn a scripting language, PHP cannot be beat.

Heh

[CausticPuppy]

Or more correctly, that's what you think ASP is.

Java Servlets

[heffel]

• Servlets provide access to a wide array of Java APIs to do practically everything, including JDBC for database connectivity to a wide array of databases, RMI/CORBA for distributed computing, etc.
• A new process does not need to be spawned with each http request, resulting in better performance.
• With JSPs it is simple to separate the static parts of your web page from the ones created dynamically.

Re:Using C++, but open to (constructive) suggestio

[Greg Koenig]

Another poster suggested Python, and I would like to agree with that suggestion.

On NT, Python can access any COM object that you can script with, say, Visual Basic. Since nearly every application on NT is also accessible via COM, this opens many possibilities.

On NT, Python also includes the ability to talk to ODBC data sources. I believe there is direct access via ODBC class libraries. If not, you can definitely use the ADO COM objects (I have done this to access SQLServer).

Python has good access to system calls on whatever platform it is running on via its rich class libraries. This is also the case with NT.

Python has a CORBA ORB, called FNORB, available that should be able to interoperate with Visibroker.

Check out www.python.org for more information about Python. There is a link from the main page to Mark Hammond's extensions to allow Python to run on Win32. You need to get two things for this: the base Python package for Windows, plus a package of extensions.

Finally, Python is undergoing a transition from the current version (1.5.2) to the new version (1.6) due out by the beginning of June. Any 1.6 stuff you see will be alpha/beta quality code.

Best of luck to you. I hope you find Python as enjoyable to work with as I have!

Re:CGI and ASP

[CodeMunch]

How is it more difficult than perl or php, etc.. for large projects??

If the script itself can't do something I can create a component and call it through ASP. I can also separate my display/data/logic layers that way.

One of the beauties of ASP is you can use vbScript, JavaScript, PerScript (more perlscript), etc...to develop with as well as COM object built in vb, C/C++, etc... There are also MANY good code snippets and help available without having to look hard.

Some good URL's:
ActiveServer pages.COM
4guys from Rolla
Abundance of helpful mailing lists & FAQ's
ASPToday
ASPHole(Under construction right now)
15 Seconds
and a whole slew of other good sites (they usually link back & forth to articles.

If you want a " in your string with vbscript you can stick in two " and it'll be escaped OR you can append the Chr() of it to the string.

So far the only limitation I have come across has nothing to do with ASP: HTML sucks for complex forms. Client side Javascript can do a lot but often you still need to split your forms up if you can't use ActiveX or Java.

Any other Q's?

--Clay

My Experiences With Java Servlets and C CGI

[Carnage4Life]

I have used CGI and C as well as Java servlets.

1.) CGI and C: Even though I am comfortable with C, I felt very uncomfortable using C to handle server side processing. C's little idiosyncracies (no array bounds checking, poor text processing, almost non-existent exception handling capabilities, etc) made it a poor language (in my opinion) for creating a large, maintainable, complex user-driven web experience. Also the fact that an SQL pre-processor is needed to deal with handling database interaction is also rather annoying.

2.) Java Servlets: Java's extensive libraries make it possible to develop the entire web experience with Java. This allows one to design the entire site from the ground up in a proper fashion (Yes, design with UML diagrams even). Servlets are rather slow the first time they are used because they have to be loaded into memory but after the first user hit, they execute very quickly (as fast as or faster than most CGI by certain benchmarks). Exception handling is another boon that allows even the most unexpected problems to be handled properly. For example, when developing a recent project I wrapped the entire program in a try...catch block which sent me an email with a stack trace whenever a run-time exception was caught, I also printed a message to the webpage with the a hyperlink informing the user to mail the error message to me just in case my mailer failed. This proved to be a whole lot more useful than the default message screen Apache provides on script errors and would have been impossible in C. The database interaction via JDBC was rather smooth and could be modularized into special DB accessor classes and servlets objects could be modularized for later reuse. The ability to use other aspects of Java easily (e.g. the XML parsing API) is also a big bonus. In fact mail.com now uses Java extensively on it's site.

Which CGI language to use?

[ctj2]

I've been writting CGI scripts from about the time HTML 1.0 was first introduced. I've written in C, C++, Perl, PHP3, sh, and in apache's SHTML languages. Each has it's good points and each has its bad points.

• C - The choice of an old generation. Fast. Once you have a CGI application written in C you will know what fast is.

  Downside is that the development time for the infrastructure is huge. C isn't designed for string processing. Even REs are harder to do in C. My 2nd to last choice in CGI programming.

• C++ - All the hardaches of C plus the anguish of C++. My last choice for a CGI langauge.

• Perl - Ah perl! Easy to write a script, nice tools built in for dealing with input streams and tainted variable detection. With the current Perl modules for CGI interfacing and HTML/HTTP output it has gotten to the point where Perl is even easy to debug.

  On the downside it is a programming language first and a web design langauge 2nd. It also has a serious limit in that it often takes longer to compile to byte code for the run time engine than it takes to run the script. Startup times on largish scripts can be huge. Somewhat solved by embedding Perl into your web server. All in all, my 2nd choice for a CGI Language.

• sh - Good old Bourne Shell. Just don't do anything with it and it will work fine. On the downside, security doesn't exist. On the upside, you can do something in 30seconds.

• PHP3 - This IS my choice for a CGI langauge. With MOD_PHP it is very fast. Reliable, good error messages, good database interfacing, good interfacing to web object generation packages (libgd, libpdf, libmhash...) In addition, it is a language that can be embedded into your HTML document. Something powerful about <? $info = mysql_fetch_array($result);echo "His name is $info{'name'}"; > being all it takes to get the results of a SQL query into a web page.

  On the downside? It is another langage, sometimes I don't have a standalone PHP interpreter to do testing with. My favorite CGI lanague.

• SHTML - A very simple language addition that has almost no power and is a pain to use. Mostly used when I want to have different pages for different browsers. Not worth mucking with.

Summary: PHP for almost everything, Perl for the rest, C/C++ if you must, stay away from shells.

Chris

On the downside? It is another langage, sometimes I don't have a standalone PHP interpreter to do testing with. My favorite CGI lanague.

My experience

[Trinition]

Just for the record, I've used perl for straight CGI, ASP (using VBScript, JScript and ActiveState's PerlScript), and most recently JavaServlets.

I tend to shy away from the ASP/JSP/PHP3 paradigms just because they integrate presentation with the code. It means designers and coders will be working in the same domain. Jason Hunter has an article contrasting JSP (and the models like it) to what he favors, a template system.

We're presently using Java Servlets with our own home-grown template system. Java is a pretty darn good language, in my opinion. It has nice, consistent syntax, good OO design, and a wonderful set of libraries for just about anything (particulary, threading, RMI and JDBC come in very handy).

It is a valid point that much web work is text processing, simply because HTTP is text-based (and all parameters/info passed back and forth is text based for the most part, too). Thus, regular expressions, and Perl because of its RE support, lend themselves well to web work. However, I know of to regular expression packages for Java, one of which we use. We still hand-code some text processing in inner loops for the best possible speed, but RE's are a tremendous development-time saver.

All of that said, my preference considering the high-level models models I've used would be: Servlets, JSP(/ASP/PHP3), plain out-of-process CGI.

Please forgive me if I have incorrectly lumped ASP, JSP and PHP3 together incorrectly, but I believe, at least from the high-level, they are similar.

CGI and ASP

[psin psycle]

Maybe ASP should be a part of this thread also?

Re:CGI and ASP

[daknapp]

You don't have to use VB for ASP pages, you know. They work with any scripting language. Me, I use ActivePerl, which is a free scripting engine to allow the use of Perl with ASP. Try it!

Re:CGI and ASP

[RobertAG]

Why not?

The ASP idea is the next logical step after CGI. Until I had to use it in a big project, I thought ASP on IIS was a good idea. Alas, like most M$ products, it turns flakey with continued use.

On the Linux side of things, I have experimented with PHP and JServ (JAVA) and find them to be welcome alternatives. They both follow the ASP philosophy. As far as server-side Perl is concerned, I haven't used it, but I'm sure a lot of Slashdotters have.

Re:CGI and ASP

[Smalldog]

PHP follows the ASP philosophy?!!?? I think you'll find that's the other way round - PHP was out and running web sites while ASP was still "codename Denali"

Re:ASP is not a language

[bad-badtz-maru]

Uh, when most people refer to ASP, they mean VBScript running under IIS.

Jeff

Sort of

[skew]

I hope you're not saying that CGI script is an invalid term. It is a script that conforms to the CGI protocol, not a script that implements the CGI protocol.

However, you're right; this question is clearly misstated. There is one clear favorite language for developing CGI scripts: Perl. You can write CGI scripts in virtually any language (that was the goal when defining the interface), but few people do. Not with CGI.

However, there are a wide variety of languages for web development, including Java (servlets and JSP), VisualBasic (ASP), PHP, ColdFusion's CFML, C/C++ (via NSAPI, Apache module), etc. Few people use these languages for CGI; each of these languages has its own respective interfaces for communicating with the server instead. (Incidentally, so does Perl: mod_perl or PerlEx.)

For more info:

• Original CGI spec
• CGI RFC Project
• O'Reilly's new Programming CGI (2nd Edition) to be published this summer (*cough* ;-)

- Scott Guelich

From primitive CGI scripts to Enterprise solutions

[roman_mir]

The question about the best possible CGI misses the point. The best possible CGI is still only CGI. Of-course you can write the best CGI in some languages (PHP, C, Perl, Java etc) however, no matter what you do your CGI script will stay only what it is - a CGI script. What is the problem with CGI? CGI can communicate with databases, it can format output into various *ML's, it is simple to use.
If all you need is a simple to use program that communicates with database and formats output - use CGI (whatever language)

Internet is about mass use, it is about global access to the information and it is about services that can be provided over its networks.
What do you do when you need an Enterprise solution for your website to handle increasing numbers of users, how do you scale well into millions (and hopefully billions) of users? You need smart systems and plain CGI is just not enough.

For an Enterprise solution to work you need n-tier applications that utilize processes spaned faster than CGI (think servlets or DLL components,) you need fast data access, you can not afford forcing your user to wait, you need smart cache to store data locally without relying on your primary data sources and legacy systems. You need load balancing to take care of your increasing user base. You need easy to maintain and manage architectural view of your entire site and developer view of the site's components. You need to have reporting and maybe billing tools (what good is your site if you don't know who accesses it and who and how to bill) You need support for various language bases since you want to go global (however maybe you don't care to do that) and PHP sounds good for this, but it is only a small business requirement. You need batch processes to run when they must (not all data must be accessed during user request, some can and must be brought to your cache beforehand to optimize performance.) You need multiple device support (browsers on PC, on your cell phone etc.)

Basically the languages you are going to use are not as important as correct architecture for your entire business.

perl

[jbarnett]

I know a lot of people already posted this (or are going to), but you will see a lot of perl around in the CGI camp. It does have some good qualities (not saying you can't find these in other launages, but...)

It can process text really well and quickly, this is very usefully in CGI program.

It is portable, quick change it from one platform to another without a lot of modifaction

A glue launage, glue an html front end to a DB back end, glue a mail server with an html form, etc...

Supported, the perl community is activlly supporting and developing new feartures into this

Some disadvantages though, is that the launage isn't to clean, some times it is very hard to maintain code, even 15 minutes after you wrote it! You can maintain the code, but you have to activelly think about this BEFORE you even start chuncking out code.

CGI programing is more or less like any other programming, you just need more in the way of

text processing
portable
interact easliy with other things (databases, sockets, etc)

IMHO perl does all these things really well. The only bad thing I have found using perl, is that a really big project can get really mess if you don't think ahead and make sure everything is written down on a white board first. If you are working on a large project using perl, please do your self a favor and sit down and write down the program "flow" before you start just randomly typing code, it will say you a lot of greif.

Use Templates!!!

[SpanishInquisition]

It doesn't matter what language you use, as long as you are able to separate HTML from code. Don't use emebeded code like PHP or Embperl, don't use a bunch of printf("$foo") in your code, you will end up with something that only you will be able to understand. You know how many time people ask me to change the size of a font, or the image aligment, or the layout of a form? A lot. With a proper templating system, all you have to do is edit simple HTML. Hey, even a designer could do it. Look for HTML::Template in CPAN, that's the most usefull module ever, heck it's even more usefull than CGI.pm (who wants to write HTML in perl anyway?).

It all depends on the task at hand...

[kill -9 $$]

Choosing a CGI-language is like any other software development process. You've got to choose the right tool for the job. That being said here are some of my lessons learned.

Perl - an excellent choice for simpler projects. It can be used in large systems, but suffers from too much flexibility. What I mean is that you can write a Perl program that looks similar to C or you can write real ugly, but compact and elegant code (not saying that C isn't elegant). Regular expressions are a real plus checking validity of arguments. The library's available for perl make it extremely powerful. Since the memory allocation, arrays and types are relaxed it makes it very flexible to do all sorts of data input from the web, etc. Output wise, its very easy to make a perl script read from a source file and substitute dynamic content into a page via regular expression substitution.

Other scripting languages - (sh, csh, ksh, bash, etc.) Pretty much as powerful as Perl. Problem is many times they can be difficult to program and understand for non-shell scripters. Also, chances are if you are on a UNIX box (or any other for that matter) you can use perl if you don't have it already. My opinon is take the time and invest in learning/installing/using perl.

C or C++- performance oriented, but one must weigh it because things like sh, ksh, bash, perl are very fast (csh is sluggish for those who don't know) I'm sure there are reg. exp. libraries for them so they can be decent in terms of value checking/substitution. Both are a bit more structured than the previous scripting languages so the code might not be as messy. I'm not sure, but I'd assume there are more C/C++ proficient programmers than perl, sh, ksh, etc. ones. If so, one could argue that the code might be more maintainable. Another problem is the code is non-interpreted so their might be compatibility issues and there is the ever famous memory leakage problems...

Servlets- One of my personal favorites. Java is a solid OO language so its a bit easier (I find) to do OO development in Java than in something like Perl and C++ (not saying C++ isn't solid but I don't feel it is as solid). The server offers a lot of features like session tracking, object persistance, threading across requests etc. making it much easier to make use of these features than in another language. Tack on the regex library and set it to perl and you have all the power of Perl regular expression listed above. (or sh, or ksh if thats what one's comfortable with). Java has a diverse set of support classes so its good for lots of different tasks. Problems are again its interpreted, but it seems to run fairly fast. Because of Write Once Run Nowhere, it can become a pain to do system specific things... (changing file permissions to something specific (at least in 1.1 of JDK))

Cold Fusion - I'm torn on this one. It's a relatively easy language to use, offers much of the power in servlets and is extendible by using custom CFM tags. My problem with it is that you end up coding with HTML-like tags (CFM tags actual); a somewhat bizzarre feat if you haven't tried it, but not impossible. Last time I checked it only ran on NT or Solaris (about a year ago) and custom tag development was limited to C++ only. Haven't used it much, but after starting with servlets I felt that I could get all the power I wanted out of the servlet and it was a much more natural language for a programmer/developer like myself. Maybe CF is better for non-IT types?

JSP- Another technology I have limited experience with, but have been impressed with it so far. Basically offers all the power of servlets and separates the business logic from the presentation layer. A little weird like Cold Fusion in that you are coding around an HTML page, but the code constructs are actual Java code at least rather than if, while, and sql tags. Another side benefit is that your business code typically resides in a Java Bean. As a result if you wanted to build other presentation layers on top of it you could fairly easy (command line, applet, VB/VC++ through CORBA?)

So in summary, in my opinion for what I've seen:

I like servlets and JSP best (haven't done a lot of JSP though yet so I may end up eating those words). They're powerful development architectures when hooked with the server. Performance wise they are decent. With the regex library they have a lot of the power of Perl (oh yeah and they're portable) Not to mention I feel they fair best in developing growing systems or very large systems. Perl is my number two choice. Extremely powerful but lacks some of the support that servlet servers have built into them (threading, sessions, etc.) which means extra work for the developer. Not to mention, although I am very good with Perl, I have seen some real ugly looking perl systems that would send many spinning. Finally all the rest. Cold Fusion is not right for me, but for somebody else it might be good. C/C++ you need to justify the perfomance requirement or other reason for using it. Other scripting languages, justify why not use perl.

What's the Deal?

[res0]

I find it quite interesting that despite the article title "Which CGI Language For Which Purpose?", many of the comments I'm reading are all big arguments over which language is easier, which language has better OOP, which has better flexibility, etc.

I think they were looking for more along the lines of "Which language would best be for serving an auction site?" or "Which setup might best serve a bulletin board news system with more than 5k users and 10k hits?"

All I know is that I have been developing web sites for the last 4 years. Recently I got into Perl with the help of a few friends of mine.

The major project I assist now is on an OpenBSD box running Apache without mod_perl. Now, yes, I realize that without mod_perl I'm losing quite a bit of speed, but I have no choice as far as configuration. It's not my box.

Which is another point that I'd like to bring up. Many of the benefits of certain languages are completely dependent on the configuration of the server. A great deal of people have no choice of configuration because they are either too broke (me) or because their management is ignorant, etc.

To conclude, I'd just like to say that for what I use it for, Perl works rather well. It serves my pages reliably, tells me when I've screwed up, and lets me do a lot of things as far as functionality that I didn't think were possible until I tried. I can load pages dynamically using a main layout file, and track hits to each of the sites and track individual users to see what kind of people are viewing the site and where they're visiting from.

For that, the benefits outweigh any side issues that may arise from the flaws in Perl's design.

So before you start posting any highly biased this-language-is-better-than-that-one posts, consider what the point of this Ask Slashdot was and try to find a reasonable answer for the question.

Macintosh Servers and CGI

[superdan2k]

In the case of a Mac server, you have two rather esoteric options:

1. Applescript CGI. There's a good tutorial on this here. And I recommend Applescript for Dummies, which, despite its title, is a pretty good foundation in the language. (And about the only thing still in print on the subject, which is odd.)

2. RealBasic CGI. RealBasic is a version of VB for the Mac, produced by a company in Texas (IIRC). It's a solid little package, and someone out there has written module for RB to allow CGI functions...

about Zope

[H.I. McDonnough]

Not much has been said about Zope - so I'll point out a couple of reasons why I love it: 1) The web interface You can edit anything on your website via Zope's web interface. It is also really easy to offer restricted access to the managment interface if you want to let your users do certain things. 2) The object database and url to object traversal Zope comes with an object database that stores all of your content. The things in your site are transformed into python object with attributes. So you can add extra bits of information (properties) to any object. The url to access stuff in your zope tree is really doing python calls. ie. http://yoursite.com/foo/bar?spam=spam Is calling the bar method of the foo class and passing it the variable spam. 3) Aquisition The auisition model make is so that anything in the namespaces above the current object is automatically in the current objects namespace. So, you need only define something once in / and then use it or override it in subfolders. 4) versions Create new versions of your site without affecting what users see until you are ready - without a staging/devel server 5) killer RDBMS support Support for Oracle, Sybase, MySQL, Postgresql, and ODBC in windows 6) Products API Easy to create reusable products and distribute them. A cool product to check out is squishdot - a slashdot clone. Create your own slashdots efforlessly. Yes, you have the option to include logic in your html - but you can also separate it if you want. Zope is really fun to work with, and for me it was a paradigm shift in web development.

Tcl/Expect CGI

[KidSock]

This would not be complete without mentioning the
Expect extensions to the Tcl language by Don
Libes.

For those of you who are unfamiliar with Expect,
it provides Tcl commands for scripting
interactive processes like telnet, ftp, or other
terminal driven apps. It's standard on most
UNIX installations(man expect).

Nice for webifiying those pecular terminal driven
tasks like telneting in to some machine and
pulling down info to be displayed in an actual
human readable format.

Check out the Expect Home Page. I know there's
a CGI tutorial floating around somewhere but
if you know Tcl it should be pretty obvious

KidSock

I recommend VBScript!

[dmccarty]

For serious code-freaks like me, I really recommend VBScript. It has powerful features, like being able to integrate your operating system with your Outlok address book. I was recently able to write a powerful script that sends itself to all of your friends, thus proving the power of the Windows Scripting Host! (Unfortunately, this powerful script also sent itself to all of my friends' friends, and that started to get crazy. Then these security companies started calling me, and now the NBI in Manila is cooperating with the FBI? Puta'ng ina!)

Oh, where was I?--oh yeah, back to how powerful this scripting tool is. It's really powerful, and I seriously recommend it! (In fact, my boss said that when I come back to work after my 10 years in the "big house" it will be even more powerful than it is today.)

--

like choosing a language for any project

[bluebomber]

CGI isn't really that much different than another project, IMO. You've got to look at a number of factors:
1. portability
2. experience of your developers with the language
3. language strengths/weaknesses for a particular task
I'm sure there's others...

I'm a big fan of perl, but I guess that is mostly because of #2...

ASP is not a language

[Pinball Wizard]

it is more like a method of communication between server and browser. It allows virtually any scripting language, including Perl and Python, to be used.

Even Microsoft recommends that you move as much code out of your asp pages as possible. Use compiled components. These too can be written in a variety of languages, C++, VB, and Java being the most common. The asp's themselves should be doing little more than reading form or querystring input and passing that along to the components. When the components are finished processing the input, they feed it back to the server and output can be written. In asp you have some choices whether to output everything all at once or just little chunks at a time, via buffering.

I agree with the poster who urged people to separate HTML from code as much as possible. ASP lets you do this. Proper asp coding can result in highly scalable sites that perform as well as anything out there. Its easy to use and its from Microsoft, so there are lots of crappy/slow asp pages as well.

Given that it is not a language in itself, I think its model is a good one for web development and I'd like to see more language independent methods like this in Apache. Has anyone tried Apache::ASP and seen how well it works?

Another LISP run site.

[wdavies]

Another LISP site.

The http://Shop.Goto.Com/ Instant Search Categories runs using LISP. It's based on a theorem prover written in LISP:)

Check out how fast the InstantResults get updated as you narrow down your requirements. For an example try http://Shop.Goto.Com/ce/dcameras/

LISP is sweet :) You know you can change a function definition in the middle of a running program, don't you :) ? Patch in a bugfix without taking down the site ?

Winton

Re:PHP -- more versatile, but not as free as it wa

[seldolivaw]

Some additional information to an already very informative post:

• It doesn't just do databases. It provides quick, easy and painless interfaces to useful things like encryption (of various kinds), basic GIF-image-manipulation (for things like bar charts etc.), as well as time-saving features like common array functions, file-management and file-editing functions, and FTP. Also, little built-in features like the way it deals on a single line with the infamous sendmail is a huge time-saver, and doesn't lose flexibility.
• Unfortunately, I'm not happy about the Zend engine, at least in the way it's not free (beer). It smacks of a Microsoft free-trial: you can write your application in this language, but you can't really do anything useful with the app until you purchase this "extension". Of course, it's not as severe as all that, but the restrictions on the use of Zend for various purposes are really annoying.