Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An experiment-driven guide to Perl

matt.might.net

Post reply on HN
Print view View original

11–20 of 44 posts

Re: An experiment-driven guide to Perl

#11

Post by mst »

sea6ear wrote: post #6
Mithaldu wrote: post #3

Full disclosure: I'm the guy who made 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 da…

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.

Right, but when there's more than one syntax to use to get that behaviour, he invariably picks the c.2001 preference rather than what we've done since.

It's like if somebody started their ruby tutorial off with how to implement your own object system with method_missing.

Sure, it fits the 'actual semantics', but it's not what we really want people to see first :)

Re: An experiment-driven guide to Perl

#12

Post by mst »

Mithaldu wrote: post #7
sea6ear wrote: post #6

Earlier quoted context omitted.

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.

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…

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.

Re: An experiment-driven guide to Perl

#13

Post by jsnell »

Mithaldu wrote: post #7
sea6ear wrote: post #6

Earlier quoted context omitted.

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.

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…

It appears that you've decided it must be a tutorial, and your only basis for that is that it's not a tutorial. That's extremely uncharitable, almost insanely so. Especially since the word "tutorial" appears nowhere in the text. The only reference to learning or teaching is a list of resources for actually learning Perl.

Re: An experiment-driven guide to Perl

#14

Post by VLM »

killertypo wrote: post #4
Mithaldu wrote: post #3

Full disclosure: I'm the guy who made 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 da…

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?

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.

Re: An experiment-driven guide to Perl

#15

Post by mattmight »

Mithaldu wrote: post #3

Full disclosure: I'm the guy who made 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 da…

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.

Re: An experiment-driven guide to Perl

#16

Post by sea6ear »

mst wrote: post #11
sea6ear wrote: post #6

Earlier quoted context omitted.

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.

Right, but when there's more than one syntax to use to get that behaviour, he invariably picks the c.2001 preference rather than what we've done since. It's like if somebody started their ruby tutorial off with how to implement your own object system with method_missing. Sure, it fits the 'actual semantics', but it's not what we really want people to see first :)

I'd actually enjoy that :) However, I first really understood objects from learning how to create them from closures in Scheme. And I'm not sure how many object systems built from array reference hacks in Tcl I've looked at.

But probably not what most people are probably looking for when they are first trying to understand something like Perl or Ruby.

Re: An experiment-driven guide to Perl

#17

Post by Mithaldu »

mattmight wrote: post #15
Mithaldu wrote: post #3

Full disclosure: I'm the guy who made 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 da…

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…

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.

Re: An experiment-driven guide to Perl

#18

Post by mattmight »

mst wrote: post #11
sea6ear wrote: post #6

Earlier quoted context omitted.

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.

Right, but when there's more than one syntax to use to get that behaviour, he invariably picks the c.2001 preference rather than what we've done since. It's like if somebody started their ruby tutorial off with how to implement your own object system with method_missing. Sure, it fits the 'actual semantics', but it's not what we really want people to see first :)

Over the course of the article, I tried to show as many different ways of doing something as possible, without assigning judgment as to the "right" way to do something.

If you point out instances where I only documented the old syntax, let me know, and I'll add newer examples as well.

Re: An experiment-driven guide to Perl

#19

Post by Mithaldu »

mattmight wrote: post #18
mst wrote: post #11

Earlier quoted context omitted.

Right, but when there's more than one syntax to use to get that behaviour, he invariably picks the c.2001 preference rather than what we've done since. It's like if somebody started their ruby tutorial off with how to implement your own object system with method_missing. Sure, it fits the 'actual semantics', but it's not what we really want people to see first :)

Over the course of the article, I tried to show as many different ways of doing something as possible, without assigning judgment as to the "right" way to do something. If you point out instances where I only documented the old syntax, let me know, and I'll add newer examples as well.

The point is that in every single topic you touch where there is a more modern way to do it, if you mention that modern way, you do it as an aside; instead of first showing the modern way of doing it, and then mentioning as an aside that there is an insane way of doing it.

Re: An experiment-driven guide to Perl

#20

Post by mattmight »

sea6ear wrote: post #6
Mithaldu wrote: post #3

Full disclosure: I'm the guy who made 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 da…

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.

You're exactly right.

An alternate theme for this article might be: "What happens when a formal semanticist looks at Perl?"

Post reply on HN