Re (tilly) 1: to perl or not to perl

[tilly]

Well strict is lexically scoped so it can be added bit by bit without worrying about legacy code.

However my best advice is to define a subset of Perl that you think allows you to program Perl well which you also think you could teach fairly quickly. For me that list would include scalars, arrays and hashes. Basic programming constructs I would insist on include functions, foreach, my, and package. I would insist on the basic array operations, push, pop, shift, and unshift. I would include simple REs. The global variables $_, @_ and $! would be acceptable. I would be willing to use wantarray wisely, with it being my responsibility to put scalar at places where something is used in scalar context but a beginner might not realize it.

To that I would throw in the semi-magical invocations needed for use, strict, vars, and exporting a function from one namespace to another with Exporter. I would add perldoc to the requirements, and say that for some set of modules that the public interface as documented in the documentation is fair game. What set of modules depends on what you are doing. And it would be allowed to write your own perlpod documentation inline.

Stop.

There is a lot missing. An awful lot. But the above list is enough to program fairly cleanly. It offers constructs to keep life sane. It offers options to reuse existing wheels. It is powerful enough to keep you productive. But it is still a list that that you could bring someone up to speed on fairly fast. It does not offer many major conceptual barriers for someone who does not have your background. There is enough room there to work on your programming style.

Now what is missing? Well references. Objects. Slices. Closures. Typeglob games. Most of the special variables. The intricate details of pack. Complex RE tricks. The need to know most of the precedence table. (Use parens.) And so on.

Can you convince them of this compromise? I don't know. You can try. I think you have a chance. I was in a vaguely similar position. I voluntarily did something like that, and it worked well. So well, in fact, that we are using a lot more Perl than we used to. It also helped that I later got to help train several co-workers.

But even if you cannot get everything on this list, look on the bright side. It is a perfect chance to go out and pick up books like Code Complete or the Pragmatic Programmer and learn about how to write better code. Most what you can learn about clarity of code doesn't need a lot of language features to apply, and is darned useful...

On the other hand it might be looked at as motivation to polish your resume a little...