

Why I stick with Perl - jrockway
http://blog.jrock.us/articles/You%20are%20missing%20the%20point%20of%20Perl.pod

======
ajross
From the article:

 _But it irritates me when I need to get at gpg from a web application, and
can't just use a "libgpg". I have to fork a gpg process, setup file
descriptors just right, write input to a pipe, wait for input on another pipe,
and then parse the result_

It boggles the mind that a perl programmer, of all people, would think this.
The relevant code for the above is generally something like:

    
    
      my $data = `gpg --decrypt --passphrase=$PASSWD $FILE`;
    

or:

    
    
      open INPUT, "gpg --decrypt --passphrase=$PASSWD $FILE|";   
      while(<INPUT>) { ... }
    

The incredibly tight integration with external programs (e.g. the code to
"setup file descriptors just right" consists of one byte!) is _the very
essence_ of what makes perl great and special. I'm just dumbfounded here. He
likes perl but doesn't understand how to fork a process?

I mean, the whole premise of the point is counter to the perl philosophy,
which is that you're already on a great and useful platform and just need a
tool to tie things together nicely. If you want a single platform designed
around the idea that all meaningful tasks are available in a library without
leaving the sandbox, you are looking at Java or .NET, certainly not perl...

~~~
jrockway
Now $PASSWD is available to anyone running "ps". The GPG manual suggests that
you open a separator file descriptor for the passphrase.

Basically, it's easy to do things if you aren't aiming for security or
correctness, but in this case, I am.

~~~
ajross
Heh, cool, the trap worked:

$PASSWD was available to everyone on the box anyway. You stick it in memory,
it's readable. That's the way life works. You probably stuck it in a database
too, right? Did you lock down the socket from local users? Probably not. Did
you store the database password off-line? Probably not, because you wanted
unattended startup to work.

The bottom line is that if you want to do password storage in your web app
that is secure against local users, you have _vastly_ more work to do than
just finding a CPAN library somewhere.

~~~
cturner
> That's the way life works.

Just because security by obscurity is not a barrier you should lean on doesn't
mean that it lacks value in combination with other measures.

Script kiddies will struggle to isolate data from memory in order to get
passwords, particularly if they can't get binaries on the machine and it has
no compiler. On the other hand, they will have no trouble using a copy and
paste ps usage.

And when I say script kiddies, I also mean the sort of 9-5 culture, corner-
cutting production support teams that exist in some organisations and who
might have accounts on shared hardware that your application runs on. Do you
really want to make it easy for them to do favours for people on the business
side who want passwords they shouldn't have?

> The bottom line is that if you want to do password > storage in your web app
> that is secure against local > users, you have vastly more work to do than
> just finding > a CPAN library somewhere.

I strongly disagree.

~~~
nailer
> Just because security by obscurity is not a barrier you should lean on
> doesn't mean that it lacks value in combination with other measures.

Damn straight. Check out the DNS spoofing defences - using random ports to
issue requests on. There's a known limit to port numbers, and you could
probably circumvent it with massive amounts of traffic, but using an unknown
port number makes it hard enough that performing that kind of attack is
significantly more difficult.

------
scott_s
_If you are like me, most programming you do is about gluing things together
with libraries._

Then I am not like you.

~~~
KevinMS
And not nearly as productive.

~~~
scott_s
I'm a high performance systems researcher, not a professional developer. If I
could write my code by just combining existing libraries, then it wouldn't be
research.

~~~
mynameishere
Did you even _look_ for the DO_RESEARCH library?

~~~
cbetz
I highly recommend Phd::Simple

------
mechanical_fish
Every article like this should come equipped with a disclaimer link to
Spolsky's Lord Palmerston essay:

<http://www.joelonsoftware.com/articles/LordPalmerston.html>

Because, though this is a relatively sober and even-handed example of the
genre, it still inevitably contains howlers like this:

 _Search for "rails". Most of these programmers will depend on one library,
Rails, but then get the rest of their code by cutting-and-pasting from blogs._

Someone has never heard of gems:

<http://en.wikipedia.org/wiki/RubyGems>

Which is hardly surprising. This is the canonical problem with articles like
this one: The guy doesn't waste time tinkering with Ruby, because he's busy
being productive with Perl, so why should he be expected to know anything
about how the Ruby community works?

(This is why I try not to write about Python except to assert that it must be
one of the best languages in the world: I'm literally unsure how to write
_hello, world_ in Python, but smart people use it all over the place, so
deference and politeness forces me to assume that it's _utterly perfect_ until
proven otherwise.)

Anyway, I'll help out by saying that I think jrockaway's point still stands,
albeit on fewer legs than before: Perl is a considerably older language, its
community is more experienced, it's (among other things) a traditional tool of
system administrators -- who are, in my experience, relentlessly pragmatic
people who crave stability, reliability, and clear docs -- and so it has had a
lot more time and incentive to organize and standardize its packaging and
documentation systems. Ruby _does_ have docs difficulties, as do many open-
source projects which have recently experienced explosive growth.

~~~
jrockway
_Someone has never heard of gems:_

I've heard of gems. They are more like tarballs than CPAN modules. For one
thing, there is no canonical place for All Things RubyGem.

~~~
bkudria
I know - isn't it nice?

~~~
SwellJoe
Is it?

------
msluyter
Meta-comment: I find it interesting that perl related posts tend to generate
so many comments. I attribute this to the fact that:

a.) A lot of people really like perl and b.) A lot of people really hate perl.

~~~
SwellJoe
And:

c.) A lot of people really like hating Perl.

I think it goes beyond basic dislike of the language...that would require
knowledge of the language, which is pretty clearly lacking in many of the
flames. I suspect it's often human tribal tendencies. Rubyists and Pythonistas
see another tribe competing in the very same environment with very similar
capabilities (because, let's face it, mild syntactic differences aside Perl,
Python and Ruby are more alike than they are different when compared to almost
any other language), and they also see an opportunity to combine to beat up on
a currently larger and older tribe.

By the time you've spent enough time with a language to get past identifying
with just that one tribe, you don't feel as aggressive an urge to pontificate
on the suckage of other languages.

~~~
nailer
d) A lot of people who like Perl like to troll people who dislike Perl, by
telling them they "don't know Perl".

~~~
SwellJoe
I think maybe you're categorizing me in group "d". ;-)

I've never said there aren't valid criticisms of Perl...just agreeing with
msluyter's very astute meta-comment, and adding one more option. I believe
that people exist in both groups "b" and "c"...I wasn't overloading method "b"
to actually mean something else. Some people in "b" probably even have valid
reasons for hating Perl...but, I think we can all agree that the majority of
flames in any language thread come from a place of ignorance about the
language. After all, if you really don't like a language, odds are good you
don't do much work in it, and so don't actually know a lot about it.

But, if you think we need one more option, I won't argue. There probably are
people in category "d" (in addition to me, it seems), as well.

------
omouse
_But why did Common Lisp need to build in at least 3 separate ways to map keys
to values (getf, assoc, and hash tables)? The answer is because the language
designers wanted all three._

Actually, the answer is that those three do different things. GETF is for
property lists which look like '(key1 value1 key2 value2), ASSOC is for
association lists which look like '((key1 . value1) (key2 . value2)), and
GETHASH is for a hashtable which looks like a vector/array and not a list.

GETF returns the value of the first key that matches. GETHASH will return the
value of the hashed key that matches. ASSOC allows you to return any value for
whatever key you're getting or whatever test you're using.

So each one has a different purpose. The trade-off is how _you_ choose to map
keys to values. It may be faster to use a hash-table instead of an assoc-list,
or it may be easier to interact with an assoc-list rather than a property
list. The point is that there's a choice and a reason why the choice is
available.

This reminds me of all the newbie Java programmers who use the ArrayList class
instead of looking for just the right data structure for what they want to do.

~~~
jrockway
My complaint was having all of these in the core language. If I want to use
property lists, why can't I just load the "plist" library? If I want
association lists, why can't I just load the "alist" library? And so on... the
core programming language is not the place to dump every algorithm ever
created.

------
hassy
So Perl is like Java then: the language sucks but the platform is great?

~~~
jrockway
Perl is the syntax, CPAN is the language. So no.

~~~
tptacek
Isn't that a bit like saying "C is the syntax, and all of computing is the
language"?

~~~
jrockway
Yes, in the sense that the pattern of the sentence is "$foo is the syntax,
$bar is the language." Semantically, however, no.

------
tptacek
"As an example, the software that runs this blog (Angerwhale) uses 212
different Perl modules."

Blog software needing 212 different Perl modules: _Not a strong argument for
Perl._

~~~
mst
Once there was an idea in perl-land, that we should take 150 or so different
little modules, package them together and make a Big Monolithic Release with
Lots Of Stuff in it.

They thought they'd call it Perl on Poles.

Then we realised that big monolithic releases were a good idea in the same way
as vista was a good idea, and went back to depending on the exact things we
needed for our app, conveniently cut up so we could depend on lots of little
libraries rather than one giant one that contained lots of stuff we never
used.

I'm sorry you find a culture of software reuse an argument against a language.
Here, let me sell you this dot net - fifty pee and a windows license.

~~~
nailer
Your post is a troll.

He's not complaining about using modules. He's complaining about using one
hundred and fifty modules, and you're attacking him on an argument he's not
making.

Your last statement is especially childish. See 'be civil' at
<http://ycombinator.com/newsguidelines.html>

~~~
mst
Bugger. I was aiming for sarcastic hyperbole rather than trolling. Sorry.

I'm trying to attack the idea that using lots of small modules is worse than
having a few big dependencies - CPAN dependency chains often -look- big
because we try to break things down into the smallest unit of viable reuse.
It's a bit more work but it's part of what makes CPAN so effective a toolkit.

If you want, re-read my post and try and mentally apply a deadpan english
voice with more than a hint of sarcasm and see if that makes up for my poor
phrasing.

------
stcredzero
Programming languages are just as much _social/cultural_ constructs as spoken
ones. The language's technical merits are just one factor. Sometimes, a bigger
factor is the community which uses that language.

Choice of language makes a difference in productivity to your team, but in
many cases, this will be swamped by other factors, like how experienced and
knowledgeable they are and how well they work together.

Then again, there are highly specialized domains where a language will make
you 100X more productive than another.

------
agranig
From a pragmatic point of view, if you need to "reinvent" stuff for some
reasons, e.g to implement them in C or whatever, prototype it in perl as
generic as possible and just translate it to C or your language of choice...
look how they did it in perl (there's next to nothing they didn't implement by
now), then implement the algorithm in "your" language. It saves you really
lots of time.

------
matstc
> The end result is that the syntax and implementation compromises of your
> language don't really matter much.

Hm. To me that's pretty much all that matters. I want powerful features and a
nice syntax.

> Python doesn't have lexical closures like Perl's

What does that mean? Doesn't Python have lexical closures?

~~~
khill
Python has closures but has issues when changing variables within them. This
leads most people to agree that Python's implementation of closures is
insufficient.

See the following link for an example and more details:

[http://mail.python.org/pipermail/python-
list/2004-July/27095...](http://mail.python.org/pipermail/python-
list/2004-July/270951.html)

Instead of list boxing, you can also use a function attribute to handle
changing the variable in the correct scope.

------
richcollins
It is this attitude that leaves us stuck with things like Unix and Windows.

The reluctance to break free from legacy technologies allows them to build
more and more momentum. Unfortunately, this momentum delays innovation.

~~~
matstc
I think I agree with you: as benevolent programmers, we should pick the best
tool for the job, without consideration for the platform, or the libraries.
This would advance the art of software faster in the long run. Unfortunately,
we are forced to make decisions based on the ecosystem of our tools, because
of short-term constraints.

