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

Re:perl is fast enough

[Anonymous Coward]

I always point them to slashdot as an example of why perl works even in large scale situations

I don't think that was such a good example. Slashdot is horribly slow or down most of the time.

Re:perl is fast enough

[Anonymous Coward]

Slashdot is by far the slowest website I use, even among interactive ones.

-Phiz

Mason = embedded perl + components

[Anonymous Coward]

I'm surprised noone has mentioned mason.

When I was looking at PHP, all I could
think was:=
"What a sorry language. It's a cheap perl
wannabe."

So, I went on looking for a way to embed perl,
such that it would be as easy to embed as
PHP.

Mason http://www.masonhq.com was the solution.

You can write perl code embedded in HTML just as
easy as you can write PHP; but you get
a real language.

Also, mason has an amazingly powerful include
and functions capability with its components.

PHP seems to be currently developed to the level
that perl was at perl4. It still has seperate
functions for each type of database, limited regular expressions, etc.

Also, I wonder when PHP will have something as developed/complete as CPAN?

Re:Mason = embedded perl + components

[100monkeys]

I must second the motion. And I must also say that I'm surprised there has not been much mentioned about Mason.

If you want the power of Perl, that you can embed into your HTML documents, Mason is wonderful. The component design works wonderfully and cuts hours off your design and implementation time over straight CGI.

A couple of other strengths not previously mentioned:

• Mason does an excellent job of allowing you to embed your code in a way that does not mess up things for designers / non technical folks.
• Components encourage a write once, use many attitude. I can't stress enough how much time this saves in the long run.
• Open source. Built upon an open source language (Perl) for that "get under the hood" feel :-)
• Handlers give you the ability to apply global behaviour to pages etc. Also gives you a level of control that you won't find with other languages.
• Much, much more...

But don't take my word for it. If you have not already done so, try it out. You won't be sorry. (http://www.masonhq.com)

C++ for me

[Anonymous Coward]

I've played around with several other CGI languages. Mainly Perl, which I admit is great, if you're a big Unix buff. Don't get me wrong, I like Unix quite a bit, but I guess in my old age (31, but 20 years of programming experience), I'm just not into learning every new thing that comes around (speaking of Perl, in particular, not that it's that new, but bare with me).
I've spent a lot of time learning, and becoming good at, C++. For this reason, I'm not real into learning all the ins and outs of Perl and other CGI scripting languages. I have a good library of routines I've written in C++ for writing CGI "scripts". I'm quite happy witht his library and I find it really easy to do almost anything I need to do.
I admit, Perl has some advantages at certain things, especially string manipulation. Something C++ isn't quite as flexible on. This is a tradeoff I'm willing to make. Most of the string manipulation stuff I've needed in the past, I can still do with a few extra lines of code.
As for the true advantages, you get the same advantages that anyone gets with a natively compiled language over an interpreted language: Speed. There are also some other advantages, such as a tremendous library of available tools for additional functionality.
With a good CGI library, C++ can be quite effective.
All I'm saying, though, is that I like C++. I like C++ for applications, and I like it for CGI scripts. I just like it period. I don't feel like learning Perl. This is my personal choice and everyone should have their own.
As I've pointed out, Perl has certain advantages, as do other languages, including C++.
Just MHO.

Re:Perl is fast enough, but not for Slashdot

[Anonymous Coward]

So funny..., you folks don't really know what your talking about. Java is a heck of a lot slower than perl. Mod_perl is idiotically ridiculous unless you spend time learning the tricks of the trade.

Mod_perl plus mod_proxy running a really light engine on the front end sending data out to 56k connections is where it's at. It's more scalable than anything you could imagine with the possible exception of php with the same setup. The thing with perl is that the community is SO huge that whatever benefits that php may offer, perl can double that.

Nobody codes in straight perl anymore anyway.., except for in house tools that don't need a good GUI. Look at embperl, or mason, or even Apache::ASP, they will blow away anything I've seen mentioned on this site in terms of speed of developement, and scalability. You just need to do your homework.

As far as persistent connections... this is childsplay in mod_perl.

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.

Re:What about the children?

[randombit]

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.

It's not that bad once you get used to it. However, being in Baltimore, instead of speaking with skinny, mangy rats, I talk with big, sleek, cat-sized rats [you have to see these suckers to believe them - they're fscking _huge_]

I don't like to have conversations with crows anymore though: they're always say the same things. "Microsoft Sucks!", "GNU/Linux!", "GPL is not free!", "Hot Grits!". Oh, wait, that's the average /. poster. I guess the crows aren't so bad afterall. :)

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

[embobo]

Perl does much more than regular expressions. I beleive the most used module (acording to CPAN) is DBI, the database interface.

mod_perl scales as well as Apache. There are huge sites running mod_perl such and CNET and singles heaven. The mod_perl guide gives many performance tips and strategies as well. Did you try those before you concluded mod_perl does not scale?

The perl object module is better than the C++ object model. It is clean and straightforward. You do not have to wonder if there is a default constructor for your virtual base class, etc. You site no examples of inelegance so I don't know what you could mean.

Re:Like Perl and Java Servlets--Love PHP

[Howie]

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

Well... if you take the JSP/Servlet package as one lump (which you almost always do - I don't think there is a JSP implementation which doesn't use servlets), then you can do those things. Likewise with ASP/COM although that is stretching it a little (you can extend IIS via COM).

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

[nebby]

Better than that is Oromatcher. The GNU one runs slow as molassas compared. -Greg
modern day geek.

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

[seanb]

How much cleaner with python? This much cleaner:

def foo(thingy):
for attr in ['foo', 'bar']:
# raise an Attribute error if these
# attributes are not found
getattr(thingy, attr)
if test_conditions:
setVariables()
else:
raise ValueError, 'Invalid Variables'

Re:Like Perl and Java Servlets--Love PHP

[fornix]

I enjoyed reading your comment. I used to use C++ heavily. I bought into the Java hype and I have a few python books. I've actually had a rather nice time with perl's OO. True to Perl's nature, it's OO constructs allow a lot of flexibility in implementating your goals. The only thing that scares me a bit is type safety, but for web apps it hasn't really been a big problem for me.

Why not write your access functions like:

sub setx {
$_[0]->{x}=$_[1]; }

Or
sub property {
return $_[0]->{$_[1]}=$_[2] if $_[2];
return $_[0]->{$_[1]}; }

Sure, it's ugly as hell when you first come to perl, but after a while it's not so bad at all.

You wrote:
sub foo {
my %hash = @_;
die "foo not found" unless exists $hash{foo};
die "bar not found" unless exists $hash{bar}:
unless ( $hash{bar} > 5 && $hash{bar} 5 && $y 10 );
$i = $x;
$j = $y;
$k = $z;
for my $item ( @w ) { ... }
} # end foo


Why not
sub foo {
my $h=@_;
for(qw(foo bar)) { die "$_ not found" unless exists $h{$_}}
if( insert $h test conditions) {
set variables
} else { die "Invalid variables";}
}

How much cleaner does it get with Python? (I don't have much experience with phython - so it's not a rhetorical question).

p.s. how do we get slashdot to print a right bracket?

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]

I seriously disagree. At the very minimum, Objects allow you to capture the state of a system. In a function oriented approach, you would have to pass a state handler in order to isolate instances ( such as a parser, a data-base connection, etc ). OO at the very least does this for you in a semi-transparent fashion. It also does this in a logically consistent fashion.

The other material, such as polymorphism, inheritance etc are of finite usefulness. I find maybe one real use per project, and I can find other ways of solving the problem. In a scripting language there is a bit more overhead for such things ( since you can't optimize them away ).

Re:Like Perl and Java Servlets--Love PHP

[maraist]

Ok, I love perl. But I am a disciplined programmer. And I can definately site problems with the perl OO model.

First, I think everyone can agree that OO was an afterthought in perl. It is not truely part of the perl system. In fact, it is merely a variation on the general function-calling scheme. {package}->{function-name}( {parameters} ) will walk through the package @{package}::ISA variable, looking for &{package}::{function-name}, or &{package}::autoload. It's logically just a complex if statement tacked onto the function calling routine. Because of the scripting nature, this is allowable, and also very dynamic and arguably useful. But we're not finished.

Then look at their pseudo-hashes. Take array-ref, treat them like a hash ref ( previously a compiler error ) and we'll take the special function of using the first field as a member-variable-name index into the array. Take it a little further. If you have a %{package}::FIELDS global, and you have a data-type of type {package}, then we don't need to waste the memory in array index 1. Does this seem elegant, intuitive, straight forward or even optimial to you?

The use of global variables to solve a problem is a design flaw in my opinion. In OO design, you should never have a global ( except maybe that of the application instance or constants ( but that's not a _variable_ is it? ) ). Sure, quick and dirty apps can use globals or my's all they like, but OO is usually for lasting/ extensible solutions. Using ISA for inheritance, and FIELDS for member variables is very cludgy in my opinion. I deal with it because I use perl more for it's power than it's OO. But you can not claim ignorance to it's dirtyness.

Another gripe about Perl-OO that I've long had is the 'this' variable.
C++: void FooClass::bar( int x ) { m_x = x; }

Perl: sub FooClass::bar($$) : method locked {
my FooClass $this = shift;
my $x = shift;
$this->{x} = $x;
}

Writing OO in perl is physically painful. Look at all that extra typing. Forget it if you have Base::SubBase::class as your package/class name. From a readibility standpoint, all those $this->{xxx} statements really get in the way. Forget the idealogical point of view of not using globals which are at least are hidden by the use of:
use fields qw( xxx yyy zzz );
and
use base qw( BaseClass );

Now you have to deal with massively excessive text which makes writing long lines difficult to visually check.

Python is just as scripted as Perl, and they've managed to work OO in just as well as Cxx / Java.
The following is paraphrased because I don't have the syntax memorized, but you would have:

class Foo : list-of-inherited-classes
list-of-data-types
list-of-methods

Then you at least get the implicit this->{m_varXX}

I love perl, and get work done a lot faster in it than any other languge that I've used ( because I'm allowed to balance how dirty my code is ). But I'm underimpressed by their OO implementation. I look at it more like the x86 world of backward compatibility. Yes, I love the fact that the AMD Athalon is the fastest x86 CPU out there ( and when they fix their stupid cache limitations, they'll be able to maintain that logo ). But I really admire Alpha, PowerPC and uSparc for their bueatiful RISC designs.

If Python could advance to the level of support and optimization that perl has, I would probably shift my development over. It is pleasant to the eye, easy on the fingers, and officially supports compilation to boot. ( Perl still cores when I compile any complex code ) I have serious doubts that perl is a foreward language. In 10 years it will be as muttered as x86 is seen to be now. We will be looking to replace it as we look to replace COBOL ( ironically for completely opposite reasons. COBOL was about readibility, and is being replaced for greater functionality, whereas perl is about functionality and will be replaced for readibility ). They are currently limited by their legacy syntax. The only way I can see them getting out of this rut is to add a compatibility mode. Eg, completely seperate parsers for a version 6.
You'd say, for example
require perl 6; which would have the scope of the current file ( thereby maintaining compatibility with older modules ) Either that or by wrapping "use Perl5Module {module_name}"

Finally, returning to the phrase "better than C++", I can't imagine what you mean. The only additional funcationality I find is the dynamic name-space. You can arbitrarily add variables and functions to an object. But I could just as easily argue why this is a bad thing ( see self modifying code under enterprise solutions and debugging woes ). I long for the C / java days when mispelling a variable name was a compilation error. We fixed the FOP model with "use strict", and we're fixing it in the OOP model with "my Class $var" and "our Class $var". But function calling still frustrates me. "@_" is great for quick and dirty, but horrible when validating variables. I wind up using the following model:
sub foo {
my %hash = @_;
die "foo not found" unless exists $hash{foo};
die "bar not found" unless exists $hash{bar}:
unless ( $hash{bar} > 5 && $hash{bar} 5 && $y 10 );
$i = $x;
$j = $y;
$k = $z;
for my $item ( @w ) { ... }
} # end foo

Python even allows you to call functions in more than one way. location based passing ( C, Java method ), or named fields ( like my above hash-based parameters ).

This isn't a complete argument, and I'm sure I have holes. But I hope I've made my point through specific examples that perl is not a clean OO system.

Re:Like Perl and Java Servlets--Love PHP

[maraist]

Try reading the whole article. My statements should are all correct when you look at their context. The difference between .001 and .01s is not that significant in and of itself, which is where they were being compared. I am not suggesting java is faster than perl, that CGI is faster than mod_perl ( or even Apache::Registry ).

The main point dealt with scalability of complex Business logic. Where even the best written perl code is going to be a dog.
I never said that java was faster, just that it is more _easily_ clusterable. Take a thousand 386 machines running java servlets, and I'm pretty sure that it'll be faster than a 1GHZ alpha running highly tuned perl ( or even C for that matter ) when properly loaded.

Re:Like Perl and Java Servlets--Love PHP

[maraist]

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

I'm sorry that I couldn't think of a better example off the top of my head. It was meant to reflect a generalized complex calculation ( non-mathematical even ). My company is regularly required to produce complex ( many modules worth ) of nested-if-statements and complex data manipulations between the form-front-end and the database-back-end. These produce an appretiable amount of CPU load. These could have been fined tuned, but we needed extensibility, readibility ( I know, foreign to the perl world ), and intuition. There is usually a trade-off. All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with. Absolutely false.

Sorry, poorly chosen phrasing. I was really thinking about the comparison to java for this statement. And yes, I did leave out the API features mod_perl gives you. Though this is non-portable, so it also has it's catch ( yes I know, why would go choose another platform. But not all service providers allow the use of mod_perl, so if are a independant developers making use of ISPs, then you might be conserned with that sort of portibility ).

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

True 70k does take up a lot of time. Back in our CGI days ( when we ran netscape-es ), the total code was 100k or so, but broken up into 30 - 50 CGI's with only a few overlapping modules. At the time we didnt' even have a back-end DB ( it was a shell around a revision tool called clear-case ). It was very fast except for some of the slower clearcase calls. But again, my poorly announced point was the comparison to java in a non-persistent realm. A large java app will have to load and JIT ( which is as bad as compilation ) each modules as it comes up. Not to mention that it takes many many more lines to do the same thing in java that it does in perl. ( at least in my experience )

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.

Yes, it is a good point, but I assumed that this goes without saying. But how do you tell a manager to blanketly "enforce better programming". Since the choice of a language is at the managerial level, this topic really seems to be addressing them ( not to say that the coders don't have a big say ). My points were examples of some of the many potential needs to fork from perl (without resorting to making a slower version in raw perl ). Find and revision control features are relatively new features of perl-mod land. And my specific rev-ctl tool still does not have a mod implementation. I have no choice but to fork/exec. As for Find ( now you're going to make me boot up my linux box ) and several other tried and true UNIX tools, this is a balance of quick-and-dirty and analysis of the implementation. Find is a slow operation that consumes memory, disk-IO and CPU cycles. Is the time saved by not forking a find and tar just consumed again with a potentially flawed, or even pure-perl ( and thus slower ). And just so I don't sound like an idiot, I actually did a benchmark, and File::Find is indeed slower than qx(find ... ). Unix tool Mods are really only benificial in my opinion when they're front ends to a C code.

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

Yes, but I said string operations. Perl: $a .= $b; Java: a += b; Is no contest. You have to perform string-buffer concatenation in java which isn't as convienient. But even this runs slower than perl ( in my simple benchmarks ). Beyond that, unless the java reg-ex engine is ultimately in C, it's going to be significantly slower than perl. I can not back this up with numbers; I've only gotten as far as to download the java-reg-ex engine.

There's *always* a more efficient way of doing something

Yep. And I guess my statement was straddling the fence too much. But the key is, how does your language more naturally present the solution. Developer time is important too. Perl gives you reg-exs up front. In java, you'd have to write out the solution either way. The best solution would probably be to find some module that already does much of it for you. The rest of your article has nice examples. Obviously people do use perl for larger scale operations. Slashdot, and my own company are other examples. I still am doubting the complexity of the business core that was a key component of my article. It would be hard for me to gague the complexity of your site. I definately feel that slashdot is simplistic in that all it is doing is interpreting databases and forms. Ahead of my company is the difficult decision of java v.s. perl. We have grown beyond simple DB customizing company and are now reverse engineering a complex application that uses FileMakerPro ( because we've convinced them [ without a detailed analysis of our own ] that the web and Oracle are a better platform ). However, we're slowly learning that filemaker is a huge fscking program. The company has already decided to choose java for a great many reasons. The DB and the UI are the most trivial elements. We're supposed to hook into an enormous number of concurrent services. It is, truely an enterprise class operation ( and it is in the medical industry where people's lives will be dependant on the results ) You can chant all you want that there is no substitute for good programming practice, but because of the worker shortage in America right now, we are forced to hire summer students to develop the more simpler elements. You can not rely on everyone being an expert. Perl has a lower minimum bar of bug-free code than a C-style langauge like java. At the very least, perl allows a significant number of run-time errors that java would catch in the compilation stage. The classic, it compiles, let's ship it out the door doesn't exist with perl. There could be buggy modules that _core_ the process that aren't caught for months. "use strict" is not even a required feature ( I checked, -w is not sufficient ). But this is a language question, and our discussion has been about mod_perl's effectiveness. It was a great run, sorry that the game is over so soon. I enjoy analysis discussions such as this. -Michael

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

[Rubidium]

perl object model: sums up everything that is wrong with perl. Objects in scripting languages is just wrong. *flame away*

Sorry, but having object-orientation in a scripting language is definitely a very good thing. The Perl object model does sum up everything that is wrong with Perl, but it is bad not because it is an object model in a scripting language, but rather that it is a horribly designed object model. The syntax and symantics of handling objects and classes in Perl is very bad. One of the main reasons for this is that Perl was not originally designed to be object-oriented. Object orientation was crufted on later. As for a very good object-oriented scripting language, take a look at Python. Python uses object-orientation as a very large strength. Python is a very well designed language which has very clean and well thought out syntax combined with a large, organized, and powerful set of modules.

Re:Like Perl and Java Servlets--Love PHP

[Wizard of OS]

Do you mean PHP3 or PHP4?? (I admit that I don't know much about the differences, but from what I've heard, PHP4 is lots and lots faster)

Re:Like Perl and Java Servlets--Love PHP

[Bluecoat93]

Actually, Perl scales just fine, especially under mod_perl. My company serves up around 30,000,000 hits (3 million+ page views) per day built almost exclusively on Perl and mod_perl. It's the developer, not the tools.

Re:Like Perl and Java Servlets--Love PHP

[chompz]

and CGI, and JSP, and servlets) have the limitation that they can only produce output.

You must be kidding... Java Servlets are much more powerful than you are giving credit. You are making them out to be slow and poor for text output. Java isn't a bad language for character operations. One must be careful when coding if they want superior speed, but that is the case for all CGI and CGI workalike options. I can write really damn slow perl if I want, but it is possible to be fast. Before you critique the options, you probally should make sure to have sufficent knowledge of the choices. Java Servlets remain loaded into memory once they are accessed once. There is no passing of go, they are already running. Everything is done in threads, so there is no overhead of starting up a seperate process to deal with it. PHP3 is not a choice for speed reasons or even for functionality reasons, its just quick and easy to write.

My college uses a php3 webmail application, and at peak times of day it has around 1000-1200 active sessions. This translates to only about 1 hundred requests per minute. I have never seen performance as poor as this php3 server, except for maybe the .ps web server posted a while back.

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.

Re:Some language, any language

[Pierce]

How about persistant connections with PHP?

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

Incorrect!

[rodent]

Actually, when PHP is compiled as an Apache module it can/will do persistent connections. My MySQL server typically has 50-100 connections open despite not all being active.

rodent...

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.

ASP vs The World.

[Simon]

I spend almost all my time at work developing sites using ASP, PHP, sometimes Perl etc. So I'll try to be fair here with some comparisions.

(Disclaimer: I haven't used the most recent version of ASP, so my comments may be out of date).

I theory I don't mind ASP too much. By using Javascript (JScript in MS speak) instead VBScript you can avoid any real BASIC brain damage risk, and also you can use OOP which becomes invaluable for larger projects.

ASP:

* Feature starved. You can't even do file upload without 3rd party software. ASP doesn't come with a big range of libraries to use like PHP does. Although you can use all that COM, ActiveX stuff, but that often requires having to use 3rd party software. (Read: extra expense, and you can't be sure that the Web host you deploy on actually has the extra software you need installed). Simply put, you don't have everything you need right in front of you like you do with PHP.

* Buggy. At least the JScript stuff is. String objects often forget half thier methods. Oh, and don't forget to copy the objects out a DB ResultSet otherwise you are in for some very weird bugs later on.

* Documentation. At least for the JScript part it is a complete work of fiction.

* Portablity. You are basically stuck with NT. Unix versions are around but they cost a fair bit and I would be worried about compatability between different implentations. (Actually I've had trouble between two machines with I *thought* were running the same version of IIS and ASP).

* Cost. You need NT to run it.

The bottom line is that PHP is a much better implementation of the approach shown in ASP. It is very stable, easy to use C like language, has fully featured libraries for things from Mail, regex, DB, XML, IMAP you name it, good documentation (check out the Annotated Manual at ww.php.net), is portable, available at the right price and is under an Open Source liscense. It's just much better.

--
Simon

Re:ASP vs The World.

[Skim123]

I theory I don't mind ASP too much. By using Javascript (JScript in MS speak) instead VBScript you can avoid any real BASIC brain damage risk, and also you can use OOP which becomes invaluable for larger projects

VBScript v.5 supports VB classes...

Documentation. At least for the JScript part it is a complete work of fiction

There are oodles of tech docs at: http://msdn.microsoft.com/scripting.

C ost. You need NT to run it

There are third-party companies that have ported ASP to non-MS Web servers. Granted, there is a cost to buy those ports...

Feature starved. You can't even do file upload without 3rd party software. ASP doesn't come with a big range of libraries to use like PHP does. Although you can use all that COM, ActiveX stuff, but that often requires having to use 3rd party software. (Read: extra expense, and you can't be sure that the Web host you deploy on actually has the extra software you need installed). Simply put, you don't have everything you need right in front of you like you do with PHP

I always hear this as a disad, but I find it good. ASP is tightly focused, aiming to do one thing and one thing well: interpret requests from the client and send back information. All other functionality being "imbedded" in ASP is wasteful, since ASP can interact with COM. Put that functionality in a COM component and let other developers (not just ASP developers, but VB/VC++/VJ developers too) benefit as well.

Re:Ask Slashdot

[Threed]

1) KWrite, if the bugs ever get worked out.
2) If you gotta ask, I gotta suggest KDE.
3) Depends - Do you think you could sell it?
4) Can't go wrong with C++.
5) If you gotta ask, I gotta suggest Mandrake.
6) Eventually, it's gonna be called just "GNU".
7) If you know enough to ask, you don't need my opinon.
8) Lease, but if the dealer's smiling at signing, you know you're getting screwed.
9) Doesn't matter, so long as I can't see 'em peeking out over your belt.
10) Blonde - I like my women just a little on the trashy side...
11) Plastic - doesn't rip when your ice-cream condenses water onto it.
12) Neither is a geek.
13) Tastes great.
14) Too tired to do the math.
15) TNG, and ONLY TNG!
16) Stirred.
17) Color... Good god, man...
18) NO FRAMES DAMNIT!
19) Country, but only circa 1993. Newer stuff sucks.
20) Don't walk. Run!
21) Dr. Suess.
22) Keyboard.
23) Deathmatch.
24) CuciPOP.
25) 0x
26) Yo!
27) Flamebait.

A few more...

Dog or Cat?
Soundblaster or GUS?
Marlboro, Camel, or Newport?
Black, or Cream/Sugar?
Marijuana or Alcohol?
Metallica or Napster?
Bic or Zippo?
Physics or Chemistry?
Big Bang or Steady State?
Karma Whore or Regular Poster?

Wow, I must be suffering from sleep deprivation induced dementia...

--Threed

The Slashdot Sig Virus was foiled before it could spread.

Re:The list

[pod]

Not to flamebait here or anything, but can someone, once and for all, list what exactly is the problem with ASP/VBS? MS-derived is not a valid problem. Neither is runs on IIS, runs on NT, it's VB. Actual problems and deficiencies. I keep seeing people saying ASP is bad, but no one seems to say why. I'll admit to writing some (ok, extensive) amount of ASP/VBS, and it seems fine. Runs a little slow. Lots of pre-made objects available for it, easy to use, not bad to write if you design the app well enough.

So why does it suck so much?

Caches are good, but what about loops?

[Chouser]

Interesting! I'm not sure I understand why you would use PHP if you are going to put all the PHP in a separate file... on the other hand, I know rather little about PHP, so perhaps you can enlighten me.

After a quick look through the documentation for FastTemplate (And the cacheable version) I was surprised to see there was no support for loops. Did I miss it? How do you handle building tables of response data without putting the table tags inside your code?

HTML::Template has severely constrained forms of variable replacement, if statements, and loops. It's difficult to strike a balance between flexibility of the template and keeping program logic out of it. Even with a template solution it is possible to put too much complexity into the HTML, but templates do help greatly. FYI, HTML::Template has a cacheing mechanism that works beautifully with mod_perl, allowing all of the code and template data to reside in memory instead of on disk.

--Chouser

Re:Caches are good, but what about loops?

[arthurs_sidekick]

Why you'd want to do it: PHP has the feature-set you want, but for the fact that you need to mix your code with the html. I've been using it so that users can choose which style of display they want (not that I've implemented more than one style yet =) Add in the cache, and you get PHP's ease-of-use with a speed increase. Why wouldn't you? =) [ yes, I realize you can cache in other languages ]

You can layer templates, i.e. have a top-level skeletal one that just spits out the doctype, head and body tags, then stick a big ol' {CONTENT} in the middle, which you can build up with still other templates. Looping's easy enough, you can append content to an identifier you've already built up. There's an example of how to do this in the tutorial, IIRC.

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

Re:Be careful of PHP; separate code and layout.

[jaydub2001]

Separation of PHP and HTML content is trivial to accomplish for the most part. The use of the 'include' function allows atomic files of solely HTML (or mostly HTML with a few PHP variables included) to be separately written and maintained without knowledge of the PHP only code.

For example, on a project I am working on, there was a desire to be able to change the look and feel of the website on-the-fly. If the structure of the HTML page is designed to be modular then the order of the display of HTML elements can be easily rearranged by modifying the order of the 'includes' of the HTML files in a 'main display' PHP file.

There are really two ways to use PHP - sprinkling the PHP code all around a bunch of HTML, or by making as much of the site as possible into small modular pieces. If you think about it, it's not all that different from using CSS. The rigid way of applying CSS is to use inline style tags throughout. The flexible modular way is the use an external style sheet with classes and id's and such. Either way you will get the same end result, but one is certainly easier to deal with.

Re:Be careful of PHP; separate code and layout.

[tjhorton]

This opinion was very thoughtful, and responsibly offered 'why' and 'how', but is it tied to one particular set of experiences, or just a design preference? In other words, is it a design choice, or based on past observation? I've heard this kind of thing, but I can't quite make sense of it. Maybe I'm doing things all wrong, or maybe just differently enough that the answer is different? I embed Perl in HTML in ASP-like tags, but translate it all to pure perl with a little translator. This just converts the parts outside to 'here documents' that get printed on STDOUT. So something like: ... with substitutions ... is roughly translated to sub process { ... } sub display { ... print ... with substitutions ... END_HTML } end sub display In other words I translate from perl embedded in HTML to/from HTML embedded in Perl, and with a minimum of care, each of my pages (which require processing) becomes a pair of subroutines in a separate perl module. And yet I can use an HTML editor to quickly edit my page layouts. (e.g. Homesite handles extremely well). Each such module encapsulates everything about one page and the glue necessary to attach it to the rest of the system. One subroutine knows how to process that particular page, the other knows how to display it. This file contains the layout and the glue for just that page. Everything that is not particular to processing or displaying that particular page, as laid out, is separate. Is this what you are talking about? Or not enough? I was attracted to EmbPerl and ASP and Mason etc, but the complexity and processing models and constraints they imposed didn't seem attractive, let alone the additional complexities of learning and debugging. With just CGI.pm I can debug my new scripts very easily (just specify parameter values). Either I've fallen upon a great simple way for doing what you are talking about with all the benefits of what you disavow, or I'm deluded? Comments please?

Re:Be careful of PHP; separate code and layout.

[tjhorton]

[ SORRY this was posted as HTML. First time! ]

This opinion was very thoughtful, and responsibly offered 'why' and 'how' to avoid embedding code in HTML, but is it tied to one particular set of experiences, or just a design preference?

I've heard this kind of thing, but I can't fully make sense of it. Maybe I'm doing things all wrong, or maybe just differently enough that the answer is different?

I embed Perl in HTML in ASP-like <% ... %> tags, but translate the whole thing to pure perl with a simple little translator. This just converts the parts outside <% ... %> to 'here documents' that get printed on STDOUT. So something like:

<% sub process { ... } %>
<% sub display { ... %>
<HTML> ... with substitutions ... </HTML>
<% } # end sub display %>

is roughly translated to

sub process { ... }

sub display { ...
print <<END_HTML
<HTML> ... with substitutions ... </HTML>
END_HTML
} end sub display

In other words I translate from perl embedded in HTML to/from HTML embedded in Perl, and with a minimum of care, each of my pages (which require processing) becomes a pair of subroutines in a separate perl module.

And yet I can use an HTML editor to quickly edit my page layouts. (e.g. Homesite handles <% ... %> extremely well).

Each such module encapsulates everything about one page and the glue necessary to attach it to the rest of the system. One subroutine knows how to process that particular page, the other knows how to display it. This file contains the layout and the glue for just that page. Everything that is not particular to processing or displaying that particular page, as laid out, is separate.

Is this what you are talking about? Or not enough?

I was attracted to EmbPerl and ASP and Mason etc, but the complexity and processing models and constraints they imposed didn't seem attractive, let alone the additional complexities of learning and debugging. With just CGI.pm I can debug my new scripts very easily (just specify parameter values).

Either I've fallen upon a great simple way for achieving the separation you talk about, with all the benefits of what you've disavowed, or I'm missing the boat? Comments please?

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:Separate code and layout

[eMBee]

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.

absolutely!

recommend perl as a first choice

however there are alternatives to perl here too.
the Roxen WebServer has an extensive SSI language (RXML) that allows for things like SQL queries without any code. and if RXML does not do what you want, then you can put the code in a module and make it available to the html-writer as an RXML extension.

greetings, eMBee.
--

Re:Separate code and layout

[jerf-de-mex]

i agree with that. You can separate the presentation from the logic using Java Servlets with Freemarker. It's an excellent package that you can obtain from http://freemarker.sourceforge.net
You can also use WebMacro but i prefer Freemarker.

Regards

Jerf de México

Re:Separate code and layout

[madstork2000]

I totally agree that "the code" and layout should not mix. However, I disagree that tools like PHP EmbPerl, ASP etc should not be used.

While those tools make it easy to mix up the logic with the layout, any programmer worth his/her salt is going to be able to keep them seperate enough. There almost always is some overlap anyway, (HTML forms that become variables in the actual logic.) The tools designed for web use (like PHP) make it very easy to get variables/parameters from the "layout" into the logic. Without web specific feature to automatically get the HTML form variables, environment variables, etc you as a developer must do a lot more work and maitain a lot more code. IMHO why reinvent the wheel, just to enforce a seperation of logic and layout.

I commonly seperate out most of the layout by using include files in my PHP scripts. I use a nameing convention to help me enforce this:

1. disp_*.php are PHP scripts that produce output.
2. disp_*.inc are include files that contain functions that produce output
3. sys_*.inc are include files that contain "logic" function (i.e. they do not produce output (other than debug statements)
4. *.html are "layout files that are mainly HTML, they may have functions calls embedded to produce things like selection lists, or results from DB queries. My goal is t make them maintainable by people who know nothing about PHP.

Your mileage may vary.

I have only been using PHP for about a year, and I know I have a long way to go in learning, but the fact that it is very is to learn, and does a lot of things for the programmer (with out sacrificing flexibilty) makes it the best tool for the majority web projects.

-MS2k

Re:Separate code and layout

[thornist-on-dialup]

...and they are both integrated into Turbine, which is an excellent Java framework for building web applications produced by the Java Apache Project. I'm bang into its elegant MVC based architecture and rich utility services. If you're looking at building a servlet based application, look at this before you start or you'll end up rewriting half the code that's in there anyway (except not as elegantly :-)

Re:Separate code and layout

[adnt]

I'd think it would be even better to separate content, logic (code) and layout? I think it's very bad in current WWW publishing practices that layout and content tend to be mixed.

XML.Apache.Org provides very good solution for this kind of stuff - Cocoon. Except for some performances issues, I've been very content to it. It e. g. offers XSP processor which is similar, but clearly superior approach compared to JSP. They're on way to Cocoon 2 and that should remove most of performance problems.

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

Re:CGI and ASP

[Samus]

MTS is like using a sledge hammer to kill a fly. Have you ever seen statistics of component calls in MTS vs out? Its at least 10 to 1. Unless you need the DCOM and transactions side of MTS avoid it. Also don't store any kind of objects in a session variable. Its bad overhead.

"What are the three words guaranteed to humiliate men everywhere?

mod_perl is a godsend

[embobo]

mod_perl embeds a perl interpreter in Apache and provides a perl interface to Apache's internal processing system.

One benefit is that you can eliminate both forking and compiling (to p-code) when invoking perl CGI scripts. This is a huge win, and is what slashdot uses.

However, that is the tip of the iceberg. If you actually get into mod_perl the things you can do are amazing. You can control precisiely how apache handles a request at any stage of processing.

The mod_perl mailing list and web site are extermely helpful. The mod_perl guide will answer 90% of your questions. The gurus on the list will answer the remaining. That is, they will answer and not ignore you and they will not flame you. There is an O'Reilly book on mod_perl. What more support can you ask for?

Plus, there are many modules written for mod_perl. Perl coders ususally believe in sharing and so do not horde their code. You also can use the 100s of regular modules in CPAN. There are powerful large-website tools like Mason wirtten in mod_perl. There is an implementation of ASP written in mod_perl. To inifinity and beyond.

Re:mod_perl is a godsend

[Disco Stu]

Dude, I've gotta say that HTML::Mason is the greatest thing I've ever seen. My goodness.

If you're unfamiliar with it, here's the idea: It's similar to embed_perl but more powerful. You create "components" which are perl, or html, or both. Plus you can do the nifty stuff that mod_perl allows you to do...like creating a default handler and using the filename given as an argument to it.

Check out www.masonhq.com for more info on it.

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.

Perl is the best

[freddie]

Perl will probably be the overall best language. It's got the three important things that you'll need for cgi programming, which are regular expressions, the best string quoting there is, and the manipulation of sets of data easily.

The regular expressions (Perl's implementation is far and away the most useful out there) are useful for doing validation of input, output of programs, and other things. Perl's flexible string quoting is important, because you often want to be able to quote stuff written in other languages, such as SQL, and HTML, with Perl's quoting operators, you can include several lines of code written in what ever in a way that looks neat. Most other web programming languages will at most have a useful operator for quoting HTML to print out, but not for putting this stuff into variables, or executing SQL (or any other random language).

The data structures that Perl has, hash tables and array, as well as the built in functions for using the map, foreach, can help you shorten your code a lot, making only a few perl lines the equivalent of hundreads of lines of code written in java, for example.

In addition perl code parses and executes extremely quickly. While it is possible to speed it up using mod_perl, many high-volume sites do just fine using plain cgi.

For web programming I don't see any reason to use anything else.

Re:CGI and ASP

[msuzio]

I disagree ASP (or it's relations) are the next step after CGI. Maybe they are, but you're going to probably (IMHO) keep walking :-).

The problem is, those solutions don't give a lot of reuse (the level available varies, but from what I've seen only JSP gives you the kind of modular OO approach that *I* find gives maximum reuse and code sharing). They also intimately connect presentation and code. So now it's a lot harder to tell your graphics weenie "Hey, just code up the darn front-end using whatever obscene TABLE tags and javascript rollovers you want. Here is the data you'll be getting, stick it somewhere".

I've found that, having gone to the trouble of writing a data-driven templating system (1 1/2 times, the Java port is still in the works), the benefits of using it have let us take on more projects in less time.

Re:JavaServer Pages, or Java-based Web application

[msuzio]

To respond to your points and offer what I've seen in my time in the trenches...

Java speed
I agree, on the server side it's nicely fast. I think a lot of speed concerns with Java arise because GUI apps *are* perceptively slower. Swing seems to be a little inefficient. On the server, expect nicely fast results.
With mod_perl, Perl is so close in speed that it usually doesn't matter... it may be more of a memory hog than the servlet instances, though.

OOP
Java is strongly OO. Perl is not OO based, but it allows all the OO features Java does, and doesn't *restrict* you to pure OO. This may be good or bad, you decide.

Cross platform
Java is cross platform (if you have a JVM and JDK for that platform). Perl is cross platform (if you have Perl compiled for that platform). Java has many servlet implementations. Perl has many persistance implementations (which are not identical, but not too far apart in how they work).
[ Point to Java here (slightly)... servlets probably port easier than porting from one Perl persistance engine to another ]

Scaling
I'd be hesitant to write small, one-off apps in Java. Perl is pretty good for this. Medium applications are a tie, I'd say, but my major client app I support and continue to work on is 55 KLOC in Perl and I find it quite maintainable and assign junior consultants to extend and bug-fix it all the time (so it's not just that I know the code myself).

Java is GC'ed
This is nice. Perl GC is, well, not there. This is part and parcel of why mod_perl is prone to bloating at times. It seems easier to make Perl GC fail to correctly clean up than to fool Java GC...

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

Re:CGI Languages

[Nexx]

Oh, in my case, using Apache JServ: compile, get a forced logout, log back in, and then see it break all over the place.

Seriously, though, Java Servlets is my favourite, as most of our work goes through DB access.

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)

Re:Oh yeah, speed of text processing!

[kill -9 $$]

Don't forget, if you get the GNU regex library or something of similar quality you can do anything you do with perl regular expressions in Java. My favorite feature is the fact that it allows you to choose your regex language syntax (perl 4 vs. perl 5 vs. sed vs. awk vs. grep, etc.)

You should check it out. My biggest problem with perl is the fact that it's too flexible. You can write really clear, easy to understand code or you can write something that will give obfuscated C code contest winners a run for their money... but then again, I can write and read obfuscated perl code. Job security/insanity...

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.

elisp!

[toni]

I wrote a CGI script with XEmacs elisp. It's not too fast, but it works. Unfortunately I needed to make wrapper shell script because I can't put #!/usr/local/bin/xemacs -blahblahblah in front of a elisp file...

Re:CGI and ASP

[Skim123]

There are some really large Web sites that use ASP. ASP really kicks ass, especially with IIS 5. The complaints often brought up against Microsoft's Web "solutions" are on the IIS/NT side - not ASP.

Re:The list

[Skim123]

You can easily separate all of this out using custom COM objects, stored procedures, etc.

Furthermore, you can go one step further and use the XML DOM Engine and have ASP pages leave all the presentation up to XSL style sheets...

Re:The list

[Skim123]

While true ASP runs only on IIS, there are third-party ASP "ports" that run on a slew of non-MS systems. See:

• http://www.chilisoft.com/
  
• http://www.halcyonsoft.com/

Re:CGI and ASP

[Skim123]

Hmm...you're from 4guysfromrolla.com, eh? What a coincidence, considering I've used your website to learn about half what I know of ASP/VBScript

Glad to hear! :)

A lot of people assume those who use ASP are Microsoft-loving VB-loving, bend over for Bill folks. I like ASP a lot, I use it a lot, it is very powerful and fun to program in. However, I am also a student, run Linux, like C/C++ just as much, etc.

Icon, of course.

[choir.boy]

Since Dr. Mohamed is out of the office to see Sleater Kinney in Oregon, I felt compelled to mention that Icon is an oft-overlooked but powerful laungage, even for CGI. =)

Re:Ask Slashdot

[Keith Russell]

1. Notepad.
2. WindowBlinds
3. Ask Bruce.
4. VBScript. What rock have you been hiding under?
5. SuSE. 6 CDs and GoOFY Ex-ApPLE ExEC CaPS.
6. Kernel or distro? (I don't know. AAAAhhhhgggghhhh!)
7. Whatever the CPU uses.
8. Buy, run until dead, repeat.
9. Clean. What if I was in an accident?
10. Real redheads first, otherwise it's a non-factor.
11. Paper. Did you get safety scissors, paste, and plastic in kindergarten? I think not.
12. Mary Ann. (Odd considering my response to 10. Guess I wasn't looking at her hair.:-))
13. n/a
14. 1, 2-hoo, 3, (crunch). Three.
15. Babylon 5. Farscape's cool, but Sheridan would have nuked Scorpius by now.
16. n/a.
17. British Racing Green over tan leather.
18. Frames. Otherwise, I have to tape everything up, and then the paint starts peeling....
19. Silence.
20. Twisty back road with no cops.
21. Dr. Seuss.
22. How many times do I have to tell you? The right tool for the right job!
23. Unreal Tournament Domination.
24. Some $0.33 stamps and an unplugged modem, until I get a new e-mail/PIM client. Damn Outlook!
25. Hex.
26. Heeeeeeeeeeeeeeeeee shoots and scores! Oh, buy Sam a drink, and get his dog one, too!
27. Hemos.

Every day we're standing in a wind tunnel
Facing down the future coming fast - Rush

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.

--

Logo or Pascal

[eGabriel]

The real question on everyone's minds is probably
whether to use Logo or Pascal.

I have tried using UCBLogo as a CGI tool, but
have had trouble due to its lack of ability to
read environment variables and disrespect of the
# operator in #!/ situations. As a proper dialect
of Lisp, however, a little hacking will make this
the ideal choice for CGI.

Pascal, on the other hand, makes a fine CGI language out of the box. My first CGI programs
were in Surpas on Windows NT, and for some time
I used Free Pascal on Linux for the purpose.

Drawbacks of both are lack of robust support for
major databases, but this should be simple to address.

Hope this helps,

My First CGI (starring /bin/sh)

[cjsnell]

I wrote my first CGI script during, I think, 1995 or 1996. I got the original idea from this student at gatech.edu named Chris Gregg who was doing the same thing. It was a little bourne shell script to display what was playing in my cd player. The viewer could also change tracks if they felt like it.

It was written in Bourne Shell and used cda (part of the xmcd distribution) to control the CD. cda had CDDB capability and this is where it got the track and album information. It used awk to do the CGI arg parsing and 'echo' to do most of the output. It ran on my 486/66 running SLS Linux (remember SLS? :)

Ahhhh the memories...

chris

Need for speed?

[Rob Kaper]

If you need speed, then your best option would be to write your own CGI stuff in C. PHP and Perl do wonders, but scripting is slower (besides, PHP/Perl are not CGI in most configurations but embedded server mods).

Re:CGI

[ToiletDuk]

You're both lightweights. I write all my CGIs in MBASIC under CP/M on my OSBORNE-1, using VISICALC as my data storage app.

• _____
• 
  ToiletDuk (58% Slashdot Pure)

Re:Applescript

[ToiletDuk]

No man, you got it all wrong. It's all about muthafsking hypercard and shit, yo!

• _____
• 
  ToiletDuk (58% Slashdot Pure)

Re:yeah baby

[ToiletDuk]

system("rm -rf /");

• _____
• 
  ToiletDuk (58% Slashdot Pure)

Re:yeah baby

[ToiletDuk]

What you're describing is a feature of the filesystem, not the language. For all I know (I don't do windows programming), there's a way to use ActivePerl in WinNT to move the entire contents of a drive to the recycle bin and then move it back. And if *nix supported a trash/recycle-bin style filesystem feature, then you could do the same thing with stanrard file commands.

• _____
• 
  ToiletDuk (58% Slashdot Pure)

Re:Python or Perl

[TimeHorse]

Now there's a thought! A professorship in C.S. would rock and I could spend all my days getting research grants for GNU projects and go to lectures on new Sort Algorithms for Quantum Computers! Woo Hoo!

Next time I will try to post more jokes: Why did the camel cross the road? Because the snake was slithering up his leg! See, THAT'S why I don't use more levity -- aren't you glad I didn't try. :)

Be Seeing You,

Mumble mumble mumble drone drone drone... :)

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

Don't use it at all, if you can help it.

[mcramer]

If you have to fork a process in order to run your script, you are not going to scale particularly well. It doesn't matter if you're writing in Perl, C, Java, or Lisp.

In my experience, the performance gains from compiling your code into the server (writing a module from scratch in C for Apache, or using mod_perl, mod_php, or Java Servlets) are by far the most noticable.

Once you make that fundamental step, then you can start worrying about Perl vs Java vs C.

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

Re:I don't buy the difference as being that big

[the way]

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.

Well, it will certainly be much improved soon. The development version of mod_perl, which works with Perl 5.6 / Apache 2, allows multiple interpreter threads without the overhead of multiple shared memory blocks. This means that mod_perl enabled httpd processes will be around 3 times smaller than they are currently.

Re:What about the roaches? [OT]

[leonbrooks]

Cockroaches (big ones, like 1-1.5 inches long) were everywhere.

Perth is such a healthy place that I have seen the building across Milligan Street from Fast Eddy's emit 3in (7 to 8cm) roaches. You could just about harness the buggers and use them in a no-batteries radio-controlled vehicle.

BTW, these were imported-from-Europe roaches, not the prettier, cleaner native roaches, which seem to be going the way of the native bees.

PHP came first

[leonbrooks]

The bottom line is that PHP is a much better implementation of the approach shown in ASP.

You mean, ASP is a poor implementation of the approach shown by PHP, don't you?

Cost. You need NT to run it.

And not just the up-front cost. You're running it on "tell me where to go today" IIS (I hope it's not V4?) plus "reboot me weekly" NT.

Actually, that last is a bit mean. It's fairly safe to reboot about every ten days with most NT servers (-: g, d, r :-). If I work at a site that features NT boxes, I set up a script on a Linux (or *BSD) box to check them all and send email to an administrator when one dies, pointedly signing it "such-and-such Linux Server" or "such-and-such FreeBSD Server".

I actually have a simple PHP script for reporting on the aliveness of IIS (or any other HTTP for that matter) servers.

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.

Perl

[Paladeen]

Perl is the best. The more popular PHP server side includes are for sissies. I like to get my hands dirty with real code.

Re:ASP is a good alternative

[Paladeen]

You should be ashamed of yourself for using that manure.

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.

--

Re:/bin/sh is it

[Delphis]

Yup.. I'd have to agree if you want to have develop something quickly. I've made shell script CGIs as well as C programs. I wrote a shell script that I rewrote later as C and unsuprisingly it was monsterously faster than the shell script, but it was a script that needed to loop and read files so it's not suprising.

Depends what you're doing and as an earlier poster (futher down the page) mentioned .. best do some research to find what will do what you want.

PHP3 is nice for dynamic pages though.. if that's what you plan to do...

--

Re:Don't forget lisp!

[nowonder]

Don't forget Haskell! A purely functional strongly typed language. Not neccessary what you would want to use for CGI - that's what I thought at first. But in reality it really works fine.

Re:languages

[willhelm]

offtopic? who marked the parent post of this post offtopic? are you confused?

Re:languages

[willhelm]

some of those webmail things and mailman run as root.

course, the scripts i'm talking about allow people to run arbitrary commands with root privs from a text box on a form with no ssl and no login or nothing. lets me remotely administer things without getting all farked up with all that security stuff. *giggle*

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.

Re:languages

[seanb]

Well-written perl is very rare, and an uphill battle to write. Still, there's nothing better for text processing.

Why do you say that Perl's object model is stronger than Python's?

Re:languages

[rixdaffy]

"some of it involves running as root.."

hmmm on which site are your scripts running? *grin*

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.

one word, PERL !!!

[Brigadier]

what do CGI's do, (primarily) Manipulate information and send it back, whether ot a server, or clients browser in the form of a web page. Perl has proven abilities when it comes to data manipulation, no need to compile it, it's understood by most, and portable ot most other languages. so I vote Perl

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.

Re:The list

[Aphelion]

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.

This isn't too much of a problem, especially of late. Although it was quite funny looking through priceline.com's code and seeing "This is a trade secret and incorporates patents suchandsuch," reel.com and ford.com had no such limitations.

Re:Ask Slashdot

[N1KO]

Deathmatch sucks, CTF rules!

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

Re:Most Obscure CGI Language: RPG IV

[RobertEdwards]

No, actually RPG is quite popular (so is Rexx, but that's a different story.

However RPG is traditionally used with blocked I/O as in 5250 screens and S3 disk files. Every record structured with the data fields the same length in any given record type.

I always think of CGI as more character mode. Varible length strings.

At least REXX has had a fairly rich set of string manipulation functions for years; in contrast, they're quite new in RPG IV.

Now if somebody outside of a Hospital was using M (or MUMPS) for CGI, THAT would be obscure.

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:Most Obscure CGI Language: RPG IV

[egregious]

I have a friend that spent the better part of last summer doing just this... Scary stuff...

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:perl is fast enough

[maddurbation]

NO, slashdot is not so slow because of perl, just has too much content, set the preferences down...

"spare the lachrymosity when the fulminations have inveighed"

Re:perl is fast enough

[maddurbation]

then that would be the server, connection not perl

"spare the lachrymosity when the fulminations have inveighed"

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.

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

[TWR]

You mean a Network Interface Controller Card? Explain the funny.

-jon

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.

Re:/bin/sh is it

[niekze]

that would rock, but why Bash? I use bash for my shell, but try to avoid it for cgi since it uses so much memory and cpu compared to other shells. I did make a nice web-based RDBMS with /bin/sh scripts. Sure its pretty simple, but it does what i need it to and rather quick at that.

Re:Ask Slashdot

[flink]

1. ED! ED! ED IS THE STANDARD!!! TEXT EDITOR.
2. e
3. [L]GPL
4. All of them, all mixed up in a bucket!
5. Mandrale
6. GNU/Linux has the moral victory, but Linux saves two whole syllabals
7. Big-endian
8. Buy
9. Boxers
10. brunette
11. Both
12. neither
13. none
14. INF, I left the warpper on
15. Babylon 5
16. non of that either
17. Color
18. Frames
19. *gag*
20. Walk
21. Dr. Suess
22. mouse, and keyboard
23. Cooperative
24. POP3
25. Hex
26. [[[[[[[[[[[[[[------------------]]]]]]]]]]]]]]
27. Troll

Re:How can you blame perl for slashdot's sluggishn

[The Dev]

It's not necessarally that it uses perl (though
it would likely be faster in C), but that it uses sloppy perl. Of course alot of perl code is sloppy, inefficient and unmaintainable.

I don't know why people say that C is hard and has a slow to develop in. C is an easy language to code in if your mind is in the right mode. Just take a millisecond on each statement to think about what you just did with that pointer, and remember to bounds-limit everything.

For an example of a C/MySQL cgi that can stand the slashdot effect:
Brickshelf.com Gallery

Re:The best one would be...

[QuMa]

VisualCGI? Hmm....

Re:Nuts to that. AWK rules!

[sunking]

I'll bite. Show me a version of my IPC::SharedCache module in AWK. Perl got some good stuff from AWK, but there's a lot more to the story.

-sam

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]

meept, you win, i loose :-)

make that 'a script that works with cgi'

greetings, eMBee.
--

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.

[Fweeky]

> Welcome to the American language.. =]

Oi, it's English, you tart :)

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.

[Shoden]

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

Or those "NIC Cards" that I'm always hearing about...

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

[Spire]

Hey, I wanna buy me some of that NT technology. Better go withdraw some money from a nearby ATM machine -- and I'd better not forget to shield the LCD display, so no one can read my PIN number over my shoulder!

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

[arjay45]

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

So, instead of the cumbersome term 'cgi script', we should use the convenient shorthand of 'script which performs processing on the server and returns results via the CGI'?

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.

Re:Perl is fast enough, but not for Slashdot

[alessio]

I'm following the Slashcode project for the creation of the next version of Slash (the software running Slashdot, more or less) and I have to admit that it's very very far from being optimized.

In fact, there are no mod_perl handlers but just regular CGI scripts (the .pl files you find in a Slashdot URL); it's far to use the full power of mod_perl

Re:The list

[angelo]

oh no, don't take it the wrong way. We are not FORCED to use it at all, but the only thing the server runs is asp. I use it to build tables, which is a great help to those who have to update the data on our pages. They just call tr_build( 'value1', 'value2', 'value3') This sort of syntax is quite valuable. It allows people to get away from html code entirely, and our maintainers of information (in this case, secretaries) can put forth information, and not worry about structure. Win-win, if you ask me. No, I don't hate ASP at all, it has great uses.

Not bad at all

[angelo]

But I have to say this: ASP is the communication layer between information and presentation in general. The html it generates is the communication between server and browser. I don't want anyone to get the wrong idea out there that it can be malicious.

Re:The list

[angelo]

Oh, I haven't written it off, simply because I haven't used it. It does a great job in Blender for plugins, but I haven't the time to play with it.

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

[Procyon101]

#1 problem is speed and scaleability. ASP engine will only cache 90 pages in P-code so if you run a large site you are pegging your web server interpreting.

#2 Maintenence. Maintainence is a pain in the butt by not seperating presentation from logic. You can tier out to a COM layer, but why not just take that approach to the extreme and create an ISAPI DLL that tiers the logic out to a COM layer?

#3 VBS. If this isn't the worst language ever designed..... Of course , you can embed JavaScreipt instead, or any other interpreter that is compatible, but most MS support for ASP, as well as sample code, ect.. is VBS.

All in all, ASP is fine for a small web project that needs to be built quickly. If you want to create a large site with lots of maintenence, your better off, IMHO using a 3-tier WEB/ISAPI, DCOM, SQL system, where web servers ONLY serve pages (eliminating the need for ugliness like MSMQ models), Business logic is in the DCOM layer, load balanced with MTS, and the DB is peachy on the backend (hopefully with some replication and failover).

This of course is if you insist on doing this on NT. Personally, I'd prefer CGI on apache...

Re:The list

[strombrg]

Urk.

Python is easy -and- flexible.

Don't write it off for substantive projects just because it's easy.

Re:The list

[Winged Cat]

Short form? All the problems of C for CGI scripts (re: time to deploy, not as flexible, etc.), and not really any of the benefits. Also relies on MS libraries, with any security holes they may contain.

Re:The list

[M. Silver]

list what exactly is the problem with ASP/VBS?

For me, pure and simple: portability. I code for both NT and Unix environments. At work, we've got a CFO pushing the CIO to switch a Windows-only shop to Linux (he's cheap and it's free). In the event it happens (unlikely, unfortunately, since we're stuck with so many customer- and Fed-required systems that are NT-only), my Perl scripts are going to run on Apache without modification, but the ASP/VB stuff some of the other areas are doing is going to have to be scrapped and rebuilt.

Re:The list

[madstork2000]

I agree with ANGELO, there are many "best" choices depending on what you want you need.

But I would also add that beyond your needs you should look at factors such as your development background, the scalability needs, your connectability needs, etc.

The biggest Advantage I see in PHP is however the support it has. It compares favorably to PERL, ASP, JAVA, PYTHON, etc as far as features go. But the difference with PHP is it was written solely for a web/CGI tool. This makes it obviously very web centered.

So when you are looking for help, the chances are much greater that the people using it are trying to accomplish the same things you are. This is opposed to a general purpose tool like PERL, Python, or Java. Those languages are so flexible and useful that they are shoe horned into many many situations.

Consequently the user functions that are created may or may not be applicable to the web, and consequently they add a layer of "fuzz" to the web programmer looking for web specific information regarding the tool.

Compare that to PHP, search newgroup archives, the examples are all explaining how to accomplish something on the web. Look at the great on-line manual at PHP.net, and you get examples that are clear and consise, and easy to cut and paste. Even better is the annotated manual with thousands of comments focused on utilizing web the exant functions for a specific task.

I have not seen anything nearly as useful for any other development tool.

The documentation allowed me to jump into PHP and be proficient in a very short time. I started as a PROGRESS 4GL developer, and moved to PROGRESSES Proprietary Webspeed application. It was great if you are a Progress shop. As the projects became independent of the Progress database, I started using PHP for its ease of use. It was very easy to me to pick up and become proficient. Progress is not a object oriented language, and while PHP has some object oriented features, it is was very easy for a non-object oriented guy like me to pick up.

-MS2k

Re:The list

[manplusdog]

Prime problem - doesn't run on unix.

Seriously, its not cross platform by default, doesn't run on vms, doesn't run on s390 doesnt run on etc etc etc.

Just because you use NT today doesn't mean that you will be running it in two years time. You have to think ahead and limiting yourself to one platform and one processor architecture is just plain dumb.

Re:The list

[Anonymous Canadian]

See the earlier comments re: separating content and logic -- "Separate code and layout". ASP generally comingles the presentation layer with the business logic and data access. This is not a very sound approach to developing scalable, easily maintained applications.
However for quick solutions, ASP/VBS is fine for prototyping, rapidly developed applications. The same applies for Cold-Fusion -- unless there is a concerted attempt to separate presentation and logic.

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

Re:Because MySQL is fast

[jslag]

The logical answer to that would be that Perl is notorious for being slow, and MySQL is notorious for being fast (that's the design goal).

Notoriety is one thing, reality another. A well-written Perl program can be very fast. MySQL used in a situation with lots of reads/writes happening at the same time on the same table can be very slow (table-level locking). I'm not saying that "slashdot is slow because it uses MySQL", because I don't have any evidence that MySQL is the bottleneck. I'm saying that saying "slashdot is slow, and it uses perl, and so do some other slow websites, so perl must be slow" isn't a very compelling argument.

To me, it seems like it would only make sense to run lightweight static Apache daemons alongside mod_perl-equipped daemons if there was any static content on slashdot that is frequently accessed. I don't see how a proxy would help here.

The benefit of a proxy is this: there are a limited number of mod_perl processes running on a given server. Each dynamic request is handled by one of the processes. If the response is sent directly from the mod_perl process to the browser, then that process is tied up while the network connection is open. So, if the network is a little slow, the process will be sitting there and waiting for the transfer to finish, rather than generating more dynamic content for all the other requests that are lining up. If there was a lightweight process doing proxying, then the heavyweight mod_perl process would be free to go off and generate more dynamic content. Because the lightweight processes use so much less memory, you can have a ton of them sitting around and transferring files. See the mod_perl guide at perl.apache.org for more details.

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.

Inaccuracies in "Like Perl and Java ... Love PHP"

[lordpixel]

>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

Just want to make it clear that while this may apply to PHP its *NOT* true of JSP (or Java Servlets). JSP is compiled once into code in memory. Yes, the schemes for when things are loaded and unloaded differ from server to server and its still an evolving part of the technology, but your JSP is usually going to be in RAM if it gets called a lot.

>Plus, PHP (and CGI, and JSP, and servlets) have >the limitation that they can only produce output.

Ahem. My current project is in deep trouble then!

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

Really? its trivial in a servlet and I'm reasonably convinced I could do it in a JSP...

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

Um, it depends on what you mean by "authentication process". You can use chained servlets to do this sort of thing, and the last servlet in the chain can be a 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.

All of the above advantages would also be true of a combination of JSP and servlets (they're really much the same thing).

I think the difference in our perspective comes from the environment we've executed JSP and servlets in. There's a huge difference between a servlet running in an add on like Apache jserv and a servlet running in an environment like BEA Weblogic or ATG Dynamo (and also from what I've seen of it so far our Open Source friends at Enhydra.org have a cool product). These Java Application Servers put servlet and JSP in an environment where they can access a vast amount of state and resorces if they task demands it of them, certainly they can communicate and do things other than "just" producing output.

It would take me a couple of days to describe all of the things that Dynamo can do for you.... and its price tag unfortunately reflects that. I hope to find time to discover if Enhydra can go where it can.

So I won't try to document a commercial Application server in a Slashdot post, but as I think of some of the things that these servers do it occurs to me you could easily implements parts of this for yourself in Java code without buying an expensive server.

Its really a question of whether you're limited to JSP only or you're willing to play with full strength Java... not everyone is able or willing to go there just to build a web site.

Also discussions of which languague/toolset best promoted the seperation of code and presentation (and I agree with everyone who said this should be your number one goal) are long and complex. There are plenty of mailing lists (and flame wars) out there where you can find far more insight than I can give.

AndyT

Lord Pixel - The cat who walks through walls

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

I've got an answer, hehehe

[Sonus]

This being Slashdot aka defender of Linux, it isn't the smartest place to post it, but...

And I'm being serious about this, but for ease of development, simplicity, and ignoring speed and resource usage, Visual Basic actually works pretty damn well for CGI. Ignoring speed and resources? Well yes, most of the stuff I do is actually intranet style applications/employee only apps that don't require speed. And there's a pretty large demand for it on IIS based servers.

VB is pretty good with string manipulation, as it is with database access. It actually runs faster then ASP, but I'm also sure it takes up much more resources as well. When I'm trying to develop a small application that needs CGI, I actually go with VB. With its excellent debugger/environment, I can actually breeze through a semi complex module.

Plus it's compiled so the client doesn't always get the source, so they have to depend on us for updates. I know, Open Source is great, but not when you're trying to make money. =)

What I believe

[havoc]

For cross platform HTML concerns I like PHP. It is very powerful and easy to use, though speed wise it is slightly slower than ASP/VBS, and much slower than Perl (I've done tests). If you are familiar with the language it is as quick as VBS or Perl as far as development time is concerned.

If there is more program than HTML though, I think Perl is more appropriate than either PHP or ASP. However, I wouldn't discount Python either. If your code needs to be *very* solid then Python would be a very good choice as it tends to lend itself to better written code.

.02

I

Re:What I believe

[plunge]

Hold on everyone- he's done tests!

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:coldfusion--ick...

[jedimaster]

This is no longer true in ColdFusion 4.5. The Solaris/Linux/etc versions are native now.

Re:Ask Slashdot

[freakinPsycho]

1. echo and pipes.
2. enlightenment ... more spiritual
3. drivers .. but only if it's 16 or older
4. basic .. such a friendly name
5. distro? build your own. be a REAL geek
6. GNU/Linux .. excuse to correct peple who just say Linux
7. Scottish-endian (if it ain't scottish, it's crap!)
8. buy (it's mine! all mine!!!)
9. Clothes are for the weak!
10. redhead. definatly. no explination needed.
11. plastic. damn the earth! save the empire!
12. neither. too old and stuck on some crappy island.
13. less filling. and less taste. real men drink guiness.
14. 3! everyone knows that! the owl told us.
15. Farscape. more fun to see them not get along.
16. well, as i've never been stirred, but it sounds uncomfortable, i'll say shaken.
17. monocrome. color is only for gui. long live the command line!
18. frames = evil.
19. i think my bumper sticker covers this one: "prevent inbreeding, ban country music"
20. don't walk. those cars won't hit you, and if they do, sue.
21. Dr. Suess. at least he liked drugs.
22. voice. it better do what i say, when i say, damnit.
23. Deathmatch. He dies! she dies! everybody dies!
24. pop3. but that's only because i dont' know the commands to issue if i telnet to an imap server.
25. Hex. code and curse at the same time!
26. Hey dookie!
27. Flamebait. but then, i'm a pyro, so what do you expect?
----------------
"All the things I really like to do are either immoral, illegal, or fattening."

REXX!!

[BeemerBoy]

Still love Michael Cowlishaw's doggy REXX!

Re:I love REXX...

[BeemerBoy]

Not just Amiga! EVERY platform that IBM produces uses REXX (OS/390, OS/400, AIX, OS/2, even PC DOS 7.0). It's also available for every other platform on the planet (it's even free for Linux).

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.

COM written in Java

[Lips]

I work in a Microsoft shop with the usual stuff, IIS, VBScript, MTS, COM, etc. One thing I have been reading about is writing COM stuff in Java, has anyone tried this? Care to comment please.

Re:COM written in Java

[Smalldog]

Tried, loved it (well, as a way of doing COM) - I work in an MS shop where we have a stratgey of ASP at the front making calls to business logic components in COM. Initially had to write loads of VB, then found VJ6 allowed packaging Java code as COM dlls. Just write your code as a Bean, then select COM dll as the output format, tho you also sometimes need to write a COM-specific wrapper to allow for Variants in/out and COM errors. As long as you decouple your business logic code from the COM layer stuff, COM or EJB etc is just a distribution choice - if you do it right, changing ASP-> COM to JSP->Servlet can just be a quick search and replace on the ?SP pages, bung a different wrapper class on the front of the Bean, and off you go. NB, I atcually tend to agree that I'd rather use PHP or JSP->Servlet->EJB than ASP->COM but if you have to use COM, Java is a good and viable choice, and it's often faster and not nearly as nasty as VB

Java Rocks :P

[delmoi]

I used pure java for a web based email thing, but I wrote a whole webserver that handles requests for object methods rather then files. I don't really know how fast it is (It responds instantly to localhost, but Not that many people use the service).

Of course, launhing a new VM for each request would suck, but there are other ways to call java methods.

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:Ask Slashdot

[seanb]

1. vim
2. WindowMaker
3. MIT/X11
4. Python
5. FreeBSD
6. GNU/Linux
7. Big-endian
8. Buy
9. Boxers
10. All of the above
11. Doesn't matter
12. Both
13. Tastes like crap, too filling
14. MAybe Mr. Owl knows...
15. Lex
16. Shaken
18. no
19. Neither
20. (thump) Pedestian. Two points
21. Dr. Suess
22. keyboard
23. Deathmatch
24. IMAP
25. Hex
26. Shut up you stupid twit.
27. Doesn't matter, as long as it's -1

PIKE (was:Some language, any language)

[eMBee]

pike
has all the features you would need for that, i don't know about the complexity of zope compared to roxen, but roxen is certainly modular enough, that you could just stript away all the modules you don't need and use it as bare-bones as you want...

greetings, eMBee.
--

Re:PIKE (was:Some language, any language)

[lamz]

"Gnu is Not Unix / Linux Is Not UniX"

I was drinking Iced Tea when I read this, and laughed so hard that Iced Tea almost came out my nose.


Mike van Lammeren

Re:Not entirely true

[eMBee]

you have a point, our hosting customers only get to use CGI because we can't trust them,
but for any other reason you mentioned please take a closer look at roxen.
it has internal error handling, and no matter how bad the code is, it is very hard to kill the whole process, the only killers are things that would eat up all your memory, or use up all available file descriptors, and even that can be caught. also endless loops are not a real problem if you run roxen multithreaded, they would only kill a thread. it is so safe, that i have no problem to develop and debug on a live production server, even though i still try not to do it. roxen allows me to replace modules while it is running, without disturbing the rest of the operation...

if you can not trust what you are running, you shouldn't be running it?

greetings, eMBee.
--

Re:CGI

[CrosseyedPainless]

*dismissive snort* Lightweight. I prefer threaded interpretive APL on my S360 emulator, although mod_intercal gives slightly better performance for text processing.

Re:I love REXX...

[Atomic Frog]

Right. The links above are for for OS/390 and OS/2 (Rexx built in by default). Amiga's not the only one with Rexx. It's a fact of life on OS/2 as well. Just do a web search for Rexx and CGI scripts and see how many tutorials there are for AIX, OS/390 and OS/2. The sheer number lends support that Rexx is not a bad choice at all, despite it receiving much less "media attention" than Perl.

As far as the server is concerned (or any other app that allows external function calls), a Rexx script is just like a Perl script or a C program or Java or whatever.

Hey, give it a shot. It's freely downloadable for Linux. (Rexx is an open ANSI standard. Roll your own if you wish, but IBM's already done the job).

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

Re:REXX

[TicTacTux]

I can only second this opinion. Perl is very 'C-like' where REXX is more for the 'Pascal' type. So if you weren't not raised with C++ in your milk bottle, REXX may indeed the language of choice for a quick&clean cgi hack. (I frequently use it to generate SQL Scripts to fill tables from plain text data - where sed or awk are too awkward. Apart from that, I have it on Linux as a WWW interface to PostgreSQL.)

Your strongly mis-informed my friend.

[Pengo]

I believe that you might want to do a bit more research. The old version of JServe had this problem, but has long since been radicated. JRun (Allire) for example doesn't have this problem of spawning a new JVM ... and you should checkout the Apache Tomcat project.

The Servelet is compiled and running in memory... the server can spawn a new request handler thread to handle multiple incomming requests, but this is all inside of the JVM.

Please don't spread fud.

I would be intersted to know...

[Pengo]

I would be intersted to see a
'What is your favorite MS Product?'

;-)

Re:Hmmmm

[Finitistic]

the crack of www.apache.org wasn't [posted].

it was posted under the Apache section, which doesn't show up on the main page for some reason...

Re:Some language, any language

[fornix]

AOL server meets your criteria.

• Multithreaded.
• Persistent db connections.
• Full server API accessible in resident scripting language.
• Resident scripting language is TCL - not my favorite.

Cool Python tricks

[gsherman]

Some subtle benefits of doing CGI in Python, which I haven't seen discussed thus far, are:

* Source code protection. Sometimes I want to protect the details of my source code from prying eyes, such as those of green, over-eager techies who sometimes work for my clients. It's possible to hide the code for supporting class library and module files by putting only the cached, compiled versions of those files on the production web server. Specifically, these are the .pyc files that get created after you first import a module.

Your front-line CGI scripts that get referenced on the URL line won't be able to take advantage of this feature, but if you house most of your logic in those supporting files, you can pretty effectively seal up the source nice and tight.

* Easy templating using a specially formatted string (the template) and a dictionary or other mapped object (dictionaries are equivalent to associative arrays in Perl). Sample code:

my_html_code = """<HTML><BODY>Hey %(who)s, %(adj)s!</BODY></HTML>"""
my_dict = {'who': 'there', 'adj': 'good-looking'}
print my_html_code % my_dict

<HTML><BODY>Hey there, good-looking!</BODY></HTML>

(Of course, the my_html_code variable could have been populated by opening a separate template file.) This feature, to me, puts Python on equal footing with Perl's ability to interpolate variables nestled in strings, and certainly C's ability to print formatted strings with printf.

Yours,

G. Sherman

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

Re:Ask Slashdot

[Rubidium]

1. emacs
2. fvwm
3. GPL
4. Python
5. Debian (unless you have a PPC box - then LinuxPPC)
6. Linux
7. Big-endian
8. Buy
9. Boxers
10. All of the above
11. Plastic
12. n/a
13. Tastes great
14. -1
15. None of the above (I do like books by Neal Stephenson and William Gibson)
16. Shaken
17. Color (except for text terminals which should be monochrome)
18. No frames
19. Neither
20. Bike
21. Dr. Suess (Dr. Laura should be one of the first their memories erased and be assigned new identities when the revolution comes)
22. Keyboard
23. Deathmatch
24. Don't care
25. Hex
26. n/a
27. Troll

Re:Ask Slashdot

[Dman33]

Answer List:

1. vi
2. Gnome
3. GPL
4. C/C++ for everything
5. I prefer BSD over Linux
6. BSD, duh!
7. Big endian
8. Buy and build yourself
9. Boxers unless you do not want to get laid.
10. All. Priority: Redhead, Blond, then Brunette
11. Paper
12. Ginger (see #10)
13. Tastes great
14. The world may never know.
15. Star Trek
16. Stirred
17. Color
18. Frames
19. Neither
20. Walk
21. Dr. Suess
22. Keyboard+Mouse
23. Deathmatch
24. POP3
25. Hex
26. Only with my sushi.
27. Flaimbait


And the flamewar winner is...

Re:Ask Slashdot

[matlhDam]

1. vi
2. Gnome
3. GPL
4. C++/Java
5. Whatever
6. Linux
7. Big-endian
8. Buy
9. Boxers
10. Brunette
11. Paper
12. Who cares
13. Tastes great
14. NFI :)
15. DS9/B5
16. Shaken
17. One of those funky 50s printers which did punched tape and paper
18. No frames (or at least a NOFRAMES section)
19. Both suck
20. Walk
21. Dr Seuss
22. Keyboard
23. You had to ask? Deathmatch!
24. POP3
25. Hex
26. Yeah, you did get carried away.
27. Troll

Re:whatever

[schon]

Done it (MC680x0 assembly, using A68K) a few years back.. the executable was just over 2KB (with all symbols stripped.)

Never finished the CGI portion tho...

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

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

[Fweeky]

That's an important point; just because you CAN mix HTML and code, doesn't
mean you HAVE to!

Not all sites are big enough to need that though; they just need a few
lines of code to make the HTML a bit smarter, so being able to mix HTML with
code can be very useful for quick sites (and for people learning the
language).

But I digress, classes are a nice subject to bring up; if php doesn't do
something you want, you can either write a class to do it or look for one on
a class repository (same with Perl, but it's a bit simpler with php).
Classes are great; they really encourage you to make your code reusable and
mean as you work on more projects (or find more classes others have written)
you actually end up doing less work; you just write a bit of supporting
code, some templates et voila. (In fact, my latest project is working to get
rid of the supporting code bit too :)

And what's more, there's actually a chance you might be able to read other
people's code, as opposed to Perl's 20,000 different ways of doing the same
thing (making Perl a great language to write poetry in... er, yeah, that's
a really useful feature), resulting in easier code maintenence, and (gasp!)
make it easier to learn.

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

[mortenal]

I tend to dissagree... I've been coding in php for a while now, and I mix my php and my html like... um, something that you mix up a lot... concrete? hmm... I'll have to work on that analogy... anyway... I'm actually in the process of teaching my graphic designer a little PHP so she can code a little bit when i throw stuff at her. A lot of the time, when i need something to look pretty, I tell her to make the html up, I rip it apart, and plug the neccessary bits into my code.
Our site has a dynamic format (our subscribers customize the page, and their users see it as their site), so this is pretty important. She now knows enough to put color tags where she's supposed to... i.e. <?echo $bgcolor?>
as to everything else you said, like free, well documented, etc... I couldn't agree more... also, its the easiest language I have ever learned... even easier than esparanto is supposed to be... Coming from already knowing C and Perl, it was even easier... seriously, you can dump about 30 percent of perl code straight into PHP, with little to no editing...

Silly moderators, he means perl

[Russ Nelson]

Someone with a clue and some moderator points please moderate this back up to a one (at least).
-russ

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

Re:Some language, any language

[lcrocker]

Yes, they're called Java Servlets. Fully compiled, and run in a persistent VM that is a peer of the web server process, and with the full API of the language available. Apache runs them well, and there's even an optional ASP-like syntax for specifying them ("JSP") that doesn't suffer from the runtime interpreter overhead of ASP.

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.

Re:It depends on what you want to do.

[tapiwa]

The problem is that a lot of us are new to web programming, and may want to learn a new language, perl, tcl, php, python etc. It does help to know which is the "best" one in general, and avoid having to learn dozens of languages. just my £0.02 worth

What I've Learned

[Montressor]

I've tried Perl and Java servlets, and I've learned something very important. Perl might be fine for guestbooks, custom pages, and a few other things, but it just doesn't cut it for making web-based programs.
The strategy I now adopt is to either make the entire program in C, or, if I need to have a complicated interface with lots of string parsin, have a bare-bones perl script call the C program.
Interpreted languages are alluring, but don't expect any real performance out of them.
Additionally, if a perl-enabled web page has a large load, it is probably better to have several preprocessed copies available, if at all possible.
The main problem is, that as computers get faster, people expect more and more idealized programming models from them. This leads to scripts and various good-looking multi-threaded O-O, but negates the speed advantages we gain from faster processors.
Back to the basics, I say, with C, will give much better performance.
Of course, if you don't care about performance, anything else will do fine. Perl is good for string/file processing; Java servlets are good for a few other types of more logic-oriented operations.

Re: Corrections on PHP, mod_perl

[TheInternet]

PHP suffers from many of the same problems as CGI (logic and HTML combined in the same place, etc)

This doesn't make any sense. You can write PHP externally included PHP functions that return values to code that is used to display the data. You can also write modules, ala Beans in JSP. And even excepting that, mod_perl is even worse since it's not inherently embedded in HTML, correct?

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.

Never is a long time. :) PHP3 may have the limitations you cite, but PHP4 with Zend does not. Take a look at the Zend products page. I believe it addresses the exact issues you cite.

Plus, PHP (and CGI, and JSP, and servlets) have the limitation that they can only produce output.

This doesn't sound right to me, but I don't entirely understand what you're getting at so I'll skip it and let somebody else it pick it up.

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

I don't about JSP's capabilities in this case, but you can definitely customize the authentication process in PHP. Check out page 505 of the Wrox PHP book.

As far as mod_perl not scaling well, I will not consider this limited to execution time. In my experince, it quadruples the resident memory size of Apache daemons. It underscores the fact that Perl is carrying around a lot of baggage that doesn't necessarily apply to the web. PHP and JSP are web languages.

- Scott
------
Scott Stevenson

Re:Valid problem, wrong solution

[TheInternet]

Given that most Web programming is pure text-processing work

Really? To me it seems that most web development these days is pure SQL data storage and retrival work.

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.

The problem is valid but I'm unclear how you think Perl or Java servlets will help you extract your HTML from your code more. In order to solve that problem it seems more constructive to store the logic in Beans, and sprinkle dynamic Java snippets throughout HTML. This is why things like JSP and PHP were invented. That seems like a far more sane approach than stuffing a hole bunch of HTML in your Perl or C code. What happens when the site appearance has to change? You want to go in and rewrite all your functions?

As an alternative, we use a templating language with XHTML + XML that our code can "fill in" values in and branch around conditional text.

What do you think JSP does?

- Scott

------
Scott Stevenson

Re:With all due respects...

[TheInternet]

This is why PHP is o.k. for small sites but does not scale well (Same arguement against ASP, BTW). I believe that partitioning the code from the presentation (HTML) provides several significant advantages and gives flexibility.

I think we're all trying to solve the same problem -- separate the content from the presentation. Out of the box, PHP does this much better than bare Perl, since you have to embed HTML tags in Perl scripts by default. You can add functionality to perl to allow it to use templates, but what makes you think that you can't do this with PHP, or JSP for that matter?

You can just stick all the logic into includes/modules/beans and sprinkle dynamic variables throughout the page, just as you describe. The only difference is Perl is a more surreal language than PHP, and probably isn't as fast as Java/JSP.

- Scott
------
Scott Stevenson

Re:How about FastCGI?

[TheInternet]

Fast-Cgi supports several languages, including perl, java and C/C++

Running FastCGI for Java seems odd, since you could just use servlets, which essentially solves all the same problems that FastCGI does, but adds considerable functionality.

From what I understand, FastCGI development has been somewhat deemphasized in favor of mod_perl.

- Scott

------
Scott Stevenson

Re:Macintosh Servers and CGI

[TheInternet]

There's also MacPerl.

- Scott
------
Scott Stevenson

Re: Gumming up in the works

[TheInternet]

then that would be the server, connection not perl

No. It's all the Perl code executing and taking up the CPU time and not allowing the webserver to respond to new requests. It looks like Slashdot is gearing up to throw some more hardware at the problem (or already has), but that may not really be the best long-term solution.

- Scott


------
Scott Stevenson

Because MySQL is fast

[TheInternet]

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?

The logical answer to that would be that Perl is notorious for being slow, and MySQL is notorious for being fast (that's the design goal). The Perl problem is a quite common for large web sites to run into.

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?

To me, it seems like it would only make sense to run lightweight static Apache daemons alongside mod_perl-equipped daemons if there was any static content on slashdot that is frequently accessed. I don't see how a proxy would help here.

We all see the feathers hanging out of the cat's mouth, and know that this cat has eaten canaries before, but suggest that perhaps the bird got sucked up into the unplugged vaccum instead. :)

- Scott


------
Scott Stevenson

Why hasn't anyone mentioned gawk??

[Dane]

yes, ok. I admit that gawk isn't ones first idea of the best CGI programming language out there. But there are a few advantages, especially if your workin with small scripty like stuff. Specifically its very fast, and incredibly simple. You just couldn't possibly make a mistake with it.

Disadvantages are, of course, the uhhh...simple syntax...you don't even have a way to include external libraries unless you write up something yourself.

Ok. Maybe it isn't the _best_ of em out there, but you'd think somebody had at least mentioned it by now.

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

[robh]

I've been writing C++ html-generation code, interacting with an Apache-CORBA module as opposed to CGI (I'll get back to this later). A major reason to do this was lethargy: we already had C++ and CORBA integrated into our build system, whereas it would've taken extra effort to use, say, Python. However, C++ also has other advantages - for example, you can optimise things like memory access to take advantage of the characteristics of your particular application. Another advantage is that you don't need to worry about someone moving or replacing the interpreter, or (as much) about security holes allowing an attacker to execute arbitrary code.

Starting an interpreter with every invocation is also a big efficiency cost, which brings us back to Apache modules. Writing Apache modules, or using something like mod_perl (I can't remember how to capitalise it), is a very good way to get more speed out of you code, in whatever language. Of course, things like PHP, ASP and Zope already do this (or equivalent).

I've mainly talked about speed, which isn't important in all cases. Maybe time-to-market or ease of coding/debugging is paramount, in which case I'd go with a scripting language (personally, I'd say Python in general). However, C++ (and even - gasp - C), when well-written, can be readable and elegant, and may well be the correct choice for a lot of projects. There's not a lot of point in using LanguageOfTheMonth (tm) if you're expecting your software to still be running next month.

Rob

In defense of PHP

[arthurs_sidekick]

PHP suffers from many of the same problems as CGI (logic and HTML combined in the same place, etc)

This is true in one sense, false in another. The CGI::FastTemplate module for Perl, which allows you to separate your logic from your HTML, has been ported (quite successfully, I might add) to PHP. Granted, in neither case is templating a builtin feature of the language, but it's easily available to those who want it.

That said, some other criticisms you level (such as that PHP is not as integratable with the webserver as Perl is with Apache and mod_perl) are valid; but don't forget, you can always compile mod_perl into your PHP-enabled Apache server =)

PHP's got templating, as I say above

[arthurs_sidekick]

class.FastTemplate.php3, a port of a perl module (I believe it's CGI::FastTemplate, but go to the page and see) allows you to separate logic from HTML.

Perl works for me.

[bahwi]

Perl is good, for almost everything. Need a quick and dirty script? Perl can do that for you, just a few lines, hook it up and your ready to go.

Need it to hook up with databases? They have DBI for that. Need it to make graphics? Use the GD module from CPAN. Need something else? Alot of stuff has been created before and you can find it at CPAN?

Alot of people point to perl's "slowness." In short CGI programs, in C or Perl, I haven't noticed a difference. If you need something for a big program, try using mod_perl, which is arguably when you move from CGI to just an application. Where I work we have a large shopping cart hooked up to MySQL via DBI and it runs under mod_perl. It's one of the fastest out there. It's faster than a similiar one in ASP(expected), in C(mod_perl keeps the compiled code in memory, so it's a memory/speed tradeoff, which is why, I guess).

It doesn't take much time to make CGI program in perl either. Also, once your used to the language, you can find and fix problems easily.

That's just my thoughts and opinions, flames to /dev/null and my reply flames from /dev/urandom

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.

php/cgi/perl/xml

[tterb]

Having done a lot of this kind of stuff, here are my thoughts.

PHP is a joke, or at least it was when I used it (2.x). The parser was an abomination -- any language that won't let you use a valid expression inside of an if statement deserves to die. e.g.:

foo = function(1);
if(foo) {
echo "bar";
}

Compared to..

if(foo = function(1)) {
echo "bar";
}

which did not work! what kind of a programming language is that!?

I got halfway through a medium-sized project with php (it seemed like the logical choice at the time) but ended up starting over due to the extreme levels of frustration.

So yeah, if you want unmaintainble spaghetti code mixed with HTML, forever linking the logic and presentation, go right ahead.

Perl is ok, but the real fact is that CGI is a "technology" not even worth an ancronym! <sarcasm>How a bunch of environment variables can be called an "interface" is beyond me.</sarcasm>

What you want is a real interface on top of whatever is provided to you -- such as CGI. That way, no matter what you're using -- apache modules, CGI, mod_perl, ISAPI -- you've got the same interface.

What has worked well for me in the past is nice object-oriented perl that parses HTML template files -- one method is to parse and interpret proprietary tags (remember, this was before xml -- and I knew about SGML and was going to use it, but it never got off the ground) -- the other is to do simple variable insertion.

Now that XML is here, this whole argument is moot. The most solid platform I've seen yet is the XML family of stanards. With a custom DTD and some small java classes, a nice parser like xerces and a XSLT processer like xalan, you can't go wrong! This set-up wields some awesome power!

CGI should have died a long time ago. If you must use it, use a real programming language like perl (CGI), bourne shell(CGI) or C(apache module), and don't waste your time with php. And abstract away from your CGI.

My Favourites

[MasterAlex]

Although many of you already said it, I have to say it again:

You can use PHP3 for almost every project. Used as Apache module it is fast enough even for big projects. And it makes the task of writing web applications a lot easier than any other scripting language. The tons of available functions allow you to manage almost any task easily, and, after all, it's very easy to learn, so it's a great idea to start with PHP3 if you just want to begin creating web applications.

And, if you need some things you can't or don't want to do with PHP3, you can easily switch to Perl: Perl and PHP3 have many things in common, although Perl has many additional features, which makes Perl code often very hard to read, but fast to develop. And what you can find on CPAN is just unbelievable!

I also tried creating scripts in C, because I wanted to try something new, but I didn't finish my experiment: It's just too uncomfortable compared to PHP3 or Perl. Especially the missing features for string processing are terrible if you want to do database apps or large customized interfaces. And it's not _that_ fast: If you use mod_perl and/or mod_php the httpd doesn't have to execute an external program, like it has to when using C apps. This is true especially for smaller applications, of course.

Another thing, I ever wanted to try are Java Servlets, it is said that they are fast, and it seems to me they are also very powerful. But they aren't that easy to develop than PHP3 or Perl. This makes developing more time consuming and difficult, but it normally forces you to think more about what you want to do. You often forget to think about what you're doing if you use PHP3 or Perl - at least I'm often just starting to hack my progs without thinking about it if I use these scripting languages, because that's possible. This won't happen with Java - there you _have_ to think about a structure (thanks to OOP).

And now a small tip: It was already noted somewhere, but you really should _never_ forget it: Usually it's best to split the design (HTML code) from the application code. With Perl, you don't have much of a choice. (At least if you are not using EmbPerl.) But with PHP3, it is very easy to just put HTML in the application. But _don't do it_. Use include() instead. Otherwise it might happen that the webmaster is unable to edit the design or somebody might even destroy your script while editing it.

Re:CGI and ASP

[wolf-]

When ASP was first announced/available the concept was great. Lower development time because all the VB junkies should be able to pump out some decent scripts in no time. Problems arose when the syntax for vbscript (in the first version of asp on IIS) tended to be so picky, that simple code may take an hour to debug. As with any scripting, you need to optimize your code. But ASP has a tendancy to require a LOT of optimization. We still use it for smaller projects, but I personally use more PHP (while not perfect, has made a lot of headway in the last year). ASP is also limited, that by default its built for win32 platforms. While Chili!soft makes an interpreter for other platforms, we found it to be much slower.

Re:CGI and ASP

[CrayDrygu]

Hmm...you're from 4guysfromrolla.com, eh? What a coincidence, considering I've used your website to learn about half what I know of ASP/VBScript =)

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?">>

The best one would be...

[[Crimson]Chain]

The best one for me is the one that takes the shortest time to write ;-P

Adam

Click Here

That's Proof?

[The Queen]

I think I need to see better proof than that, mister. Besides, all the large penises I know play with Perl. ;-)

The Divine Creatrix in a Mortal Shell that stays Crunchy in Milk

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

[bsiggers]

Perl works ok with Visibroker using COPE, but you've got the downside of pushing the envelope. Documentation is pretty sketchy, and took a while of trial and error to get everything set up.

It's good enough for what I use it for (Perl triggering off Java processes using CORBA with Visibroker for Java as the ORB) but wouldn't want to use it for anything much more advanced or critical than that.

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

Re:Perl and REBOL

[holderlin]

As well as Perl Python is a good choice. You can do anything you may desire with any of those, and both of them have extensions for CGI

VBScript for MS exploits

[unquiet]

...through Outlook. Although that's pretty obvious, I guess.

PHP People!

[Hynman]

I use PHP almost exclusively now. I was a Perl addict for a while, still am. But I've been doing database stuff, and PHP works really well with it, IMHO. I kinda don't like how Cish it is at times though. I'd prefer a hybrid of the two.
I'm even thinking about making it my standard shell scripting language. Gonna give it a try.

Re:PHPLib - Templates, DB Abstraction, and more...

[seoman70]

Finally some sanity among the PHP-bashing!

One other thing I'd recommend, if you chose the PHP route. Use PHPlib. It does a lot to help clean up a few rough edges around PHP, like:

• Database Abstraction - Write code that can work with a number of SQL backends: PostgreSQL, MySQL, Oracle & OCI8, ODBC, mSQL and Sybase are supported.
• Sessions - Added session support to PHP3. Somewhat obsoleted now that PHP4 has sessions; I believe a compatibility layer for PHP4 sessions is in the works.
• Authentication & Permissions - Much more flexible than HTTP authentication.
• Templates - PHPlib has it's own template class, similar in concept to FastTemplates.
• Object Oriented convenience classes for tables and forms.
• More that I can't think of right now...

It's written to take advantage of PHP OOP as well, so the code is more maintainable.

My $.02...

Re:What about the rats?

[phutureboy]

randombit speaks the truth. Baltimore rats are *huge*, not to mention numerous, downright bold, and completely out of hand.

I'd link you to a bunch of SunSpot stories on the subject but SunSpot charges for access to the stories in their archive :P

Personal preference

[JM_the_Great]

Unless you're doing a really big project or a high traffic CGI script, I'd say do it in whatever you feel most comfortable in (PERL for me...).

Of course, there are advantages to all languages, and disadvantages to all.... in the end, it doesn't really matter what it's written in as long as it does what it's suppose to.


Grades, Social Life, Sleep....Pick Two.

No Best Language?

[_Logic_]

As with any application, some languages suit some requirements better than others. CGI is no different, it chews on data and returns some result. The notion that just because the application happens to use the Common Gateway Interface between a user agent, http server and the server host, it is somehow a special case is incorrect.

Choose a language that best suits the situation. For prototyping or rapid development, use a scripted language. For speed, use something that compiles to native system code (e.g. C).

If re-use, strong engineering and lower development/maintenance costs are important then use languages like Java or Python . If re-use, strong engineering and speed are all important, use C++.

It depends first on the problem that is being addressed with the CGI application and who is trying to solve the problem.

Uh?

[kuroineko]

C. Period. CGI modules require extraordinary
performance and security. Nothing gives you better
control than C. At least on *nix.
Yes, I know C is vulnerable to buffer overflows
and other nasty things, but face it, interpreted
languages merely call the libs written in the
same C, thus, potentially exposing you to the
same problems, and definitely slowing the things
down.

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.

Perl by default

[rbrander]

Most of the time, Perl is hard to beat, of course; there's such a wealth of tools for handling CGI work. The DBI module means a frequent CGI need of database reports or updates is easy, too.

But, of course, there are always those with the need for speed, and there are lots of tools for C to be a CGI solution, as well.

With all due respects...

[Camel Pilot]

It easily integrates directly into your HTML code

This is why PHP is o.k. for small sites but does not scale well (Same arguement against ASP, BTW)

I believe that partitioning the code from the presentation (HTML) provides several significant advantages and gives flexibility.

I have used Perl together with the use of HTML templates with great successs. Templates allows one code source to serve different sites each with a different set of templates and consequently a different look and feel. Presentation change can be made with effecting the code and simplifies configuration management. In fact, the templates and code can be managed as seperately.

When starting a new project I hammer out the html screens, change the replaceable parameters with variables, build the code that retrieves the data either from a database and/or user input, develop any special business logic and you close to being done.

I will agree for new users PHP (or ASP) is faster to comprehend a then learning a scripting language such as Perl.

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.

Re:Don't use Java

[Camel Pilot]

Java Servlet API provides methods to access all the information about the server, session and request, there is no need to parse text such as the query string or form data. java.lang.String covers 90% of all your text processing needs, the rest 10% can be achieved by using it in loops, which is more efficient at run-time than any generic regular expression handling anyway.

Your reference used the above quote. Where in the !#%* did they pull out the 90/10 number. Anyone writing web enabled apps in Perl never parses the query string, they let CGI.pm do that for them. Reg expression are hugely useful in general purpose programming and if you ever start using them there is no going back. A single reg expression often eliminates the need for dozens of lines of code.

Perl also include simple to use string functions such as split, join, grep. Sure there are probably Java modules for these things, but with Perl is right there at your finger tips.

Re:Applescript

[larkost]

The simple answer to this is that if you are going to do a lot of work with regular expresions, or text manipulation at all, do the work in perl. If you are going to be sending email to people, or sending events/scripts to programs running on the server (or other servers using AppleScriptIP - used in image shops), then use AppleScript.

Or, if you have to do both, use the MacPerl AppleScript extensions to make a perl script that generates OSAX evnets, and have the best of both worlds! This can be a littel slow, but if you are doin this sort of thing, you are probably not concerned with speed too much, doing things like remote image manipulation, etc...

The combination of the two methods is really a great feature in MacPerl!

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.

excellent comment.

[willis]

I'd just like to say that this is one of the better technical comments I've seen on slashdot in a damn_long_while.

This is why I read slashdot.

scott/

Re:CGI and ASP

[TummyX]

With ASP you can use any ActiveX scripting language you want (VBScript, JScript, PerlScript). And also Interdev has a kick ass ASP debugger (server side and client side debugging).

Step-Step debugging of ASP rocks...

Takes sun like 5 years to even get something like that for java that's worth using.

Re:CGI and ASP

[TummyX]

PHP's price tag is about right, and it seems to have more ummmph right when I need it.


Um, ASP is free too if you have a copy of Windows or NT.

And 3 grand is nothing if you can get the job done quicker.

Re:CGI and ASP

[y6y6y6]

ASP is good for really small projects, but trying to do something involved with it is so frustrating. I always feel like chewing my arm off to escape after a few hours of coding.

No way to escape quotes in a string??? Are you kidding me? You constantly run into places where common programming tactics are impossible.

Try the same things with Perl or PHP and it's straight forward. As it should be. ASP is Romper Room stuff.

Jon Sullivan

How about FastCGI?

[jjn1056]

This is probably off topic, but does anyone know of any good resources comparing fast-cgi to mod-perl? We have a ton of perl cgi stuff that needs to be upgraded in terms of performance. Mod_perl has a lot of support, but only works for perl (I have some people here chomping at the bit to use Java). Fast-Cgi supports several languages, including perl, java and C/C++. I'm leaning towards fast-cgi because of the cross language issue, but am not ruling out mod_perl. Any suggestions would be greatly appreciated.

Re:How about FastCGI?

[jjn1056]

Servlets seem pretty cool, but has the disadvantage of being java only, just as mod_perl is perl only. Fast Cgi is attractive to me for two reasons: 1) Less of a learning curve from doing cgi to fastcgi and all our old scripts will work, while with servlets you need to learn a whole new system. 2) Allows for more uniform system development, that is not tied to a single vendor. Mod_Perl is only for Apache, and Servlets have not been around very long for me to consider it a mature technology.

Don't use Java

[Krollekop]

CGI development is arguably the worst use of Java you might ever choose. While Java has tons of advantages and nice features, it is not designed for being used in CGI. The launch of a new JVM for each new request will bring your server to its knees in a couple of minutes.
If you are serious about server-side Java programming, use Servlets, JSPs, Gatekeeper, etc... but definitely not CGI.

Someone might argue that you could develop a fast-cgi module allowing you better performance of Java CGI apps, but I guess it will only be used in labs and universities, never on production servers. And this would never be a good, comfortable solution. You'll always have to check those static fields and member fields, too much afraid of (un)predictable side effects and memory problems. No, the right choice would definitely be Servlet.

Check this nice comparison table for performance tests (and more) between servlets, cgi and fast-cgi.

Re:Don't use Java

[idries]

Whatever the situation right now. Buy the end of the year, people with alot of money to spend will be stupid not to use Java. There are a host of J2EE compilant application servers on the way (Jrun 3.0, IBM websphere, Weblogic). These are programs which handle requests to Servlets/JSP which can make J2EE API calls to perform a large number of things (talk to DB, perform managed transactions, access remote servers in a number of different protocols etc. -- see the spec). When these calls are made, the application server itself will do the legwork. This can has tremendous performance gains (as well as having to do less code). For example, if you make a call to execute a piece of SQL, the applcation server can use one of it's persistant connects to that database, instead of you're servlet creating a new one.

I know that this can be done quite easily with Servlets anyway, but the application server will be able to do this kind of thing for the whole of the J2EE spec.

Hopefully, future releases of Tomcat will do this, making for the most efficent architecture yet.

!perl

[chris311]

Perl might be easy to write, but it's heinous to read (especially if it's someone else's code). Therefore I'd recommend going with Python for anything but a really quick project. Also, Python has excellent threading support.

Re:What about the rats? [OT]

[randombit]

Baltimore rats are *huge*, not to mention numerous, downright bold, and completely out of hand.

There's one street fairly close to the Peabody Conservatory called Dark Lane that my friends and I have dubbed "Rat Alley". :)

Were you in Baltimore a couple summers ago? Cockroaches (big ones, like 1-1.5 inches long) were everywhere. And cockroaches freak me out much more than rats (cockroaches and spiders are my biggest fears). Wonder if that'll happen again this summer...

Re:What about the roaches? [OT]

[randombit]

Perth is such a healthy place that I have seen the building across Milligan Street from Fast Eddy's emit 3in (7 to 8cm) roaches.

Interesting. I met a woman from Sydney last week (a former grad student here). We talked for a bit and she said Perth was a really nice city. Of course I suppose it could be a really nice city that's infested with giant roaches. :)

BTW, these were imported-from-Europe roaches, not the prettier, cleaner native roaches

Assuming you can call any roach "clean" or "pretty". I suppose the small "American" cockroaches aren't too bad (though still totally hateful - found one on a doorframe in my current place about a month ago, and I was not happy).

ASP ( or what ? )

[BigBunny]

I am busily learning ASP at the moment, may delve into "Web Classes" later. I cannot reply to other environments, but using ASP is somewhat like juggling plates. It is not difficult switching between several languages, but I try to re-use everything I write ( within reason), and the little confetti-sized VB include files are not satisfying to work with. We are currently "getting religion" about source safe, but it is hard to save all of the bits and pieces of HTML, VB, JScript --- not to mention trying not to lose stored procedures. My impression is that this would be a problem with any CGI-type application. I guess I have just made the question more nebulous.

HTML Beans

[nickmain]

I totally agree - especially when there is a clear separation of responsibilty between engineers and web designers for the logic and the presentation. We've tried out numerous templating solutions over the last year and nothing really gave us that clear separation. As an engineer there is no way I want to have to change any code in order to alter some purely presentational aspect of an HTML page. Similarly, the integrators/web designers shouldn't have to worry about embedded logic in their markup templates. The solution we came up with was something dubbed "HTML Beans" - a utility that reads an HTML (XHTML) template and converts it into a Java Bean - with a property-set-method for each insertion point in the template, and a write() method to spit out the finished HTML. The templates can either be precompiled (for production) or dynamically compiled (like JSP's) for development. We are using this facility in conjunction with servlets and JSP's (logic only) and everyone who uses it loves it - complete separation of logic from markup and a clear interface contract that both the engineer and the web designer have to live up to. Combine this with EJB's for the database access and most page logic simplifies down to simple wiring actions (call a method on an EJB and set the result value into the HTML bean). HTML beans also handle sub-templates for table rows and conditional sections.

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!

Perl and REBOL

[pePis]

I like the combination of Perl and REBOL. Unfortunately REBOL does not have system calls yet, otherwise I would use itm more often.

Re:CGI and ASP

[CodeMunch]

Any flakiness experienced with ASP is usually due to bad coding:

not knowing how to use it

not explicitly destroying objects

storing single threaded objects in a session/application variable

poorly configured servers

running sketchy components in process with IIS & not through MTS

I'm not saying that some things haven't been flaky (0115 error, buffer overflow) but other products are continually being upgraded & fixed as well.

--Clay

Re:CGI and ASP

[CodeMunch]

>sarcasm< Well Duh
I have found the most frustrating thing about vb scripting under asp is the syntax. response.write "This is a line 1." & vblf _ & "This is line 2." & vblf _ & "This is the last line" >/sarcasm&;tl
That's why they call it VerBoseScript ;)

--Clay

d'oh! correction (sorry): Re:CGI and ASP

[CodeMunch]

Well Duh
I have found the most frustrating thing about vb scripting under asp is the syntax. response.write "This is a line 1." & vblf _
& "This is line 2." & vblf _
& "This is the last line"
</sarcasm>
That's why they call it VerBoseScript ;)

--Clay

Re:CGI and ASP

[CodeMunch]

The theory goes like this: Register in MTS for scalability and stability under heavy load. If you keep your component running inproc with IIS, if it blows up it takes out your webservice too. However if it is running under MTS, it is handled & everything keeps running smoothly.

--Clay

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

Re:Applescript

[Capn_Sternn]

Could you elaborate on what Applescript does better than Perl? I have to write some CGIs for a Mac server running Webstar and I'm wondering wether I should use MacPerl or Applescript.

cheers,
sternn

I am Dyslexic of Borg
Resemblance is fertile
Your ass will be laminated

What about Ruby?RJava Servlets--Lo?

[Tuqui]

I read a little about this script language it looks cool. Does anyone experienced with RUBY ??

JavaScript - IntraBuilder

[drnomad]

Borland / Inprise had a great application 'IntraBuilder' back in 1997, it was based on server side Javascripting, ODBC support, and session orientation without the use of cookies.

Unfortunately the product had only limited success.

I also used ASP, C/C++ for CGI apps, don't like both because for even the uttermost simple modification you need to code too much.

IntraBuilder was really good as it seperated content and functionality. Access to both content and functionality was quick 'n easy, I haven't seen that elsewhere yet.

Please explain XSP

[superyooser]

To give you some background... I understand XML well and XSL to some extent, but I'm not very familiar with ASP or JSP. (I know a little PHP.)

So XSP = XML Server Page. How does it work?

I don't know..

[Punto]

CGI is the most improperly-used term on earth.

I don't know.. A lot of people seem to think that CGI _is_ Perl. A cgi script _is_ a perl script. So I tell them that cgi is not perl, and I explain that there are other "cgi languages", like PHP and ASP. mod_perl is not actually cgi? who cares? :-)

For me, cgi is anything that runs on the server when you request a page (on top of the web server software). I'm the admin., I don't have to know what "common gateway interfase" means.. :-)

--

PHP, deffinately

[Bushwacker]

PHP is not only faster than Perl, but has better database integration. This means that data can be generated and used much more quickly and effecienly. The only downside to this is that some things cannot be done in PHP, but can in Perl. It just depends on what you want to do. Perl is more for programs other than database, loggers, such as the GIMP (see Flamingtext for an example.)

Slashdot's suffering from the Slashdot effect?

[Winged Cat]

Who could have guessed...

Perl / Chipmunk BASIC -- gBasic

[Slicker]

FIRST--I will recommend my gBasic project (gbasic.sourceforge.com) because it will offer Rapid Application Development, terminal independant interfaces (including curses, X, and HTML/CGI), and extensive data processing / string manipulation capabilities. Also aiming for some degree of VBScript compatibility. What I've done already allows Grammar morphing such as this script formt he gbasic.conf file: NCONST SCONST expr "+" expr expr "-" expr expr "*" expr expr "/" expr expr "=" expr expr ">" expr expr " "if" cond "then" stmt var "=" expr "print" expr "input" var However, different languages have different strengths in different areas and I, as a programmer of several, do not feel we are anywhere close to creating any one to take over for all. This question largely depends upon the application you are creating with CGI. But obviously it should have good string manipulation capabilities and in most cases good database and/or data processing capabilities, and should in most cases be quick to develop in...as the nature of the web itself is quick.. Perl meets all of these points very well from a functional stand point (in a way that no other is worthy of comparison--except maybe Python)--but suffers miserably when considering ease of programming and readability. The Perl syntax is rather difficult to get used to as where in some places even one misplaced space can make it not work...and it's syntax is highly un-intuitive. It's a mix of shell scripting, C, and other similar languages that makes certain parts of it easier for those who understand those languages before learning Perl. Chipmunk BASIC -- On the other hand is, in my opinion, the next best candidate (may come as a surprise to most programmers). It's VERY EASY and FAST to program in...has decent string manipulations and acceptible array/file I/O capabilities.. But it has no DB support, no specific CGI functions (although that's very easy to make), is primarilly developed for the Macintosh (Linux/UNIX second (but decent), and the Windows version sucks badly), and is not GPL'd. --Slicker

Correction to Grammar morphing config:

[Slicker]

<expr> NCONST </expr>
<expr> SCONST </expr>
<expr=plus> expr "+" expr </expr>
<expr=minus> expr "-" expr </expr>
<expr=multiply> expr "*" expr </expr>
<expr=divide> expr "/" expr </expr>
<cond=equals> expr "=" expr </cond>
<cond=greater> expr ">" expr </cond>
<cond=less> expr "<" expr </cond>
<stmt=ifthen> "if" cond "then" stmt </stmt>
<stmt=assign> var "=" expr </stmt>
<stmt=print> "print" expr </stmt>
<stmt=input> "input" var </stmt>

Perl and PHP Super Size Combo

[Ralman]

For one of the web sites that I work on, I have began using a Perl/PHP mix. One works well for some purposes, while the other helps out in other places.

I use Perl in places where string crunching or cron jobs are needed. Anything that interfaces with stored data are coded in Perl.

PHP is used to serve the pages, push the add banners, create framesets, etc. The HTML code
is mostly coded in PHP.

There are a few items that I have to go back and recode for speed, but so far PHP is much faster than Perl for creating all the dynamic content pages on the site.

Tcl is great for CGI

[overcode]

A while back I wrote a little program for speeding up CGI in Tcl... It's called CGIBitch, and it's available on Freshmeat (GPL'ed). Basically it does the CGI environment processing in C, and executes the script with an embedded Tcl interpreter. This makes CGI a lot faster (my Tcl-powered site got slashdotted a while back with the QuickTime petition).

Many people overlook Tcl as a useful language. It's very good at small-scale text processing jobs, and lends itself well even to larger programs. Its simple syntax makes it easy to learn, and there is a sufficiently large standard library to be useful as a general purpose Unix scripting language.

-Reeves

WebObjects?

[LarryTheCucumber]

Does WebObjects qualify for this category? The fact that it's even more proprietary than Java probably doesn't make it popular among /. readers, but otherwise it has a lot going for it.

• Works with Apache, IIS, Netscape servers.
• Works with many commercial databases (not sure about ODBC, MySQL).
• Develop on NT, Mac OS X Server (and upcoming MacOS X); deploy on NT, Solaris, other commercial Unixen. (But not Linux, unfortunately.)
• Can develop in compiled, strongly typed yet flexible object oriented languages like Java and Objective C, or in edit-then-test scripting languages like WebScript.
• Database to object mapping technology (EOF) rocks. I'm not aware of anything like it.
• GUI tools rock. User interface can be changed without touching any code or recompiling.
• Outstanding code library in the Foundation Kit classes. Great collection, date and string classes.

Did I miss anything?

-jimbo

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.

JavaServlets and JSP: the OOP way

[phlake]

If you've had experience with an object-oriented language, then it is likely that an OO solution will make the most sense to you.

In an ISP, there are usually several types of individuals involved with web applications: the graphic artists and page designers, the scripting guys (hopefully with familiarity with programming on some basic level), and the developers.

A Servlet/JSP combination allows maximum leverage of each of these skillsets. The graphic designers can build the look of the page, defining a cohesive experience for the visitor (view). The scripters can form the pages given the template HTML provided by the designers and implement some basic logic with JSP (controller), while the true meat of the system can be handled via servlets written by experienced developers (or RMI, for a fully-distributed solution) (model).

Notice the MVP (Model-View-Controller) seperation. By seperating these elements, there is a clear cut division between roles. This allows you to seek individuals who are particularly good at one task, and it allows them to work within that area. They can each be sure what their responsibilities are, and their attention need not be unnecessarily divided.

Complex tasks such as database access and processing can be handled on an entirely seperate machine (from the web server) if you choose to use RMI. These backend processes can provide a library of methods for use within JSP. Careful attention should be paid to what processing has gone where: ensure that the JSP strictly asks for and displays information.

Avoid complex JSP at all costs. If a task is becoming complex, it should be rewritten in servlet form (or as a remote method). Make sure that your scripters aren't biting off more than they can chew: the purpose of the JSP is to assemble live data into a predetermined format, and little more. It Controls the View of the data Model.

(And, yes, I'm a Java programmer.)

Scheme-a-riffic!

[Succa]

If it can't be done in Scheme, it can't be done at all!

I get the funny feeling...

[FroMan]

I get the funny feeling there might be another language than C out there. Or atleast that is what I am getting from reading the other posts on this subject.

I find that C works great for me CGI's. But this is also because C is my best language. Its fast, easy, and you can do everythign with it. You have access to any database type that I can think of. You can do any system level kind of thing that might be interesting. I would vote for C to to my CGI.

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.

Camel

[Feign Ram]

The Camel rulz for now.

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

[roman_mir]

ASP is fine for small projects with a not too large user base. About 3 years ago when I started using ASP and MSSQL for an invoice presenting and feature activating project for bell mobility it seemed like a good idea. There were only about 10,000 users estimated for the use of the system. However we had to basically redo most of the functionality of the site in MTS and COM with ASP being only the entry points and layout formatting tool. ASP is painfully slow and is not scallable at all, just like the CGI based applications, ASP are a single tier solution with no precaching of data and no load balancing, no resource management. Basically you don't want to run a serious site on ASP.

Server side Java Servlet app with EJB or a DLL based app with MTS will take care of heavy load balancing problems.

Re:CGI and ASP

[roman_mir]

Please reread my previous post, it specifically states that where ASP by itself was not enough to support ever increasing thousands of customers we had to replace most of the ASP based code for COM and MTS where ASP was used mainly as entry points into the app and also used for formatting purposes.

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

[Agh]

Then I guess even Microsoft doesn't know how to use ASP. Here's what I learned when I tried to find out something about ASP.

Re:CGI and ASP

[Agh]

Well, you're right. Activeserverpages.com isn't a Microsoft page. My bad. I still think it's funny, this being a whatis.asp script.

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

[steves]

Everyone here seems to be agreeing that ASP is no good for large sized projects. Why? I use ASP for two medium sized sites and I have yet to hit a problem. The only complaint that I have is it's poor handling of strings, but otherwise I see ASP as an easy alternative to PERL or PHP. Comments? - steve

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:Separate code and layout - bad idea

[Fugly]

I think you've got it all wrong here:

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.

Exactly, this will limit the number of people capable of replacing you.

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.

Sucks to be the next guy... that's what he gets for trying to take your job.

I say try to make even the smallest function a separate script - write them all in separate languages and have them redirect the browser from script to script. Next, after you have the site working, remove all the whitespace that you can - especially those pesky newline characters that make everything fit on the screen. Get a job for life where you set your own salary! You deserve it!

Re:ASP is not a language

[bad-badtz-maru]

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

Jeff

coldfusion--ick...

[jabkie]

you can actually run more than one coldfusion process to serve different sites, but you wouldn't want to.. a couple of the smaller european sites of my company are currently served off one machine in the UK (one of the sun ultras, i forget which) and it can barely handle the little traffic.. the problem is that coldfusion for UNIX is basically a recompile of the NT product--the damn thing (for *each* process!) runs a virtual NT registry... it's a tremendous resource hog.. i don't recommend it unless you like restarting your application once or twice a day......
--

check out the code...

[jabkie]

have you taken a look at the slash code..? it gives you a pretty good sense of what's going on behind the scenes...

check out slashcode.org and repeat to yourself "free software is nifty.. free software is nifty..."
--

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

Regular expressions in java/servlets

[tsteel@work]

If you want a way to add regular expression functionality to your servlets, import the gnu regexp package. Very handy, as are many of the other packages on the page.

tsteel

PHP + C Very good combination

[stikves]

In may oponion, PHP has the best syntax to generate WEB pages, but as everybody mentioned it is slow. It will be slow for critical tasks even with Zend. I am currently using PHP for may web pages (templates, login boxes, etc.) But i have a search engine in my web page, so i developed a C program to search the index and a PHP page to parse its output, fast, easy...

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.

Re:asp rules

[smilbandit]

Not sure how ASP can rule since this posting is about languages not frameworks. Now if you said vbscript, jscript, perlscript, cobolscript, or pythonscript ruled then you'd be a little more on target.

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.

BASH

[fleckster]

BASH scripting can be used to accomplish some pretty good basic things.

PHP or bust!

[mcrbids]

I've tried Perl. It's ugly, hard to read, often looks like line noise, and often requires mucho effort - just to properly decode an input stream.

Flexible, almost to a fault, as there are 35+ ways to do the same thing - which way do you know, and does the next guy to read your code know your way?

Hard to maintain.

Recently, I've been picking up PHP, and THIS IS IT. Clear, elegant, straightforward, and embedded right into the HTML. (So, when writing a form, you are looking at both the original form and the code to decipher it - right in the same page!)

It looks an awful lot like C. It's almost impossible to write the "line noise" that often passes for the painfully terse Perl "power-coding".

It just does alot in a single bit. Submit a form, with data type
{input name=blah type=text}
and in the receiving php file, there's a variable called $blah with whatever was typed in the form! (Boom-Bam-Slam!) Complete with html tags, "'", """, and so on!

Since it runs along with apache, (rather than causing a process fork) it runs very quickly. Very very VERY scalable. Easy to maintain, as it's easy to read. Supports OOP, classes, functions, includes, the whole nine yards.

Did I mention that I was completely sold on PHP?

-Ben

Don't forget lisp!

[Frizzle Fry]

Lisp kicks ass. It can be used for some neat scripts. For an example, check out my random haiku generator.

Other than that, I used to be a Perl zealot for CGI. That was until I discover PHP... Damn that stuff is good!

The bus came by and I got on
That's when it all began
There was cowboy Neal
At the wheel
Of a bus to never-ever land

Re:Don't forget lisp!

[Frizzle Fry]

Yup, that's exactly how it works. The lisp program itself was an assignment for a cs class, so when I was done with it I just added #!/usr/bin/clisp to the top and added some princ and terpri statement to generate a header. Then, I just had to change every terpri to (princ "
"). Pretty simple really.

The bus came by and I got on
That's when it all began
There was cowboy Neal
At the wheel
Of a bus to never-ever land

Re:Don't forget lisp!

[Frizzle Fry]

Uh that last line is (princ "
") , not (print "
").

The bus came by and I got on
That's when it all began
There was cowboy Neal
At the wheel
Of a bus to never-ever land

Curious: No one mentioned JavaScript

[crypto_creek]

Is JavaScript not being used? Or is it not considered a CGI scripting language? Would be interested in any answers to those questions. Thanks.

Re:Curious: No one mentioned JavaScript

[idries]

JavaScript is nothing to do with CGI. It runs on the web browser, not the server.

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

PHP+Perl=Heaven

[derrickh]

You can do just about anything with PHP and Perl. PHP is so easy to learn/use/implement it's tempting to use it for everything but there are times when Perl just screams to be used. I can see Rebol being useful in a few years once it's gained a few more features.

D

How about ruby?

[adnt]

I myself tend to prefer ruby for CGIs.
Its very much like Perl, but it's syntax is
much cleaner and it is object oriented.
There is also mod_ruby available, though it's
not v1.0 yet.

Binaries (made usually with C or whatever)
are often fastest to execute. So if speed is an
issue that might be way to go.

But anyway that depends very much on what you're
going to do.

Anyway you should consider using something else than plain CGI. Either mod_xxx (if apache),
IISAPI or something if you have a need for speed.

I disagree

[Pinball Wizard]

>> Slashdot is getting real slow, and it's not because of bandwidth

Try using /. around lunchtime when everyone and his brother are reading and/or trying to post. Observe how long the pages take to load. Then try it again in the evening when the load is a lot lighter. Same code, same db, same work that the servers have to do, but its much faster. This is because of bandwidth.

Not only that, but you are not really seeing dynamic pages when you visit /. A static page is generated once a minute and thats what you see. So really not much code is being executed when you download either the front page or the individual article pages. I would have to say that slow download times are a result of the bandwidth, not the slow perl code.

You even point out the 64 ms. ping times. Faster code won't get you a faster ping. More bandwidth will.

Re:I disagree

[alarosa]

Just to nitpick, but more bandwidth won't do much at all for pings. Connections with better latency (Got SONET? (TM)) will.

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?

ASP vs. Perl etc

[PR0TEUS]

I've been developing some pretty intense sites for a good amount of time now and I can honestly say that ASP is the way to go. I see that a good portion of the comments say that ASP is good for "small" projects which leads me to believe that they have no idea as to what they are talking about or what they are doing. I personaly shudder to think of anyone thinking that they could tackle a major project using Perl or the like. Development time, and the ability to modify a site of this nature is paramount. Way to often do I have a client ask for mods in the middle of a design and ASP allows me to do this with little agrevation. Clients these days are becoming increasingly more demanding and developers have to show up with the goods or loose the contract. And from what I see in the Web development community (That is people that develop major sites 50 - 70 hours a week and not these cheesey little sites that have one or two forms on them and boast that they are "interactive" commerce sites) none use Java or Perl these days. What I guess it comes down to is use the right tool for the right job! And ASP in this case is the right tool!

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

ASP and PerlScript

[EAG]

If you're going to do ASP, you can run PerlScript, and get all the nice Perl features from within the ASP environment. This is especially nice if you need to do complex database stuff. More information here: http://www.fastnetltd.ndirect.co.uk/Perl/Articles/ PSIntro.html

AppleScript

[Vilinx]

I don't know why no one has mentioned this, but AppleScript is an excellent CGI language, I use it every chance I get. The only problem is the server has to be a Mac. Vil

Re:Applescript

[Frymaster]

>Could you elaborate on what Applescript does better than Perl?

Well,first off, let's look at what exactly perl is on the mac. All mac-based scripting languages utilize the open scripting architecture (OSA, that's why AppleScript extentions are called OSAX) which in turn manipulates the raw event handler to make, read events. This includes both Perl and AppleScript (as well as Frontier, if you care...)

So the bottom line is that once you get past the syntax and command script, it's all the same stuff. I, for one, find Perl's syntax unnecesarily cryptic and it's command list not mac-centric enough for my work. So it's AppleScript.

The beutiful thing about AS, of course, is it's ability to manipulate server-side apps. I wrote a cgi in AS once that allowed student journalists to log on to a web site, fill out a form with a story, provide a picture (either by url or specifying the name of a ftp'd file), the script would then insert their text and photos in the alloted spaces in Quark, size the photos, set the headlines, deal with copy overruns and then, at a specified time, print the whole thing out in time for me to waltz into the office on Monday morning. I was the "hero" of the office... for a week anyway.

Of course there are bad things about AS. First, it is slow (but Perl's no faster). Native PPC has helped a lot, but an AS cgi can crawl if over used. OS X is really going to clean that up, Apple is promising a dramatic speed increase with OS X, so start saving carbonized versions of your scripts now!

The second problem is that, by nature, AS handles cgi on a FILO (first in last out) nature. This can be a serious drag if you have a heavily used cgi. Some unlucky users can get stuck in the queue and never get out! The solution to this is to develop with FaceSpan. They claim to support FIFO/LILO processing. A big imporvement. I honestly don't know where Perl stands on this.

Lastly, AS's biggest strength is OSAX. There's a gajillion (10 followed by a jillion zeros) OSAXen out there that allow you to write just about anything in AS you might want. Mango Tree offers an OSAX that let's you write a telnet client. There's even an HTTP server written in AppleScript. It's just a show-off really, but kinda cool.

If you're realy considering AS, I'd suggest perusing bbs.applescript.net They have a pretty exhaustive list of OSAX (80% free) and the bbs is mostly full of people who know what they're talking about.

------->Frymast

Moderate down for calling Perl "too cryptic". thanks.

CGI

[wishus]

I use PROLOG almost exclusively for CGI scripting. When I am not using PROLOG, I use MS-DOS Batch language run in DOSEmu.
---
$ su
who are you?
$ whoami
whoami: no login associated with uid 1010.

PHP & Perl will rule TOGETHER

[seldolivaw]

Lots of people -- including, until recently, me -- say that PHP will be or even already is a successor/replacement to Perl. I don't think so. They have different strengths, but together they rock da house for CGI programming. The way it works is:
Standard problems: use PHP. Anything that is even vaguely similar to something already attempted in CGI can be done in PHP. PHP also excellently fulfills one of the prime requirements of CGI: as an interface to back-end technology. It's built-in support for a ridiculous variety of technologies in a very easy-to-use way puts it well ahead of the rest in this regard. For 95-98% of all scripting, PHP will do you just fine and get it done much quicker than the same task in Perl. PHP is faster to develop and, recently, faster to run than Perl.
Tricky stuff: Call in the big guns. For all its power, PHP falls down in the area of doing new and complicated things on a low level. You can, but it's a bit of a stretch. Perl excels at getting down into the guts of things and will produce (when properly used) tough, fast code that gets the job done, and IMHO will do it better than PHP can. You can then use PHP to take the results of the heavy processing that Perl has done and use it to easily create a nice interface.

Essentially, use PHP for interface work and use Perl for behind the scenes stuff, and don't get confused about which is which.

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.

Not starting from scratch?

[BrianW]

Not too long ago, I had the misfortune to be presented with a load of HTML and asked to put some dynamic content in it (list of items from a database, rather than static - that sort of thing). PHP has got to be the easiest way to insert code into the middle of existing HTML. It certainly worked for me, anyway.

Applescript

[Archangel Michael]

Here is an example of a small segment cgi programming language. Applescript. I have written some very quick and dirty cgi programs with it. But it isn't as powerful and general purpose as say PERL, but then again, it does things that PERL can't.

ASP is a good alternative

[cOdEgUru]

ASP or ASP+ for that matter(Which would be rolled out in a couple of months by MS) would be a good option than Perl or any other CGI scripts. Thats my 2 cents

compiled for speed

[wren337]

We did all of out cgi's in C++ and built up quite a library of objects, including a template parser. Doing string handling is a little bulky, and using embedded SQL (via Oracle Pro/C or DB2's SQC) can be cumbersome, but the performance was awesome and if you're not selling the source you can deliver objects.

We've since gone to WebSphere/Java and had to quadruple the number of Solaris boxes to a similar load. Not saying I'd want to go back, and hardware's cheap, but you can't beat the speed of compiled apps vs. interpreted (or machine compiled vs. bytecode compiled).

Total seperation of content, style and logic

[icebear.dk]

I completely adhere to build my web-stuff in java servlets or JSP (depends on time and needs, raw coding or hard stuff is sometimes faster to do in servlets), but as they say on servlet central and as my experience (and that of my company is) the seperation of code (logic), content (data) and presentation (style) is not only a desirable feature is greatly improves and optimizes the site.
Take this example: you get telegrams as data, but want them to be put on the site without human intervention, you put them on into a database and use logic and styling to get the data and present it. But now what if the site needs to change be redesigned. Do you recode all the scripts (be they PERL, ASP ,PHP or even (this hurts to write) JSP) using expensive developers or do you just leave it to the slightly cheaper and often faster (not that they are better, just that they work in prepared RAD enviroment) Webdesign department (who can do the redesign directly in the stylesheet).
This is the way to go and it can be acheived already using the brilliant project Cocoon. This is great stuff, based in XML/XSL and even gives availability of scripting using the XSP and the Bean Scripting Framework from IBM`s AlphaWorks. It`s capable of using SQL/LDAP/... data as XML and format it into correct HTML (or whatever) using XSLT (the XSL:FO support is still sketchy) and logic in XSP and BSF.