In defense of Perl.
blog.directededge.com
blog.directededge.com
The fact that you called it "Ruby on Rails" does not inspire confidence. Rails is a complex Ruby framework, and a lot of Rails code actually consists of calls to a Ruby-based DSL for the Web. It's hard to appreciate the kinship between Ruby and Perl, or Ruby's usefulness for Perl-like tasks, when you approach the language from that high-level angle. Try Programming Ruby or The Ruby Way -- or, heck, try _Why's Poignant Guide to Ruby with Cartoon Foxes, which is how I learned, though its unique style is not for everyone.
Ruby was built by a Perl fan; it was named in honor of Perl, and I find that most of the glue-code tasks that were easy in Perl are even easier in Ruby.
I will certainly use Perl in the future -- one good thing about the language's awesome documentation culture, and its excellent automated build tools, is that they let you use Perl code without having to read any of it. But I don't read or write Perl anymore unless I really have to -- just as, back in 1999, I didn't use sed or awk and avoided writing shell scripts, because I had Perl.
I only have cursory experience with Rails and Catalyst, but the first thing I noticed is that Rails is much friendlier to Ruby novices than Catalyst is to Perl novices. Still, Catalyst is pretty nice if you're a Perl developer looking for a Rails-like framework.
I still use Perl occasionally, but essentially for *Nix sys-admin stuff.
It might be narrowminded to blame Perl 6's schedule slippage (and the general shakeup in Perl leadership and Larry Wall's struggle with cancer) for the broader community decline. But there was a time when, say in web apps, Perl was the default choice. That default started to change when some smart hackers wrote some terrific libraries in Ruby and Python, and broad segments of the hacker world started to agree on roughly what features they expected in a web framework. I'm not sure why those hackers didn't choose Perl, but if I had to pick exactly one thing, it would be Perl's awkward handling of references, a skill that might have been easily picked up by C hackers but seems exceedingly arcane to those reared on Java.
I spent some time (maybe 6 months) with Python recently. The first few weeks you're amazed at how uniform and regular everything is. It's so simple! But then after you've gotten used to Python, it starts to wear on you that there's no shortcuts for things that you do n times / day. And it's not just that Perl saves you typing, it's that Perl doesn't annoy experienced programmers by making them do every single thing the uniform (and longer) way over and over.
Another thing is naming. There are various clumsily-named things in Python. For example, "dictionary"? It's a hash. "Tuple"? I don't blame Guido, because I don't believe he's a native speaker of the rat's nest we call the English language, but it almost appears that some things are named different from the Perl-equivalents just to be different. Anyway, what you find after having used both Python and Perl is that Perl really does have that smooth well-worn "I use this every day and it fits like a glove" feel, and a lot of that has to do with well-chosen names for things, and operators that look like what they do.
No, that's just false. In the last year, we've gotten a new major release of Perl, with many, many new features. (See the perl510delta man page for details.) On the CPAN, we've seen 1000s of new libraries released. We have a new object system, called Moose, which is probably one of the best object systems of any language. The Perl conferences have been seeing record attendance.
Basically, Perl is stronger than ever. We just spend our time programming instead of talking about ourselves incessantly, declaring other languages dead, winning awards for being 'the most attractive hacker', or covering up security holes.
I recently went through a re-eval of what tech I wanted to be working with and ended up with Python. I tried to return to Perl but couldn't do it. Mainly it is because I'm back working on web projects and Perl's web frameworks aren't so nice. People worship CPAN, but I've never found it any more useful than SF or Googe Code. That is to say, useful yes, but amazing or worthy of awe? Not hardly.
I will say though that Perl was pretty much the only language that made me smile and I eagerly await Perl 6.
OK, I'll bite. I know Perl. Perl is versatile. Perl is powerful. But Perl is Ugly with a capital 'u'. Give me Python or Ruby any day.
Regular Expressions have turned out to be so useful that they've been slurped into every modern language (and using the Perl interpretation of regex to boot), so it's pretty much a null statement to say that Perl is ugly because of regular expressions...because it means every language is ugly. This is usually what people mean when they call Perl executable line noise...but is it really the fault of Perl that folks write regexes that are longer and more complex than is readable? Perl just happens to be a culture that is steeped in UNIX history, and sometimes we reach for a regex before other more readable tools...it's a failing of the developer, rather than the language. I find regexes in Python quite ugly, myself, since they're in the ghetto of a library rather than a first class part of the language. In Perl, you can take a reference to a regex, or turn it into an object, and of course, you can use regexes extremely concisely and in one-liners and quick throwaway scripts. I consider this a worthwhile tradeoff.
Sigils, on the other hand, are core to the language and Perl uses them more heavily than almost any other modern language (PHP and Ruby both use them to some degree, but nowhere near the degree of Perl), so if it's not the sort of thing you like, then Perl is not the sort of thing you'll like. This one, at least is a point of real difference.
I don't find sigils particularly offensive or particularly nice; I'm pretty much indifferent to them. Though I am happy to know that the inconstant sigils of Perl 5 are going away in Perl 6, as they've been a source of confusion for me on many an occasion (though less so when I'm working with Perl a lot--I haven't written a bug in weeks due to that particular quirk, and I don't think I've ever written one that the compiler didn't catch immediately). References are also problematic, and will also be made prettier in Perl 6 (in particular, function references are automagic when it is apparent that's what you want to happen).
My first dynamic language (if I don't count tinkering with ARexx on my Amiga when I was a kid...and I don't) was Perl, and I worked with it for several years. Then I went to work in a Python shop, luckily with some of the best Python developers in the world working on some of the most interesting Python code going (if you use Python, you use some code written by several of the folks I was working with), and I really enjoyed working in Python and found it "cleaner" than the Perl I was accustomed to.
After a few years with Python, I found myself working with Perl again...and I set myself the task of learning it a bit more systematically then I had the first time around. Turns out, Perl is a quite pretty language...and I like it better than Python. Both are very fine languages, but Perl suits me better. I was merely judging some extremely nice Python written by masters of the language vs. random snippets of Perl found on the Internet, and unsurprisingly Perl fared poorly in the comparison.
Ruby, on the other hand...I might actually find it prettier than Perl--it has a lot of the things I love about Perl, and very few of its rough edges. Though I'm not fond of the seeming standard usage of "end" for blocks. You guys know you don't have to use those, right? I mean, it's not Pascal. You can use curly braces, and it'll work just fine...and bouncing on % works. I'm also not fond of the occasional verbosity of Ruby that seems to be a function of its "everything is an object" philosophy.
Anyway, beauty is in the eye of the beholder...and conciseness is one of my primary "beautiful" qualities. And, if Perl is anything, it is concise (at least, it can be, and for almost any task).
I honestly don't know what kind of crazy design process could possibly lead to the way Perl handles nested lists. $a[0]->[0]? @{$a[0]}?
Why? God?
I'm not entirely sure why perl doesn't have good support for nested arrays and hashes, but I'm pretty sure it's not to do with sigils.
I don't think anyone thinks list-flattening is a good idea, these days. And, of course, Perl 6 gets better handling of complex data structures...if I recall correctly, it gets an explicit "slurpy" sigil that provides the flattening behavior, but I don't actually work in Perl 6 yet, so I'm not sure of that.
Perl 6 does not flatten by default. (And, obviously, sigils remain a core part of the language.
Long answer: As for writing code, however, you don't need to write $a->[0]->[0]->[0]->[0]->[0]. After the first dereference (if any), you can omit the '->'s because arrays and hashes only store scalars so perl knows you're talking about a reference. You can use all the arrows for backwards compatibility.
Perl references seem to carry a lot of historical baggage that leads to the expressions mentioned elsewhere in this thread. The rules behind them always seemed arbitrary and I have never felt like I had a grip on them.
Now that said, I'm still more likely to blow my foot off with C than with Perl, thanks to the do-it-yourself memory management. But at least when it happens it's for the right reasons.
You're my hero, and I mean that.
I'm glad we cleared that up, and I'll readily agree that complex data structures via references is among the most glaring warts in Perl. It's obviously more complicated and error-prone than it ought to be, and moreso than other similar languages.
I've got this theory that the thing that people talk about most in any language or technology is the thing that is actually most broken about the language. People talk a lot about references in Perl, and I know they're broken by design. Similarly, I've got my suspicions about monads in Haskell, since people spend so much time trying to explain them...seems like there must be some fire under all that smoke. But I could be just imagining it, and I think I probably need to spend a lot more time with Haskell before I can accurately detect bogosities.
But LISP had been doing it that way for decades before Perl came along, and I'm sure it wasn't the only one.
Regular expressions are expensive. I find a lot - actuially, most - of the things I'd do with RegExs in Perl can be replaced with string methods in Python.
Additionally, it's also common for Perl users to use RegExs to do things like modify markup languages, which is extremely fragile - use a tree data structure and paths. Python has even has element trees built it in recent versions.
> Anyway, beauty is in the eye of the beholder...and conciseness is one of my primary "beautiful" qualities.
You're not the beholder. You're the author. Is your work so limited it has no purpose after you leave ? Code should be written for the people who have to maintain it.
Your beholders value simple code rather you selfishly saving a few keystrokes.
They are not that expensive. In perl, you pay for executing opcodes. If you can do with one regex what would require 10 "fast" string manipulations, then the regex will nearly always be faster.
I imagine Python is similar; there is bookkeeping to be done every time you call a core string function. If you can condense the operation into one call into the core, then you save yourself the bookkeeping overhead.
Additionally, it's also common for Perl users to use RegExs to do things like modify markup languages, which is extremely fragile - use a tree data structure and paths. Python has even has element trees built it in recent versions.
This has nothing to do with Perl. You can write bad code and use bad techniques in any language. I'll bet a Google Code Search will reveal tons of hand-built parsers written in Python. Most people don't know there is a better way to solve a problem, so they use whatever they think of first.
Code should be written for the people who have to maintain it.
When you write code, expect that you will be the primary maintainer forever. You will spend more time reading your own code than anyone else will, so optimize it for yourself.
Your beholders value simple code rather you selfishly saving a few keystrokes.
If you can't read Perl, perhaps it's because you don't know Perl. I can't read Python. Why? Because I never bothered to learn it. Does that make it intrinsically "unreadable" or "unmaintainable"? No; it just means I am dumb. Don't blame the language for your own ignorance.
And even if they were remarkably more expensive, I'd still take "has an awesome implementation of regexes" over "does not have an acceptable implementation of regexes, but does have a few limited string processing methods that are fast". Luckily for Pythonistas, Python does have a reasonable regex implementation (pretty much the same as Perl in most regards, though not as nice to use), so it's not a problem.
But, I'm baffled that someone would suggest that a language is better because you can use more limited tools that might be marginally faster than extremely powerful and flexible tools. And, I'm also a little concerned that the previous post seems unaware of Perls other string processing tools...regexes are not the only tool in the toolbox. Perl is a monster for text processing. Regexes are the teeth...but there are also claws and horns and a pointy tail. I think Perl 6 also has laser eyes and breathes fire, but that might just be a rumor.
Because Python has both, and so much data is already split on common delimiters, and having a fast way to handle them is awesome?
I know, and I said so. But, so does Perl (one of several "fast ways" of processing text in Perl is to use regexes, but it's not the only way). That's why I'm confused that you seem to think you're making differentiating statements about the two languages. That's all.
I happen to like Python, I just don't think it makes sense to present Python as a better text processing language than Perl...when, by most measures, including performance, it probably is not.
Unfortunately - and this is a cultural problem more than a technical one - nobody ever seems to use them, instead favoring RegExs for everything.
Agreed, but most of the time I only need one string manipulation, and from what I can tell, the code behind split and endswith etc. are faster than using RegExs in the same place. Recently I've had to convert something back to Python 1.5, which lacks string methods, but has regex's, and it's noticeably slower. >>It's also common for Perl users to use RegExs to do things like modify markup languages, which is extremely fragile - use a tree data structure and paths >This has nothing to do with Perl. It has something to do with Perl - Perl lacked these data types in the mid 90s Perl boom. So people who learnt Perl then see no problem with using what's always 'worked for them'. I agree it's nothing to do with the language as it stands now.
> When you write code, expect that you will be the primary maintainer forever.
Would you hire someone that said that to work on your startup?
>> Your beholders value simple code rather you selfishly saving a few keystrokes.
> If you can't read Perl, perhaps it's because you don't know Perl.
That's a troll. I can fix a problem with a blank editor and Perl, and I can read and debug most people's Perl. Not being able to understand someone's sloppily indented bracket abortion-code isn't because I don't 'know' the language.
Actually, that's mostly not true. I work on a 450,000 codebase, and I wrote almost none of it. I read far more Perl than I write, as with any language used in a project that isn't a throwaway.
Your beholders value simple code rather you selfishly saving a few keystrokes.
You've got it backwards. I'm selfishly thinking of myself when I read it, not when I write it. I'm selfishly looking to save time while I read by having more functionality in the same amount of lines of code--a map or a join, for example, is far more concise than explicitly iterating over a data structure and operating on it. You may not prefer to read the single line map or join version over the multiline block of code in a loop, but I certainly do.
>Actually, that's mostly not true. I work on a 450,000 codebase, and I wrote almost none of it. I read far more Perl than I write, as with any language used in a project that isn't a throwaway.
Er, you've just proved it true. Other people wrote that code, hopefully to make it easier to maintain by those who come after them.
Like you say, code is read more often than it's written.
I think it is ugly because of its haphazard attitude to default behaviors. Sure the default is usually what you want, but if it isn't, there's no way to derive what you do want from principles, you just have to know it. The Perl documentation is littered with references to "magic" and so on. Whereas with (just for an example) Tcl, once you know the very basic principles, everything else can be determined logically from there.
I've found only a few gotchas that really get me in Perl. Mostly its DWIM (Do What I Mean) philosophy really does what I mean. References, as I mentioned, are a source of trouble for me, but almost nothing else in Perl is.
But the beauty of Ruby on Rails is abstraction. It takes a while getting used to the code and the framework, but that time invested is paid off in productivity. Ruby on Rails is really on a whole new playing field. Complete object orientation, a fully developed framework to deploy and TEST with a single command in the terminal, MVC, it is just ... heavnly. To be honest, any language can build the Rails framework. Ruby isn't necessarily too unique in that sense. What does make it unique is having an evangelical preacher for its framework, David "oh so sexy" Hansson, and a kind and awesome community.
You should give it another shot, if you're a web developer, it'll make your life a million times easier.
Rails to make your life easier? well that's true if your creating web apps that fit into RoR's philosophy. To quote a member of HN "Coloring outside the lines is not allowed".
I do agree with you on one thing though, I believe the massive boost in Ruby's popularity is the great marketing campaign behind it.
Nearly every mainstream framework we know has at least been influence by RoR.
Every language has this stuff. Nobody writes CGI.pm-style web apps anymore; that died in the early 2000s.
You should give it another shot, if you're a web developer, it'll make your life a million times easier.
This is incorrect. Ruby has a major problem right now; module authors have no respect for each other... they will happily modify core functions (and other classes) when you load them. This is not fun to debug. Ruby is still very new, and it's still getting over the mistakes all languages go through. Back in the day, people did this with Perl, but eventually the community learned that monkey patching (etc.) was unacceptable, and most modules don't do it anymore. Eventually Ruby will be as mature as Perl... but why wait... Ruby and Perl have an interchangeable featureset.
Just to give the other side, while metaprogramming can be dangerous, in 3+ years I've rarely had unexpected behavior because of rogue monkeypatching. Not to say that it can't happen, but that in reality, it isn't a major problem.
http://blog.jrock.us/articles/You%20are%20missing%20the%20po...
Or wondered why blocks of code needed to be delimited once for humans via indentation, and once for a parser via curly brackets.
Actually, you can nowadays. With Perl 5, use strict, use warnings, use Moose, write tests, and have a look at modern Perl best practices.
And, of course, Perl 6 should be quite well-equipped for handling large projects right out of the box, ... once that box gets here. :)
Sometimes it's acceptable to use them in a very small scope:
my $entire_file = do { local $/; <$filehandle> };
my $entire_file = readline $filehandle, -line_separator => ''; entire_file = open('file').read()
1) He said - "you can comprehend it without knowing the language" and you responded with "well, of course you can't read it - you don't know it!". The argument is specifically about being able to read a language without knowing what % ! and $ stand for.
2) Equating a programming language to a human language as if proficiency or deficiency in the first implies something about the second is really a bad idea. Human languages evolve naturally without a designer who can make a language less or more readable. For a programming language, there is always a designer, and readability by a person "unskilled in the art" is a major category by which the language is judged.
Think this is probably easiest to understand....
my $entire_file = slurp 'file';Right. maybe you should come tell that to all of the Perl lovers I have to work with who use them semi frequently.
I used to do only C and didn't like using lesser "scripting" languages then I forced myself to learn Perl and Python in parallel. Now I actually like Python and use it a lot. Yet I still loath Perl more than I originally thought I did. People need to face the facts Perl is a disaster of a language and you don't need to know much about Perl to know that.