5 ms·
> 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
by 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 agoWho 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 agoFirst, 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 agoSorry 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)
- berntb 17y ago>>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... :-)
- jrockway 17y agoI 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.
- EliAndrewC 17y agoMy 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.
- berntb 17y agoThe 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? :-)
- kingkongrevenge 17y ago> 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?
- Goladus 17y ago
- acg 17y agoI 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.
- berntb 17y agoHalf 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.
- acg 17y agoTrolls 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.
- berntb 17y agoFirst, 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.
- mechanical_fish 17y agoDo 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.