Why Did I Choose Perl When Building Crowdtilt? | Hacker News Reader

Why Did I Choose Perl When Building Crowdtilt?

dsog.info

120 pointsknighthacker138 comments

There is some decent justification in there, but I think the generic question, in a lot of questions is:

Why did I choose to build X with Y?

The generic answer is usually:

Because it is what I know.

The extended answer may include particular features of the language or environment or it may include the support provided by a particular cloud infrastructure.

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.

In other words, choice of language can take on many facets. Good to see PERL mentioned again.

There are always tradeoffs, but sometimes you can find "the best tool for the job". And that may or may not be the tool that you know. You gotta be flexible and open to learn other tools that may suit the situation better.

In the post I don't bash any other languages at all. In fact, I encourage people to learn other languages too. At the end of the day, it'll help you evolve your thinking process and extend your skill set.

Thank you for your comment :)

Not saying you bashed languages, but made a good argument for PERL. And the points were good and provided substance. Which, personally, I find useful and will likely guide me to look into things I may not know or revisit something I don't know. PERL might be the exception.

What I liked about the post - it didn't focus on hype, like that around NodeJS (it's badass rock star tech); additionally it brought up a language no so en vogue.

Keep up the good work.

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.

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 agree. It is a misconception that Perl is "dying". It powers a lot of the web. It had a bad rep a few years ago due to cryptic-looking codes that were written as a throw away code and somehow spread all over the web :).

I was one of the skeptical developers at some point, but then I got hooked :).

Modern Perl changes the old rep alltogether. I encourage people to write well architected, maintainable, extensible code and follow design patterns regardless of the language of choice.

Regardless of the structure of modern usage its syntax is still very noisy for the reader. It seems the majority prefer the cleaner syntax that doesn't use punctuation to define the type of access a la BASIC.

As a self-trained programmer who cut his chops on Perl, I find it a bit humorous that people complain about reading Perl, while every coding test at a job interview involves some five-way algorithm or other generally-arcane CS concept that CS people spend two years practicing and that the business will never use. Two forms of complexity, one valued much higher within the industry.

It is so hard to know that @ means array and % means a hash (key/value pair) haha.

It's not that hard to know the types of the variables you created without punctuation in the identifiers, either.

Well, it's not just the type of the variable but also how you're treating it - world's most concise cast...

Also, it means one doesn't have to dodge keywords in naming their variables. Doesn't count for a lot but is nice.

>you created

Agreed. However, working for a company with more than one developer...

Yes, the sigils can make Perl code look noisy, especially as Perl uses curly braces and semicolons too. However, they do have a couple of nice benefits: firstly, they make variable interpolation easier (and less noisy!) than in other languages like Ruby and Python. Secondly, sigils make it easy to see what kind of data you are dealing with, obviating the need to scroll through your program to the variable declaration.

I've not touched Perl aside from modifying and using basic scripts for process automation and administration tasks.

But since you called-out Python and Ruby, I'm curious what you meant.

In Python, for example, interpolation would look like:

print "I ate a %s for %s" % ('banana', 'lunch)

(or the newer way with nominally more keystrokes)

print "I ate a {0} for {1}".format('banana', 'lunch')

I've done plenty of PHP work and I get that I can do "{$varhere}" but for strings of any length or complexity it was totally common to use sprintf() an I have to assume the same readability principles apply in Perl?

In Perl you could write

print "I ate a $fruit for $meal"

printf 'I ate a %s for %s', $fruit, $meal

"This is %(adjective)s readable Python in %(genetive)s opinion" % {"adjective":"more", "genetive":"my"}

> 'This is more readable Python in my opinion'

edit: variable names

Also, I agree that for this simple case, perl (and other's) simple dollar substitution is nicer.

Since there was a mention of extending the language in this thread, there's also:

http://lfw.org/python/Itpl.html

The sigils make variable interpolation easier only in the most generic case "interpolate $me". Anything more sophisticated requires a temporary variable.

You can avoid using temporary variables with the @{[...]} and ${\...} idioms:

  my $x = 1;

  say "$x + 1 = @{[ $x + 1 ]}"; 

  sub plus1 { $_[0] + 1 }

  say "$x + 1 = ${\plus1($x)}";

I am not especially enamored of variable interpolation, but for those that are, Perl 6 does a much cleaner job than Perl 5 imo.

Well... arguably they make it easier in the half-dozen simplest cases. Which just happen to be what's needed 90% of the time.

Huh? That will tell you wether foo is a hash or not, but not what kind of things it contains. So, as soon as you subscript you $foo or @foo or €foo, you are lost again.

A good IDE would be of much more help (and strong typing makes writing such an IDE way easier, but that is a different issue)

You know Perl gets hassled because of the variable sigils, but when I've taught Perl to newcomers it didn't seem to be much on an issue. Maybe this is because Modern Perl tends to be more clean and OO, there's not the sigil busyness you might see in old Perl code used by admins in the mid 1990's. I think this is really just something people that use other languages are bothered by. I know we all have preferences. When I do Javascript I tend to miss the sigils a bit :)

It might look noisy - but it is just easier to parse in your head when you know what is a variable and what is a function or a keyword. I have came to believe that much of the 'Perl is ugly' notion comes from the fact that the $ character does not have nice typefaces (http://perlalchemy.blogspot.com/2011/01/is-responsible-for-u...).

Who cares about the syntax? The real problem is the weak typing.

And this would be why PHP is so popular?

Very true! It seems fashionable to make fun of Perl and C++, but in the real world, they are everywhere, doing everything and they work extremely well.

Workhorses are never fashionable.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses"

- Bjarne Stroustrup

He was very biased; it counts for little.

There are only two kinds of people: the ones others complain about and the ones nobody cares about.

Wah! :) Is there a like button here?

You, sir, will be quoted some day :)

Not sure why it got all the down votes. Since Visual BASIC faded away there's been two mainstream languages that have come in for much complaint; C++ and PHP. All languages suffer some valid criticism as none are perfect but the weight of criticism for these two suggest much is deserved, it is in my opinion. Consequently, that the author/facilitator of C++ has a fun quote to dismiss the large-scale criticism is fun but "counts for little" as he's biased.

It's really not that surprising when you think of how much of corporate programming is taking data in format A and outputting format B. Perl is fast and well suited to data transformations.

I hope the strong testing culture and rock-solid reliability are another good sticking point.

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.

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

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.

That being said, I don't feel that any 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.

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.

Indeed :).

Checkout these modules: Test::Class::Sugar MooseX::Declare

Thank you for your feedback.

Those are both excellent examples. One modifies the core language syntax to allow for writing tests in a cleaner and easier way. The other one modifies the language to make writing OO code in a new way, one that will be familiar to Java developers. I don't know of very many languages that allow developers to modify the core language via 3rd party modules. That's why Perl will never die - it will simply evolve as the needs of programmers change. Hey, Smalltalk Roles are a nice idea ... ok we'll add those (Moose::Role). Hmmm, lets allow method signatures to declare types for their params ... sure no problem (MooseX::Method::Signatures). Wouldn't it be cool if we could treat arrays as objects and invoke methods on them? Sure, here you go (autobox::Core).

As has been alluded to in another comment: Which other languages that compare to perl have you actually looked at?

Python has rich meta-programming. Ruby has (almost) single-handedly super-hyped and re-invented the idea of domain specific languages (DSLs). Lisp is of course all about this (as is Forth).

Javascript builds on the ideas from Smalltalk and (especially) Self to allow you to crazy stuff with how objects work...

Java can't do much of this, but the JVM has been bent in surprising ways by efforts like Clojure and Scala...

While it is great that you know and like perl -- That particular point in the post (and this comment) seems rather poorly researched.

I'm very much on the burnt-by-crazy-old-nasty-perl-legacy-crap side of the fence -- but I can't deny that I see some of the reasons why people would like to use perl -- it's just not for me. The statement "Perl evolves in a ... manner that makes the language always fresh" makes me want to hide under the bed -- if I have to deal with someone else's code in production ;-)

Still -- it's a bit strange to see the claim that perl is somehow much more flexible than other comparable languages.

"As has been alluded to in another comment: Which other languages that compare to perl have you actually looked at?"

I am very familiar with all of the languages that you mention. They are all great languages in their own right. My comment however was about Perl's ability to easily evolve the core language via contributions from its community, as opposed to other languages that require a lenghty process performed by the core maintainers of the language. This allows Perl to evolve at a much faster pace than other languages. A lot of your points do not seem relevant in that context.

"Python has rich meta-programming."

Who cares? So do most modern languages.

"Ruby has (almost) single-handedly super-hyped and re-invented the idea of domain specific languages (DSLs)."

The Perl community has been writing DSL's since before most people had heard of Ruby. Real DSL's. Not just invoking functions without parens and labeling it a DSL, as is often done in the Ruby community. Ruby in no way invented or re-invented anything having to do with DSL's.

"Lisp is of course all about this (as is Forth)."

Agreed. Lisp macros are very powerful. Lisp is a great example of a language that can do this.

"I'm very much on the burnt-by-crazy-old-nasty-perl-legacy-crap side of the fence -- but I can't deny that I see some of the reasons why people would like to use perl -- it's just not for me."

This is a common complaint. People have had to deal with Perl code that they do not understand. It may have been poorly written, or it may have been perfectly written Perl code. If you do not take the time to learn Perl, you would not know the difference. The most common reaction is to blame the language.

"Still -- it's a bit strange to see the claim that perl is somehow much more flexible than other comparable languages."

It may be strange to you because you are not very familiar with Perl.

"People have had to deal with Perl code that they do not understand. It may have been poorly written, or it may have been perfectly written Perl code. If you do not take the time to learn Perl, you would not know the difference."

The problem is that Perl's TIMTOWDI culture and the inconsistent evolution of the core language make learning "enough" Perl harder than learning e.g. "enough" Python.

Yes, I definitely agree that Perl is harder to learn than Python. My point was that people may not have the time or interest to learn Perl, and so when they see Perl code that they do not understand, they blame it on the language instead of their own lack of knowledge.

Perl has a very rich and powerful and expressive grammar. It takes a good bit of effort to learn all of it. Python has opted for a grammer that is much more simple. That definitely has its benefits. For me personally, I feel constrained when writing Python code due to its lack of expressiveness.

Python's "one obvious way" to do things changes over time too!

I didn't say I had to deal with perl code I didn't understand, just nasty perl code. Of course the coder in question is the problem, not the language as such -- I've just seen more obscure hacked together perl code than eg: python.

I'm perfectly aware this is a subjective opinion: I don't like perl very much. I never claimed everyone else should dislike perl -- in fact I stated the opposite -- I see why it appeals to some people.

> My comment however was about Perl's ability to easily evolve the core language via contributions from its community, as opposed to other languages that require a lenghty process performed by the core maintainers of the language.

> "Python has rich meta-programming." >> Who cares? So do most modern languages.

Well, your claim is that perl has strong meta programming, and that perl programmers use it -- implying that eg: python programmers choose not to, and rather sit on their hands waiting for Guido to bless their new data structure or syntactic sugar for improving arrays?

See eg: http://www.python.org/dev/peps/pep-0218/

I suppose this your "lengthy process" ? But the set module was available before it became part of the core language, so if you were the programmer that needed a new datatype nothing stopped you from implementing it and uploading it to the package index? (Although I don't remember quite how well the package index worked back in 2000 -- CPAN certainly has a long and solid history behind it :-)

For another example (again python):

http://kashif.razzaqui.com/30414548 "Javascript's Prototype Inheritance in Python"

As for ruby, note I said "super-hyped". Maybe I should've said "re-introduced", or "introduced to a new generation of programmers", rather than "re-invented".

> It may be strange to you because you are not very familiar with Perl.

Perhaps. I would be very much interested in some examples of the DSLs you speak of. I guess perls regex-handling would lend itself to be used as a poor man's Standard MetaLanguage?

Well, ok -- I guess (after a bit more googling) I see what you mean:

http://www.catalyzed.org/2009/05/dawn-of-a-new-age-in-perl-h...

Now, while power obviously is power -- I don't see many immediate uses for that, that can't be done better within in python via magic methods etc.

But in case others are interested, here's a couple of links I also came across:

http://stackoverflow.com/questions/214881/can-you-add-new-st...

http://eli.thegreenplace.net/2010/06/30/python-internals-add... (Most definitely in the "don't do that"-category from a python point of view :)

If this (writing a new language) is really what you want, you would probably be better off playing with pypy and its restricted python, though:

https://bitbucket.org/brownan/pypy-tutorial/src/8cfb3cd72515... (Tutorial for writing your own interpreter with rpython)

https://bitbucket.org/cfbolz/pyrolog/src/aa127d31df0c/prolog... Working implementation of Prolog, built with pypy/rpython

The python example you linked to http://eli.thegreenplace.net/2010/06/30/python-internals-add..., which shows an example of adding an 'until' keyword, requires you to recompile the python interpreter. From your article: "After making all the changes and running make, we can run the newly compiled Python and try our new until statement". Of course you can extend any language by recompiling it and creating a new interpreter. That is exactly my point! Perl lets you achieve the same thing simply by using a module from CPAN.

I don't think you have been paying attention to what I have been saying. You keep mentioning that python has strong meta-programming. I never said anything about meta-programming. Perl, python, ruby, everybody can do meta-programming. I said that Perl lets you easily modify the core language grammar via 3rd party modules. This is an extremely powerful feature, if you took a second to think about it.

Yes, I should have been clearer in my previous comment: What I meant to say was that I see what the previous poster meant, and I was wrong.

However, if someone wants to do something similar in Python, here are how you would (have) to do it. I didn't mean to say that it was the same - or as straightforward.

This is also why I linked to the r(estricted)python examples with pypy -- because they give you more of the power to define a whole language -- but that also isn't the same as being able to do it within the language itself.

As for meta-programming, I have always meant that in the sense of lisp macros, not simply chaining some cleverly named functions.

I'm still not convinced it's a feature I would want in Perl -- but then again, I don't particularly like Perl, and I don't use it -- so clearly what I think of it doesn't matter: I'm not the target audience for Perl features.

Thankfully we don't all prefer the same tools :-)

You had asked for some examples of Perl modules that extend the core language. As was stated by @knighthacker, MooseX::Declare and Test::Class::Sugar are excellent examples:

https://metacpan.org/module/MooseX::Declare https://metacpan.org/module/Test::Class::Sugar

Just look at the SYNOPSIS section for example code. If you know some Perl, you will notice that the code would normally not be valid syntax. Yet simply by using a module, you can define classes (MooseX::Declare) or describe tests (Test::Class::Sugar) in a brand new way.

So, you acknowledge that your experience with Perl is outdated, yet you're sticking to your guns.

The particular claim was that Perl programmers extend the core language via Perl's ability to do meta-programming and that Perl is more flexible than other (comparable) languages. Further clarification with regards to DSLs show that the poster meant that Perl has been more flexible for quite some time (before Ruby hit in the western world) -- ie: from the time that I did look at Perl rather seriously.

At that time there were already quite a lot of movement within eg: python with improvements being made to the language, in the language itself.

So, yes, I guess I'm sticking to my guns.

And, incidentally, I was wrong:

http://news.ycombinator.com/item?id=4463536

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.

When I first started here I asked the same question: "Why?" - and I got essentially the same answer as this article.

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.

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

Ummm... What?!

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.

Not the same thing. DSLs are not the same as extending the functionality of the interpreter. And it's basically the flexibility of perl as a procedural/functional/declarative/OO language (i.e. lack of assumptions of how you want to work) with its roots in practical natural linguistics (as opposed to theoretical as with lisp) that makes this possible. Yes, that does mean coding with some discipline (Perl::Critic and Moose & friends helps here), and some things are more of a pain in the arse than with a more opinionated language, but it seems a reasonable trade off to me.

I'll give you macros, but if you define DSLs as "chained methods", many languages have DSL supports. The author's talking about Perl's support for mangling the language itself through third party modules.

What does Perl have in that regard that Ruby hasn't? Ruby also has open classes and you can chain and modify any of the base classes, be it "String" or "Object".

I don't know anything like "MooseX", but that might be because Ruby actually has a somewhat working object system.

Perl lets you add new language keywords which take effect during the parse phase.

So, basically, Perl has macros? REAL macros? Like, say, in Lisps? Could I, for example, make fully inlined merge sort, as demonstrated a couple days ago here by a post from Racket blog? Now I'm curious.

Sort of. Perl has support for something like reader macros. See http://search.cpan.org/~zefram/Devel-Declare-0.006011/lib/De... for details.

One could, in theory, build something like Lisp macros using it, but I don't think that anyone has.

Perl 5's parser manipulation doesn't go as far as manipulating an AST, yet. I would like that, but Lisps still have a strong advantage there.

Sure, but the intent of the author seems to be to say that the language can be molded in ways that make it easy to apply in specific domains. Whether that's with macros or with a DSL-ish approach you're pretty much achieving the same end result. Ruby's blocks make it fairly easy to create DSLs that look like you've actually changed the underlying language in some way - Rails makes heavy use of these features, for example.

Exactly. MooseX::Declare is a good example.

Of all the reasons why the OP chose Perl for their project, this is the one that makes the most sense:

5. Perl code is fun to write.

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.

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 :-)

Checkout Moose -- it is one of the thing the author points to about Perl. Tools like Moose do an amazing job of fixing the warts but keeping the power.

Moose's support and flexibility as an OOP layer is second to very few.

http://moose.iinteractive.com/

If the developers don't plan ahead then you'll regret whatever language you choose once the project gets big enough. Perl because it's "write once", Python because it's loose typing, C++ because it's so big and complicated, ...

Isn't the maintainability of the code a function of who wrote it?

That is one aspect, but not the only one. When you start to write complex software you realize that the language, frameworks, libraries, design patterns, etc impact the maintainability of your code.

frameworks, libraries,

This is basically what Modern Perl and CPAN modules are all about. Checkout Perl Dancer as a web framework for example and you'll see simplicity.

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 heard this argument before: I'll build my product using X because nobody else is doing it, so all the best Xers are going to line up. I can't speak for the author, but I haven't seen it quite work out.

Unless you're talking exclusively to language/stack zealots, the best guys are evolving the tools, and the next-best are evolving with them. That's not to say that all things old are bad and all things new are good, but we do tend to get better at different classes of problems.

As the author suggests, though, Perl has this incredible longevity and extensibility. I really like it whenever I work with it, and it wouldn't be a turn-off if I was considering working there. But if someone came to me and said, "I want you to develop a To-Do web app in C++," I'd probably pass.

In all fairness, I think it depends on what "X" is in your case. If you've decided on Prolog as your language of choice, you are going to be limited to a pool of government type candidates and IBM event management gurus.

Perl was one of the first mainstream advanced scripting languages to run the Web, so the amount of folks out there that cut their teeth on CGI/Perl is pretty wide and deep.

For me, I started writing my first Web apps in Perl, and moved over to PHP.

I personally wouldn't work for a company ONLY because of the programming language. I have to be super passionate about their product as well and then the language choice comes after.

So far hiring hasn't been a problem for us. However, we don't focus on hiring Perl hackers, but outstanding hackers instead. They grow to enjoy Perl after a few hours and sometimes during the interview ;) haha

That's funny, because most of the "hot" startups are choosing/using languages that they can actually find developers for. If great Perl hackers were easy to find, more startups would use Perl.

That's a chicken and egg problem though, especially in a place as driven by fashion as the technology startup scene in Silicon Valley. Training a decent developer to be effective with Perl is fairly easy (use my free book on the subject!).

Getting attention because you didn't use Node or Clojure or Erlang or Ruby or Python or Java is trickier.

(I've been at this long enough to remember hearing from VCs "Your product has a Perl backend and a Python frontend? Oh... would you consider rewriting it all in Java? Java has more buzz.")

I second the reference to the book. It is a must read for all new devs at Crowdtilt. Excellent book @chromatic.

I've been playing around with perl over the last 10 years, and over the last 4 years or so doing perl professionally.

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.

Python on the other hand looks like a sufficiently different take on the dynamic language problem, so as to be more interesting.

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.

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.

So .. maybe it's not always a good thing? Including this particular reference in the article?

So I usually write Python. Perl has a similar heritage to Python and I think the two are similar in many ways (more in Rakudo). As a Python programmer, I think there is nothing wrong with liking and using Perl. I don't think you should find this uncomfortable or strange. I also think there is no clear-cut reason why you would absolutely have to switch, as long as Perl was still suiting your purposes.

You are exactly right. But for some cases, it is a great thing. You obviously need to know when is the right time to be explicit. I remember doing the Stripe CTF and I was like, I wish all people would learn to be explicit about those parameters.

Thanks for the feedback :).

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"

I know of no other language that has anything like cpantesters.org. Everything that gets uploaded to the CPAN gets tested automatically on a large matrix of Perl versions and host platforms, often within minutes of the upload. Furthermore, the entirety of CPAN is the continuous integration test suite for Perl 5 itself.

Edit to add: I know why this sounded familiar! I had forgotten I wrote about it recently:

http://www.modernperlbooks.com/mt/2012/08/why-i-use-perl-tes...

I use Perl for the Turing completeness.

Java doesn't have any of them.

>> EVERY OTHER LANGUAGE DOES THAT

Do you really know about this?

I've done a bit of Python lately. The infrastructure isn't close (see e.g. Perl Testers, chromatic had a blog post about it quite recently). Also, CPAN is much richer than pypi.

Which modules are missing on Pypi?

It's not the modules - it's the infrastructure of the CPAN environment.

See this comment on an old Perl thread for some pointers

http://news.ycombinator.com/item?id=4042344

Off the top of my head -- a serious sql parser and the whole TAP test ecosystem. After a while I stopped checking cpan for what I needed, since I just got angry.

Another difference: In the Perl world, you can find and have dependency trees with dozens to hundreds of modules installed from cpan -- and you expect it to work, particularly since the module tests by default are run at install. (It is a bit painful with too many dependencies, but it works if you need it.)

I think there are many cases where packages may not be in one language repo, but in another. However, Python does have a lot of testing packages available that do a swell job. Also, the JUnit test-report format these days tends to be what I see a lot of.

http://wiki.python.org/moin/PythonTestingToolsTaxonomy

Also, as far as SQL, and even Object Relational Mappers goes, there's SQL Alchemy.

You can verify they are present here, in PyPi: http://pypi.python.org/pypi

SQL Alchemy doesn't have an SQL parser, which I asked for.

See http://search.cpan.org/~rehsack/SQL-Statement/

It contains a parser and evaluates SQL expressions on lots of data sources(!).

The testing tools on Perl use a common infrastructure and can work with each others in a plugin fashion.

Good Story and Dancer is really good. For these that want to give it a try we support dancer on the free hosting at http://1.ai

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:

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.

ii. CPAN. It is unusual for me to go there and not find something that I can use for a task.

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 wonder if this will make hiring easier or harder in the valley?

It is a very good question and I had to think really hard about it in the early days. My take on it is that I appreciate good developers regardless of the language of choice and those are the stars that we want to have at Crowdtilt. Good developers will usually learn any "needed" tools in a matter of hours.

In fact, I think if anything Perl would speed up the time it'll take to train a dev and get him/her to have an impact on the product from day one due to how easy is it to learn.

In fact, I think if anything Perl would speed up the time it'll take to train a dev and get him/her to have an impact on the product from day one due to how easy is it to learn.

Which will be negated by how hard real-world perl code is to read and maintain.

There's a school of writing "modern" Perl, using source filters and object systems. Bare Perl is a mess but, in somewhat of a Lispy way, you can use Perl to rewrite your Perl. If none of your functions have signatures and you're manually blessing objects, your codebase will quickly turn to shit. Using a standard bits (such as Moose) to give you a consistent object system and method call syntax changes things dramatically.

This is a new fad and it undoubtedly leads to more maintainable code, but it still feels like a bad tradeoff to me: you get the verbosity of stricter languages without the benefit (compile-time errors) at worse performance than plain Perl. I'd rather write something new in Scala or Go nowdays than in strict "modern Perl" style / Moose (and I've used Perl almost exclusively for the past 13 years).

umm, verbosity?

  package Point;
  use Moose; # automatically turns on strict and warnings
  has 'x' => (is => 'rw', isa => 'Int');
  has 'y' => (is => 'rw', isa => 'Int');
  sub clear { my $self = shift; $self->$_(0) for qw/x y/}

Verbosity.

    class Point {
        has Int $.x is rw;
        has Int $.y is rw;
        method clear() { $.x = 0; $.y = 0; }
    }

Perl 5.18 may have the following:

  use mop;
  class Point {
    has $x = 0;
    has $y = 0;
    method clear { ($x, $y) = (0, 0) }
  }

ref: https://github.com/stevan/p5-mop/blob/master/t/000-examples/...

Looks like a noble attempt to remove perl5 and ruby pain in the arse points simultaneously. Wonder if it will ever come to anything ...?

Perl 6 is / will be sweet :)

Perl 6 is sweet, and will be sweeter when it has better performance. :)

Source filters? Hahahahaha. The only acceptable source filter to use is Smart::Comments - https://metacpan.org/module/Smart::Comments - and even then, if you fire up code using Smart::Comments in the interactive debugger it's going to be a pain in the arse.

Moo/Moose (and Mo and Mouse if you must) are on the other hand game changers.

I definitely recommend reading "Modern Perl". It is a game changer.

http://www.onyxneon.com/books/modern_perl/index.html

Developers that write unmaintainable and unreadable code exist. This has nothing to do with the language. That's where "Good Developers" come in.

You don't even need to know how to write code to understand the code written at Crowdtilt or any other company that really uses Modern Perl and have good practices.

Yeah, but the language helps a lot on that. And so, it is related to the language.

Comparing the readability of python vs perl/c-like languages show it clearly. In python the readability come as a natural idiom, it is part of their zen!.

I found that when I develop in python/delphi/pascal the code is readable by default, but in ANY c-derived language could become messy fast. Something as simply as how align a IF clause. In C-like language I could go wild (and I see a LOT of code that look different, from person to person) and in contrast I read almost any python code as if I was write by myself.

In python the readability come as a natural idiom, it is part of their zen!

Superficial readability, perhaps.

Neither PEP 8 nor PEP 20 get into interesting questions about maintainability like:

    * How long should individual compilation units be?
    * How do I factor my code?
    * What metaphors do I use to name components?
    * How do I know when to break apart components?
    * How do I know when to merge components?
    * How do I write effective documentation?
    * Is this API easy to use?
    * Have I sufficiently encapsulated this component?
    * How easy is this code to test?
    * Does this code match local style?
    * Does this code follow the idioms and express the necessary elements of the problem domain effectively?
    * Is it easy to misuse this API?
    * Have I made too much information public?
    * Have I made too little information public?
    * Does this code make potential bugs screechingly obvious?
    * Do I handle potential error conditions sensibly and completely?
    * How much work do I face enhancing this code in the future?

PEP 8 concerns itself with far less interesting things, like why vertical alignment is annoying. In my experience, that's one of the least substantial elements contributing to maintainability.

As for readability, it doesn't really matter if someone who doesn't know the language can't read it.

You need good developers to tackle those interesting questions. There is no answer, because you can only rely on rule of thumb and you must know when to break the rule of thumb.

PEP 8, on the other hand, is to get these good developers to agree on the less interesting things, such that they can use it as a stepping stone to the more interesting ones. PEP 8 requires strict compliance, because if different developer ignore different portion of PEP 8, you end up with nothing.

In short, if you have long lines of code crammed together with no spacing, get them to look pretty based on PEP 8 first before we talk about how easy is this code to test.

I agree, but nothing in Python the language addresses any of my questions. Those concerns are so far beyond the language level that the language is irrelevant.

It's incredibly easy to write good Perl.

It's just easier to write bad Perl, and most Perl is set it and forget it in scope.

Hiring people willing to work in Perl isn't that tough. Hiring experienced Perl developers with experience solving specific issues is tougher. Hiring a experienced Perl hacker that's fully embraced something front-end development using Extreme Programming is going to be virtually impossible in your local area. I'm a recruiter w/ first hand experience trying recruit for many languages, and I find Perl-based posotions much harder to fill.

Part of the problem is that people like me tend to prefer to work remotely, work on contract, and get paid more than $35 an hour.

As long as you get the job done, we don't care where you are. I don't think many companies care anymore. Or maybe they still do.

I'm writing to beginner programmers. Please, please don't use Perl.

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.

see https://sites.google.com/site/steveyegge2/ancient-languages-...

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.

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.

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: http://www.perl.com/pub/2000/12/advocacy.html No one with a OPEN mind who isn't lazy wouldn't move onto Python or Ruby.

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.

Anyhow those are my 2 cents. I have to go to sleep.

Your post gets a number of things wrong about Perl.

> For crying out loud Perl has pointers in it.

It does? Do you mean references? You'll need to use reference syntax when using nested data structures, but this is the same syntax that you'll find in Python and Ruby - you could think of those languages as using references by default instead of having array or list types.

> Perl doesn't do basic parameter checking in functions.

This is true - you'll need to deconstruct `@_` yourself. It is a shame. There is Params::Validate and Method::Signatures to fix this.

> Perl doesn't come with a decent repl.

Yeah, this is annoying. Get Devel::REPL and use that.

> Perl doesn't do sane type checking. print "abc" + 1; prints 1. It isn't a syntax error (like in Ruby or Python).

This throws a lot of people off, when they expect it to work like Python or Ruby and it doesn't. "abc" and 1 are actually the same type - scalars. A scalar can be a number or a string behind the scenes, and they're automatically converted, so you can just read data from a file and not have to worry about that. You want to use the dot operator, `print "abc" . 1;`, which prints "abc1" (which is what I think you want).

In those languages, it throws a type error, not a syntax error, which is an important distinction. Intergalactic law states that you're not allowed to complain about Perl if you don't know this.

> wantarray is one of most horrible things I've seen a programming language

Having list flattening means you can dump all kinds of data into a function and not have to worry about where it came from. Recently I wrote the line of code `highlight qr/regex/, @colours, @more_colours`, where I just dumped values from arrays into the function and didn't have to worry about destructuring them. If I wanted to pass the arrays, I'd put a backslash before them. It's sort of the opposite of Ruby's unary * operator.

Perl has warts just like any other language. Its warts are just more infamous (because Perl is used so much, a lot of people are having to maintain old codebases) and more visible (Perl has a culture of using the CPAN to fix things with the language (MooseX, Modern::Perl) whereas other languages' users tend to just put up with it).

I disagree that the average code is what counts. When I helped out on a Python cause, the lecturer barely knew Python, and taught it as though it were C (the students learned while loops first, then for loops, and never actually learned about generators. Yeah, I know). The code they wrote was definitely below-average. But not once did they turn to the Internet to see what proper Python code was like - they just followed the course, and did what it told them. If you learn Perl from a book, the amount of sub-par Perl code in the wild isn't going to affect you. Or, to put it another way: how can someone else make my language a worse one merely by writing in it?

I do agree that Perl is a bad choice for your first language: the choices it gives you and the amount it leaves up to you could get confusing when you're trying to learn it by yourself. Perl is a language for when you're a better programmer, and you've learnt to code at a higher level.

Please don't make assumptions about my Perl knowledge as I don't make any assumptions about your technical knowledge. I'm actually a Perl Programmer full time.

Yes, Perl does have pointers in it. The term 'References' (in Perl) is marketing cover up you fell victim to. Run this: my $x = [1, 2, 3]; print $x; It prints ARRAY(0x206a998) on my machine. There's a address and a type, that's a pointer. Please read the Steve Yeggie I posted above (he explains it quite well) and then reply back (if you are so inclined).

>It does? Do you mean references? You'll need to use reference syntax when using nested data structures, but this is the same syntax that you'll find in Python and Ruby - you could think of those languages as using references by default instead of having array or list types.

So I have include 2 modules do something incredibly basic and fundamential to all programming languages. What a joke. C has been doing this SANE behavor since the 80s (maybe seventies). Along those lines (sorry, I'm being sarcastic to get my point across) why don't we have all scalars get random wrong values (after you assign something to them)? Then you can include a module Variables::UseRealValues so it behaves correctly. Then Perl fanatics can tell me how other languages are less flexible and Perl via TIMTOWTDI is better.

> This is true - you'll need to deconstruct `@_` yourself. It is a shame. There is Params::Validate and Method::Signatures to fix this.

Fair enough, I meant type error. I know what scalar is.

> Perl doesn't do sane type checking. print "abc" + 1; prints 1. It isn't a syntax error (like in Ruby or Python). This throws a lot of people off, when they expect it to work like Python or Ruby and it doesn't. "abc" and 1 are actually the same type - scalars. A scalar can be a number or a string behind the scenes, and they're automatically converted, so you can just read data from a file and not have to worry about that. You want to use the dot operator, `print "abc" . 1;`, which prints "abc1" (which is what I think you want). In those languages, it throws a type error, not a syntax error, which is an important distinction. Intergalactic law states that you're not allowed to complain about Perl if you don't know this.

Yes other languages have warts. Perl just has more of them.

>Perl has warts just like any other language. Its warts are just more infamous (because Perl is used so much, a lot of people are having to maintain old codebases) and more visible (Perl has a culture of using the CPAN to fix things with the language (MooseX, Modern::Perl) whereas other languages' users tend to just put up with it).

But people don't just learn from books. All of us google how to do a particular task when we doing it (especially under time constraints). With Perl's unwieldy syntax you're likely to copy something wrong (I don't just even mean cutting and pasting, but concepts). Someone will probably have to read this code later. So 'on paper' it doesn't make you're language worse (as you question below) but in practice (and that's what really matters) Perl's lots of wrong ways to do it really shoots you in the shoot.

> If you learn Perl from a book, the amount of sub-par Perl code in the wild isn't going to affect you. Or, to put it another way: how can someone else make my language a worse one merely by writing in it?

I find it slightly annoying all these 'why I use Perl' links on hacker news. Advocacy is lame. With Python or Ruby you'll see more links on a new library or a tutorial (like math library on the front page). Rarely do you see a 'why I use Ruby' or 'why I use Ruby' link.

One final thing, for all my Perl critism I find the community intelligent and very helpful. I just think the language is poor and they should move on alreay to Ruby or Python. It's a shame they waste on their talents on Perl.

In Ruby can write `puts Object.new.inspect` to get something like `#<Object:0x7f88ded4cc68>`. Does that mean Ruby has pointers?

If you can't do math on it to access other parts of memory, it's not a pointer in the C sense.

But you deference the addresses just C. I'd say it's more a like a pointer than not. And this is where I have I issue. You don't deference addresses in Ruby or Python. When you are writing data structures in Perl you have constantly have to deal with extra syntax (and mental work). I'd say about 10% or so of my syntax errors come from this and it's completely unnecessary. It's a huge pain (to me atleast).

I'd say it's more a like a pointer than not.

Are you familiar with the distinction between "pass by reference" and "pass by value"? If you call everything which behaves in the former way a pointer, I think you confuse an implementation strategy with a language construct and you lose an important feature of C pointers.

What you see in Perl (and Ruby) is a unique identifier that happens to be a memory address. It could be anything else, but the memory address is an identifier that's essentially free to generate. That's it. It's otherwise irrelevant. You have to write code in a language which has pointers to do anything with that information, and even then you have to cast it to a real pointer to do so.

We could discuss Perl 5's dereferencing syntax (it's ugly, no argument there) but that's a syntax issue and not an implementation concern.

I'm familiar with C and understand why pointers are there. I understand what you are saying and you make a fair point. I'll take back my statement Perl has pointers. Claiming Perl has pointers is very murky (although it has some truth to it). The heart of what bothers me is you have to deference addresses (similar to what happens with pointers in C) in Perl. This shouldn't exist in a scripting language syntax. It lots of unnecessary syntax, compile errors, and mental hoops you have to go through when coding. Ruby and Python don't have this serious (I think so at least) wart.

> Are you familiar with the distinction between "pass by reference" and "pass by value"? If you call everything which behaves in the former way a pointer, I think you confuse an implementation strategy with a language construct and you lose an important feature of C pointers.

The heart of what bothers me is you have to deference addresses...

I don't understand why you keep saying that. They're not addresses.

From the language side of things, they're first class scalar entities just like strings and numbers. From Perl 5 they have nothing to do with memory addresses. (You might as well suggest that a nested data structure in any language without pointers is "dereferencing addresses", or that accessing object attributes is "dereferencing addresses".)

You can't write in Perl something like:

    my $reference = 'ARRAY(0x1234abcd)';

... and expect to access the array at that point in memory even if you stringified an array reference and saw that its stringification included that hex address. References are not pointers. They don't dereference addresses.

From the internals side, they're SVs, just like all other scalars in Perl 5. An SV is a C structure. Yes, the internals use pointers, but so does any other virtual machine implementation.

(Okay, you can write code like I said above, but to make that work correctly, you have to write C to do it, because C allows direct access to memory by address.)

I'm sorry. I'm actually a little dyslexic and if a wrong word slips by the spell check I can get myself in trouble. s/deference/dereference/.

Consider: my $x = [1,2,3]; print "@$x\n";

In the second line I consider "$" dereferencing the "address" that points to an array. I don't know anything about the internals of Perl virtual machine and what that "address" really means. But to the common programmer it seems like you have to do the same work you would have do in C dereferencing pointers. Python and Ruby have no such operator, right? This unnecessary work is what I'm complaining about (and all the associated extra syntax).

I don't understand why this is getting down voted.

Because some of your assertions are factually incorrect. That's a valid reason to downvote.

Wow. A five-paragraph I-hate-Perl rant by someone who obviously neither knows the language nor wants to.

Though I probably wouldn't recommend Perl as a first language for everybody either, that's some pretty weak arguments. Appeal to authority of other Perl haters only proves Perl haters exist.

For crying out loud, Perl doesn't have exposed pointers. Perl doesn't prevent the programmer from doing basic parameter checking in functions. Decent REPLs are available for Perl. How could "the Perl REPL" not work with readline if he just said there wasn't a Perl REPL in the previous sentence? Perl doesn't have the same opinion as him as to what sane typing is. Doing stupid stuff results in undefined (to him, at least) behavior. It's possible to implement action-at-a-distance in Perl.

Python and Ruby have their warts too, they're just not exposed in this thread because there's no hater around to quote out-of-context lists of surprising behavior.

Arguing not to learn Perl because the average Perl out there is ugly? Non sequitur. No one with an open mind blah blah blah? I've got opposing data points. (not to mention the true scotsman)

Particularly ironic to quote that MJD text from almost twelve years ago. All of the behavior he described, I can now mostly observe from Python self-appointed champions.

And now on HN as well.

(I'm not saying you have to use Perl. I'm just saying dismissing it for the "reasons" listed in parent post doesn't make sense.)

Reason no 6: The expression of people's faces when I tell them that I use Perl. “Oh! wow, why?” Priceless.

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.

Good article, especially the praise towards CPAN. It seems to get lost in the hustle and bustle of the cutting-edge discussions, undeservedly so.

I'm sorry but most of these arguments can be used to defend the use of ruby or python as well.

That's true, they're also true of Perl. These languages have a lot in common and a lot of overlap in what they can be used for.

TL;DR - I know Perl.

This is a great comment. Not sure why it we downvoted in oblivion. Sometimes there's nothing to say about an article, really. Way to drop the hammer, dude. Enough with HN pretension.

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.

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?

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.

Perl 5 has been around for a while and has seen quite a bit of optimization. It's fast.

And the regex engine is amazingly fast (there is one faster I believe). Try throwing a 20,000 item list at this little program, and then use the resulting regex to match another 20,000 items and see how long it runs (hint: not very, considering):

    #!/usr/bin/env perl
    use warnings;
    use strict;
    use Regexp::Assemble;
    my $ra = Regexp::Assemble->new;
    while (<>) {
        chomp;
        $ra->add($_);
    }
    print $ra->re . "\n";

Well I'm told that newer versions of perl optimise alternations internally and this is redundant now:

   my $re = join "|", @list;
   my (@matches) = $txt =~ /$re/g;

Quicker and faster...

Does he think he has to justify jis language choices to others?

Maybe he's worried because someone else might have to read the code someday and they might wonder why it's Perl.

What's needed is a way to store code in an "intermediate" form that can easily be translated into whatever scripting language is desired.

Reply on news.ycombinator.com