After a few threads around here such as CGI (Perl) vs JSP, I thought this might interest some people. :)

The other day, I met up with one of my old friends and collegaues from my last job, a guy that I think is a great programmer, and whose opinions I really value. When we were working together, we used mainly java to build (large and small) web applications. We also used perl and PHP for small stuff, and Q&D solutions. Since some of it was done in Apples WebObjects 4.5.x, it can be argued that it wasn't pure java development, but let's put that aside. For all things that matters, WebObjects done in java, can be compared to the EJB and J2EE stuff that is coming from Sun now, although it was created way earlier. It also has tons of almost unsolvable problems with scaling and performance - quite a few people use it, and advocate it, but fail to show up that super-site of theirs - it don't exist. Two years partially working with this and being on the mailing-lists tells me this is really so. Although it might have changed recently, who knows?

After leaving this company, he has a friend that is a EJB/Java servlet expert, and he got my friend lots of books and other things to study, possibly in the hope that he would come work there. After studying and experimenting quite a lot, my friend concluded that Suns proposed solution is pretty flawed: it doesn't make for speedy development, it has lots of performance issues, and although it supports clustering 100%, that clustering doesn't strike any of us as efficient, or even reliable. I'm mostly going on what he explained here, so you know. :) Given the huge price tag to get the real environments that do work, this is only feasible for large corporations that wants some really huge and complex, and has the money. Even then, my friend wasn't all that sure it couldn't be done faster in something else.

Being an old java programmer before I turned to perl, I still like java, and there are still tasks I'd gladly choose java over perl. For example, handling complex business logic, doing threaded servers and socket stuff. It might be because of what I am used to, but some things are - to me - lots easier in java. Most aren't, however... read on. :)

Anyways, he showed me this quote from an article over at IBM about choosing the right server-side scripting language:

So, which one should you use?

So which is "the best", the one to switch to or gloat about already using? Actually, the best language to use is the one you know best. I know this may sound weak (Jeez, take a stand!) and useless to the absolute beginner. But, the simple fact is that if you are a Tcl guru who doesn't know Perl, you probably shouldn't write your entire site's CGI in Perl just because "everyone else is doing it". Besides extending the development time, there is the very real hazard of accidentally leaving wide security holes. However, should you have a good reason to move from a known language to one that you have not yet mastered, let me recommend porting some scripts from your native to the adopted tongue to get the feel of it before jumping into that mission-critical Web app.
I would also like to point out that contrary to some popular sentiment, Java servlets and/or PHP scripts are not inherently significantly faster than their "scripting language" brethren. Their engine runs as part of the Web server, the argument goes, and doesn't require the resources to start a new process for each request as is required of CGI scripts. This is only true if you run your programs in the "CGI way" and don't put the Perl or Python or Tcl engine on the server. There are modules to do this and anyone utilizing these languages should look into these.

If you are new to the CGI game, hopefully some of these possibilities have whetted your appetite. Which language should you choose to start with? Look over all the programs and see which one makes the most sense. How easily can you figure out what is going on intuitively or from context? Which would you feel comfortable trying to compose from scratch? Which would seem least obtrusive in your dreams and speech? They are all free, so cost isn't an issue. Toss a Web server on your system and have a go!

Finally, if it seems that I'm bashing Java servlets as a server-side solution, I don't mean to. Most server-side applications are relatively small (in the other languages), and the overhead of Java's object-oriented syntax and packaging may not always be worth the development time and effort. Quite frankly, there are only two reasons I can see for writing Java servlets instead of using the others. One, your company is a Java shop and Java programmers are required to do server-side programming; or two, your server-side programming needs require large, complex programs, and it has been determined that you need the "power of Java." If this requirement was determined by your pointy-haired boss, use one of the other languages, surf for a few weeks, then tell him you did it in Java.

This is the conclusion from the article that I found very nice to read - lots of it I knew, but I thought I'd share that link with you all, because it does indeed make a lot of good examples and points. And you just gotta love the punchline...

For myself, I think it is good to know as many approaches as possible, since it makes you a better programmer IMO, and even if you are "perl only", it can't hurt to "know your enemy". :)

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

Comment on
Which platform to use for CGI?
Replies are listed 'Best First'.

Unless you are dealing with a very simple web application situation, the actual language you work with isn't very important at all. At least, not the language-as-language. Rather, you should care about the larger environment of your problem.

I would say that the things that you care about more are

Support from your corporate IT department

Ability to satisfy customer requirements

Deadlines, and your familiarity with what you're doing

Support from your corporate IT department

Once you deploy the box with your web solution on it, who will do the backups? Who will manage the its IP configurations? Who will give it a name on the corporate DNS? Who will provide the source data for it, and how will they do it?

Corporate IT.

I've gotten Linux boxes running Apache, MySQL and mod_perl into large corporate environments before, but always in Stealth Mode. Fortunately, the boxes only need servicing about once a year, but if it were any more frequently than that, then very likely we would have played "by their rules." And you can't influence those rules from the outside.

Ability to satisfy customer requirements

In one web project I worked on, I had to generate GIF (later PNG) graphs of business activity on-the-fly to be included in web pages.

Then they told me that they wanted to drag-and-drop those graphs into Excel so that they could manipulate them for other purposes.

Err...

Fortunately, I managed to talk them out of this. The "compromise" was that I showed them how to download the GIFs so that they could include them themselves, and I provided the processed data that I used to make the graphs so that they could generate their own Excel graphs based on that data.

The hell of it is, Microsoft does provide controls that you can plug into IE and IIS and ASP and all that that will let you do exactly what they wanted to do -- honest-to-God drag&drop COM graph objects that they could lift from the web page and put into Excel. If only you go the 100% Microsoft route.
The moral of the story: make sure that you know your customer requirements beforehand, so that you can use the technology that will satisfy them.

Deadlines, and your familiarity with what you're doing

If you do have complete control over your project (on a technical front at least), then you have two choices: the "get it done" choice, and the "learning experience" choice. If you want to "get it done", then don't try anything new. Just go with whatever you happen to already know. Otherwise, you have no right to expect that the project will take any less period of time than infinity.

The hell of it is, Microsoft does provide controls that you can plug into IE and IIS and ASP and all that that will let you do exactly what they wanted to do -- honest-to-God drag&drop COM graph objects that they could lift from the web page and put into Excel. If only you go the 100% Microsoft route.

There's a very important lesson in this statement that the free software / open source world will have to learn if it ever intends to neuter Microsoft.

The most important quote from that article is the best language to use is the one you know best. And for management lurkers that can be reprhased the best language to use is the one your staff knows best.

All languages have their plus and minuses. You'd
be quite surprised at what's been done with some languages - I've seen some pretty heavy duty apps done in
pascal! Know the strengths and weaknesses of your language
of choice - showcase the strengths and work around the weaknesses. Have an open mind about other languages, you may
find constructs you want to push for inclusion in the next
rev of your language(s) of choice.

-derby

update: That's a fairly decent link (ibm's developerworks is a pretty good resource) but I think the
author blew it on Perl's standard block of [CGI] code isn't hidden away in a module. CGI was definetly around when he wrote that article (may 2000).