Hacker News Reader

Comment by chromatic | Hacker News Reader

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

View on HN

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.

In Perl this would be way more complicated

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.

The point of his example was to show why reference syntax is a pain. "# Use a list directly" is not what happens in a lot of code that I have to read.

you can use any of the Perl OO systems and replace

    push @$xs, 7;

with

    $xs->append(7);

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!

> push @{$xs->[3]}, 6 # omgwtf?!

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.

> if you don't use it all the time

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.

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.

Berntb. Please email me, goladus@goladus.com, if you would like to discuss my credibility. Otherwise please stop with the baseless character attacks.

The reference stuff is natural to old C programmers, if they think a bit. It is ugly, but will just take some work hours to learn.

All that is dwarfed by learning the language specific libraries, no matter which language you use.

And by the way, use strict/warnings, so you aren't bitten by a spelling error for variable names. :-)

Edit: BTW 2, how do you do one-liners in Python? :-)

Do you really hire or recruit people to work on your projects merely on the basis of reading code with no problem?

No, but everyone we hire must first pass through that stage. To become a Perl expert one must first spend quite some time as a Perl beginner.

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.

All I can do is wish you luck.

> You don't write code for novices....

That's not what I wrote.

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

End-users of open-source applications are not "maintainers" but still value readable code.

If your software works so well and is so well documented that end-users never have to look at the code then there is no problem.

I wouldn't recommend writing code to be readable by complete novices, but code that requires less obscure knowledge to read is more valuable.

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.

Who cares? Why does that matter?

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:

    ABC::Myclass->find_or_create({thing => $thing->itm, otherthing => $x->itm});

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:

    ABC.Myclass.find_or_create(dict(thing=thing.itm, otherthing=x.itm))

If you don't remember what dict() does you can look it up. Alternately:

    ABC.Myclass.find_or_create({'thing' : thing.itm, 'otherthing': x.itm})

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)

No, in fact, you can't. You can't use parameter lists in perl. You can't use variables without context.

This statement is meaningless. I have no idea what you're talking about.

Try this:

  function( args => 'go here' )

And anyway, what exactly is the difference between your JavaScript (Lua? Python?) example and your Perl example?

    ABC::Myclass->find_or_create({thing => $thing->itm, otherthing => $x->itm});

    ABC.Myclass.find_or_create({'thing' : thing.itm, 'otherthing': x.itm})

Other than "Myclass" being a field of ABC in your example, I don't see any difference at all.

Your argument really makes no sense. I suggest you just say "I hate Perl" and stop trying to justify it.

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

It's not an uncommon problem for really smart people to have mistaken assumptions about what makes things hard.

I'll expand on that.

As you yourself has noted, you don't write enough to really know the language. Tim Bunce talks about what goes for real users of the language.

Also, he is quite central in the community and certainly knows more about problems with education and teaching than either of us.

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

Reply on news.ycombinator.com