Hi,

We at my firm have been debating for several weeks over which platform the next generation of our product should be developed on.

Among the contenders were ASP.NET, JSP and Perl (mod_perl + Apache::ASP).

All of them have their "pros" and "cons", so it was no easy choice for anyone.

->> The bosses wanted an established technology with substantial mindshare, security and scalability. Price was also a factor.

->> The developers wanted a well-documented, extensible toolkit that could do anything with minimal effort, and adapt to unforeseen changes down the road, as well as a rich collection of add-on components for enhanced functionality.

->> The network engineers wanted something that wouldn't tax the servers or the network more than necessary, and took into account serious issues like security, load-balancing, clustering, failover scenarios, deployment and upgrades.

So we looked at the big application servers for Java: WebSphere ($15,000/processor) and BEA WebLogic ($4,200). These products do not have a reputation for being cheap or easy. Those of us who had worked with them before only had nightmare stories to tell.

Java: Close, but no cigar.

Then we looked at Microsoft's ASP.NET and the .NET Framework.
Pros:

• Well-documented.
• Easy to set up.
• Great OO Model.
• Nice web page templating system.

Cons:

• Needs IIS to run properly.
• Security is an issue.
• Simple things take a lot of code.
• Several features we need simply are not there (see below).
• Closed-source, so extensibility is limited.

The features we need, while seemingly advanced, are not new concepts. Java has some of them, but at too great a price in terms of performance and overhead. .NET will have a hackneyed implementation of them with its next release.
The features in question are:

• Network-installation of application code on server startup.
• Automatic discovery of remote methods for locally-defined objects and classes.
• Server- and Domain-level application security on a method-by-method basis.
• Run-time evaluation of autogenerated code, without performance penalties.
• Run-time definition of new classes and methods, without performance penalties.
• Anonymous functions (also definable at run-time).
• Extensible, anonymous event handlers (i.e. -- onBeforeUpdate, onAfterCreate, etc).
• Full run-time access to the webserver's API, for fine granularity of control over requests and responses.
• Platform-agnostic: same code works unaltered on all target platforms.
• Scalable Session-state manager available to all servers in a cluster, without the need for "Session Affinity".
• Web-only servers offload the heavy lifting to secured application servers (where the auto-discovered remote methods live).

We knew what the application should look like, it was a matter of what tools would help us get the job done on-time and under-budget.

These features are definitely outside the scope of most web applications, but they are the minimum requirements for what we are building.

Fortunately we were able to find a tool with all of these features, as well as the pros .NET had to offer, just to name a few. Perl.

Through an XML API, we are able to support clients running on any platform, but the core itself and the initial client package will be written in Perl.

Maybe a future release of .NET will support all the features the design depends on, but for now it looks like we would end up doing too much extending to make things work the way we need them to.

To be sure, ASP.NET is an excellent way to build websites and web applications, and its event-driven model helps simplify some things that would be difficult to produce otherwise. IIS6 has several great new features, but we're still stuck without direct access to the server API (unless you consider ISAPI DLLs direct access), runtime generation of new classes and/or methods, and abstracted discovery of remote methods/etc.

<UPDATE: Here are the Pros & Cons we were looking at.>
Perl also has its Pros and Cons.
Pros:

• Easy to do complex things with very little code.
• CPAN.
• Regex.
• Autoloaded methods.
• eval strings of code within the current namespace, without major performance penalties.
• Use remote modules with ease through extending @INC.
• Self-documenting with POD.
• As free as the GPL, Artistic and Apache licenses.
• Huge user base.
• Huge install base.
• Stable.
• Portable, goes anywhere Perl and Apache have been ported to.
• XS and Inline::C/::Java/etc allow interaction with existing libraries and 3rd party interfaces.
• Apache has a solid track record.
• mod_perl can be quite fast, and considering the server API methods it exposes, is much easier to do complex things with mod_perl than with ISAPI filters on IIS.
• Dubious code can be run in "safe" mode.

Cons:

• Doesn't have a marketing department to generate hype.
• Great Perl programmers are seemingly in short supply.
• No UML-based code-generator.
• Compared to C# & VB.NET, Perl seems old and esoteric (i.e. $^W, $/, &$AUTOLOAD(@_), etc).
• Lack of control over your methods and classes getting overridden. No "sealed" attribute for objects.
• Source code is plaintext, not compiled for distribution. Tamper-prevention requires use of source filters.
• Percieved lack of acceptance in the enterprise.

</UPDATE>

I'm just glad we didn't have to compromise our design to fit inside our toolset's box.