This article isn't terribly interesting, really. Yes, you can write clean, understandable code in Perl and most widely used languages. Yes, you can write awful code in any language. The real test of messiness, ugliness, readability and comprehensibility is in the cases in the middle. How easy is it to write readable code? How hard is it to write bad code? And this one might be a little controversial, but how does the culture around the language value readable, clean code?
Put another way, when I'm actually working on a project in the language, what's the likelihood that someone who I'm working with or who worked on the project before me has really messed up the code base in ways I'm going to be dealing with for years? And how hard am I going to have to work to not be that guy?
Finally, the article uses an example of parsing LaTeX with Perl vs. Python, and uses a regular expression. Now, I don't know if LaTeX can, in general, be parsed with regular expressions, but writing a parser aside, it's no surprise that Perl wins when dealing with regular expressions. That's a fine thing, and definitely something Perl's got going for it (or possibly against it, depending on how you feel about regular expressions), but Perl just about grew out of being a regexp DSL -- it's not really a fair fight. Put a full Perl TeX parser up against one written in Prolog, and I bet Prolog would win, but it doesn't mean I'd use Prolog over Perl for most things.
>>when I'm actually working on a project in the language, what's the likelihood that someone who I'm working with or who worked on the project before me has really messed up the code base
Well, the quality of Perl code is very diverse, since a lot of system administrators are mangling the language... :-)
Perl's general community seems to be very good (newbies went with PHP for quite a while). You can arguably see the CPAN as a result of that. (It is common to say -- "Perl is irrelevant, the killer app is CPAN!".)
Another advantage is that Perl doesn't have so many embarrassing fanboys as certain other environments...
(I believe the hype level regarding the scripting languages comes from them being so similar that they compete for the same niche.)
Since Moose seems to standardize a solution to the OO syntax ugliness, the main Perl problem is IMHO the parameter passing to functions/methods. There are advantages and disadvantages to most everything.
Edit: Small syntax/word choices. Removed ":-)" on comment that other environments have too many fanboys, language wars are such a time waste.
Perl still sucks, and I wrote Perl5 code for years. It's more about the inconsistency in the way the language is implemented. Having to explicitly scope variables, the disaster than is OOP, the riddling of special cases and context-sensitivity, by-ref vs. by-val, etc etc etc. Having to memorize all of these various cases sucks. The only upside to Perl is the CPAN. Other than that, there's no reason to waste your time when there are fantastic languages like Python and Ruby out there.
Steve Yegge says it best:
"Within about 3 days, I was more comfortable with Ruby than seven years had made me with Perl. I was still accidentally sticking "my" in front of variable declarations, typing "sub" instead of "def", little things like that. But I was already starting to think in Ruby, and suddenly I had all this extra space in my brain. You have to learn Perl by memorizing, but you learn Ruby by understanding."
Perl is pretty big language and build of not very orthogonal parts. I've read somewhere an interview with Larry Wall where he said he was not planning to make the language very clean and orthogonal from the start - but instead he wanted to watch the way people use the language and then cut off the unused parts (the actual analogy was with building pavements along the paths that people made in the grass instead of planning up front how they are going to commute). I think that cut off phase never came. After some 10 years of programming in Perl, there are still areas that I don't know really well - I just don't use them, and when reading other peoples code I still sometimes need to lookup something. I can see why this can be annoying. But eventually the size of the libraries that you need to memorize when programming is still much bigger than the language itself, so it does not matter that much.
My prediction is that other languages will not build their CPAN equivalents soon. It looks so easy to copy, especially if you believe you have a better language, but what people don't see is the complex network of things that enable CPAN existence. It's not just code repository it is a complex ecosystem.
Whenever I have to use Perl, I get to a point when I want a nested data structure. Then I remember that I have to use a completely different syntax to do so, and my head explodes. Who thought explicit and non-automatic references were a good idea?
Nowadays I use Ruby if I have a choice: most of the best bits of Perl, less of the worst bits. The language actually feels like it was designed, rather than accreted over time.
Perhaps Perl 6 will be better, but I'm guessing scripts and apps written in Perl 5 will be around for a long, long while yet.
This was a very refreshing read. I used to write Perl at my last job, and a little bit where I am now. The language serves a noble purpose, parsing data, and it does that extremely well and in a very understandable manner. When others step into the land of Perl, it can be a little daunting, but once you work out the difference between @ # and $ it all gets a little more clear. Thanks for this!
I have been programming perl and php for many years now - I don't agree with rbranson here. Its not that perl is the best tool , if it solves your problem use it , otherwise please stop whinging about it. If you really feel so strongly about the issue, you are welcome to fix it.
Every half-baked, low-quality, ill-designed language has defenders somewhere on the web.
Why is this news?
In my professional career I've used C, C++, Perl, and Ruby.
I come with no preexisting biases.
...but after having written several programs in Perl until they became unmaintainable (despite my good coding style), and then rewritten them in Ruby in something like 1/10th to 1/20th the lines... I've got no particular interest in spending time reading about how Perl is wonderful.
I've been there.
I gathered my own data.
See Paul's thoughts on blub programmers and blub languages.
> ...but after having written several programs in Perl until they became unmaintainable (despite my good coding style), and then rewritten them in Ruby in something like 1/10th to 1/20th the lines... I've got no particular interest in spending time reading about how Perl is wonderful.
I agree with another poster. I'd love to see the data that you gathered.
I've worked fairly extensively with both Perl and Ruby, and I have a hard time imagining anything which is 10-20x shorter in Ruby than in Perl. I also have to question the maintainability assertion. Ruby and Perl are similar enough that I'm pretty sure I can take a "maintainable" program in either one and port it to the other with minimal changes and no noticable change in maintainability.
> Ruby and Perl are similar enough that I'm pretty sure I can take a "maintainable" program in either one and port it to the other with minimal changes
Without intending to flame, I can't imagine that you'd say this if you've used some of the more powerful techniques in Ruby.
If you've used techniques X,Y, and Z in Perl, you can find them in Ruby. ... but unless you think in a Lisp-like way, you won't even realize that techniques G' and E''' exist in Ruby, but not in Perl.
Some content would be nice, rather than the implication that I'm just an ignorant blub-er.
So, once again, how about some of that data you say you collected to back up what you're saying? Which "more powerful techniques" are you talking about?
First I am not completely buying the "rewritten them in Ruby in something like 1/10th to 1/20th the lines". But I will give you the benefit of doubt since I don't know ruby.
I do know Perl thought, and I also know few other languages, including say Groovy.
And while there certain tasks which can be expressed in Groovy better, there are also others who are better expressed in Perl! And I think it would be the same for Ruby!
Ultimately, Perl, Groovy and Ruby all fall under the same category and are more or less the same type of things!
Perl is still a very good choice for code creation and software developed because: 1) It has very competitive feature set 2) Huge library set 3) The best community 4) It is still evolving
I am sure we can almost do a s/Perl/Ruby on this post and it would still make sense.
People who are defending Perl do so, because they want it to grow, and as Perl grow they grow with it. If you have ever been passionate about anything, you should understand where the people who defend Perl come from!
I've got an admin interface to an ecommerce website. The admin screen gives access to all sorts of entities: series of videos, individual videos, copies of DVDs, customers, wiki pages, etc.
Let's say that there are 40 different types of entities.
I could write custom views for each of these.
Or, using Ruby's reflection, I had them all share common views which then use reflection to figure out the basic data and the relationships between data types.
E.g.:
<% reflections = item.class.reflections.select {|key, val| [ :has_one, :has_many, :belongs_to, :has_and_belongs_to_many ].include?(val.macro) }.to_array
reflections.each do |key,val|
if ! reject.include?(key)
%>
<h1> <%= key.to_s %></h1>
<% bullet_pts = item.send(key).to_array
if bullet_pts.empty?
%>
<span style="padding-left:25px;"><i>none</i></span>
<% else %>
<ul>
<% bullet_pts.sort_by {|x| x.methods.include?(:name) ? x.name : 0}.each do |subitem| %>
<li><%= linktext = subitem.respond_to?(:name) ? subitem.name : (subitem.respond_to?(:text) ? subitem.text : subitem.id )
# TJICFIX P3: this is an ugly way to specify a link. do it better!
link_to(linktext, :controller => subitem.class.to_s.pluralize.underscore, :action=>:show, :id =>subitem.id) + "<br>" %>
<% end %>
</ul>
<%
end # if "none" else "lots!"
end # if ... reject
end # reflections.each
%>
With the above as a partial, and one other that's similar, a full view for a very very complicated object becomes this:
I'm reworking this approach for a new project right now. The new code goes beyond "index" and "show" views to "edit" and "create" views. Also, because most of the controllers are pretty similar, except for business logic, I'm also about to start compressing those down with metaprogramming (except for callbacks, which will vary).
In this particular codebase, I think that the expansion to rewrite it in Perl would be much more than 20x. Maybe more like 100x ... or 200x.
Given a framework like Moose (entirely fair, since you've dragged Rails into the discussion), I'm not seeing anything yet that can't be done with Perl. I sort of get the feeling you haven't used Perl in a while and aren't familiar with any of the modern object frameworks.
Perl is very influenced by the Unix command line. I can remember years ago (when other mini computer operating systems around and everyone was mad on pascal) my college lecturers disdain for the design C and Unix.
If the same thing happens again terseness, power and flexibility win against ridged ideas of how programs/command-lines should be written.
Perl exploded with the web, however before the web it was widely used. It might not be the web programming language of choice but it it's still great at manipulating information, processing large files and general administration.
I consider shell script programming archaic, yet I still see it as a job requirement for UNIX SA jobs. Once I learned Perl I never had the urge to write another bourne shell or ksh script ever again. I still need to read and debug them from time to time though.
It's painful to watch Unix SAs who don't understand shell scripts (which are, after all, a way of automating repetitive command-line tasks), because it is such an essential part of understanding the OS and how it works.
I think it is important to know when to use a quick shell script, and when to solve the problem with some Perl (or even some C.) Sometimes it is quicker to throw together a shell script, with a bit of sed, awk, or some simple for loops, automating the command line you just manually ran a moment ago; sometimes it's best to solve the problem by switching to some Perl.
Put another way, when I'm actually working on a project in the language, what's the likelihood that someone who I'm working with or who worked on the project before me has really messed up the code base in ways I'm going to be dealing with for years? And how hard am I going to have to work to not be that guy?
Finally, the article uses an example of parsing LaTeX with Perl vs. Python, and uses a regular expression. Now, I don't know if LaTeX can, in general, be parsed with regular expressions, but writing a parser aside, it's no surprise that Perl wins when dealing with regular expressions. That's a fine thing, and definitely something Perl's got going for it (or possibly against it, depending on how you feel about regular expressions), but Perl just about grew out of being a regexp DSL -- it's not really a fair fight. Put a full Perl TeX parser up against one written in Prolog, and I bet Prolog would win, but it doesn't mean I'd use Prolog over Perl for most things.