[PREV - CASE_STUDY_1]    [TOP]

CASE_STUDY_2

I came across some interesting ammunition for
perl advocacy written by Steve Yegge, someone
who isn't a fan of perl (to say the least),
but got to watch Java and perl programmers in         CASE_STUDY_4
action at Amazon for a number of years.

"Is weak typing strong enough?":

   [ref]

Some quotations (with
many sentences ellided):

   "I watched the strong/weak battle play out (in various
   ways) in Amazon's Customer Service Applications group
   for years."

  "One thing I observed was that the folks who
  favored Perl always seemed to be able to get stuff
  done really, really fast, even compared to experienced
  Java folks. And they had their act together; it wasn't
  just crude hackery, as many Java programmers would
  like to believe. Their code was generally very well
  organized, and when it wasn't, they'd go in
  periodically and fix it. Sometimes they did quick,
  hacky scripts, and in fact the ability to do this
  proved to be mission-critical time and time again. But
  generally the Perl stuff worked just as well as the
  Java stuff. Whenever performance became an issue,
  they'd find clever ways to make it perform well
  enough."

  ...

   " So for years, we had Java and Perl development
   going on side by side. This was a decision made in
   old days, purely for expedience reasons. When we were
   deciding how to implement Arizona (our internal
   web-based application suite for CS), we had about a
   50/50 split between Perl and Java programmers on the
   team."

   "During the initial development, the Perl use-cases
   got finished astonishingly fast. For a while, Arizona
   had more Perl than Java, because our Perl programmers
   started grabbing tasks assigned to the Java
   folks. Over time, the "climate" across the company
   pushed us to migrate everything towards Java. It was
   a pretty complicated situation not worth recounting
   here, but over a period of years, most the Perl stuff
   in Arizona was gradually rewritten. (I hear after I
   left, the climate changed again, with Java being
   phased out in favor of C++ and Perl, but for reasons
   mostly unrelated to the languages themselves.)"

   "In any case, for several years I got to watch Perl
   and Java folks working side by side doing pretty
   much the same tasks. In some cases, they even had to
   implement the same logic in both languages. Yes,
   there were inefficiencies with our Perl-and-Java
   approach. However, it was the right decision at the
   time, and as a result, I was personally able to
   witness a more or less apples-to-apples, multi-year
   comparison of the strong-typing and weak-typing
   camps at work in the same production environment."

   "In nutshell, I was pretty impressed. I was
   a die-hard Java guy at the time, and even then, I
   could see that the Perl code was far smaller and
   simpler than the Java code. It didn't feel "cleaner",
   since Perl itself is a bit challenged in that
   department, but it seemed modular enough. It had a
   well-defined architecture, and it got the job done,
   year in and year out."

   "Our Java code (to me) seemed far more complex, even
   though I could read Java more easily. I think Java
   programmers have a tendency to overengineer things,
   myself included. I suppose many Java folks would
   have thought of our Perl code base as grossly
   under-engineered. But if it was really
   under-engineered, it seems like it should have
   caused more problems than it did. In practice, most
   of the problems in the Perl code were
   interoperability issues with external services (or
   databases, in cases where there were no services
   yet.)  Most service owners didn't include Perl
   bindings for their interfaces, so our Perl folks had
   to do a lot of head-scratching to find workarounds."


--------
[NEXT - CASE_STUDY_3]