Thank you all for the response. If you allow me, I will try to get the context in which I posed the questions into a sharper focus, and propose a conclusion.

Since I signed up for a password here at PM, I have learned a lot by reading, and reading more and trying to follow your discussions. Most of this in my spare time, since I am not supposed to programming, I’m supposed to be analyzing data. I enjoy learning Perl to a great extent, and there are many pitfalls that I am now able to avoid, thanks to PM.

However, I started this thread with a quote from Larry Wall, because to be perfectly honest, in a sense I was fooled by the Perl evangelists into believing that this would be a language that would really allow me to define a subset of instructions that I needed for the (relatively) simple job at hand, and think no more of it. I work at a university, so any new tool or technique I develop, I’m supposed to be able to explain to someone else (be it a member of staff or a student). If I quote Larry, some of them will be as enthusiastic as I am, but if I tell them that ‘IT=learning perpetually’ it is unlikely that they will rush out and buy a copy of the Camel. Science is learning perpetually too, and most of us hardly have the time to keep up with the primary literature. If there is no ‘copy and pasteable’ set of instructions I can come up with, or a small and well defined subset of the language, then the applicability of this in a course on statistics (for example) is rather limited.

Permutation analysis appears to be a promising (or at least a very useful) tool in the biological sciences 1,2. It has the great disadvantage that one has to be computer savvy and know some basic programming to be able to apply them effectively. From your response so far, instead of talking about the marvels of this language (as I have done in public), I should advise them to either hire me (which is not that bad an option, since I will reach the end of my contract soon :) or seek other, professional, advice when staff or students want to apply permutation methods or need to massage large datasets.

Refs:
1 Manly, B. F. J. (1991). Randomization and monte carlo methods in biology. New York, Chapman and Hall.
2 Good, P. (1994). Permutation tests, a practical guide to resampling methods for testing hypotheses. New York, Springer Verlag.

Ah! Now you're asking about effective advocacy.

I'm going to disagree with an analogy you've made here:

If I quote Larry, some of them will be as enthusiastic as I am, but if I tell them that ‘IT=learning perpetually’ it is unlikely that they will rush out and buy a copy of the Camel. Science is learning perpetually too, and most of us hardly have the time to keep up with the primary literature. If there is no ‘copy and pasteable’ set of instructions I can come up with, or a small and well defined subset of the language, then the applicability of this in a course on statistics (for example) is rather limited.

Consider this: In one course on statistics--let's say, a sophomore-level terminal course designed for people in the social sciences--one doesn't need calculus. All that's going to be needed is high school algebra (if you went to a good high school)--a reasonable expectation for any college student.

In another course--let's say, a junior-level course, not terminal but without a required follow-up designed for people in engineering--one might well require some simple first-semester calculus--a reasonable expectation for an engineering student.

In another course--let's say, a senior-level course in stat theory designed for statistics and math majors--you'd darned well better be able to integrate over multiple variables, and you'd better have a fairly broad overview of math--a little linear algebra wouldn't hurt--a reasonable expectation of an upper-class stat/math student.

Now, can we really say that the first or the second course have "a small and well-defined subset" of mathematics required for statistics? Not really, in my opinion.

Much of what is talked about here for really good style is about writing safe and robust code that'll work in a an uncertainly secured, multi-user, production environment. What you describe isn't that--it's someone working at a desktop or a workstation on data they've captured, which can reasonably be expected not to have any booby-traps in it--for instance, I don't think you have to worry about tainting.

The analogy to make when talking Perl to these folks is language--no one (even ex-English majors like me) expects to know everything there is to know about the language, but everyone expects to know what they need to know to use it. Perl is quite similar--there is a fairly basic set (darned if I can define it right now) of functions and operators that'll do simple data munging, and most of them operate in a fairly intuitive way.

I do know the attitude you're describing--it's prevalent in business (the number of highly-paid, otherwise competent business people in the IT industry that I've had to show things like how to defrag their drives (and why), or how to make Excel add up a column of values (I'm not making this up) is astounding), but I think you have a chance to advocate Perl effectively, if you can rein in your enthusiasm just a bit.

Tell people that Perl is this very neat programming language that's a lot like English (or whatever language they favor)--you can do very easy things in it very easily, and you can (if you want) shoot for becoming Shakespeare.

They key to doing this is to define for yourself the very basic tools in Perl that are sufficient for the task you have at hand, then use, and demonstrate the use of, those tools tirelessly.

As far as course presentation goes, consider two approaches:

1) Write a module (simple modules aren't hard to write--you can (don't hurt me!) cut and paste the basic template from perlmod and begin experimenting) that does what you need done, then present that.

2) Suggest that Perl is such a valuable yet simple tool for data analysis that it would be worth teaching as a part of the course--only a week or two. It is (in my opinion) a reasonable expectation of a student studying statistics in the sciences that said student has had some exposure to the basic concepts of programming. Check the catalog where you work and see whether or not a basic computing course is a core course--it's likely that it is.

(If it's not, then a larger, more difficult, and longer-term project is to convince the powers that be that a course in programming should be required, and that Perl is an ideal language for such a course.)

It's very easy to get caught up in the fancy stuff Perl can do and forget that the basics of Perl are still in there, and that one doesn't have to use all the bells and whistles just because they make pretty noises.

Good luck--and thanks for starting an interesting (and, I hope, useful) thread.

They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

I find it ironic that Larry would invent a very large language that very few could be reasonably expected to master and then says that you don't have to master it... :-)

But I think that Larry is right. You can get things done while knowing remarkably little Perl. But there is a lot of Perl to learn, and learning it brings benefits. There is a lot to learn about programming in general, which will likewise bring even more benefits. You don't need that to find it useful. But without it you will repeatedly shoot yourself in the foot, and you won't even know you are doing so! That is life.

Neither Larry Wall or anyone else can make learning more a useless or irrelevant thing to do. (Though some - in particular Microsoft - try to market products that they claim have done so.) But you can certainly define a useful subset of the language which you stick to and can readily bring someone else up to speed on. There is sometimes great value in doing so.