
Why Did I Choose Perl When Building Crowdtilt? - knighthacker
http://dsog.info/blog/Perl/Hacking/Technology/2012/08/31/why-did-i-choose-perl-for-crowdtilt/
======
jmspring
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.

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

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

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

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

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

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

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

~~~
draegtun
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)}";

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

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

~~~
knighthacker
Indeed :).

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

Thank you for your feedback.

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

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

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

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

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

------
rotten
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!

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

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

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

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

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

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

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

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

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

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

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

~~~
knighthacker
_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.

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

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

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

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

------
darklajid
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?

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

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

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

~~~
asher
Which modules are missing on Pypi?

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

~~~
brekken
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>

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

------
rdevnull
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 ?

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

------
jvrossb
I wonder if this will make hiring easier or harder in the valley?

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

~~~
lawnchair_larry
_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.

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

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

~~~
singingfish
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/}

1;

~~~
colomon
Verbosity.

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

:)

~~~
dkoch
Perl 6 is / will be sweet :)

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

------
gdog
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-...](https://sites.google.com/site/steveyegge2/ancient-languages-
perl)

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.

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

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

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

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

~~~
chromatic
_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.

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

~~~
chromatic
_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_.)

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

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

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

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

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

------
juan_juarez
TL;DR - I know Perl.

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

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

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

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

~~~
singingfish
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";

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

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

