http://qs321.pair.com?node_id=376433

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

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:


Cons:
</UPDATE>

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

Replies are listed 'Best First'.
Re: Choosing a Platform
by graff (Chancellor) on Jul 22, 2004 at 02:01 UTC
    Sorry to be a nit-pick, but you started out by saying:
    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.
Re: Choosing a Platform
by jplindstrom (Monsignor) on Jul 22, 2004 at 09:03 UTC
Re: Choosing a Platform
by greenFox (Vicar) on Jul 22, 2004 at 06:31 UTC

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

    --
    Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

Re: Choosing a Platform
by hardburn (Abbot) on Jul 22, 2004 at 13:07 UTC

    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.

    ----
    send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

Re: Choosing a Platform
by perrin (Chancellor) on Jul 22, 2004 at 16:24 UTC
    I have no doubt that Perl can do the job for you, but your list of requirements is... well, not a list of requirements. There is no way you can know that you need "run-time definition of new classes and methods, without performance penalties" before you've even chosen a platform! Different platforms handle situations in different ways, and you should really do as the Romans (or Java programmers) do when you're in Rome. Right now, you seem to have a pre-conceived design based on what you know about Perl, which is fine, but don't bother pretending you are considering other languages then.

    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.

Re: Choosing a Platform
by deibyz (Hermit) on Jul 23, 2004 at 13:51 UTC
    You've mentioned WebSphere and WebLogic, and price and performance as disadvantages.

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