Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Salut!

On Mon, 15 Aug 2016 17:14:02 +0900
"Stephen J. Turnbull" <turnbull.stephen.fw@example.com> wrote:

> Josh Glover writes:
> 
>  > No huge codebase can be "quickly rewritten" in any language.
> 
> +1

Well.. I question the existance of large code bases in perl :-)

Is there really so much perl code out there that is in productive
use? And why does it look like there are more perl jobs in Japan
than anywhere else?
 
> 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).


My experience with PyPI and CPAN is that it's harder to find
good and well written stuff in PyPI while in CPAN you have one or
two choices and one of them is the good one. But then, i'm most
likely biased :-)

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

>From my biased sample: all of it :-)
Modern perl is very very very close to what perl was 15 years ago.
Most changes were in the sidelines where it didn't hurt people.
The only one exception that was a bit messy was utf-8 support
(it took two attempts to get it right).

What people consider "modern perl" these days is mostly a way
of writing perl, not a different syntax. Especially things like
Moose make life quite easy, if you need more than simple data
structures (I will not comment on the traditional perl5 OO system).
Even though it depends on some modern perl features, most (everything?)
of it could be written with perl 5.6 already. 

BTW: a good read on "modern perl" is the book "Higher-order Perl"
by Mark Jason Dominus. And even that is already 10 years old.

> 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 use NumPy and SciPy but I don't really like them. But that's probably
mostly because I need exact control over what's going on (think of
algorithm prototyping for stuff that goes eventually into hardware).
I often need to dig deep to figure out what actually is happening within
a function to see whether i can use it or need to write my own.
The documentation is usually quite superficial to the point where
I wonder why they do not just link to some wikipedia article, because
that's what i am going to read anyways after reading that one word
"description".

Why do I still use it? Because any other framework takes more time to use.

(Side note: I have started to use VHDL for some of the prototyping,
for it offers the ultimate control... with the little drawback that
everything needs to be written from scratch)

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

And this is, what I hate with python. The constant need to check
and rewrite scripts when updating python, because something might
have changed in the language, subtely breaking things. Python, like
any other language, is for me a tool to get work done. I don't want
to invest time into keeping scripts alive that i've written and that
otherwise work fine. 
 
>  > 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?

As perl5 didn't change much over the past 15 years, it's still a magnificent
language for text processing. Most of my day-to-day scripting needs are
fullfilled with a dozen lines of perl. Some are simple read-file-calculate-
stuff-and-output-number other are parse-this-and-make-a-completely-new-file
(I did an almost complete VHDL parser only using regexp about 10y ago, in order
to generate testbench skeletons from entity definitions). There are a few
things that I do differently today, like using Moose for anything that
needs OO and Marpa for parsing stuff, but generally speaking, my way of
writing perl didn't change much over time (yes, some of my newly written
scritps still look like butchered awk scripts).


			Attila Kinali
-- 
Malek's Law:
        Any simple idea will be worded in the most complicated way.


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links