So perl is not hard to read because there's a book about best practices, and optional libraries that enforce coding styles?
I respectfully disagree. Reading perl requires understanding a significant amount of perl-specific trivia for any given block of code, that's why it is hard to read.
sub item_check {
my ($tree) = @_;
return $tree->[2] unless (defined $tree->[0]);
return $tree->[2] + item_check($tree->[0]) - item_check($tree->[1]);
}
Lua:
local function ItemCheck(tree)
if tree == 3 then
return tree[1] + ItemCheck(tree[2]) - ItemCheck(tree[3])
else
return tree[1]
end
end
These demonstrate the REALITY of what it's like reading perl code vs. other languages. Count the number of different symbols you must know in order to understand the perl code, versus the number of symbols you must know to understand the lua code. Anyone familiar with functions, variables, and standard control flow will be able to read the lua with no problem. If you look at other code snippets, like Javascript and C#, you'd amend the comment to say that anyone familiar with methods and object-oriented programming will be able to read the code with no problem.
With perl, you have to know perl. You have to know perl's control flow ("unless"), you have to know perl references(->), you have to know perl's parameter passing semantics and the meaning of @_, and you have to know perl's variable prefixes.
That's why perl is hard to read. That's why people who use perl all the time don't understand why it drives everyone else crazy. They have all that crap in their heads already. You never smell your own bad breath. Style guides don't fix this problem.
unless is that difficult to understand? Its plain english has totally understandable semantics without reading a lick of documentation about perl.
you have to know perl references(->)
This is just like C++ and an arrow is pretty dang readable and plain to me. Perhaps even more informative than a period.
you have to know perl's variable prefixes.
I might be convinced to give you this one but really reading the perl code isn't that difficult even with 3 extra symbols to know. Even not knowing the symbols the code example you show is both readable and concise.
Yes perl may have some quirks but for the most part it "Does exactly what you think it would by reading it". That was a design goal of the language after all.
Of course anyone could write perl code that is incomprehensible and makes use of perls semantics to obfuscate their purpose (using every example you cite) but that is with effort on their part and significant effort in some cases. And just to drive the point home may I present lua code that is way harder to read than any perl code I've ever seen even in an obfuscated perl contest: http://www.corsix.org/content/obfuscated-lua
To reiterate, no one in their right mind would right lua code like that except as an exercize and experiment. Same thing goes for perl. The perl code you show above is perfectly readable. Unless does exactly what you expect it to. -> arrows mean exactly what you would expect them to. Arrays start at 0 exactly like most programmers expect them to. and on top of that its readable. The only point you bring up that I think supports you argument is the @_ and argument passing semantics. But again that's only one and as another poster pointed out Lua has at least one also in it's array indexing.
I never said that code wasn't readable at all. But it's more complicated than the lua code and not as easy to read. I've never used Lua in my life but barely have to think about reading it. The questions I do have are keywords that are easy to search for in documentation. With the perl, I have to double-check and make sure there's nothing funny going on, and that is a VERY simple piece of code. If you look at another function in the same program (which I didn't use because the lua version is recursive which you could do in perl if you wanted), you'll see some non-obfuscated perl code that is a much better example of the pain of reading perl if you are not familiar with its idiosyncrasies. Not only do you have to trace through every step of each loop, you have to figure out what the double-asterisk syntax means and the bracket syntax.
I still think this example is a bad one. Again only one example you cite really qualifies as hard to understand, the double asterisk syntax. Otherwise the foreach loops both do exactly what they read like.
Even the .. syntax makes sense and does exactly what you would expect of that punctuation if you had to guess.
And it really was mostly random. I picked lua because I knew some people who used it, and was pretty sure it was a somewhat similar language to Perl in terms of problems its designed to solve, but that I'd never seen it before. I picked binary trees mostly because I was pretty sure both languages would have results for that test.
I wanted to see if it would be easier or harder to read the Lua vs. the Perl. It was easier for me to understand the Lua than the Perl, and I have attempted to explain that.
I don't care if you believe me or not. To anyone who doesn't already program in Perl full time: go to that site and pick random samples of code to read. Read through the various different solutions. Decide for yourself which language is most annoying to deal with.
For the record, here is the lua version of the same function.
local function BottomUpTree(item, depth)
if depth > 0 then
local i = item + item
depth = depth - 1
local left, right = BottomUpTree(i-1, depth), BottomUpTree(i, depth)
return { item, left, right }
else
return { item } -- Faster for LuaJIT: return { item, false }
end
end
You wrote the same old point -- the expressibility and some old ugliness make it a bit steeper learning curve for Perl. A troll favorite. You wrote that Perl was one of your two most experienced languages -- but obviously, you're a beginner not doing many hours development/month.
Everyone pointed out the standard answers -- this is a small cost in the beginning, learning libraries dwarf this, Perl is easy to use for people knowing C/sh/etc, there are plus/minus with expressibility, etc.
Then your second code example is on the wrong side of obfuscation with modifying an array while appending to it -- inside two tight loops!.
(Sure, this was some performance test and it was the language's worst case, or something, so it had been rewritten in an attempt to get better speed, but... still, I've seen saner things in obfuscation code.)
When this is pointed out, you just claim that it is an accident that you happened to pick this hairy recursive-to-iterative example...
I would have given you the benefit of the doubt, if this hadn't been a typical troll subject... But, no.
b) This was the third trolled Perl discussion I read on HN in a row. And trolled in the same boring way. Why would I want to waste more time on language wars?!
> Anyone familiar with functions and standard control flow will be able to read the lua with no problem.
Who cares? Why does that matter? Do you really hire or recruit people to work on your projects merely on the basis of reading code with no problem?
I care a lot more about being able to understand the problem domain and maintain the code than merely being able to read it by way of familiarity with an Algol-derived language with class-based OO support and dynamic typing.
> With perl, you have to know perl.
... just like every other programming language ever written. (Oops! Lua's array indices customarily start at one; good luck with those fencepost errors by people who can merely read the Lua code but don't know Lua.)
My main problem with Perl is references and contexts. Most of the experienced programmers I work with find themselves unable to write or debug code that requires the use of these Perl concepts.
For example, my co-workers and I find it easy and intuitive to work with lists in Python
xs = [5, 6]
xs.append(7)
print xs[2] # prints 7
xs.append([]) # easy to append lists to other lists
xs[3].append(6) # easy to append to the inner list
some_func(12, "hello", xs, True) # easy to pass to a function
In Perl this would be way more complicated for reasons that are obvious to someone who knows Perl well, but a mystery to people who use Perl casually.
$xs = [5, 6]; # must be a reference
push @$xs, 7 # deference $xs as a list
print "$xs->[2]\n" # still not too bad
push @$xs, [] # add a nested list reference
push @{$xs->[3]}, 6 # omgwtf?!
some_func(12, "hello", $xs, 1) # not too bad
Understanding "push @{$xs->[3]}, 6" is asking a lot just to deal with a nested list that you need to pass to a function, especially compared to the easily understandable "xs[3].append(6)". For that matter, it's asking a lot to make you understand the difference between a list and a list reference. It's asking a lot to ask to understand the concept of "evaluating in a ___ context", especially when other languages manage to do the same things without these concepts.
Does it need to be more complicated, or are you perhaps trying to make the code look like Python? While there are good reasons for using references to pass lists to functions, it seems clearer (and more Perl-ish) to do the transformations on a list rather than a reference:
my @xs = (5, 6); # use a list directly
push @xs, 7;
print $xs[2];
push @xs, [];
push @{$xs[3]}, 6; # treat $xs[3] as array
some_func(12, "hello", \@xs, 1);
While one could probably argue that pushing to the inner array is clearer in Python, the rest seems just as clear. And if one was writing for an audience not comfortable with references, one could always use a temp variable for clarity:
my @inner;
push @xs, \@inner;
push @inner, 8;
For that matter, you could do the same for your 'omgwtf' line:
my $inner = $xs->[3];
push @$inner, 9;
While there's nothing wrong with the Python, they strike me as pretty comparable in clarity.
That's a wonderful thing about Perl, but we're talking about readability here. To read Perl code in practice (written by people other than yourself), you need to know an extraordinary number of Perlisms. This is the curse of TMTOWTDI.
not really extraordinary, unless you only know one language!
most programmers know half a dozen languages, and another half-dozen technologies and tools
Plus the fun is in the details ;) I love languages with depth in them!
Maybe the first time you see it, for at most two minutes once in your entire life.
I kind of wonder if the people who freak out about this syntax stuff have ever studied a foreign language. Do they scream and run out of the room every time they hit an alien grammar construct?
> Maybe the first time you see it, for at most two minutes once in your entire life.
To the contrary, the main problem I've seen and experienced with Perl is that it's very hard to look up syntax. If I had no idea what that code was doing, I would be hard-pressed to Google for "@{$xs->[3]}". I've seen co-workers lose hours to debugging because they think that they find themselves in situations where an X is being evaluated in a Y context, or where they need to dereference a nested something but don't realize that this is what they need to do, etc.
I'm not saying that Perl is unusable because of these things. I'm merely saying that these problems do not exist in other languages, by and large, with the possible exception of C++. They don't run into these sorts of problems when they use Python, which people can just kind of pick up and start using without requiring a deep understanding of the language. (I love "Why I Dislike C++ for Large Projects" for an example of why this is true for C++: http://www.mistybeach.com/articles/WhyIDontLikeCPlusPlusForL... )
I hope I don't come off as a Perl-hater. Although I'm mostly a Pythonista, sometimes there's a Perl module in CPAN to do something that I can't find a library for in Python. This community is probably Perl's greatest strength, which is argued quite eloquently in the OP. Similarly, I often use C++ when I need to write something that runs really fast and/or needs to interface with a low-level library. Both languages can definitely be useful even when other languages are available.
My criticism is simply that Perl (and C++) requires a much deeper understanding of the language to use effectively than most other languages. I have co-workers who have used Perl as a scripting language for years, but who have very little understanding of what references or contexts even are. This often bites them and they lose hours of time trying to figure out why they can't seem to pass a list of hashes to a function, or something. (Similar things often happen with C++.) And this doesn't happen with languages like Python, which make it much easier to write programs without deep knowledge of the language.
It still slows you down if you don't use it all the time. Unless you're someone who has been programming in perl every day for years at a time, then that line is most assuredly not something that takes 2 seconds to learn and you'll remember forever. Seeing something like that while you are reading code means you have to STOP what you were reading, patiently sort it out the syntax and refer to the documentation to be sure you haven't made any mistaken assumptions, and THEN move on. Even if that only takes a couple of minutes, it adds to the frustration level of reading code. And the point is that it is perl-specific. It doesn't happen with most other code that I have to read.
I rarely write "push @$ref" expressions, but they don't slow me when I see them. It is blindingly obvious to me what is happening here. I have never read a manual entry that specifically documents this situation, either... it just makes sense from what I know about push and what I know about references.
(Yes, you need to learn Perl to know Perl. Please let me know what programming language you don't need to learn to use.)
Please let me know what programming language you don't need to learn to use.
I have frequently been able to debug or explain unexpected behavior in programs written in languages I had never used before. Javascript, C#, Python, windows shell scripts, PHP, ASP, Emacs Lisp, and Visual Basic 6.0.
Common Lisp, C, and bash are the only languages I had to really "learn" before I could read code. Perl is the only language I feel like I have to re-learn every single time I have to read it.
It's core to the language; very common usage. Context overloading is very core to the language. I don't know what kind of programming you could do that wouldn't involved references used in this way.
If you want to talk about the rough edges, I can do that. I actually know and use Perl. But when people who clearly have not invested much time with the language try to criticize it's always idiotic. I mean, let's talk about the 'each' operator or the archaic format stuff. The basic syntax of the language is fine; you just don't know it.
As I wrote in another place, the main problem with Perl is the trolls, like Godalus seems to be.
All that garbage has really lessened any interest in Python and Ruby for me. I really don't want to join communities which have so many members doing so large amounts of hype, language wars and trolling.
All that garbage has really lessened any interest in Python and Ruby for me. I really don't want to join communities which have so many members doing so large amounts of hype, language wars and trolling.
So true.
Perl people are not immune to this, though; I have seen a lot of snipes at Haskell and Common Lisp in various Perl forums. People see a threat to their way of life, and do everything possible to maintain the status quo.
(The "complaints" are always about the same sorts of things, too. Perl sucks because it has sigils, Haskell sucks because I don't know what a functor is, and Common Lisp sucks because you can't get into the first element of a list and drive it. These are rarely problems with the languages, and more typically problems with the commenter.)
It is funny, because Perl has been around longer than Python and Ruby, and Common Lisp (in some form) has been around longer than Perl. If the designers of Python and Ruby had done their job, there wouldn't even need to be a debate, we would all be using whichever one was newest.
I care a lot more about being able to understand the problem domain and maintain the code than merely being able to read it by way of familiarity with an Algol-derived language with class-based OO support and dynamic typing.
Surely being able to read the code makes it easy to maintain: the reason you might use perl is for existing libraries/support and the level of abstraction available.
Language design has a direct impact in maintainability.
> Surely being able to read the code makes it easy to maintain....
I've never written code intended for complete novices to maintain. I don't care if people who have never programmed in the language before can maintain code written in the language without learning the language. I think that's an effective way to ruin your code and your project and any long-term plans you have around the project.
I care deeply about maintainability and learnability, but I care not one whit if someone who's never programmed in Perl can look at real-world Perl code and suss out exactly what it does and why based on... guesswork? Intuition? Experience with languages that are not Perl?
In design there is a trade-off of complexity vs. usability. Perl does a good job at giving programmers access to a lot of complex features by using clever/borrowed metaphors and idioms. The complexity still remains. This means when writing systems above a certain size perl is not a good choice precisely because it takes time to parse.
I like perl, but maintainability has more aspects than just following community conventions.
I don't know where you got the dislike of Algol: I cannot see the resemblance of algol and lua. Algol is in perl's ancestry (via the bourne shell) though.
> This means when writing systems above a certain size perl is not a good choice precisely because it takes time to parse.
> I like perl, but maintainability has more aspects than just following community conventions.
I think you contradict yourself.
In my experience, maintainability has a lot more to do with naming conventions, the use of abstractions, the use of metaphor to understand and express concepts of the problem domain, testability and coverage, repetition, the use of language and library idioms, consistency of expression, unit boundaries, and encapsulation of code and concept than language syntax.
> I don't know where you got the dislike of Algol....
I don't dislike Algol, but I believe that there's a strong tendency in certain circles to believe that Algol-family syntax is so obviously right (or pervasive) that jumping between languages in that family is simple.
Let me summarize as I'm beginning to think that Perl is a member of your family:
- You don't write code for novices
- You don't think language design has an impact on overall maintainability of the code, maintainability is all about the abstractions and naming conversions of the programmer.
- You would insist that any code you wrote should be maintained by a professional programmer.
- Readability of an algorithm has nothing to do with maintainability, if you name everything right the reader is a fool if he doesn't get it.
> You don't think language design has an impact on overall maintainability of the code....
Also not what I wrote.
> maintainability is all about....
Still not what I wrote.
> You would insist that any code you wrote should be maintained by a professional programmer.
That's a lot closer to what I wrote, but it's subtly wrong.
> Readability of an algorithm has nothing to do with maintainability....
That's nowhere near what I wrote.
> if you name everything right the reader is a fool if he doesn't get it.
I've never written anything, anywhere, suggesting that idea.
Please do give me some credit for having coherent thoughts based on practical experience writing widely used programs. The nuance in my parent posts wasn't particularly subtle.
Half a dozen comments here (and lots in every other discussion on the subject) notes that you better learn the language before you talk about readability. (Perl has more syntax to learn -- the extra work is dwarfed by the libraries in every modern language. But you better follow the "Best Practices", for Perl.)
Goladus might not be a troll, but according to his own statements he doesn't write enough Perl to really know it. He just sprouts lots of opinions on things he don't know.
Edit: A few words for clarity.
Edit I might also note that Goladus' second code example did a complex algorithm without comments in a way that could be classed obfuscated.
Trolls don't normally make good points. In a way you illustrate the point being made:
but according to his own statements he doesn't write enough Perl to really know it. He just sprouts lots of opinions on things he don't know
From the point of view of a professional programmer as simpler language like Lua takes hours to learn. What you loose is the power of expression, however for a novice one doesn't perhaps want this power. For example if I were writing a platform for photographers, I wouldn't choose a perl as an extension language: it depends on the audience.
Don't get me wrong I've written perl in commercial environments since 1994, and privately before that. Goladus makes a good point.
First, Godalus implied that he knew what he was talking about regarding Perl, until it was pointed out that he didn't. Then he changed story.
Edit: I might also add that Godalus' second code example modified an array inside an append to the array -- inside two tight loops... I've only seen things like that in obfuscations. (It could be extreme optimization -- but with a few earlier versions in comments or cvs/subversion/git/etc.) Tell me THAT code choice is not trolling...?
Edit: Removed the rest, which has been written by multiple people in this thread.
Ask the guy who made the slides debunking the "myth".
This is not about hiring or recruiting people. This is simply about language readability.
I have been using perl longer than any other major language except C, and I still have to review basic syntax crap every time I have to read perl code.
... just like every other programming language ever written.
Not true. Perl requires significantly more language-specific trivia than most other languages, and for marginal benefit. Differentiation between scalar, list, and hash is not especially useful most of the time. It doesn't significantly help readability (or writability) and makes the code more complicated.
A nonstandard default array index is one piece of trivia. In fact, it can be deduced from the example I gave, and if you aren't sure you can check. I highlighted several in that one perl example.
I have been using perl longer than any other major language except C, and I still have to review basic syntax crap every time I have to read perl code.
I have been using Perl longer than any other major langauge, and I never have to review "basic syntax crap". Not to make a personal attack, but perhaps the problem is not Perl.
First, the name is "Perl" -- "perl" is the executable. If you have written so much Perl, you should know this.
>>I highlighted several in that one tiny perl example.
You can highlight lots of examples by choosing how to write the code. The Perl code could be very similar to the Lua.
But, yeah... the linguistic inspirations gives more syntactic ways to write things. That is not only bad, but (as TFA said), you better follow the "Best Practices" book.
All that is anyway dwarfed by the language specific libraries you use, as soon as you do something interesting.
Personally, I think the worst part of Perl is all the painful trolling you have to suffer on the discussion web sites...
>>A nonstandard default array index is one piece of trivia.
Hmm... that would in fact be really weird. I have lots of habitual loops over indexes etc which I'd have to change, lots of edge cases. It would be like driving a car where you turn the wheel left to turn right -- but only on Mondays.
Sorry that you don't like the "trolling". At worst, I am venting, though I am trying to make a point.
The reality is that I am annoyed at having to deal with perl (actually am using DBI.pm; written by the guy who created the original slideshow) and am annoyed to read him "BUSTING!" a Perl readability myth without even understanding why Perl is hard to read in the first place.
You could have written the Perl code very similar to the Lua.
No, in fact, you can't. You can't use parameter lists in perl. You can't use variables without context.
And even where you can, this particular example which I just pulled up completely randomly wasn't written like lua. Which is what life is like when you are surrounded by perl code and are not a perl expert. Here's real code I was annoyed to have to read:
Double-colon, hyphen-arrow, equals-arrow, variables with context specifiers, curly braces, and parentheses all for a simple library call. Curly braces normally mean a block of code, but here it means we're defining a hash. Double-colon and the dereferencing symbol mean different things, but I don't really have to care about that, it's just visually distracting. With python syntax it might look like this:
Note that in Python, curly braces are the standard way of defining a dictionary literal and are not used for anything else, as one can determine by searching for '{' in Python's context-free grammar: http://www.python.org/doc/2.5.2/ref/grammar.txt.
To determine that those curly braces in the perl example defined a hash, you have to root around in the docs looking for curly braces until you stumble on something that discusses hashes rather than code blocks.
All that is anyway dwarfed by the language specific libraries you use, as soon as you do something interesting.
I would agree that by the time you are neck-deep in a gigantic perl project then all that trivia will come second-nature. I have never done a gigantic project in perl. I have read lots of code various languages, though. Perl and C are the only ones where the language itself gets in the way, and C is really not that bad. (C++ is so bad that I'm not claiming to have ever successfully understood C++ code for a significant program)
>>without even understanding why Perl is hard to read in the first place.
You are talking about Bunce there.. he is smart (and pedagogically talented) enough to know what he is talking about, more than amateurs like us. :-)
>> Which is what life is like when you are surrounded by perl code and are not a perl expert.
Hmmm... you wrote "using perl longer than any other major language except C"? At the end, you wrote that you mostly read code... you're not really a full time programmer, but browse code for different languages?
Again -- you're out of luck with most "real" environments, since you need the libraries.
TCL is really optimized to be trivially easy...
>> You can't use parameter lists in perl. You can't use variables without context.
There are misfeatures in all languages. Without checking, you can find solutions for most every Perl problem on CPAN.
If you go there, check Moose. Also check Enlightened Perl/Modern Perl on the web.
If you are only going to read without writing, then you will probably not start enjoying Perl. If you use it for real, it is fun and has a really good community.
Most of '::', '->' etc exist in other languages. I already discussed that.
For another example, Python's ability to keep {} for one thing really kneecaps the possibility to do one-liners with the same syntax... :-)
No offense, but your "tree == 3" is hard to read. Most people assume == means "equal to", and containers cannot be equal to the integer 3.
I can guess that you mean the length, but if that's the case, why don't you write "length(tree) == 3"? If we are just going to guess to understand, then we have the same problem with Lua that we have with Perl. With Perl, you can guess that $array->[number] is an array lookup, that the $ in "$foo" is essentially meaningless, and so on.
In other words, Lua and Perl are both hard to read.
As someone recently getting into using Perl, the Guidelines and Tools Slide (#36) was amazingly useful. Its got a whole list of things I've wanted, but didn't think to go out and look for yet. (Primarily tools/books on writing good perl or testing it).
The debunking of the myth of unreadability omitted something of concern to me: How much Perl code "in the wild" uses those best practices?
I have no doubt that Perl can be written in a disciplined and reasonable manner, readable to people familiar with its idioms, and not especially bug-prone. I cringe every time I come across Perl code because I've never actually come across any real Perl that's written that way. Or maybe I have, but I've always gotten discouraged with the language before mastering enough of the syntax to master the idioms, so I can't really tell.
This is not a problem with Python. It's easy to learn to read Python, and I have yet to come across really bad Python in practice. Good coding seems to flow easily from the way the language is made.
> How much Perl code "in the wild" uses those best practices?
Not enough.
Consider this, though: how much Perl code "in the wild" is the result of programming novices who learned just enough Perl to do a job without actually having to learn how to program or how to write Perl code well or how to write maintainable code?
I suspect that it's far more than you might think.
If that's true, then the complaint is that Perl is too easy to write.
If you know python and ruby, learn something that I will actually improve/change your programming: Scheme, ML, Prolog, Smalltalk, Common Lisp, Haskell, Mozart/Oz, or Forth.
Python and Ruby are not that different, and neither is that different from Perl.
I'll differ from berntb - you should learn Perl exactly because it's fairly similar to those languages you already know, and the effort required to do so will be minimal.
You may not end up using it all that frequently, but an hour or two seeing how another programming language does something is usually interesting perspective, imo.
IMHO, the best part with Perl is the community (CPAN is a result of that) -- and the worst part is the relentless trolling on web sites like this...
Since Ruby/Python/Perl are really similar, I'd recommend that you learn something completely different instead.
Disclaimer: I like Perl. What makes Perl fun for me is to a large part that the linguistics influence results in Perl breaking most "normal" laws for programming language design, but still works. I go to work smiling.
I don't think it's a lingusitics thing, rather, Perl was not designed to be limited like other popular languages were. Larry never sat down and said, "I am the only person that is possibly smart enough to understand this concept, so I am not going to add it to the language". (Java and PHP's designers did. Look what that got them...)
I respectfully disagree. Reading perl requires understanding a significant amount of perl-specific trivia for any given block of code, that's why it is hard to read.
http://shootout.alioth.debian.org/ Binary trees problem.
Perl:
Lua: These demonstrate the REALITY of what it's like reading perl code vs. other languages. Count the number of different symbols you must know in order to understand the perl code, versus the number of symbols you must know to understand the lua code. Anyone familiar with functions, variables, and standard control flow will be able to read the lua with no problem. If you look at other code snippets, like Javascript and C#, you'd amend the comment to say that anyone familiar with methods and object-oriented programming will be able to read the code with no problem.With perl, you have to know perl. You have to know perl's control flow ("unless"), you have to know perl references(->), you have to know perl's parameter passing semantics and the meaning of @_, and you have to know perl's variable prefixes.
That's why perl is hard to read. That's why people who use perl all the time don't understand why it drives everyone else crazy. They have all that crap in their heads already. You never smell your own bad breath. Style guides don't fix this problem.