I eschew the use of the 'E' word, due to the repeated and blatant
abuse of the term as marketing hype from empty suits, I'll assume the
original author intended the term to be interpretted as "mission critical,
scalable, networked, secure, fault-tolerant (or at least fault recoverable),
possibly web-based, possibly transactional".
Think "J2EE/WebSphere/WebLogic/et al".
I recently implemented/delivered a pure-Perl application
(framework, actually) that meets many of those
requirements. While it took some convincing, after I delivered the first
working prototype in a few days, the debate quieted some. Then a few days
later I delivered the updated prototype with some add'l features the customer tacked on,
and they consented to let me proceed with Perl (they had a pretty serious jones for
C++, but were smart enough to understand that the complexity and platform migration
requirements would probably doom such an effort).
So here's my experience:
- 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)
- 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.
- 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).
- 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.
So I'm convinced that Perl is capable of meeting the 'E'
class requirements I outlined above. But I do have some
reservations - and a few frustrations.
To summarize:
-
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.
One non-obvious issue may be the lack of a single "bible"
of writing 'E' class Perl. Many Perl tomes exist, but
they all tend to focus on a specific application set
or API, or on the language itself. I'm unaware of any book
or website that has attempted a complete and lucid
discussion of building 'E' class apps using Perl,
ala the shelfloads of J2EE books.
(IMHO, P5EE doesn't count,
its not much more than a laundry list).