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

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

Josh Glover writes:

 > No huge codebase can be "quickly rewritten" in any language.

+1

Regarding employment: Note that if someone *tries* to rewrite a large
COBOL or Perl codebase in (say) Python, there will be tiny semantic
differences in apparently equivalent syntax.  So they'll *still* need
a COBOL (Perl) guru to help isolate and iron those out.

 > I would further argue that Python is a worse choice than modern
 > Perl for large projects, given their equivalent expressive power
 > and Perl's much richer library ecosystem (CPAN).

💩 × 1000 = 💩

Note that despite my well-known bias[1], I do not assert CPAN = 💩.
Merely that the larger anything is, the higher the percentage of 💩.
PyPI's percentage is quite high, too (and X?Emacs's is asymptotically
equal to 1.0, much as I love Emacsen I hive to admit it).

BTW, how much of CPAN do you consider to be written in modern Perl?

As far as a "modulo 💩" definition of "rich" goes, I have never found
that there was no package on PyPI that did what I needed.  Speaking of
💩, of course I do occasionally find there is none that does what I
need *well*. :-)  I suppose that's true for CPAN (CTAN, CRAN, Gems,
...), too.

 > Python wins in scientific / numerical computing due to its
 > excellent libraries in that area.

Also in web frameworks, email, SNS APIs, and others.  (Once again,
despite the excellent and deserved reputation of NumPy and SciPy,
"win" is not *over* Perl -- I don't use it, I can't compare -- but
certainly Python is a winning option.)

 > I forget the exact numbers, but given the strong correlation
 > between lines of code and defects, I would argue that large
 > codebases should be avoided as much as possible.

Somewhat OT for the thread, but here I go:

This simply is not possible, though.  Complex problems (like "running
an Internet business" ;-) require large, complex code bases.  And much
higher than the correlation between size and defect *rates* (not much
actually, defect rates tend to remain basically the same as codebase
scales -- assuming resource budgets are adequate, of course, which
they usually aren't) is the correlation between quality of developer
and defect rate ("factor of ten differences in productivity *and*
quality").

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, and keep productivity and defect rate stats so you can mentor
(and if *absolutely* necessary, which it usually isn't, fire)
developers whose quality is very low and/or highly variable.  (No, you
can't just hire stars, there aren't enough of them, and they don't
always work and play well in teams, anyway.)

And, of course, if you have an existing codebase to maintain, hire
developers experienced in the implementation language(s).

 > One great way to keep codebases smaller is to use a more expressive
 > language, such as Clojure, Haskell, Racket, OCaml, etc.

Or all of them!  (Hi, Curt!)  But that hurts readability, too, not all
developers can be that multilingual, and sometimes you do need to read
code that others maintain.

<plug mode="unabashed">
Python has done a pretty good job of incrementally incorporating quite
a few syntaxes that are big wins (comprehensions, generators) over the
years, making it quite expressive.  Not quite so much as Ruby
(especially for DSLs where Ruby shines, if you like DSLs).  And IMO
the new asyncio keywords are the writing on the wall for Python 4 (ie,
another big backward compatibility break) because of their similarity
(syntax is isomorphic, really) to generators.  But that's going to
take a decade or more to really be painful, I hope.
</plug>

 > Anyway, Perl was a really big deal for early web development, and
 > for very good reasons at the time.

Yes.  I still remember working with Jeff Friedl during the Kobe
earthquake recovery, and how fast he could crank out reliable (for the
time) CGIs.

 > It is still fantastic for text manipulation and those shell scripts
 > that get too long for Bash but aren't worth making proper programs
 > out of.

How does that fit with "modern Perl"?  Or is it just a separate reason
for using Perl?


Footnotes: 
[1]  See also http://blog.aurynn.com/contempt-culture.