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