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.

You mentioned some specific "cons" regarding ASP.NET and JSP, but you didn't have anything similar relating to Perl. What, in particular, did your discussions and research reveal that were "cons" against the mod_perl approach? (Or did I miss something?) Was it just the bosses thinking that Perl is not "an established technology with substantial mindshare"?

There's nothing wrong with preaching to the choir, but I'm sure I'm not the only one who comes to PM to keep an eye out for traps and shortfalls in our chosen toolset, and pointing out issues in Perl were considered to be problems would be a useful service (especially if they were technical issues).

Still, thanks (++!) for a very good read.

I took your advice and added some major points about Perl that did come up in the recent weeks.

/J

"Doesn't have a marketing department to generate hype."

This is a con? *grin*

Perl seems old and esoteric (i.e. $^W, $/,

Slightly tongue in cheek but maybe you should use English; :) Nice to see someone elses comparisons though, thanks for posting it. It would be interesting to see a similar breakdown of your pros and cons for Java.

Most of your cons for Perl seem like problems of politics and viewpoints than real technical issues. Which means (perhaps obviously) you need to approach Perl acceptance as a political problem, not a technical one.

Perl does have UML tools, though I personally am warry of automatic code generation.

Source code is plaintext, not compiled for distribution. Tamper-prevention requires use of source filters.

This issue has been discussed before. See Here is a commercial obfuscator.

Update: Also, don't discount Python and Ruby. They have Apache modules that also allow fiddling with Apache's internals (though they don't seem to go quite as deep as mod_perl, at least in Apache2). People with a Java background may be much more satisfied with these languages.

I'm confident that you could build whatever this project is in Java or ASP.NET. You could avoid the cost and most of the problems with Java by using open source tools instead of the expensive commercial products. However, if you have a good development team that wants to use Perl, just do it. If you are looking for help with political arguments that your managers are making against Perl, then ask for that.

Runtime definition of classes and methods.

The main ideas here are:

• We want our installed codebase on the web servers to be as minimal as possible while still leveraging a large number of classes and methods.
• Less code is a good thing. If we can shave off several thousand lines of code to write, document and debug, then that's great.
• This thing has to scale out in a big way. The less we have to worry about quirky behavior of any kind, the better.
• If we can look at 8 lines of code on a web server and see that it's looping through the items in your cart, sorting them by name, calculating the subtotal, looking for cross-selling relationships, checking for discounts and making sure we still have all you items in stock, that's a good thing.
• Declaring everything we want to iterate through as Iteratable, as well as defining its One True Sort Method, is too much work. Let the machines get paid for that.

  Defining all these methods on the core servers, and also defining "pass-through" methods on the web servers would defeat the point of having lots of functionality, but very little code.

  If, on a web server, I say: User myUser = User.retrieve(12); I want it to go get user #12 from the core server. I don't want to have to specify that this method is somehow special because it, like every other method for every single object, is defined within the core.

  The other part of the problem is if I want to override "User.retrieve()" locally. That local method should still be able to call it's superclass' method on the core server.

  With Perl, this is easy: Just use AUTOLOAD. With C#, it is possible, but not easy. There is currently no C# equivalent. We would have to define the same methods locally (by hand), but have them call out to the core using webservices. If we have 100 servers running as clients to the core, we would have to go update 100 servers with new methods whenever we add new functionality. If our application has 1000 methods running on 100 servers, it can become unmanagable very quickly.

  Consider this scenario. You have 30 websites running as clients on 1 server. Website#1 wants their Contacts to have unique email addresses, but Website#2 doesn't. Website#3 wants 1 Contact registration per household, Website#4 wants at least 3.
  We can simply have domain-level Class method overrides take care of the Contact.Create() method, leaving the rest of Contact alone.
  We could have implemented some front-end logic on their website's lead-capture form, but what about the administrative tool which everyone uses? We couldn't enforce the same validation/requirements on the backend this way.

  We can offer sensible default behavior out of the box, but when (not if) our customers come to us with special requirements, we can now accomidate them with a reasonable amount of effort, while leaving our other customers' data, objects and experience out of it.

  I would be very interested in finding out techniques for achieving the same kind of runtime flexibility and extensibility using other development platforms out there. In fact it could make writing the plugins for other platforms a bit easier later on.

  Thanks!

These still aren't really requirements. I was thinking of something like "handle customization of system functions for individual customers in a way that minimizes our work." Assumptions about using multipe servers, remote methods, etc. are all design, not requirements, and they are affected by your choice of platform.

You talk about code generation as a way to achieve ease of maintenance and avoid "quirky" behavior. In general, code generation is pretty confusing and error-prone, and often makes maintenance harder.

Then you're talking about remote method calls, without any context for why they have to happen. Your first goal should be to eliminate as many remote calls as you can, since they will slaughter the performance of your system. If you do have to do something remotely, that still doesn't mean you need AUTOLOAD (another rather quirky and error-prone feature). You can do this sort of thing with proxy objects, or various rmeote method call systems that different platforms supports.

I don't know enough about your system to give you concrete advice, so all I'm really saying is that deciding you need functionality along the lines of AUTOLOAD before you have chosen a platform seems backwards to me and implies that you really have chosen a platform already in your mind.

While this is indeed the most measurable decision you can make, it is hardly the most important. I have seen teams argue for months on platform choice. At the same time, they spend zero seconds arguing on the importance of testing, hiring experts, agile process, or the other important issues.

Must be something about the visibility of the platform choice (look he is using Visual Studio!) vs. the non-visibility of the important stuff.

Cannot remember the name of the famous consultant, who has been on many a project, and was asked: what is the most productive platform? His answer: it makes no difference, as long as the team gells arount it, and has a passion for it.

What about Apache+Tomcat? Even though I would choose Perl, I've been working with Apache + Tomcat in lage production environments with very good results, and price will be ok for them too =).