There is some decent justification in there, but I think the generic question, in a lot of questions is:<p>Why did I choose to build X with Y?<p>The generic answer is usually:<p>Because it is what I know.<p>The extended answer may include particular features of the language or environment or it may include the support provided by a particular cloud infrastructure.<p>As an example, the stuff I am personally working on now, I mostly use Python because I know it well and the ecosystem for webapps is pretty mature. 7 or so years ago, Python (in particular) mod python wasn't even close to modphp, so I went with PHP. Today, if I was adamant about building on Azure, I'd choose NodeJS (thus JavaScript) or C# because they are first class citizens of the platform.<p>In other words, choice of language can take on many facets. Good to see PERL mentioned again.
The one thing I've learned as a consultant working outside the startup world, in the boring world of everyday business is just how much of the computerized world still runs on perl. I've seen some fantastically made systems and some real stinkers.<p>In the HN echo chamber, it seems like everyone who's anyone has moved on to ruby, rails, python, django, etc. Look into the every-web. My god, it's full of perl.
I hope the strong testing culture and rock-solid reliability are another good sticking point.<p>CPAN is more than just a repository of modules: it's a tool-chain of software. When you upload a module you get a tonne of feedback about which platforms and versions of Perl the tests fail on, you get reports from CPAN Testers about your library in the wild, and when new Perls come out you get notifications if your library gets broken.<p>The ability for the language to evolve, I think, has been a big reason why Perl is still around. It's able to adopt new features and simultaneously remain backwards compatible for long periods of time (for the most part).<p>I don't use perl most of the time, but when I do I like it.
I personally don't like the 'flavor' of most Perl that I've seen or written - and it was my first programming language - but it's obvious that it remains one of the most relevant languages in terms of shipped code.<p>That being said, I don't feel that <i>any</i> of the reasons given in this post are in any way leading to the conclusion 'Use Perl'. In fact I think all of those points apply to just about every major high-level language today. CPAN is definitely a very high-quality system, but I think nearly every language I use has something functionally similar. The same sort of argument works on the other points, or so it seems to me.<p>The one exception is the ease of extending the language. I'm not familiar with that functionality of Perl, but I can say that extensibility of the core language is by far my favorite feature of Scheme. If Perl has a similar ability, then I will absolutely concede that that is a powerful feature indeed.
Our company is primarily a Perl shop as well. Hiring is one of the big challenges with a technology stack based on Perl. Especially hiring younger talent who are more interested in the latest trendy language.<p>When I first started here I asked the same question: "Why?" - and I got essentially the same answer as this article.<p>In the end, as long as the development team is comfortable with it, and it works, and there is still a community of supporters, I suppose it doesn't really matter what it is written in.<p>Hey - at least it isn't PHP!
"As far as I know, Perl is one of the only languages that can evolve via 3rd party modules."<p>Ummm... What?!<p>There's a long tradition creating DSLs in the Ruby community. Lisp/Scheme/Clojure have macros. OCaml has campl4. I'm sure there are many others.
Of all the reasons why the OP chose Perl for their project, this is the one that makes the most sense:<p><i>5. Perl code is fun to write.</i><p>If you are comfortable in your environment, then moving fast comes naturally and you have far more opportunities to succeed.
I've had some experience with perl. While it has a lot of advantages (most of them are described in your post) it clumsily support OOP and is very hard to maintain. It's true that perl gets you going pretty fast, But once your code base reaches several hundred classes, you'll really regret ever considering it for production.<p>As a grad student I found myself using it quite a lot for writing quick and dirty scripts for data manipulation until I finally decided to move to python. Since then, I never look back :-)
How do you find hiring? A Blekko founder said they chose Perl partly because as one of the few hot startups to be using Perl, it would make them a top choice for great Perl hackers.
I've been playing around with perl over the last 10 years, and over the last 4 years or so doing perl professionally.<p>Because I'm in the job market at the moment I figured I'd take a closer look at Python and Ruby, so I'm concurrently reading two python/ruby books. To be honest, I don't see much in it. If I were to chose one I think I'd have to go with python, because Ruby looks to me, just like perl but with a different set of weird symbols to remember, and a slightly different set of downsides.<p>Python on the other hand looks like a sufficiently different take on the dynamic language problem, so as to be more interesting.<p>PHP I'm not bothering with right now. It's just like perl only with most, if not all of the design intelligence removed.
I learned perl in the past (I'd rate myself as ~somewhat proficient~, ignoring 'new style perl'), and I like the language. That puts me in a strange place when I talk to friends: I don't know ruby nor python, but do think that perl's a nice language. A strange position to be in, by now.<p>That said: The do what I mean paragraph kind of reminded me of the Stripe CTF. One of the levels (5?) was vulnerable to pass parameters to a POST handler via query string. In other words: In level 5 in that CTF, if you followed one possible solution, you abused this flexibility.<p>So .. maybe it's not always a good thing? Including this particular reference in the article?
I see these justifications for perl almost every time it comes up - The community, cpan, writing lots of code fast. These are good things, but it's worth pointing out that EVERY OTHER LANGUAGE DOES THAT. Ruby has gem, python has pip - modern languages have these things built in by design. Not to hate on perl, because there's things I like about it, but this article could be retitled "what I like about not using fortran"
Good Story and Dancer is really good. For these that want to give it a try we support dancer on the free hosting at <a href="http://1.ai" rel="nofollow">http://1.ai</a><p>Perhaps how popular a solution for the web is depends also on free or easy hosting options where people can experiment ?
I reach for Perl frequently, primarily for two reasons:<p>i. I've been using for 20 years or so, since Perl 4. By the time I check back to verify some point of Python syntax or library use, I will have written the code in Perl.<p>ii. CPAN. It is unusual for me to go there and not find something that I can use for a task.<p>I like Python and do use it a good deal, largely on Windows. Yet some months ago, I ended up writing a few longish scripts to run on Windows, with ActivePerl.
I'm writing to beginner programmers. Please, please don't use Perl.<p>Use Ruby and/or Python. Other competing scripting might be good (like lua) but I haven't used them. I do know however Ruby and Python are better.<p>see
<a href="https://sites.google.com/site/steveyegge2/ancient-languages-perl" rel="nofollow">https://sites.google.com/site/steveyegge2/ancient-languages-...</a><p>90% still holds true. This guy knows more than 99% of the Perl advocates on this thread (he's also smarter than me). Do another search on other famous programmers (like Rob Pike) and almost always you'll find negative comments about Perl. There a reason companies like google use Python and universities (like MIT) teach in Python.<p>For crying out loud Perl has pointers in it. Perl doesn't do basic parameter checking in functions. Perl doesn't come with a decent repl. The Perl repl doesn't work with readlines. Perl doesn't do sane type checking. print "abc" + 1; prints 1. It isn't a syntax error (like in Ruby or Python). Do some basic google searching. wantarray is one of most horrible things I've seen a programming language thats unique to Perl. You how know generally side effects are bad in functions? Well, I don't want to get into it... but just google it.<p>Perl has a weird cult culture to it. There are a few smart people who are really into it but it isn't because of the languages merits. This is well described by one of perl most famous developers:
<a href="http://www.perl.com/pub/2000/12/advocacy.html" rel="nofollow">http://www.perl.com/pub/2000/12/advocacy.html</a>
No one with a OPEN mind who isn't lazy wouldn't move onto Python or Ruby.<p>Remember too at the end of the day it is how good or bad code theoretically is. Is what you see out in the wild. What you work with. The chances are you won't be looking at chromatic's code. Perl code is about the ugliest, most unreadable code you'll find on average. I recently saw something Brain D Foy (a Perl expert) acknowledging this. The average code is what counts.<p>Anyhow those are my 2 cents. I have to go to sleep.
Normally I'd just on the author for using a prototype in production, as admitted in point #1, but being open about it garners brownie points.<p>Good article, especially the praise towards CPAN. It seems to get lost in the hustle and bustle of the cutting-edge discussions, undeservedly so.
Perl is a really great language at getting things done today. Its failing (and the thing that makes a "mem" perl developer and a star developer) is what happens six months to a year after you complete a feature.<p>If you are willing to have some discipline up front (and the expense of some amount of velocity), it can save your bacon later.
Does anyone have a good handle on how good perl interpreters are, or whether there are perl "compilers" that do something fancy, i.e. turn it into bytecode?<p>What with all the fancy compiler/interpreter technology going into things like V8, Nitro, pypy, cpy, etc, would be interesting to see how perl is keeping up in terms of speed.
Does he think he has to justify jis language choices to others?<p>Maybe he's worried because someone else might have to read the code someday and they might wonder why it's Perl.<p>What's needed is a way to store code in an "intermediate" form that can easily be translated into whatever scripting language is desired.