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

[Josh Glover <jmglov@example.com>]

On 15 August 2016 at 10:14, Stephen J. Turnbull
<turnbull.stephen.fw@example.com> wrote:

> Josh Glover writes:
>
>  > 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 = 💩

True.

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

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

> Also in web frameworks, email, SNS APIs, and others.

I'm not sure that Python's web frameworks are really any better than
Perl's. 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.

>  I would argue that large codebases should be avoided as much as possible.
>
> This simply is not possible, though.  Complex problems (like "running
> an Internet business" ;-) require large, complex code bases.

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.

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

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

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

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

>  > 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?

Just a separate use case where Perl is still a very good option.

Cheers,
Josh