Re: RFC: How to survive your first few months of Perl

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.

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

Comment on Re: RFC: How to survive your first few months of Perl

Replies are listed 'Best First'.
Re^2: RFC: How to survive your first few months of Perl by jplindstrom (Monsignor) on Nov 12, 2008 at 14:14 UTC
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	[reply]
Re^3: RFC: How to survive your first few months of Perl by BrowserUk (Patriarch) on Nov 12, 2008 at 18:07 UTC
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."	[reply]