90% of EVERYTHING is crap.

Perl is an amplifier. It amplifies the bad along with the good.

At least rewriting programs is easier in Perl than in most other languages.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

I'd have to disagree with the blanket statement of At least rewriting programs is easier in Perl than in most other languages.

It all depends on what language you know best. Personally, I find re-writing a badly written straight 'C' program easier than Perl. I write Perl (and at rare times, good Perl), but I'm don't come close to the tight code that someone like yourself, Randal, chromatic, or btrott writes.

Any sufficient complex process or algorithm poorly implemented in any langauge is going to be difficult to rewrite, particularly if you don't have any idea of what the target algorithm is.

--Chris

e-mail jcwren

Actually I have to agree with jcwren. I write crappy perl-code.
I started programming perl close to the date I joined PM.
I don't have years of experience like some of you have here. Actually I started
programming 6 months ago before that I installed and maintained
hardware and software.
So don't expect from me nice code, but with comming to PM I learn
how not to code. I get sometimes amazed with the solutions given here
PM to different problems and the comments given on code, with this
interaction I learn a great deal and sometimes prevent me from
making mistakes...

I still hope PM remains like it is a helpfull community and we are
all willing to help others.
This is why I think it's important that higher level monks keep
they're motivation to point out what lower level monks are doing wrong.



--
My opinions may have changed,
but not the fact that I am right

I admit my first effort in Perl would probably give me a fit if I went back and had to maintain it and I agree with your comments on the whole but:

'Dont worry about the mess you inherit, ... it probably isnt your job to sort out'

If only, this time it is my job and theres no one to pass that buck to ... :-)

I found this book useful. Refactoring : Improving the Design of Existing Code
But the problem is it's OOP oriented with examples in java.
Anybody have a good book they can recommend for redesigning existing code in a non-OOP/non-OOP->OOP world?
But it does contain some ways of identifying what exactly in the code feels wrong.
Bad code smells funny, but sometimes it's harder to isolate what makes it that way.
I used this to make my college group projects go easier.

',this time it is my job' in which case best of luck - but at least you have a clear definition of what you have to do and hopefully you have agreed the resources and timescales before starting...

I don't often come across projects where Perl is already used (generally I just get on with it and use Perl whenever possible). I think that in the last five years I've been at three places where Perl was used.

• At the first the code looked OK to me, but I didn't know much Perl at the time and looking back I'm pretty sure that it was basically shell scripts written using Perl syntax. I think most of it was written under Perl 4.
• The second one was the back end of large UK-based auction site and it was written by people who knew no Perl. I was brought in as a "Perl Expert" but whenever I suggested better ways to do things I was told that they didn't have time to go back and fix existing code and that as long as it worked they were happy with what they'd got.
• At the last place I spent months rewriting a system that was in Perl, but that had been written by someone whose Perl wasn't very good.

So, yes, my experience backs up your theory. I suspect the major problem is that there is so much bad Perl out there on the web that the chances of people coming across merlyn's Web Techniques columns before they find Matt's Script Archive is pretty slim.

exasperation overload, point taken...