In defense of Perl.(blog.directededge.com)
blog.directededge.com
In defense of Perl.
http://blog.directededge.com/2008/08/03/in-defense-of-perl/
12 comments
I was comparing Ruby on Rails to Python with Django in that context; I looked at them when I was evaluating web frameworks, though obviously I deviated away from that in the rest of the post. Sorry if that was unclear.
I initially looked at Ruby a number of years ago, and didn't really care for the syntax either. Rails made me take a second look, and while I'm not sure I consider it a thing of beauty, it is eminently practical, and a pretty good compromise between Perl's minimalist style that lets you get lots done - and then forget what the heck it does, and Java's blah blah blah verbosity. Also, Ruby gems are handy - maybe not quite to the level of CPAN, but they're pretty good.
I don't know Rails at all but I'll go out on a limb suggest Perl's Catalyst is probably just as good.
Prefacing a one-liner like this with "I don't know Rails..." is just begging to be downmodded, but damn... -3? This is a rough crowd.
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 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.
Very thin limb you're sitting on. Very thin.
As a one time ultra-heavy Perl programmer, when I returned to programming this year after a hiatus of several years, Ruby just made the most sense to me, and you do a good job of listing why.
I still use Perl occasionally, but essentially for *Nix sys-admin stuff.
I still use Perl occasionally, but essentially for *Nix sys-admin stuff.
I love Perl, but its essential problem at this point is that it's lost momentum. After over 7 years of waiting for Perl 6, a huge gulf has developed between the people who can influence language development and new users. In this time, other language communities have taken great steps to attract new users, and in many cases they've been pulling in more former Perl hackers than converted Java/C++/etc folks. In web apps, Rails and Django are king for a reason; they're excellent libraries that are well-documented and easy to choose because of broad support in the language's community. Perl's Catalyst is workable (I've used it) but is tricky to install and configure, has inferior docs, and a thinner set of libraries. And it isn't what all your friends are doing.
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.
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 think your assertion of community decline is baseless. It probably hasn't grown as have others, but it's not in decline. It's also a fairly nice and quiet place to get things done without a riot of newbie noise.
This isn't really true. Ever read Perlmonks? There are tons of newbies. The IRC channels are the same way.
Perl was never the "default choice" for web apps on its merit as a language tho'. At the time (I was there) on a typical large institutional or corporate Unix box you had C/C++/FORTRAN compilers for the engineers to use and Perl installed by the sysadmins for their own use, and that was pretty much it for languages. Getting a whole new language installed for a project that wasn't even "official" was a non-starter. The path of least resistance was to use Perl for CGIs. If Unix sysadmins had been into REXX instead, then that would have been the default choice. Now that most Unixes ship with several scripting languages installed already, people are free(r) to choose. Perl was simply in the right place at the right time.
Yes, these days, people are free to choose. However, after trying the alternatives, I think Perl is still a winner.
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.
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.
The awkward handling of references is exactly why I stopped using Perl. The way they worked never clicked with me and caused me to spend too much time fighting the language. I'm much happier with Python/Ruby.
I love Perl, but its essential problem at this point is that it's lost momentum.
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.
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.
Interesting points. It could well be my professional frame of reference that's shifting. Maybe a historical analysis of job listings would give a less biased take?
I have a similar history. I wrote my first web app in 96, in C on SunOS. Since then I've worked on all different types of platforms and at last count had used 13 different programming languages in that period.
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.
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.
Most people talking about Perl are quick to groan about its ugliness. I’ll first note, most of them don’t know Perl...
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.
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.
Most folks who say Perl is ugly are talking about one of two things (or both): Sigils or Regular Expressions.
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).
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).
The ugliest parts of Perl (in my admittedly not-exceptionally-well-informed opinion) are dereferencing variables and automatic list flattening.
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 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 agree that this approach is deranged. It all stems from the decision to distinguish between values and references. That decision comes from the available hardware and typical programming background at the time of Perl 5's development (early 90s). At that time computers weren't abundantly fast for most programming goals, and storing all variables as references (or objects) was a pretty serious "extreme OO" position. Plus, anyone who called himself a hacker would have to be competent with pointers in C, and Perl references were substantially easier than that. So Perl layered on ways to reference and dereference values, and @{$array->[1]{"foo"}} was born.
storing all variables as references (or objects) was a pretty serious "extreme OO" position
But LISP had been doing it that way for decades before Perl came along, and I'm sure it wasn't the only one.
But LISP had been doing it that way for decades before Perl came along, and I'm sure it wasn't the only one.
When Perl references start making as much sense as C pointers it will be a considerable improvement.
You really believe that? I simply can't believe anyone would find working with complex data structures in C easier than in Perl. It just doesn't make sense, but obviously a few people agree with you. Have you actually worked in Perl (and C)?
C pointers make sense to me because they represent what's going on in the machine. The syntax and the rules behind it are simple enough that they click, for me.
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.
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.
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.
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.
It handles lists that way because of the braindead idea of sigils which, in order to be semantically consistent, cannot have as an element of a list being a list.
I'd like to see you back that up. $a[0][0] does exactly what it looks like it should do: it takes the first element of the list at $a[0]. (Incidentally, this is exactly the same as the gp's $a[0]->[0].) The only problem sigils introduce is the -> in expressions like $a->[0]. ($a is a reference to a list, and you can't write $a[0] in this case because it will look at the list @a.)
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'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.
It's historic. In The Beginning...Perl was a different language, a simpler language built to take the place of awk/sed/grep/shell in one mostly consistent package, and when it later obtained complex data structures, they were implemented on top of the existing semantics, which involved arrays and hashes that could only store scalars.
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.
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.
It has nothing to do with sigils. It has to do with the legacy of arrays and hashes only storing scalars in ancient Perl.
Perl 6 does not flatten by default. (And, obviously, sigils remain a core part of the language.
Perl 6 does not flatten by default. (And, obviously, sigils remain a core part of the language.
Short answer: Don't write $a->[0]->[0]->[0]->[0]->[0], write $a->[0][0][0][0][0]. It does the same thing.
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.
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.
> Most folks who say Perl is ugly are talking about one of two things (or both): Sigils or Regular Expressions.
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.
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.
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.
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.
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.
They are not that expensive.
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.
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.
> 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
Because Python has both, and so much data is already split on common delimiters, and having a fast way to handle them is awesome?
Because Python has both, and so much data is already split on common delimiters, and having a fast way to handle them is awesome?
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.
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.
If there's there are string methods in Perl, great - I'll check this out next time I'm working on some Perl.
Unfortunately - and this is a cultural problem more than a technical one - nobody ever seems to use them, instead favoring RegExs for everything.
Unfortunately - and this is a cultural problem more than a technical one - nobody ever seems to use them, instead favoring RegExs for everything.
> If you can do with one regex what would require 10 "fast" string manipulations, then the regex will nearly always be faster.
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.
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.
You're not the beholder. You're the author.
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.
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.
>> You're not the beholder. You're the author.
>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.
>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.
Most folks who say Perl is ugly are talking about one of two things (or both): Sigils or Regular Expressions.
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 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.
Ah, yes, I suppose if Tcl is the pinnacle of beauty, then Perl would represent ugliness.
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.
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.
I agree that Perl's CPAN is probably the most awesome thing invented since slice bread. If you want to hack together something really quick, like PHP, Perl is awesome.
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.
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.
I think alot of major frameworks written in other languages have all if not most of the features Rails has. Django, Pylons, CakePHP, CodeIgniter, Catalyst, and Mason are to name a few.
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.
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.
That's it, we're all just victims of some catchy jingle.
In a manner of speaking yes, just take a look at the massive spike in mindshare Rails has garnered since it's release. Let's take into consideration the passive influence it also has on framework developers as well.
Nearly every mainstream framework we know has at least been influence by RoR.
Nearly every mainstream framework we know has at least been influence by RoR.
True, but that's not because people can't get the annoying ideas out of their head, it's because of the legitimate innovation that Rails brought into the mainstream.
The Cake is a lie!
But the beauty of Ruby on Rails is abstraction. <list of features>
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.
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.
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.
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.
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.
It looks like a lot of people are missing the point of the original article, so I wrote a long-winded reply here:
http://blog.jrock.us/articles/You%20are%20missing%20the%20po...
http://blog.jrock.us/articles/You%20are%20missing%20the%20po...
In defense of <insert religion here>. A programming language is a tool and some tools are better than others. There's no need to defend them.
Well, it depends on why it's being attacked. My feeling is that Perl is an under-appreciated tool because it's not cool to like Perl. In the post I don't really try to defend Perl's actual flaws, which are many, but to point out to an audience that presumably mostly doesn't know Perl, that it can be really useful for some sorts of tasks.
Any given language is under appreciated by that subset of programmers that mistakes their own ignorance for the language's shortcomings.
I feel Perl is under appreciated because too many people have inherited badly written Perl code, and thought that languages needed to enforce readability.
Or wondered why blocks of code needed to be delimited once for humans via indentation, and once for a parser via curly brackets.
Or wondered why blocks of code needed to be delimited once for humans via indentation, and once for a parser via curly brackets.
Does Perl run on Vista? That would be an implosion of uncoolness :)
Are you suggesting religions don't need to be defended?
I’m a Perl developer and a big fan of Lisp. However, it should be well known by now that Common Lisp is the only dynamic language that beats C in performance. It also defeats Python and Ruby in productivity and joy. And the code is beautiful and clear to read. It used to be that there weren’t any good routes to using Lisp for the web, and it didn’t used to be fast either, but now both of those obstacles have been overcome. Ruby is unstable and keeps changing, making previous code unusable. Anyway Ruby is just a lame hack impersonation of a Lisp. Everyone should skip the trends and use Lisp. If for whatever reason Lisp is not an option, Perl is the alternative that’s been around a long time and is going to keep growing. It has CPAN. End of story!
Obligatory xkcd comic: http://xkcd.com/224/
> I’m also not advocating doing large projects in Perl.
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. :)
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. :)
"Fast hacks, fast, quickly." From my perspective and style of working, I would call this a temptation, not an advantage. ;-)
The thing I hate most is all the special global variables you can set that effect the behavior of various functions.
These are indeed bad, and nobody uses these features anymore. (They are important to have around for library authors, but you will probably never need them in "user code".)
Sometimes it's acceptable to use them in a very small scope:
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 => '';This is why I stopped using Perl. I think this
entire_file = open('file').read()
The only reason why you find the Perl hard to read is because you don't know Perl. I find Spanish hard to read. Why? Because I don't know the language. That doesn't mean that there's anything wrong with Spanish as a language, though, it just means I don't know it.
Two points:
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.
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.
Don't give up on languages because of cosmetics... find a better reason!
Think this is probably easiest to understand....
Think this is probably easiest to understand....
my $entire_file = slurp 'file';"and nobody uses these features anymore"
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.
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.
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.