4 ms·

Full disclosure: I'm the guy who made http://perl-tutorial.org http://perl-tutorial.org a few years ago because the top google result for "perl tutorial" was a

Full disclosure: I'm the guy who made http://perl-tutorial.org http://perl-tutorial.org a few years ago because the top google result for "perl tutorial" was a perl 4 tutorial. I have looked at many tutorials and have a vested interest in getting quality tutorials in people's hands to avoid them writing shitty perl. That said, this tutorial is terrible on a number of points, since it teaches outdated things that have long been known to be dangerous and are only kept around for the sake of backwards compatibility. Reading it is wholly a waste of your time, unless you already know perl like the back of your hand and wish to get enraged; or have the masochistic desire to learn perl in a manner that will punish both yourself and others for your mistake of reading this tutorial. If you truly wish to learn about Perl in a whirlwind tour, read either the very short free book Modern Perl [1] or any other short tutorial linked on the site i mentioned first. If you're the author of this tutorial, i applaud you for the effort, but wish you'd have spoken to any part of the community before publishing. If you feel like it, #perl-help on irc.perl.org is a great place to start. And if you meant this as a troll, 10/10, would rage anytime. [1] http://onyxneon.com/books/modern_perl/ http://onyxneon.com/books/modern_perl/

killertypo 13y ago
as a fellow perl'er (but not knowing it like the back of my hand) and having to learn through hardship and failure and obscenely old tutorials, what key pionts here can you point out that are absolute no-no's and should be avoided?
- Mithaldu 13y ago
  * very first program simply does not work * lack of strict * lack of warnings * lack of my * bareword filehandles * mentions &-calling of subs * thinks it's the same as normal calling * snowflake formatting style * mentions EXTREMELY outdated books as further reading * confuses capitalization of builtins in code examples * fails to explain compile phase semantics properly, instead introduces "use" as magical * quotes hash keys * explains prototypes as something that could be used in general * explains post-fix dereference syntax, but describes cumbersome circumfix syntaxes as default * 2-arg open instead of 3-arg open I'm halfway down, i can't be arsed anymore. I feel like i'm reading the Leeds Perl 4 tutorial all over again.
  - killertypo 13y ago
    what's funny, i saw the lack of strict and thought...hrmm, well without that we'll see what happens here.
  - mattmight 13y ago
    > very first program simply does not work Guilty. Facepalm. Embarassed. Fixed. > lack of strict Not in scope (it's not a tutorial on good Perl), but I'll mention it. > lack of warnings Added a general disclaimer in the abstract. > lack of my I documented `my` in the subsection on scoping disciplines. I _tried_ not to use features before I'd introduced them. And, for most of the "probes," `my` wasn't necessary. > bareword filehandles Good point. Added scalar filehandles, as well as how to pass bare words with typeglobs. Changed most examples to scalar filehandles too. In doing so, I stumbled across the implicit method invocation form that happens when the first argument to a procedure is an object, so I added an example of that too. This is exactly the kind of "semantic surprise" that led me to start digging. > mentions &-calling of subs Of course. It's possible, and it can change the semantics of procedure call. > thinks it's the same as normal calling I had documented the differences. Look carefully: The procedure call example includes an error case. In the parameter passing subsection, I had included a mention of how `&proc` (no args), receives current @_. > snowflake formatting style Yep. Definitely not a style guide. > mentions EXTREMELY outdated books as further reading I added a link to Modern Perl (as suggested). And, the new edition of Mastering Perl came out last week. It flipped through it, and it seemed updated. > confuses capitalization of builtins in code examples Bug. Fixed. > fails to explain compile phase semantics properly, instead introduces "use" as magical Guilty. I thought about including this in the first revision, but I was nearing exhaustion. I'll add it later. > quotes hash keys It's legal. > explains prototypes as something that could be used in general I just explain what they are. They're a part of the language, and they have important consequences for both parsing and interpretation. > explains post-fix dereference syntax, but describes cumbersome circumfix syntaxes as default I don't endorse either syntax as default. > 2-arg open instead of 3-arg open I'm not trying to document the library, or teach good use, but I added an example for 3-arg. Thanks for your feedback!
- VLM 13y ago
  Trying to do OO stuff without the mighty MOOSE? Whoa, retro, man. MOOSE came out about a decade ago. Awesome OO implementation, no point using any other technique. He's calling "open" in a way thats been a no-no since like Clinton was prez, or at least a long time ago. You can debate making filehandles plain ole variables or not. The cool kids do it a different way than he does, which is not necessarily wrong. Backticks are looked at about the same way... so how exactly do you handle stdout/stderr separately with backticks, oh you don't, um... There's another, better way to safely call system stuff. Also he seems to be missing all error detection / correction / recovery code in general, both in every example and as a general topic. The Perl Cookbook was awesome... in 2003. The reference book you need is "Modern Perl" by chromatic, edited by Shane Warden, etc. CPAN gets one mention at the end. Thats wrong. The first thing you do when writing Perl is see whats out there to glue together. Also this is a fun way to learn stuff, rather than boring basic arithmetic or boring toy examples you can sling XML all over creation using a parser, or all kinds of crazy stuff. Life's just a lot more fun with CPAN. From a style perspective if Perl::Critic and/or perltidy disagree with you, and if you're a noob, you're doin' it wrong. I know when its acceptable to disagree with Perl::Critic but a noob will not, noob should trust Perl::Critic. Perltidy is a little bit more flexible, Perl isn't whitespace controlled but if you get really weird no one is going to understand your code. So pipe it all thru perltidy, in vi its "(esc):%! perltidy". Perltidy is also an interesting, although very forceful, way to find mismatched quotes and the like.
sea6ear 13y ago
I posted this article. I believe that the author, Matt Might is a professor specializing in programming language theory at the University of Utah. My understanding of this article was that it was less of a tutorial and more of an analysis of the actual semantics of Perl. Thus it is less about how one should write "Modern Perl" than it is about how Perl actually behaves in various circumstances.
- Mithaldu 13y ago
  If it's not a tutorial then i don't understand why he explains EXTREMELY basic things in the worst possible way, fails to actually explain the interesting details of subtle and complex things (like the differences between the ways a sub can be called (no, they do NOT all do the same thing)), and managed to produce a document that looks like it contains literally ALL the things from ALL the bad tutorials i've seen in the past 9 years, with nothing from any of the good ones.
  - mst 13y ago
    Actually, he does appear to explain &foo() later on, he just doesn't bother mentioning up front that it's completely different. I think if you consider it as an academic piece, where you're supposed to read all of it and then think, it wouldn't be a bad introduction to perl as it was written in 2003.
    - tredontho 13y ago
      Okay, I've read a few of Might's posts, and they're pretty interesting. But it irks me for some reason that nowhere in the posts can I find a date. Am I missing something? Where did you grab this 2003?
      - mst 13y ago
        From the code. Were I to paranthesise the sentence, "perl as it was written in 2003" would be one clause.
  - 13y ago
mattmight 13y ago
Article author here. To be clear, this is not a tutorial on writing good, idiomatic Perl. (And, I've strengthened the article's disclaimers to that emphasize that.) It's a semantic excavation of Perl. My goal was to understand how the Perl interpreter thinks, and to answer language design questions like: How are parameters passed--by value, by alias, by name, by reference, by need? How are variables scoped--lexically, dynamically, globally? What is the effect of @ in a prototype? For the .. operator, how is the implicit toggle scoped--at the procedure or the nearest enclosing block? How do prototypes influence context, and how do contexts influence evaluation? That is, I wanted to understand what was possible. The possible is entirely separate from the good. As a formal semanticist, I was continually surprised by how Perl behaved. As someone that has had to occasionally debug other people's Perl, I believe there is value in understanding the syntactic and semantic quirks in the language. Thanks for your comments. I'll be updating the article with your feedback.
- Mithaldu 13y ago
  In that case it would be nice if you actually restricted yourself to posing questions, answering them with experimental code and output, then discussing the result; as opposed to explaining the basics of scalars or posting patently false things like this: > For example, the following statement prints to the console: > > print Hello, world! ; # prints Hello, world! Pretty much half of that article should be deleted, and if the rest was discussion of interesting behaviors in a scientifical manner, that would actually be interesting.
- VLM 13y ago
  I can dig it. By analogy something like "If you insist on installing deck screws with a hammer instead of a screwdriver, this is what happens with a sledgehammer, this is what happens with a large heavy rock, this is what happens if you use your fist..." It is interesting, rather than terrifying, when seen in that light. However, Google is going to google, thats its thing, so some victim in the future might think this is the one true answer to using objects in perl, which is not cool.
- Fasebook 13y ago
  I haven't read the article completely, but I've enjoyed what I've read so far. I'd like to follow along in more detail with a perl interpreter. I'd love to see an entire book that completely tears down the entire interrupter from the perspective of within. I purchased Ruby Under a Microscope, but I was kind of put off by the similar issues other commentators are having, that it appears to be a basic introduction to how to write Ruby, but that is just how the task has to be approached (based off your existing assumptions and test to see if they hold up). But when the task is complete, you have knowledge on a better way to write Ruby, by accounting for all the exceptions that you can't "see" in the source code, due to leaky abstractions.
voltagex_ 13y ago
>have a vested interest in getting quality tutorials in people's hands to avoid them writing shitty perl. Thank you! I did have the idea of starting a more general site to highlight this problem (wrongtutorial.com) but I couldn't find the right approach. Good tutorials are hard to find - and the amount of obsolete or just plain wrong information is staggering.

killertypo 13y ago

as a fellow perl'er (but not knowing it like the back of my hand) and having to learn through hardship and failure and obscenely old tutorials, what key pionts here can you point out that are absolute no-no's and should be avoided?

Mithaldu 13y ago
* very first program simply does not work * lack of strict * lack of warnings * lack of my * bareword filehandles * mentions &-calling of subs * thinks it's the same as normal calling * snowflake formatting style * mentions EXTREMELY outdated books as further reading * confuses capitalization of builtins in code examples * fails to explain compile phase semantics properly, instead introduces "use" as magical * quotes hash keys * explains prototypes as something that could be used in general * explains post-fix dereference syntax, but describes cumbersome circumfix syntaxes as default * 2-arg open instead of 3-arg open I'm halfway down, i can't be arsed anymore. I feel like i'm reading the Leeds Perl 4 tutorial all over again.
- killertypo 13y ago
  what's funny, i saw the lack of strict and thought...hrmm, well without that we'll see what happens here.
- mattmight 13y ago
  > very first program simply does not work Guilty. Facepalm. Embarassed. Fixed. > lack of strict Not in scope (it's not a tutorial on good Perl), but I'll mention it. > lack of warnings Added a general disclaimer in the abstract. > lack of my I documented `my` in the subsection on scoping disciplines. I _tried_ not to use features before I'd introduced them. And, for most of the "probes," `my` wasn't necessary. > bareword filehandles Good point. Added scalar filehandles, as well as how to pass bare words with typeglobs. Changed most examples to scalar filehandles too. In doing so, I stumbled across the implicit method invocation form that happens when the first argument to a procedure is an object, so I added an example of that too. This is exactly the kind of "semantic surprise" that led me to start digging. > mentions &-calling of subs Of course. It's possible, and it can change the semantics of procedure call. > thinks it's the same as normal calling I had documented the differences. Look carefully: The procedure call example includes an error case. In the parameter passing subsection, I had included a mention of how `&proc` (no args), receives current @_. > snowflake formatting style Yep. Definitely not a style guide. > mentions EXTREMELY outdated books as further reading I added a link to Modern Perl (as suggested). And, the new edition of Mastering Perl came out last week. It flipped through it, and it seemed updated. > confuses capitalization of builtins in code examples Bug. Fixed. > fails to explain compile phase semantics properly, instead introduces "use" as magical Guilty. I thought about including this in the first revision, but I was nearing exhaustion. I'll add it later. > quotes hash keys It's legal. > explains prototypes as something that could be used in general I just explain what they are. They're a part of the language, and they have important consequences for both parsing and interpretation. > explains post-fix dereference syntax, but describes cumbersome circumfix syntaxes as default I don't endorse either syntax as default. > 2-arg open instead of 3-arg open I'm not trying to document the library, or teach good use, but I added an example for 3-arg. Thanks for your feedback!
VLM 13y ago
Trying to do OO stuff without the mighty MOOSE? Whoa, retro, man. MOOSE came out about a decade ago. Awesome OO implementation, no point using any other technique. He's calling "open" in a way thats been a no-no since like Clinton was prez, or at least a long time ago. You can debate making filehandles plain ole variables or not. The cool kids do it a different way than he does, which is not necessarily wrong. Backticks are looked at about the same way... so how exactly do you handle stdout/stderr separately with backticks, oh you don't, um... There's another, better way to safely call system stuff. Also he seems to be missing all error detection / correction / recovery code in general, both in every example and as a general topic. The Perl Cookbook was awesome... in 2003. The reference book you need is "Modern Perl" by chromatic, edited by Shane Warden, etc. CPAN gets one mention at the end. Thats wrong. The first thing you do when writing Perl is see whats out there to glue together. Also this is a fun way to learn stuff, rather than boring basic arithmetic or boring toy examples you can sling XML all over creation using a parser, or all kinds of crazy stuff. Life's just a lot more fun with CPAN. From a style perspective if Perl::Critic and/or perltidy disagree with you, and if you're a noob, you're doin' it wrong. I know when its acceptable to disagree with Perl::Critic but a noob will not, noob should trust Perl::Critic. Perltidy is a little bit more flexible, Perl isn't whitespace controlled but if you get really weird no one is going to understand your code. So pipe it all thru perltidy, in vi its "(esc):%! perltidy". Perltidy is also an interesting, although very forceful, way to find mismatched quotes and the like.

sea6ear 13y ago

I posted this article. I believe that the author, Matt Might is a professor specializing in programming language theory at the University of Utah. My understanding of this article was that it was less of a tutorial and more of an analysis of the actual semantics of Perl. Thus it is less about how one should write "Modern Perl" than it is about how Perl actually behaves in various circumstances.

Mithaldu 13y ago
If it's not a tutorial then i don't understand why he explains EXTREMELY basic things in the worst possible way, fails to actually explain the interesting details of subtle and complex things (like the differences between the ways a sub can be called (no, they do NOT all do the same thing)), and managed to produce a document that looks like it contains literally ALL the things from ALL the bad tutorials i've seen in the past 9 years, with nothing from any of the good ones.
- mst 13y ago
  Actually, he does appear to explain &foo() later on, he just doesn't bother mentioning up front that it's completely different. I think if you consider it as an academic piece, where you're supposed to read all of it and then think, it wouldn't be a bad introduction to perl as it was written in 2003.
  - tredontho 13y ago
    Okay, I've read a few of Might's posts, and they're pretty interesting. But it irks me for some reason that nowhere in the posts can I find a date. Am I missing something? Where did you grab this 2003?
    - mst 13y ago
      From the code. Were I to paranthesise the sentence, "perl as it was written in 2003" would be one clause.
- 13y ago

mattmight 13y ago

Article author here. To be clear, this is not a tutorial on writing good, idiomatic Perl. (And, I've strengthened the article's disclaimers to that emphasize that.) It's a semantic excavation of Perl. My goal was to understand how the Perl interpreter thinks, and to answer language design questions like: How are parameters passed--by value, by alias, by name, by reference, by need? How are variables scoped--lexically, dynamically, globally? What is the effect of @ in a prototype? For the .. operator, how is the implicit toggle scoped--at the procedure or the nearest enclosing block? How do prototypes influence context, and how do contexts influence evaluation? That is, I wanted to understand what was possible. The possible is entirely separate from the good. As a formal semanticist, I was continually surprised by how Perl behaved. As someone that has had to occasionally debug other people's Perl, I believe there is value in understanding the syntactic and semantic quirks in the language. Thanks for your comments. I'll be updating the article with your feedback.

Mithaldu 13y ago
In that case it would be nice if you actually restricted yourself to posing questions, answering them with experimental code and output, then discussing the result; as opposed to explaining the basics of scalars or posting patently false things like this: > For example, the following statement prints to the console: > > print Hello, world! ; # prints Hello, world! Pretty much half of that article should be deleted, and if the rest was discussion of interesting behaviors in a scientifical manner, that would actually be interesting.
VLM 13y ago
I can dig it. By analogy something like "If you insist on installing deck screws with a hammer instead of a screwdriver, this is what happens with a sledgehammer, this is what happens with a large heavy rock, this is what happens if you use your fist..." It is interesting, rather than terrifying, when seen in that light. However, Google is going to google, thats its thing, so some victim in the future might think this is the one true answer to using objects in perl, which is not cool.
Fasebook 13y ago
I haven't read the article completely, but I've enjoyed what I've read so far. I'd like to follow along in more detail with a perl interpreter. I'd love to see an entire book that completely tears down the entire interrupter from the perspective of within. I purchased Ruby Under a Microscope, but I was kind of put off by the similar issues other commentators are having, that it appears to be a basic introduction to how to write Ruby, but that is just how the task has to be approached (based off your existing assumptions and test to see if they hold up). But when the task is complete, you have knowledge on a better way to write Ruby, by accounting for all the exceptions that you can't "see" in the source code, due to leaky abstractions.

voltagex_ 13y ago

>have a vested interest in getting quality tutorials in people's hands to avoid them writing shitty perl. Thank you! I did have the idea of starting a more general site to highlight this problem (wrongtutorial.com) but I couldn't find the right approach. Good tutorials are hard to find - and the amount of obsolete or just plain wrong information is staggering.