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

31–40 of 44 posts

Re: An experiment-driven guide to Perl

#31

Post by perigrin »

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…

It might also be useful to add to the disclaimers that many of these things that aren't explicitly documented can be in flux. Parameter passing is currently for example being discussed and may change (experimentally and in a backwards compatible fashion) between the upcoming 5.20 and next year's 5.22 release. It also may not, but I know it's been actively discussed this month.

Re: An experiment-driven guide to Perl

#32

Post by perigrin »

sea6ear wrote: post #16
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 :)

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.

Actually (and sadly) for some jobs with Perl that involve codebases older than 2007. That material would be useful. Because, like the languages you mention, deriving object systems from Perl5's rough axioms, was at one point something of a hobby for people.

Re: An experiment-driven guide to Perl

#33

Post by perigrin »

theOnliest wrote: post #30
chromatic wrote: post #27

Earlier quoted context omitted.

I'll admit that this is baffling. The inner parentheses force evaluation of the two inner comma operators in the scalar context provided by the function prototype. `1` and `3` get evaluated in void context and discarded, leaving `2` and `4` as the two arguments to the function. (I had to look up `+` in prototypes, however.) Without a working understanding of lists and context, this example is undoubtedly baffling, bu…

I guess I really meant "is baffling without a thorough understanding of context." I feel better about looking up the + now that I know you did too, though! I don't think I've ever seen code like that in the wild, and I've never seen a Perl programmer attempt to call a sub with nested parens, like what_are((1,2),(3,4)) before.

You may not realized that's what you saw, but for example all of the Moose documentation uses effectively a nested param:

    has foo => ( is => 'ro' );
is equivalent to:

    has('foo', ('is', 'ro'));
because Moose's `has` sugar is written as a exported function.

Re: An experiment-driven guide to Perl

#34

Post by mattmight »

Mithaldu wrote: post #5
killertypo wrote: post #4

Earlier quoted context omitted.

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?

* 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…

> 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!

Re: An experiment-driven guide to Perl

#35

Post by ceronman »

I loved this article.

I started writing Perl nine months ago because of my new job. I learned it with the Modern Perl book, which is really nice and goes directly to the best practices. However, I've found that real life Perl code is full of the old/deprecated/insane ways of doing things as well. And Perl developers really take the TIMTOWTDI principle to the limit.

This article helped me to understand Perl more. And specially to understand real life Perl code better. I also liked the language designer perspective and the semantic analysis. Thanks for writing it!

Re: An experiment-driven guide to Perl

#36

Post by theOnliest »

perigrin wrote: post #33
theOnliest wrote: post #30

Earlier quoted context omitted.

I guess I really meant "is baffling without a thorough understanding of context." I feel better about looking up the + now that I know you did too, though! I don't think I've ever seen code like that in the wild, and I've never seen a Perl programmer attempt to call a sub with nested parens, like what_are((1,2),(3,4)) before.

You may not realized that's what you saw, but for example all of the Moose documentation uses effectively a nested param: has foo => ( is => 'ro' ); is equivalent to: has('foo', ('is', 'ro')); because Moose's `has` sugar is written as a exported function.

That's true, but I've never actually seen anyone call 'has' like that. Plus, Perl's behavior on lists makes sense (always flatten) if there's no mucking around with prototypes, so that's much less confusing than the behavior in the article.

Re: An experiment-driven guide to Perl

#37

Post by perigrin »

theOnliest wrote: post #36
perigrin wrote: post #33

Earlier quoted context omitted.

You may not realized that's what you saw, but for example all of the Moose documentation uses effectively a nested param: has foo => ( is => 'ro' ); is equivalent to: has('foo', ('is', 'ro')); because Moose's `has` sugar is written as a exported function.

That's true, but I've never actually seen anyone call 'has' like that. Plus, Perl's behavior on lists makes sense (always flatten) if there's no mucking around with prototypes, so that's much less confusing than the behavior in the article.

The first one I presented is the way the Moose documentation calls has, the way the Moose test suite typically calls has, and the way I and most of the rest of the Moose Cabal call has.

The second one isn't common at all, but I have seen people both completely leave out the parentheses:

    has foo => is => 'ro', isa => 'Str', ...;
or treat has as a straight function

    has(foo, is => 'ro', isa => 'Str');
both of which cause Perl::Tidy to do weird things.

Re: An experiment-driven guide to Perl

#38

Post by mst »

tredontho wrote: post #26
mst wrote: post #12

Earlier quoted context omitted.

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.

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?

From the code. Were I to paranthesise the sentence, "perl as it was written in 2003" would be one clause.

Re: An experiment-driven guide to Perl

#39

Post by mst »

Mithaldu wrote: post #19
mattmight wrote: post #18

Earlier quoted context omitted.

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.

Wow. Author asks for bug reports ... you explain it's all buggy and don't provide a single example.

For your sins, I'm going to see if I can convince the author to get it into a repository and then I'm going to give you a commit bit ... :D

Re: An experiment-driven guide to Perl

#40

Post by theOnliest »

perigrin wrote: post #37
theOnliest wrote: post #36

Earlier quoted context omitted.

That's true, but I've never actually seen anyone call 'has' like that. Plus, Perl's behavior on lists makes sense (always flatten) if there's no mucking around with prototypes, so that's much less confusing than the behavior in the article.

The first one I presented is the way the Moose documentation calls has, the way the Moose test suite typically calls has, and the way I and most of the rest of the Moose Cabal call has. The second one isn't common at all, but I have seen people both completely leave out the parentheses: has foo => is => 'ro', isa => 'Str', ...; or treat has as a straight function has(foo, is => 'ro', isa => 'Str'); both of which caus…

Sorry, I meant I'd never seen it called the second way (nested parens). I also haven't seen the no-parens version, which looks really bizarre!
Post reply on HN