How can I do a (short) Perl talk when my audience doesn't know Perl?

I'm planning out a 10-minute presentation to give in my databases class this week. My first thought was to talk about a DB object-persistence class I've been writing (It's similar to Class::DBI except simpler and more functional). However, given the exceedingly low time limit for the talk, and the unfamiliarity with Perl among the classmates, there is no time left to get people up to speed on the basics (Perl OOP, DBI.pm) during the presentation to talk about my favorite features of this module.

So I decided to change the focus and plan a presentation on Perl object persistence layers in general, showing only basic features and how easy they are. But even this looks like it may take more than 10 minutes: Perl OOP is not something I expect others to understand after just one slide. Also, how can you talk about dynamic accessors and mutators without explaining AUTOLOAD? I don't want to spend a lot of time on these concepts so that I can get to the real meat of my presentation, but on the other hand they are still very important and I don't want my audience to be drowning in Perl they don't understand.

I'm also unsure of the right amount of code examples in Perl to show. I don't want their unfamiliarity with the syntax to slow things down as well. C++ is the lowest common denominator at our school, so do I have to show translated C++ code to make it easily understandable? I fear doing this because I want to talk about Perl specifically, and how it makes things easy.

Thanks in advance for any suggestions! Cheers,

blokhead

Replies are listed 'Best First'.
Re: Perl technical presentations
by djantzen (Priest) on Dec 09, 2002 at 17:35 UTC

    I have a couple of general comments:

    1. Avoid the urge to proselytize. There is virtually zero chance that you'll be able to convince a bunch of C++ programmers that Perl is better than anything in less than 10 minutes. To this end, don't attempt to explain how easy, flexible, or DWIMish Perl is. Show how to accomplish some task, but let the audience make their own value judgments. gjb is onto something good with the suggestion to show how DBI provides code portability over various DB backends.

    2. Keep your presentation directly related to the themes you're working on in the class. This will help ensure that your classmates are on the same page as you during your presentation, and make your instructor happier when assigning a grade.

    3. If you give code samples, you're probably better off expressing concepts using pseudo-code. Even explaining the most basic elements of Perl like scalars and arrays will needlessly eat up your time. So, distill the core ideas and express them in a language-independent way.

Re: Perl technical presentations
by gjb (Vicar) on Dec 09, 2002 at 16:09 UTC

    I'd limit myself to explaining a bit about DBI, i.e. how it allows to abstract away from specific database backends and how easy it is to change backends (if one sticks to standard SQL of course). I guess that will be quite enough for the time allotted.

    I guess that if everyone is familiar with C++ it should be too hard to understand sample code in Perl. I'd not go into translating C++ to Perl or vice versa since this might lead to a shouting match on syntax which I consider unproductive.

    If time allows (which I doubt) you could point out that one can do OO and give a functional (not the implementation) of your Class::DBI alternative.

    Just my 2 cents, -gjb-

Re: Perl technical presentations
by Callum (Chaplain) on Dec 09, 2002 at 17:22 UTC
    In only 10 minutes ther's very little you can cover, particularly if there's any interaction with the class -- even a simple question will take a minute to ask & answer.

    Assuming there's minimal interaction, a quick compare-and-contrast with other languages they know will be the quickest way to convey a sizeable amount of information, followed up by DB specific comments -- eg the availability of lots of DB modules on CPAN.

    I'd be inclined to avoid your home-grown module in favour of standard ones -- if people want to follow up on what they've heard in class it will be easier for them to do so.

    Lastly, you may wish to provide a one or two page sheet outlining more information on perl and URLs for online references, plus address any specific questions on the sheet that you may expect based on your class.

Re: Perl technical presentations
by dws (Chancellor) on Dec 09, 2002 at 18:56 UTC
    I'm also unsure of the right amount of code examples in Perl to show.

    For whatever amount you do show, use a large font. There's nothing quite as frustrating as sitting in the back of a room trying to read tiny font that's been through a projector. I've seen many, many presentations fall flat because much of the audience couldn't read the code.

Re: Perl technical presentations
by belg4mit (Prior) on Dec 09, 2002 at 16:17 UTC
    What about something like EZDBI or DBIx::Simple. Both of which are Perl, database related, and minimalist. DBIx::Simple is an OO interface though and might require more background/explanation. EZDBI abstracts some standard SQL to functions, which should make it easier. However, there are some context-sensitive features which might be too complicated and need to be skipped.

    --
    I'm not belgian but I play one on TV.

Re: Perl technical presentations
by rir (Vicar) on Dec 09, 2002 at 22:17 UTC
    It may not be suitable for your venue, but it sounds like a good place to demonstrate the roots of perl. Perl as a better awk, sh, and sed all rolled into one. Which is to say, if you aren't familiar with Unix, Perl as a text manipulation tool.

    How many times have DBA's had the problem: How do I get this cruddy data cleaned up and into my database? The answer is Perl.

    This could be a fine showcase for perl. How to change integers to tri-state sql booleans? How to extract sql data from HTML data? How to populate small static tables in an sql database?

    How to clean up hand entered data? Like

    EDP^DESCRIPTION^WGHT^... 1001^stl sq .5^.425^... 1002^Steel Square 3/4^1.92^... 1002^SQ STL C1018 1.25"^5.31^... 1003^steel round C1215 1"^2.67^...
    to extract shape, grade, size in decimal, weight_per_what if available and to enforce a standardized abbreviation and capitalization pattern upon the data.

    In a few years someone may recall how that guy in database class solved the tough munging problem they're facing now with just a paragraph of Perl.