1. I don't use IDEs, but the customer wanted one, so I pointed them at the usual suspects (EPIC, Komodo, OptiPerl). They've been pretty happy with Komodo. I, however, am still searching for a solution that provides a usable debugger for multithreaded (even multiprocess) apps. (Maybe someday I'll have time to pursue it w/ Devel::STrace)

2. I decided to use a threads based solution (primarily since it had to run on Win32, where it would be threaded whether I forked or not, and I'd be running on SMP h/w). Unfortunately, as many of us know, Perl threads are a double-edged sword, and continue to be fraught with issues (jdhedden's recent excellent efforts notwithstanding). Hence, I had to build a lot of infrastructure to provide a reasonable solution to OO + threaded Perl.

3. Staff resources were at a premium: it was basically me and half time of one of their staff. As a result, things got hectic toward the end, and testing suffered. However, the framework met most requirements. Eventually, problems surfaced during deployment (as usual), but most problems were identified/fixed within 24 hours, and the patching process using Perl couldn't have been simpler. ("Here's a new module, just run the usual make/make install."). Additionally, the app had originally been targeted for Win2K3, so thats where most testing occured. During deployment, the customer decided to switch to Linux. While there were a few hiccups, the migration was nearly painless (I think that effort may have fully convinced the customer). Finally, the biggest doubt in the customer's mind - performance - was allayed when a large number of users were able to use the framework without any noticeable processing delays. (tho I certainly still have some concerns, esp. with threads::shared, and with the large footprint resulting when 20-40 threads are in use).

4. The biggest issue thus far has been fault tolerance/recovery (which should be a clue that this is definitely an 'E' word app). E.g., see Perl coredump analysis tool ? and Devel::STrace: strace for Perl scripts (with some seedlings) for details and the eventual solution; I'll definitely be researching more module reload and thread management capabilities in the next release cycle.

• Perl allowed me to prototype the solution PDQ, which got the customer's attention. And the ability to quickly turn around a set of updates to said prototype clinched it.

• Time from prototype to production deployment, using only 1.5 staff, was about 6 months, including about 3 weeks of "ripening" time. A Java solution might be possible in that timeframe, but would require a small army of staff. I personally doubt that a reliable C++ version could be developed in less than 10 staff-years. As to Python or Ruby, they'd likely provide lead times similar to Perl...but also have their own set of problems (see below).

• Perl IDEs (or edittors cum IDEs) are available, but debuggers for large scale Perl really don't yet exist.

• Perl can scale, but the "weight" of threads and esp. threads::shared, impose some architecture considerations (hence, Thread::Apartment). Things are getting better, but I've already begun sketching out an alternative for threads::shared for certain classes of data. That said, Perl certainly outshines the Python and Ruby solutions in that regard, as Perl uses real threads. Python and Ruby may benchmark faster on raw compute tasks, but when the app hits the kernel - esp. an SMP kernel - that perceived advantage comes to a screeching halt.

• Delivering updates to the customer is certainly more painless than either C++ or Java; and hopefully, with some CPAN modules I recently discovered, things will only get better ("look, Ma, no restart!").

• Platform migration was a breeze (in my experience, better than Java).

• As a framework app, the customer can write and plugin their own modules. Perl makes that effort very easy.

As to the authors contentions of Perl's shortcomings:

• better error handling - yes and no. Perl certainly provides many different ways to trap errors. The problem is the myriad ways various module authors choose to employ those methods. A true exception handling capability (not the heavyweight eval{} version) would certainly be welcome.

• logging - plenty of logging packages exist; the author needs to spend some CPAN search time

• threads - I'll agree to some extent; there are certainly things that Perl needs to address wrt performance and footprint

• assertions - again, yes and no. C++ and Java assertions are needed because the languages require such volumes of code to do simple things that a serious forest v. trees problem arises. OTOH, Perl tends to get lots of things done in a pretty minimal syntax (tho I'm not a sigilista), hence, the developer can "connect the dots" more readily. At the same time, a single logic error in Perl can have a broader impact, so assertions have value.

• native compilation - I'm leaning to the "no" side. There are certainly many times I wished I could compile a Perl app down to a nice small executable (executable "bundlers" do exist, but they'er not really "native" or "small"). But my recent experience taught me that the only advantage of such executables is obfuscation, and at the expense of maintainability/supportability. In our current era of cheap large memories and multicore, multi-Gigahertz CPUs, the perceived performance improvement of native compilation is becoming a myth. That perception also seriously underestimates the productivity and supportability impact of scripted languages on the ROI equation.

• IDE - depends on the definition. If its just another syntax highlighting edittor, there are plenty. If its a wizard driven app assembler, I'd prefer not to have one (tho there are Perl/Tk tools for GUIs). If its a debugger, then Perl is still coming up short.

• frameworks for web, CORBA, SOA - Given the significant numbers of web frameworks for Perl, I think we can dismiss that contention. CORBA ? Meh. (Is there still a CORBA ?) SOA ? Not much more than a variant of a web framework. Perhaps more importantly, the sorts of things that require frameworks in C++ or Java, are often too simple to implement in Perl to justify a complete framework. One significant hole in Perl is an XA transaction manager framework.

• Looking at that list, I fear the author may have been stuck in 1998, and needs a serious technology refresh timeout.