Gentlemen, a call to arms!

[muppet]

On Oct 13, 2006, at 2:46 PM, Paul Makepeace wrote:

> On 10/13/06, jesse <jesse at fsck.com> wrote:
>>
>> The Railing against Rails is starting to get on my nerves.
>>
>> How about, instead, somebody tell us what cool stuff they're doing  
>> with
>> Perl?
>
> Part of the problem here is the "I'd tell you, but I'd have to kill
> you" issue. Perl has being going underground ever since it went
> mainstream.

I'll agree with that.  I spent about four years working on an in- 
house perl+C-based toolkit that is currently being deployed around  
the world... but in a low-key fashion.  The actual stuff being done  
with it now is by someone i trained, who is writing a white-paper  
about the application.  And, of course, i can't tell you what it is,  
because it's proprietary.

I will posit that a very large amount of perl is written by people  
who don't understand it well, and give it a very bad reputation.  I  
have spent a good amount of time fixing in-house perl code written by  
C programmers, getting order-of-magnitude speedups just by using a  
hash instead of repeated array lookups (8 minutes to ten seconds in  
one case), reducing overcomplicated logic, removing unreadable hacks,  
etc.  Cut and paste runs rampant.  And, despite perl having one of  
the best libraries in the world (CPAN), a disturbing majority of perl  
programmers appear to suffer greatly from poor wheel reinvention  
syndrome.  It's difficult to defend perl in a room full of python and  
ruby bigots when everyone knows how bad the local perl code is.

Oh, and these days i'm mostly using perl for code generation, log  
parsing, and other development tools.  Nothing webby or high-profile.


--
In some newer operating systems, time_t has been widened to 64 bits.  
In the negative direction, this goes back more than twenty times the  
age of the universe, and so suffices. In the positive direction,  
whether this range is sufficient to represent all possible times  
depends on the ultimate fate of the universe, but it can be expected  
to postpone overflow long enough for such implementation limits to be  
abolished.
   -- Wikipedia, on UNIX time.