Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
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:

  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.

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

In reply to Re: Perl in the Enterprise by renodino
in thread Perl in the Enterprise by Scott7477

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (5)
As of 2024-03-29 09:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found