Quite frankly, if these are (even semi-) experienced programmers, I'd throw most of what you've listed away. They are either

• too simple--like Data::Dumper.

  They won't appreciate how useful it is, until they've tried dumping Perl data structures manually, as they currently do in whatever languages they are used to, but will tend to think: "This is what Perler's get excited by..."

  Far better to just use it as a part of demonstrating something else, without actually making any fuss about it. They'll then know it's there, and when they need it, they'll know what to look for.

• Too complex--like Moose, POE, Catalyst, Jifty,.

  No brief overview of any of these is going to do any one of them justice. And API tours are about the most boring way to spend time that you'd rather spend doing something else.

  And for goodness sake leave B::Deparse et al. completely unmentioned unless you want the "conceptual model wars" to be their abiding first Perl experience.

If you want to enthuse programmers for a new language, show them what it can do for them. Something relevant to their experience and/or imminent tasks.

That's why that RoR video was so effective. It showed people who've been struggling for months and years with PHP/JavaBeans/CGI.pm&Template::Toolkit how much of their current and previous efforts had been expended repeatedly servicing the requirements of their tools and environments rather than their specific applications. Repeatedly reproducing stuff that their tools should be doing for them. It's that "let me do the stuff I need to do and let the tool take care of the rest" that grabs so many Ruby neophytes by the scruff of the neck and turns them into devotees.

Find something that matches their immediate requirements. Start with a 'blank canvas' that includes all the good stuff--strict, warnings, Data::Dumper; whatever else is relevant--and take them through the steps of turning that into something (simple!) that works.

Install a relevant module "in front of their very eyes", and then just use it. Look something up with perldoc, or the on-line html, as a part of the process, without getting into details about it. Write your tests and then use them to test your code and locate a 'bug'.

And leave plenty of time for questions. Because if you do it right, there'll be plenty. Indeed, you can use the number of hands that go up when you first ask the "Any questions" question as a strong indicator of your success.

I wouldn't say Moose is too complex. It's a perfect fit for the problem it solves, and rolling your own accessors is bound to give a bad first impression of Perl.

Just stay away from Roles and meta programming and possibly even type constraints and it's very straightforward.

Type constraints might make people who already use explicitly statically typed languages feel less nervous though, so that might me another win.

However, once they have gotten into it, it's obviously important to know how "native" Perl OO works so they don't get lost in existing code bases.

/J

I didn't say Moose was "too complex" of itself, just that it was too complex to do any sort of justice with a brief overview (amongst several other brief overviews) within a typical conference session.

Personally, I think that Moose is far too complicated internally, and far too slow to risk holding it up as an example to Perl neophytes coming from compiled languages. They'll code up some simple hierarchal OO standard test--A genus tree or managerial hierarchy--run it twice and walk away. It even throws away the slim performance advantages that native Perl OO has over Ruby and Python.

Performance may not be eveerything, or even a significant something for many people, but exagerating and exacerbating the compiled/interpreted differences by using an OO framework that enacts such a penalty, in order to achieve functionality that very few will ever feel the need for, just doesn't make sense to me.

Class::MOP seems to see "Meta Object Protocol" as an end in itself, to the detriment of all other considerations. The docs do a good job of listing what it can do, but a pretty poor job of explaining why you would ever want to do those things.

As an exercise in exploring what and how Perl 6 might work--hopefully without the penalties--it is an incredible piece of work. As a useful and usable piece of Perl 5 everyday wear, I have my doubts. Maybe Mouse, I haven't gotten to try that recently to see how it is faring.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

1. Use strict and warnings!
2. diagnostics
3. perldoc -f
4. YAPE::Regex::Explain
5. perl -MO=Deparse and perl -MO=Deparse,p (B::Deparse)
6. perldoc -l Some::Module | xargs less

perldoc -f

In my first few months of using Perl (back in 1995), I cannot tell you how much time I would have saved if I had known about this option on perldoc. Initially, I was learning by adapting code that someone else had written, so in the course of a day, I ran "perldoc perlfunc" repeatedly to look up the details on function calls, and I was constantly paging down to the function of interest...

UPDATE: On second thought, I have to admit that I learned a lot more about perl (and grew to appreciate it more quickly) by virtue of spending so much time with the "perlfunc" man page.

perldoc -l Some::Module | xargs less

How about perldoc -m Some::Module instead?

--MidLifeXis

If you define PERLDOC_PAGER=less or PAGER=less in your environment, say in .bashrc or the equivalent, it works fine. Otherwise perldoc will use more as a pager, which works, but doesn't know how to scroll backwards. That's sad.

Use strict and warnings!

Doh! I was missing the obvious :-)

They are an integral part of the language, and you can use them for quite many things - and often you have to use them (unless you want to write complicated things).

No one seems to have mentioned PerlMonks! A couple of screen shots showing questions and answers from PerlMonks may be appropriate to show the fairly rapid and generally helpful nature of replies.

And in that vein, we would not want to leave out Super Search... I think one of the best ways to get acquainted with some new module is to put this into the first text box ("Match text containing: ..."):

Some::Module <code>
[download]

If the module in question actually exists, that query to Super Search is sure to turn up a variety of nodes containing code snippets using that module. Best thing ever.

And in that vein, we would not want to leave out Super Search...(snip)...Match text containing: ...Some::Module

For those kinds of searches, I wouldn't overburden the site...you could more easily use google and get better results. Save SuperSearch for things like searching by poster or (no replies)/(replies only), etc.

Oops...DUP of node below.

And in that vein, we would not want to leave out Super Search...(snip)...Match text containing: ...Some::Module

For those kinds of searches, I wouldn't overburden the site...you could more easily use google. Save SuperSearch for things like searching by poster or replies only, etc.

The question I'd ask your potential attendees, is why are they interested in Perl? What does it bring to the table that they don't have in their other languages? How can knowing Perl help them?

If you can give them a reason to do perl, and some basic resources, the rest will take care of itself.

I've listed a few things below that I think are cool bits of perliana.

PAR::Packer is worth mentioning, it solves the problem of "how do I distribute my work?".

I'd but things like strict, warnings, diagnostics, Perl::Tidy, Perl::Critic, under a "Perl Hygiene" header. Also PBP needs mention here. It's worth noting that while Perl gives you the technical freedom to hang yourself, we use cultural mores to restrict our behavior, rather than technical limitations. PBP does a good job of covering a lot of these rules and practices that have developed. A little basic hygiene goes a long way.

Test::* also deserves mention.

Inline::C and friends are also good to point out. As a C programmer, Inline::C and the Test modules are enough to get excited about.

My first thought, like kyle's, was to add in strict, warnings, and diagnostics. With those on it is a 100% better beginner's experience, at least!

I also like that you are going to do an overview of modules like DateTime, WWW:Mechanize, etc. Those are big time savers, easy to learn to use, and useful to almost everyone. Are you facing a reluctant audience, or one with people eager to get into Perl?

Are you facing a reluctant audience, or one with people eager to get into Perl?

It's a conference for developers (500 of them) coming from several distinct backgrounds (Perl, Python, Ruby, PHP, Java, C/C++, etc).

No one is forced to go and see my talk, so I imagine I'll only have interested people in the audience.

Then show a few simple regular expressions. Mention that they can become horribly complex, but there is no need to scare them with it.

Next show how to do something useful with a CPAN module by cutting and pasting the synopsis, and then making a few modifications.

If you have sufficient hubris, and are reckless, take a request from the audience and write a program that solves an audience-suggested-problem right in front of them, while explaining what you are doing. Watching a good, experienced coder is incredibly instructive. You could have a shill request a problem in case no one else in the audience has a suitable idea. But you can guess and prepare ahead for a few ideas, such as a log file analyzer and a web scraper.

Another approach to a live coding demo would be to have a Death Match, where two individuals or teams of experienced Perl programmers compete to solve a hard problem in a short amount of time. Switch the projector back and forth between the two teams, and add color commentary. I learned the cut-and-paste-the-synopsis trick from watching a Death Match, and I have used it dozens of times since then. That challenge was to write a mail reader in 20 minutes!

One more thing - be sure to show off ptkdb. I realize that lots of people here don't like debuggers, but they are expected and ptkdb is very nice.

The purpose is to provide them with tools and resources that'll ease their first Perl adventures.

Well, first thing is knowledge, then the tools. Probably a demonstration of how to get things done with perl comes first, and I'd go with the advice of BrowserUk for that. But since they are programmers, I would - the knowledge part - talk about how perl is different:

• context, huffman coding, dwimmery
• data types (and references), namespaces, packages, scoping, bare metal OO system
• compile time vs. runtime, and switching back and forth
• BEGIN, CHECK, INIT ... END

I'd trade Data::Dumper for Data::Dump::Streamer, and show B::Deparse, Devel::Peek, Devel::Leak::Object etc., CPAN of course, and lastly redirect them here.

I personally believe that while it is certainly true that CPAN is one of the major points of strengh for Perl and similarly important are the communities, you're stressing too much the accent on tools as opposed to the basic language itself, which is the starting point for the latter ones, and everything else.

For example, when I once gave a presentation myself about Perl I took a very personal approach, that perhaps was best suited to the environment I was talking to: namely a universitary one as opposed to the $job one you're most likely to refer to... However I started writing the proof a combinatorial identity in two ways: i.e. respectively with managing fussily all indices on sums and omitting (most of) them on assuming null values for certain quantities outside of certain ranges, which made the latter just as sound and as unambiguous as the former, but much more readable at the same time. I did so to illustrate an analogy for dwimmeries. Then one should necessarily talk about contexts. Talking about natural language principles in Perl, especially in terms of statement modifiers, or at least hinting at them would be very important to either get one intrigued about the language itself or letting her decide that it's "not for her." Also, I think that it would be wrong both to omit OO programming in Perl altogether and to refer in detail to any model in particular, be it the one extreme of the DIY "standard" which may scare some or the opposite one of, say, Moose. OTOH one should mention that both exist, and hint to the full spectrum of intermediate possibilities, but above all... now yes: the huge amount of CPAN modules, be they "procedural" (please let me pass the term for lack of fantasy finding a better suited one!) or OO or... whatever!

I personally believe that while it is certainly true that CPAN is one of the major points of strengh for Perl and similarly important are the communities, you're stressing too much the accent on tools as opposed to the basic language itself, which is the starting point for the latter ones, and everything else.

I'm with you on this one, but I'm wondering whether the complete context of the talk might make the approache(es) mentioned so far more applicable. If the talk is "How to survive..." and the audience is people who've already decided to learn Perl but are bewildered at the tool choices, then listing resources and tools is entirely appropriate. On the other hand, an introduction to Perl for those interested but not yet crying for help would be much more profitable (IMHO) if it centered on the language itself.

A friend of mine tells his junior administrators, "The most important thing about Unix is experience, but it doesn't have to be your experience: learn from mine!" I think that applies equally well to Perl. Demonstrating Perl's elegance to people generally piques their interest better than anything else will. Showing how simply Perl solves a real problem is a great segue.

Along those lines, clear, non-obfuscated Perl is also a great hook. Perl can be very ugly and still run, but it can be beautiful too. Showing Perl's pretty side can really surprise people who've heard the horror stories of write-only code.

WWW::Mechanize, CPAN::Mini and Perl::Tidy are far too specialised to be of interest to most people. I've never used Mechanize in my own code and am unlikely ever to, for example. CPAN::Mini is useful only to a small subset of users. And Perl::Tidy likewise. "Perl on Windows" is of course only useful to people working on Windows or who want Windows-specific functionality. Again, a small subset of perl people.

And I agree with the other comment that Moose/POE/Catalyst/Jifty/... are far too big for a brief overview to do them justice. But I'd add that they're also far too complex for beginners even if you dedicate a whole tutorial to each one (POE still confuses *me*, and I still don't see the point of Moose or even know what Jifty *is*). And again, they're only useful for a small number of people.

The most important thing for new perl users is the community, so concentrate on that and the CPAN. There's lots of useful tools based around the CPAN, so show them too. eg, the diff tool on search.cpan.org, cpantesters, etc