Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is Perl dying or not?

175 views
Skip to first unread message

Ignoramus7380

unread,
Oct 19, 2012, 10:43:53 PM10/19/12
to
Let me first state that I a perl user, since 1996, I have been always
very happy with perl. I have written 1,430 perl scripts and modules. I
am self employed and make most of my income from websites that I wrote
using mod_perl.

So this is not some kind of "perl suxxx" troll. Rather, I want to ask
if perl will continue to be a viable ecosystem. I have a lot invested
in and relying on perl and I have a vested interest in having perl to
be a great platform.

Lately, I have been seeing a lot of evidence that adoption and use
of perl declines in favor of superficially "easier" languages. The
number of developers, commits, activity etc seems to be dropping. Even
this newsgroup seems to be declining faster than Usenet in general.

My question is, should I be concerned by this trend or not?
Ultimately, I do not care super that much that perl is number one
scripting language, only that it continues to be a great platform.

Thanks

i
Message has been deleted

Ignoramus15392

unread,
Oct 20, 2012, 9:45:03 AM10/20/12
to
On 2012-10-20, Michael Vilain <vil...@NOspamcop.net> wrote:
> In article <dNydnY1caOF0kh_N...@giganews.com>,
> What are you trying to accomplish by posting here? Do you have a
> perl-specific problem you're trying to solve (other than venting your
> job insecurities)? I've been doing technology since the early 1980s.
> I've been through PDP-11s, VAXes, SUNOS, and Solaris. Perl runs on all
> these platforms as well as my MacOS X system.
>
> You write Perl for a living. When that ceases to be a viable living,
> you'll do something else. What's the problem?
>

The problem is that I already have a bunch of perl stuff and I want to
make sure that it will continue to run years ahead. I also want all
latest and greatest stuff like imagemagick to continue being supported
in perl.

i

Randal L. Schwartz

unread,
Oct 20, 2012, 11:38:02 AM10/20/12
to
>>>>> "Ignoramus15392" == Ignoramus15392 <ignoram...@NOSPAM.15392.invalid> writes:

Ignoramus15392> The problem is that I already have a bunch of perl stuff
Ignoramus15392> and I want to make sure that it will continue to run
Ignoramus15392> years ahead. I also want all latest and greatest stuff
Ignoramus15392> like imagemagick to continue being supported in perl.

There are more people coding Perl today than there were 15 years ago
during the dotcom boom "when Perl Ruled the Web".

There is more activity on the CPAN today than there has ever been.

There is more activity on Perl releases today than ever (new minor
releases every three months!).

Perl 6 is slowly maturing, bringing in a whole new audience.

Perl is alive and well. More people are using it, every day. In fact,
I know employers that cannot *hire* enough Perl programmers for both
legacy and new projects. So it's a seller's market if you know Perl.

print "Just another Perl hacker,"; # the original

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Message has been deleted
Message has been deleted

Ignoramus15392

unread,
Oct 21, 2012, 3:50:46 AM10/21/12
to
On 2012-10-20, Michael Vilain <vil...@NOspamcop.net> wrote:
> In article <RPednTwKwvBCNx_N...@giganews.com>,
> The longer you work the more you'll realize that this sort of thing is a
> pipe dream. Eventually the finely wrought system you spent years
> writing will be decommissioned when the site or company that's using it
> move to another platform. Or the legacy system is mothballed.

Well, it is my site and my company.

i ALREADY HAD THIS SORT OF EXPERIENCE When the Safe module was
decommissioned.

> Death and taxes are the only things that are permanent. And they both
> forms of entropy. And even entropy isn't what it used to be.
>
> Unless you control all aspects of a system, you don't really control
> it's growth or change. Learn to dance on shifting sands. Take up
> basket weaving or Tibetan sand mandalas.
>
> And write the best, most open-architecture code you can. Until someone
> changes something out from under you and you have to do it again. And
> again. Be glad you're not pushing a rock up a hill every day.
>

yep

Rainer Weikusat

unread,
Oct 21, 2012, 11:02:49 AM10/21/12
to
mer...@stonehenge.com (Randal L. Schwartz) writes:

[...]

> Perl 6 is slowly maturing, bringing in a whole new audience.

For the kind of problems I need to handle, Perl 6 (or actually any
other bytecode-based language designed by 'witz kidz' from
academistan) is DOA: If it can't do deterministic automatic memory
management and possibly, can't actually manage any resources
automatically except memory and possibly, can't even do that (as I've
learnt by painful experience, 'resource leak' is the middle name of
the JVM which leaks just about everything that can be leaked, memory
explicitly included) -- and I'm not going to put a large amount of
effort into code written for language XYZ only to discover that the
planks I needed to build on sink as soon as you leave familiar
waters (and, as usual for 'open source projects' with the errors being
ignored side effects of intentional design descision nobody who
doesn't want to mainain the thing all by itseld can fix) -- I can as
well code in C instead.

'Mark and sweep' garbage collections marks everything which contains
it as "This is a toy for people who enjoy playing around with their
'great ideas' but shrink back from anything resembling actual work
because it bores them. Use at your own risk". Coinicidentally, I
write code which solves completely boring problems but it has do so
reliably: The computer is an infrastructure device and ideally, nobody
would ever notice that it is even there because the only way to do so
is when it fails to work.



Shmuel Metz

unread,
Oct 22, 2012, 9:10:18 AM10/22/12
to
In <87a9vfz...@sapphire.mobileactivedefense.com>, on 10/21/2012
at 04:02 PM, Rainer Weikusat <rwei...@mssgmbh.com> said:

>For the kind of problems I need to handle, Perl 6 (or actually any
>other bytecode-based language designed by 'witz kidz' from
>academistan) is DOA: If it can't do deterministic automatic memory
>management and possibly, can't actually manage any resources
>automatically except memory and possibly, can't even do that

Nonsense; the memory management policies in a language don't depend on
whether you compile into machine code or into a byte code that
requires an interpreter; they depend on the defined semantics. A C
compiler that generates correct machine code will have the same warts
as a correct byte-code compiler for C, although there are certainly
efficiency considerations.

>JVM

That's not the only byte code.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

Kevin Walzer

unread,
Oct 22, 2012, 11:08:53 AM10/22/12
to
On 10/19/12 10:43 PM, Ignoramus7380 wrote:
> Lately, I have been seeing a lot of evidence that adoption and use
> of perl declines in favor of superficially "easier" languages. The
> number of developers, commits, activity etc seems to be dropping. Even
> this newsgroup seems to be declining faster than Usenet in general.

I can't speak to the relative decline of this newsgroup, but I can say
that I'm learning Perl precisely because it seems to be actively
maintained, developed, and supported. I say this as one who has done
programming in several different languages (Tcl, Python, C/Objective-C,
AppleScript, a bit of JavaScript). Perl may no longer the TEH SEXY the
way Ruby is, but I was very disappointed in Ruby's options for building
and deploying desktop apps (non-existent on the Mac); by contrast, just
a little bit of dabbling with a simple Perl::Tkx script, pp, and PAR,
and I had a fully standalone desktop executable ready for deployment.

I'm still getting my head around lots of aspects of Perl, but the
deployment question was answered with a resounding yes--I'm sold.

--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Ignoramus21608

unread,
Oct 22, 2012, 9:58:11 PM10/22/12
to
On 2012-10-20, Randal L. Schwartz <mer...@stonehenge.com> wrote:
>>>>>> "Ignoramus15392" == Ignoramus15392 <ignoram...@NOSPAM.15392.invalid> writes:
>
> Ignoramus15392> The problem is that I already have a bunch of perl stuff
> Ignoramus15392> and I want to make sure that it will continue to run
> Ignoramus15392> years ahead. I also want all latest and greatest stuff
> Ignoramus15392> like imagemagick to continue being supported in perl.
>
> There are more people coding Perl today than there were 15 years ago
> during the dotcom boom "when Perl Ruled the Web".
>
> There is more activity on the CPAN today than there has ever been.
>
> There is more activity on Perl releases today than ever (new minor
> releases every three months!).
>
> Perl 6 is slowly maturing, bringing in a whole new audience.
>
> Perl is alive and well. More people are using it, every day. In fact,
> I know employers that cannot *hire* enough Perl programmers for both
> legacy and new projects. So it's a seller's market if you know Perl.
>
> print "Just another Perl hacker,"; # the original
>

Randal, this is a great answer, I have calmed down a little.

The "other scripting languages" look like a joke to me, from the
perspective of a long time perl user.

i

Andrew Gideon

unread,
Oct 23, 2012, 7:39:02 PM10/23/12
to
On Fri, 19 Oct 2012 21:43:53 -0500, Ignoramus7380 wrote:

> Lately, I have been seeing a lot of evidence that adoption and use of
> perl declines in favor of superficially "easier" languages.

I had to spend time again today dealing with code written in one of those
"easier" languages. It was a completely hardcoded piece of crap, and the
client was unhappy that the code was no longer working following some
content - read: data - changes.

Of course, the client hired the original programmers. In theory, they
brought this upon themselves. But it's tough for non-technical people to
properly evaluate the quality of technical people. Even the quality of
the work is tough to evaluate immediately, as a lot of "quality" involved
in software is related to its ability to evolve over time.

But sometimes I think we've made programming too easy - or at least too
easy in environments not sufficiently restrictive. Clients are getting
burned by ignorant coding, and this tends to make people trust our
profession even less.

- Andrew

Rainer Weikusat

unread,
Oct 25, 2012, 12:30:31 PM10/25/12
to
Andrew Gideon <c182d...@gideon.org> writes:
> On Fri, 19 Oct 2012 21:43:53 -0500, Ignoramus7380 wrote:
>
>> Lately, I have been seeing a lot of evidence that adoption and use of
>> perl declines in favor of superficially "easier" languages.
>
> I had to spend time again today dealing with code written in one of those
> "easier" languages. It was a completely hardcoded piece of crap, and the
> client was unhappy that the code was no longer working following some
> content - read: data - changes.

[...]

> But sometimes I think we've made programming too easy - or at least too
> easy in environments not sufficiently restrictive.

I think this is wrong. 'Making programming easy' usually (and very
incorrectly) refers to reducing the amount of code which needs to be
written in order to deal with issues arising because of 'the solution
domain', the classic example would be memory management. But what
makes programming hard is not that this awful computer contains so
much stuff which doesn't exist anywhere outside of it (such as memory
which needs to be managed) but to come up with an algorithm capable
of solving a particular problem. Getting the problem-domain specific
stuff wrong will usually not prevent a program from functioning
because of technical reasons. Consequently, when manual memory
management is required, careless or clueless programmers will learn
that well enough to keep their programs from 'crashing' (or showing
any other obvious signs of a malfunction) but they will still produce
incorrect results.

ccc31807

unread,
Nov 9, 2012, 5:58:30 PM11/9/12
to
On Saturday, October 20, 2012 11:43:41 AM UTC-4, Randal L. Schwartz wrote:
> Perl is alive and well. More people are using it, every day. In fact,
> I know employers that cannot *hire* enough Perl programmers for both
> legacy and new projects. So it's a seller's market if you know Perl.

I meet people from time to time who work or have worked in technology, and after a while we get around to talking about Perl. I'm always surprised (even though I shouldn't be by now) when they say that they use(d) Perl. It really is surprising how often that turns up.

By the same token, most languages are 'dying'. For example, over the past several years, I have become heavily invested in Common Lisp. This is a very powerful and mature language, yet has the reputation of a dead language like Latin, something with a wonderful past but no present or future. Still, Common Lisp has domains where it can't be beat and still has features that other languages haven't even thought of. According to popular wisdom, Lisp is dead, but the popular wisdom is just wrong.

Randal, I keep my finger on the pulse of the job market, and all I see are jobs in .NET, Java jobs, and a goodly number of Python and PHP jobs. Perl jobs seem to be mostly six month contracts. I trust that you know what you're talking about, but I don't see it, probably because I don't have your connections. If one were to look for Perl jobs, where do you suggest that one start?

Thanks, CC.

Charlton Wilbur

unread,
Nov 12, 2012, 7:46:22 PM11/12/12
to
>>>>> "cc" == ccc31807 <cart...@gmail.com> writes:

cc> Randal, I keep my finger on the pulse of the job market, and all
cc> I see are jobs in .NET, Java jobs, and a goodly number of Python
cc> and PHP jobs. Perl jobs seem to be mostly six month contracts. I
cc> trust that you know what you're talking about, but I don't see
cc> it, probably because I don't have your connections. If one were
cc> to look for Perl jobs, where do you suggest that one start?

YAPC::NA. I thought Asheville in 2011 was insane with the number of
people hiring. And then in Madison in 2012, I realized it could be MORE
insane.

(To be honest, one of the reasons that in my perception Perl is thriving
but it's still damn hard to find a Perl job is that Perl, and especially
CPAN,are extremely powerful levers that can even be applied to
themselves. If there's a common problem pattern in Java, often the best
that can be hoped for is some scaffolding and template code to be added
to Eclipse, and as there's no CPAN-equivalent, most developers who run
into that problem wind up solving it again. With Perl, it's very likely
that such a problem will be solved a couple times badly by people
feeling their way around it, and then someone smart solves it well and
shares the solution - either internally to his or her colleagues at that
company, or on CPAN for the entire world to benefit.)

Charlton



--
Charlton Wilbur
cwi...@chromatico.net

dome...@gmail.com

unread,
Apr 23, 2013, 9:39:34 AM4/23/13
to
On Friday, October 19, 2012 10:43:53 PM UTC-4, Ignoramus7380 wrote:

<SNIP>

>
>
> So this is not some kind of "perl suxxx" troll. Rather, I want to ask
>
> if perl will continue to be a viable ecosystem. I have a lot invested
>
> in and relying on perl and I have a vested interest in having perl to
>
> be a great platform.
>

<SNIP>

IMHO, perl is proof that there is such a thing as a language that is too flexible. There are a LOT of free perl scripts on the Internet that are pretty terribly written, and so at first glance, some people get an impression of perl that it is kindof kludgy. The truth is that it has been adopted by people with so many different programming backgrounds, that perl tends to have dialects within itself.

Many got tired of trying to bend their minds around this and ran to python for structure. Many never automated their way around perls particularly verbose object oriented syntax, and ran to Ruby.

In practice, perl is very good for writing tools that make writing perl clean and fast. But you have to get past the fact that you _should_ write perl like perl, and NOT like BASIC, C, Java, etc. etc. etc. even though that is what brought you to perl in the first place.

The hardest thing about perl, is learning what good perl design is, because it is so easy to misbehave and get away with it.

My 2 cents.

Justin C

unread,
Apr 23, 2013, 10:04:03 AM4/23/13
to
On 2013-04-23, dome...@gmail.com <dome...@gmail.com> wrote:

[snip]
>
> My 2 cents.

This thread has passed on, it is no more, it has ceased to be.
It has expired and gone to meet its maker. It is bereft of life,
it rests in peace. It has kicked the bucket and shuffled off
its mortal coil. If you hadn't ressurected it it would be off
with the choir invisible. This is an ex-thread. It died sometime
last year.


Justin.

--
Justin C, by the sea.

Rainer Weikusat

unread,
Apr 23, 2013, 2:46:45 PM4/23/13
to
dome...@gmail.com writes:
> On Friday, October 19, 2012 10:43:53 PM UTC-4, Ignoramus7380 wrote:

[...]

>> So this is not some kind of "perl suxxx" troll. Rather, I want to ask
>> if perl will continue to be a viable ecosystem. I have a lot invested
>> in and relying on perl and I have a vested interest in having perl to
>> be a great platform.

[...]

> IMHO, perl is proof that there is such a thing as a language that is
> too flexible. There are a LOT of free perl scripts on the Internet
> that are pretty terribly written, and so at first glance, some
> people get an impression of perl that it is kindof kludgy. The truth
> is that it has been adopted by people with so many different
> programming backgrounds, that perl tends to have dialects within
> itself.

A splendid non-sequitur: There is a real lot of 'terribly written'
code in any programming language 'on the internet': What precisely
constitutes 'terribly written' is very much a matter of opinion (and
'opinion' doesn't necessarily mean 'reasoned opinion' here) and there
are a lot more bad programmers than good programmers, as with anything
else (=> Sturgeon's relevation). Even if there was more 'terribly
written free Perl code' on the internet, that would - at best - be a
hint (not a proof) that Perl is a lot easier to use than less
frequently abused languages. Also, all programming languages have
'dialects within themselves', just like all other languages.

> Many got tired of trying to bend their minds around this and ran to
> python for structure.

What's this supposed to mean?

> Many never automated their way around perls
> particularly verbose object oriented syntax, and ran to Ruby.

Or this?

I've been using Perl extensively since about 1995 without encountering
any 'particularly verbose object oriented syntax' which had warranted
'automating around it'. In fact, I've been using objects based on
anonymous arrays and manual slot allocation until fairly recently and
the only reason why I wrote (and published) some code to automate that
was to demonstrate how little is actually needed to turn the existing
'Perl OO' facilities into a complete OO-system, in contrast to
'everything anybody else ever came up with plus two kitchen sinks to be
on the safe side' approaches a la "Der Elch ist los!".

> In practice, perl is very good for writing tools that make writing
> perl clean and fast.

What does this mean?

> But you have to get past the fact that you _should_ write perl like
> perl, and NOT like BASIC, C, Java, etc. etc. etc. even though that
> is what brought you to perl in the first place.

Anything perl can compile and which has the intended effect upon
execution is 'Perl written like perl': Like any language, it can
accomodate different styles of writing: The mere fact that a text
someone else wrote reminds you of a different text written in another
lanuage is not an indicator of any particular quality. And people can
have different reasoned opinions on 'style issues': Eg, to me, a
'regex' is something delimited by forward-slashes and the occasional
forward slash inside a regex needs to be quoted. That's the way all
other tools I regularly use offering such features work and -
conveniently for me - Perl (can) work(s) in the same way.

Other people are convinced that 'avoiding the occasional quoted
delimiter' is sufficiently important that each regex should utilize a
(set of) delimiter character(s) which has been individually chosen to
avoid the need to quote anything. To me, this just looks needlessly
noisy ("What's the delimiter this time ???") and since it won't teach
awk, ed and sed new tricks, anyway, why bother with that?

> The hardest thing about perl, is learning what good perl design is,
> because it is so easy to misbehave and get away with it.

You seem to be fixated on syntactical issues to a degree I really
don't understand ...

George Mpouras

unread,
Apr 26, 2013, 3:03:49 PM4/26/13
to
is this a joke or something ?

johannes falcone

unread,
May 6, 2013, 3:12:04 PM5/6/13
to
well I see dancer, catalyst, mojolicious, memcached, mogilesFS, perlbal, plack, starman, continuity, perl 5.16.3 and s megashitload of stuff on metacpan so I think perl is far from dead

"just like java, but on time and under budget"

lolz
0 new messages