12 ms·
Perl tutorials suck (and cause serious damage)
- kokey 15y agoHe must be from the same tribe as my girlfriend, who also doesn't seem to capitalize her grammatical person 'i'. Perhaps they read the same grammar tutorial.
- Mithaldu 15y agoI'm from germany AND lazy. :)
- rcthompson 15y agoI was about to say that maybe the lowercase "i" was a sign of humility and selflessness, but never mind. (Just kidding, I'm sure you have generous helpings of both :)
- Mithaldu 15y agoHaha. Sometimes i do also think about this being a choice on that, but it's more a post hoc ergo propter hoc thing. The original reason is mostly that i rarely ever capitalize anything. :)
- va_coder 15y agoIsn't that the Perl culture? As someone who has seen a lot of Perl code, I'm serious.
- Mithaldu 15y agoI'd like to answer, but the question is a bit vague. What are you referring to with "that"?
- mgkimsal 15y agoI took "that" to mean "hard to read / cryptic code".
- Mithaldu 15y agoThat is by far not the norm for code written nowadays by CPAN authors who are aware of advances in the art. Have as an example the code in the very first module featured on frepan.org at the moment: https://metacpan.org/source/ALEXMV/Module-Refresh-0.17/lib/Module/Refresh.pm#L73 https://metacpan.org/source/ALEXMV/Module-Refresh-0.17/lib/M...
- w0utert 15y agoWell, that code starts out with the following procedure: ====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8 BEGIN { # Turn on the debugger's symbol source tracing $^P |= 0x10; # Work around bug in pre-5.8.7 perl where turning on $^P # causes caller() to be confused about eval {}'s in the stack. # (See http://rt.perl.org/rt3/Ticket/Display.html?id=35059 for more info.) eval 'sub DB::sub' if $] < 5.008007; } ====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8 As someone with a 2-digit number of years of experience in 4 different programming and casual experience with about 4 others, I couldn't for the life of me have figure out what that code does, if some hadn't commented it. The rest of the code looks a bit like PHP by the way, except uglier (not trying to flame here, just my opinion). Maybe some day someone will be able to explain why anyone in their right mind would voluntarily choose to program in Perl, if not because of prior experience with the language, or some form of religious beliefs. The 'look at the xyz CPAN modules!' argument doesn't really cut it for me.
- Mithaldu 15y agoLiterally the only hard part there are the magic variables, which one can look up easily as long as one knows that they're all listed under `perldoc perlvar`. (Though i'd like to mention that he should've used `use English;`.) Either way, my point still stands. I took an entirely random and fresh piece of code and aside from one tiny well-documented bit, all of it is easily readable and most importantly: Extremely different from the code example used in that study. The rest of your comment does not merit discussion because you've your prejudices and are content with them.
- mchanson 15y agoI think there are two very different sides to perl culture. About ten years ago I worked on a OO Perl project which was ~10k lines. It had coding standards, test suites, documentation, and was easy to maintain and bring new engineers into. The other side is hacked together scripts. Which have their place, but are often a mess.
- Mithaldu 15y agoActually, there is a name for both sides: There is the CPAN, which is obviously what it is; And there is the DarkPAN, a term describing all the internal projects in companies, or small tools hacked together by people who don't know or care about the CPAN.
- jpdoctor 15y ago> or small tools hacked together by people who don't know or care about the CPAN. In some parts, the latter is referred to as BedPAN.
- mmuro 15y agoThis isn't a problem with the tutorials. It's a problem with the freshness of those tutorials. If you are really worried about this, write a blog post (or several) that show people how to properly code Perl.
- Mithaldu 15y agoI tried to keep the title short and attention-grabbing. Note how one of my solutions basically say: "We need to write a perl clone of Python Tutorials." Also, more importantly, this task is so huge that a single person trying to solve it on their own is doomed. It needs to be a community thing.
- keithpeter 15y agoAgreed, but this is part of a much wider problem with the currency of pages that have a high search engine rank. Try searching for information about an obscure problem with (say) Linux. The pages found often relate to earlier versions of the OS and even in some cases 2.4.xx kernels. You have to know a bit to be able to filter the search for newer releases.
- pwaring 15y agoIt's not a tutorial as such, but the Modern Perl book is up to date: http://www.onyxneon.com/books/modern_perl/ http://www.onyxneon.com/books/modern_perl/ Unfortunately you can't create your own set of tutorials from it, and it doesn't rank highly in Google.
- Mithaldu 15y agoI'm aware of Modern Perl and recommend it for every novice, but as you mention, it is not a tutorial and thus doesn't have much to do with what the average newbie is looking for. It's also not readable on the web.
- snorkel 15y agoUnfortunately Perl coding culture includes a few deeply entrenched bad habits such as using horribly short variable names, overuse of the default variable, and using regex when a simpler string match would suffice. These subtle bad habits make typical perl code hard to follow and thus reflect badly on the language itself.
- hapless 15y agoThat's not really a current concern for the perl community. That was true 15 years ago. Lots of 15-year-old code is out there on the internet for folks to sneer at.
- sliverstorm 15y agoIn my opinion, the fact that 15-year-old code is floating about and still relevant should be something to appreciate.
- grout 15y agoFor some people, though, any use of the default variable is overuse. Nothing to be done about that whine.
- snorkel 15y agoIMHO it's OK to use $_ in small scope contexts, like in a tight loop, but very offensive when $_ refers to an operation that occurred three pages back.
- steve8918 15y agoI appreciate the author's honesty. To be perfectly honest myself, the last time I looked at Perl was about 4 years ago, and I despised the experience. I used it for about 10 months because the company I worked at had their entire infrastructure running on it, but it was the worst code I had ever seen, so I quit. If I remember correctly the code that broke the camel's back for me (pun intended) was: $a = $src[$src]; I've forgotten my Perl syntax so the syntax may be incorrect, but essentially what happened was that the original author had defined two different variables with the name "src", one being a scalar variable and the other being an array, and apparently those have two different namespaces. So when I looked at the perl tutorial that the author points out, it looked like regular perl to me. However, if the syntax of Perl has changed since 2007, then I'd be willing to give it a shot. Although I've recently started learning Python, and I'm enjoying it, except for the dynamic typing and the GIL... which is a rant for another time.
- waqf 15y agoPerl 6 changes this syntax to @src[$src], effectively admitting that the way sigils worked through Perl 5 was a failed experiment.
- steve-howard 15y agoYeah, the sigils indicate a sort of namespace (@ for array, $ for scalar, & for function), but that breaks down because when dereferencing an array, the @ becomes $. I have a fair amount of experience with Perl and I still had to read your explanation to remember how that could be valid. In the company I worked for that used Perl extensively, there were coding standards. In fact, you don't even need that, you just need to remind everyone that cleverness is not a goal in writing maintainable software, even if cleverness is what Perl's best at.
- skimbrel 15y agoThey weren't originally intended to provide namespacing, as far as I know. They were there to make the compiler's life easier. The reason that an array subscript is "$foo[0]" is because the $ sigil means "HEY COMPILER, the expression here is going to evaluate to some scalar". @foo is the entire list and the compiler treats it as a list type; $foo[0] is an element of the list and needs storage/behavior of a scalar. Same thing for hashes: %bar is the whole hash; $bar{quux} is an element and must be treated by the compiler as a scalar. The programmer must remember that square braces mean array subscript and curly braces mean hash lookup. So basically, this is a compiler optimization implemented by having the programmer provide hints to the compiler. It's overhead that probably isn't needed in the modern age, but we're effectively stuck with it. It wouldn't be so bad if they hadn't made the second (and IMO worse) decision: You can reuse symbols across contexts. The way this works is that the compiler maintains a symbol table where each symbol has a slot available for each of the types (scalar $, array @, hash %, subroutine &). This was originally the way to emulate pass-by-reference: you'd write a subroutine that assigned its arguments into typeglobs (* foo — think of it as a wildcard for all things named foo that behaves as a magic scalar with the contents of foo's symbol table entry) and then pulled them back out as the types it wanted: local(*foo) = @_; foreach $bar (@foo) { do_something($bar); } This amounts to telling the compiler "I want to alias the name foo in all contexts to my argument, and then go look at what's stored in the array at that name" and is a poor man's pass-by-reference. Perl 5 has a real reference system that completely obviates the need for this, except for the case of monkey-patching a subroutine, where you still say: local *Package::quux = sub { ... }" What's left is an unfortunate case where things like the GP mentioned ($bar = $foo[$foo]) are possible, and people who think they're being clever will do these things. Like the parent said, this is not a good thing to do.
- nickolai 15y agoIn this particular case it is also google's fault for turning up results of such dubious freshness( blekko for examople gives perl.org as first result - which looks better to me) So as weird as it sounds, Google shares the blame for the poor perl code being written.
- st0p 15y agoThe situation for PHP is just as bad, try googling for php mysql tutorial... The first five results are all using oldskool mysql_connect like back in the day. This is deprecated in php 5.4 and much better alternatives exist nowadays. Definitly a bad situation for any language IMHO.
- alttag 15y agoThis suggests a different alternative exists: re-branding Perl (or PHP) as Perl6 (or PHP5), and consistently using those terms within the community to distinguish the two. Make a point that it is a different language, enforce the usage (via style guide) in all public facing commentary. It will take time, but the community will start to change, and thus actually change what users are searching for. Think of HTML/CSS. One gets a more relevant set of results by searching HTML5, because there was a great deal of effort put into explaining how the language had changed. When looking for bleeding-edge features, a search for CSS3 is more helpful than a search on CSS (which like the perl situation, sometimes returns legacy garbage). The same applies when trying to troubleshoot a problem on OS X: adding 'lion' to the query often improves relevance of results. I short, make a conscious effort to create a new label and inject it into the public consciousness.
- danssig 15y agoOr you could, you know, do what other languages do and just move on to perl 6. It was meant to replace perl 5 after all. To be honest, as a outsider this whole movement of keeping perl 5 around forever after perl 6 is getting closer and closer to usable is one of the most bizarre, cultish things I've ever seen in the tech community (and that's saying a lot).
- Mithaldu 15y agoOh man, i should've seen this post before i answered to your other one. You're either a magnificent troll or are just commenting on things you have barely a passing knowledge of. Do you also wait for Perl 6 because it will make all Perl code 5 times faster like the recruiter at that Berlin company i visited?
- grout 15y agoPerl culture has largely moved from static pages to blogs and Twitter, and Google doesn't do well in that situation. Disclosure: I work for a competing search engine. But that's why I know.
- alex_c 15y agoDocumentation rot is one of the most annoying things when trying to learn a new technology, and the fault lies mostly with Google. "Definitive" sources sometimes instantly become obsolete when a new version of a technology is released - and sometimes they don't. Sometimes they very clearly indicate which version they apply to, often they don't - if you're new to a technology you're unlikely to be aware of the difference. The real problem is that "relevance" for technical resources has a very different meaning from "relevance" on the Internet at large, because the content pages and incoming links, by themselves, don't contain all the necessary information to judge whether a page is still relevant. As a result, Google is in some ways less and less useful as a programmer's tool - not because Google is getting worse, but because there are more and more layers of obsolete information out there.
- mcantor 15y ago> As a result, Google is in some ways less and less useful as a programmer's tool - not because Google is getting worse, but because there are more and more layers of obsolete information out there. This is bloody brilliant.
- ChuckMcM 15y agoIts got a name, information white out, and can occur for a number of reasons. The example I use is finding information on Steve Jobs from 2000 - 2005 is nearly impossible on Google because the first 50 - 100 results of the query 'Steve Jobs' is filled with eulogies and references to his death. But news worthy events are only one form of white out, historical weight is another (as the perl example shows). Disclaimer I work at blekko.com (a search engine) which allows you to specify things like /date=2005 in the search providing semantic intent. Searching through white-out situations is one of the uses of the slashtag system.
- majika 15y agoThanks for the disclaimer. Your post is propaganda. Finding information on Steve Jobs from 2000 - 2005 is actually pretty easy on Google. Search "steve jobs", then on the left-hand bar, click "custom range," and input 2000 to 2005. Done. I invite readers to actually try the blekko example to see how incapable it is. Searching with /date=2005 : (a) sorts the results by date, such that you the first few pages are full of irrelevant pages from Dec 31, 2005. And, (b) only returns results from 2005 (it's not clear how to search over a time range).
- billturner 15y agoI think Perl could use something like "Learn Perl The Hard Way." The foundation for the tutorial/book is already there: http://learncodethehardway.org/ http://learncodethehardway.org/
- prodigal_erik 15y ago> Another option would be to reach out to the maintainers of those sites and convince them to take down their sites or at the very least add links that prominently point to more modern content. Not only should advocating link rot as the preferred solution alarm any web user, but there are people out there who specifically need to learn Perl 4 to maintain or port crappy old systems (they might even outnumber people selecting Perl 6 or 5 for new projects), and we shouldn't throw their tutorials down the memory hole to make the language look more sane. Stick with a notice that better dialects are available, please.
- jleader 15y agoI seriously doubt there are more people maintaining code in Perl 4 than there are starting new projects in Perl 5 or Perl 6. Perl 5 replaced Perl 4 in 1993. I personally know of several companies using Perl 5 when they start new projects; I think my last exposure to Perl 4 in production was around 1995. On the larger subject, I agree, old documentation shouldn't be discarded, but should be clearly marked as referring to an older version. Of course, the horrible outdated examples the original article mentions have such disclaimers, but people still see their code as representative Perl code.
- jpr 15y agoNot to say anything about the language itself...
- gatlin 15y agoThere is a subset of Perl one can get a sense of by reading the Camel book in order which is sane, readable, and effective. If you read Wall's explanations and justifications you get a great mental model on top of which the "weird" stuff makes sense and feels even natural. Most criticisms I read focus on how dealing with legacy Perl is typically bad because it was written poorly. The thing is, I've read legacy PHP, legacy Python, and other "legacy" code that was just as terrible. The new Perl code I work with, though, written by my colleagues, is every bit as elegant and readable as code in any other language - provided thoughtful people are writing it. Perl has a bad rep but I have yet to see a single legitimate argument thrown at it which doesn't boil down to "I read some bad legacy code." I've been in the same boat, and believe me, I sympathize :)