Why I stick with Perl

http://blog.jrock.us/articles/You%20are%20missing%20the%20point%20of%20Perl.pod

by jrockway • 18 years ago

56 99 18 years ago

blog.jrock.us

scott_s3• 18 years ago

If you are like me, most programming you do is about gluing things together with libraries.

Then I am not like you.

KevinMS• 18 years ago

And not nearly as productive.

scott_s3• 18 years ago

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.

Hexstream5• 18 years ago

Not necessarily. What I don't like about the "programming is about gluing libraries together" approach is that you have to deal with a plethora of hidden costs:

1. Finding the available libraries for the job. There might not even be one if you're doing something somewhat novel. Or there could be a huge number of them, most of them crap.

2. Evaluating the libraries found in step 1. You might find that no library is a superset of the others, that for example there's 3 of them that each tackles 1/3 of the problem in exactly the way you want but you have to compromise and choose only one of them.

3. Dealing with the library's bugs, limitations, misfeatures, incompatibility with your usual programming style. To fix those problems you either have to dig deep into a codebase that's not even your own (if you even can), or you take the passive approach and contact the vendor to ask them to please fix the bug or implement the feature and then wait 2 weeks or 2 months or 2 years or foverer until it gets done.

Whereas with the "I have a strong NIH syndrome and will do everything myself" I have lots of up-front costs but at least I know pretty much exactly what they are and the problems that come up are fun things like: "oh, I need to master this super powerful technique", not boring ones like: "oh, I need to get in touch with the maintainer of this library to implement a new feature I need if he so chooses".

ajross6• 18 years ago

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

jrockway11• 18 years ago

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.

ajross6• 18 years ago

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.

nailer9• 18 years ago

> It boggles the mind that a perl programmer, of all people, would think this.

I moderated you up assuming you were about to provide a better way to perform the task then nastily calling an external command to do it.

I should have read your post fully first.

edu• 18 years ago

The idea is that in perl is very usual and common place to call externals programs, the thing is that you don't need to setup the filedescriptors manually as jrockway says he does in the article.

matstc2• 18 years ago

> 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• 18 years ago

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

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

sapphirecat• 18 years ago

Python's closures are basically read-only in the 2.x series. 3.0 will offer read-write access via the nonlocal keyword: http://www.python.org/dev/peps/pep-3104/

It still won't be exactly the same, because Perl uses `my $foo` once to declare its lexicals; Python will require `nonlocal foo` declarations in all scopes that will use `foo`. The final result is the same, though: using variables from outer scopes.

stcredzero• 18 years ago

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.

mechanical_fish• 18 years ago

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.

jrockway11• 18 years ago

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• 18 years ago

I know - isn't it nice?

ezmobius2• 18 years ago

umm rubyforge.org?

mst9• 18 years ago

"Someone has never heard of gems:"

No. He has. So have I. He's commenting on the reality of a culture dominated by fanboyism and a framework advertised on the basis of being "full stack" which to naive eyes can seem to be "everything you need".

rubygems -enables- granular reuse of libraries, and many ruby people take great advantage of it.

But as a whole the perl community has got a hell of a lot more practice than the rails community at it - and of course rails has inherited the same fanboyish muppets that used to give perl a bad name (line noise? no, that's a phase you go through and grow out of if you're any good, takes about 3 months or however long it takes you to need to maintain your own line noise :), went on to give PHP a bad name, and in a few years will probably have given rails a bad name (possibly they are doing already? I dunno, being a perl head I tend to ignore that sort of groupthink idiocy, my language was unfashionable when I first learned it :)

swombat2• 18 years ago

I know numerous people who have started using Rails only recently and use plenty of gems and plugins (and even write/distribute their own in some cases).

There are muppets everywhere, but I don't think they dominate the Rails community.

richcollins• 18 years ago

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.

matstc2• 18 years ago

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.

hassy• 18 years ago

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

jrockway11• 18 years ago

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

tptacek9• 18 years ago

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

tptacek9• 18 years ago

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

jrockway11• 18 years ago

Did you read the sentence after the one you quoted?

tptacek9• 18 years ago

Yes. Paraphrasing: "if I had to write all that code myself, my blog would have far fewer features". What features would those be?

mst9• 18 years ago

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.

nailer9• 18 years ago

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

msluyter• 18 years ago

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.

jrockway11• 18 years ago

Yup, I noticed the same thing. There are 110 comments between the two Perl articles today, and only 3 on the "government can take your laptop for no reason" article. Amusing.

I think people get really upset when they are told that Perl isn't actually dead. I mean, it is, right? How come people are still using it!? </sarcasm>

SwellJoe8• 18 years ago

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.

nailer9• 18 years ago

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

agranig• 18 years ago

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.

omouse• 18 years ago

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.

jrockway11• 18 years ago

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.

Why I stick with Perl

Related Stories