7 ms·

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 p

• chromatic 17y ago
  > 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.)
  • Goladus 17y ago
    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.
    • berntb 17y ago
      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.
      • Goladus 17y ago
        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 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)
• zaphar 17y ago
  seriously? You have to know perl's control flow ("unless" 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 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.
  • Goladus 17y ago
    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. sub bottom_up_tree { my($depth) = @_; my @pool; push @pool, [undef, undef, -$_] foreach 0..2**$depth-1; foreach my $exponent (reverse(0..($depth-1))) { push @pool, [reverse(splice(@pool, 0, 2)), $_] foreach reverse(-(2**$exponent-1) .. 0); } return $pool[0]; }
• igouy 17y ago
  +1 for intelligent use of benchmarks game source code
• jrockway 17y ago
  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.