*ponders*

No. It's not ridiculous. It's irresponsible. Your organization will now have uneducated programmers producing their production code. They will be wasting your money, time, and squandering your reputation among your customers.

It is your responsability to educate your programmers to know the full depth and breadth of the language(s) they are working in. If they choose to not be educated, they have also chosen to not be paid. It's as simple as that.

Here's another way to look at it - you have hired professionals, not babies. Don't baby them!

------
/me wants to be the brightest bulb in the chandelier!

Vote paco for President!

Not all people who have to program in Perl are programmers. And in many organizations it would be irresponsible to insist that they should be.

It is often wise to give some measure of responsibility to your users. They have jobs to do, and it would be unwise for you to make your professional programmers a perpetual bottleneck for all aspects of that process. Should you be involved for some activities? Yes. But just as you do not need an architect to put a picture up in someone's home, you should not need a programmer to modify a personal utility script.

However when you do that, you now have people who are not programmers who need to program. Should you insist on making them all programmers? I think not!

This is one of the prime reasons why Larry Wall insists that baby Perl is Officially OK...

I will agree with that, and even endorse that. However, if you ask a user to maintain/update a script/program that involves references, there is one of three solutions:
1. Things blow up cause the person responsible doesn't have the knowledge
2. You're at fault because you didn't take into account the complexity of the assignment
3. The user now needs to learn about references
I'm taking a very hard-nosed stance about this because there has to be some amount of accountability, somewhere. You can't just say that someone wants to directly modify something using complex features of a language and not have to learn those features. Sorry. It doesn't work that way.

------
/me wants to be the brightest bulb in the chandelier!

Vote paco for President!

No, what I am saying is that if I have to teach someone perl (or any other programming language for that matter), the last thing I want to show is actual references and explain how they work since this requires me also to tell about how the memory layout of a machine is, how transfer of arguments work etc.

If I feel that the person I'm teaching is currently not able to cope with this, I wont squash him with something that will make him go home feeling he is totally lost.
Rather I will try to teach him regular expression, hashes and arrays. Why do you think that the book Learning Perl doesnt even cover references?

T I M T O W T D I

No, Learning Perl doesn't cover references. However, that means that merlyn felt that references shouldn't be brought up in the first 4 weeks of teaching a complete novice how to program from scratch. A complete novice, not a professional learning another language.

If you have someone who already knows how to program, they shouldn't be using Learning Perl after the first week. They should be diving into Programming Perl and loving it! When I taught my successors at my previous position how to program in Perl, I didn't waste their time with Learning Perl. They knew how to program, and quite well. They just didn't know Perl.

You don't need to describe memory locations or anything like that to someone who knows Java or C/C++. "A reference is basically a pointer, but nicer." is what you tell a C programmer. "A reference is a reference." is what you tell a Java programmer. There. That's all there is to references.

I'm sorry, but I fail to see why you want to baby your professionals.

------
/me wants to be the brightest bulb in the chandelier!

Vote paco for President!