3 ms·

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

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.

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.