Re: [tlug] perl? (was: Employment for "oldies")

["Stephen J. Turnbull" <turnbull.stephen.fw@example.com>]

Josh Glover writes:

 > I would imagine quite little, though CPAN's great strength is that the
 > modules tend to be fairly battle-tested. It's usually a good sign when
 > a popular library hasn't changed in 10 years. :)

Or maybe everybody is afraid to touch it. :)  I'll grant you that CPAN
modules seem to have more of the "do one thing and do it well" flavor
than Python packages do.  So it doesn't surprise me that there are
popular, robust libraries that haven't changed in 10 years on CPAN,
but few on PyPI.

 > I'm not sure that Python's web frameworks are really any better than
 > Perl's.

As I say, no experience with the latter, but I too doubt that there
would be a difference in usability, features, or performance.

But what Perl web frameworks?  For Ruby of course I know about Rails
and in PHP Drupal, but I don't think I've heard of Perl frameworks to
compete in the same space as Rails or Drupal or Django or Plone.  I'm
sure there is a slew of "do one thing" modules (say at the level of
"URL dispatch" and "HTML templating language") that can be assembled
into a nice web service, and I know there are several nice wikis (but
there is probably a nice wiki written in brainf!ck, people just like
to write wikis!).  But are there integrated frameworks with their own
"theory of the web", like Django's "not really MVC" model, and content
management services, like Drupal and Plone, and frameworks like Rails
(which kinda stands alone in its application space)?

 > I think in the Python vs. Perl discussion, use the one you're most
 > familiar with. I certainly wouldn't rewrite any Perl code in
 > Python, as I don't think there's any difference in the
 > expressiveness of the two.

Actually, all the Perl code I've ever had to maintain I had to rewrite
in Python to understand it.[1] :-)

 > Yes and no. A service-oriented architecture can keep individual
 > codebases from bloating too much. Of course, the problem then
 > becomes integration and operating the many services.

Exactly.  If you keep the complexity out of the fabric, it will creep
back in at the seams.  I did mention "modular design" of which SOA is
a powerful example, which helps a lot, but doesn't completely eliminate
complexity.

 > > My take is what you really want to do is keep developer count down as
 > > much as possible, use modular designs so no developer is out of her
 > > depth,
 > 
 > Yes.
 > 
 > > and keep productivity [stats]
 > 
 > No.
 > 
 > > and [keep] defect rate stats
 > 
 > Yes. ;)

You can't say no to productivity stats and yes to defect *rate* stats.

 > Productivity stats are really difficult, as whatever metric you use
 > ends up getting gamed, whether consciously or unconsciously.

There's only one metric that can't be gamed, and that's profit.[2]

The trick is to use the statistics in an incentive-compatible way.  If
gaming productivity gets way out of hand, you disconnect the
productivity data completely from compensation, and in the extreme
from MIS reports, using it only as input to less poorly tuned
statistics (eg, defect rate).

However, I don't see how you can do scheduling (except in the "when
the fork comes out dry it's done" sense), or personnel tasking,
without productivity information, at least crude information.

 > I would argue that in the modern world, developers who can't be that
 > multilingual are not the ones you want to be hiring.

I would argue that in modern baseball, players who can't pitch like
Maeda *and* hit like Ichiro are not the ones you want to be
drafting. ;-)  I dunno, maybe there are that many multilingual
programmers around, but at Pycon (sample of 3500) I mostly see them
on the podium, not meet them in the seats.  Most people I know *have*
programmed in several languages, but each one takes a spin up time of
months to years before they're fluent both reading and writing it.

And there's always the problem that "writing Perl as if it were
Python" (or vice versa) is very likely to result in poor style and
nonperformant code.  I think it's generally pretty hard to learn to
write idiomatic code in several languages, just as it's hard to learn
to speak several natural languages idiomatically.

Footnotes: 
[1]  This is the "executable pseudo-code" feature -- after writing a
couple of pages of pseudo-code, I realized that what I was writing was
so close to valid Python there was no point in writing invalid Python.
And so was born a port.

[2]  I mean at the organizational level we're talking about.  Of
course whole companies like Enron and LiveDoor gamed profit, but they
could do that because they could rewrite the accounting system.  I
don't think you can do that. :-)