in reply to Premature optimization
A case in point, client rings up 'Can you extract the email address of everyone from our POP3 box?'. No problem! 15 mins later with the help of POP3Client I had the answer. Few hours go by and then they ask, 'We downloaded them, can you do it again from this mailbox file?'. Another 15 mins later with the help of MBoxParser I had one happy customer.
I hate to think how long it would take me in another language. I could have been banging my head against the wall for ages!
The one bad thing I would have to say about perl is that it lets you get away with a lot. Turn off strict and warnings and you can get away with a lot of sloppy code.
There is some shocking CGI scripts about, everytime I go to look for something (yesterday it was a simple web log) I poke around the code and I'm shocked. I found Graymatter which seems to be well recieved. What do I find?
- No strict or warnings
- Not using CGI.pm
- Function calls with a & in front (one of my pet peeves - I think it looks terrible)
- A horrid stack of if statements, no thought of using some sort of hash as a dispatch table or anything more maintainable
- HTML scattered through the script - with excellent templates modules such as HTML::Template (my favorite) that are so easy to use, there is no excuse
This is just one example of bad coding. I think the main problem is that perl makes it so easy, some people don't think to do it right. Maybe I'm being pedantic here but I take pride in neat well written code :)
One of our clients sent over their desiger to look at some of the cgi scripts I worked on for a project. They wanted him to tidy up the HTML output and fit it into their "look". I handed over the templates he'd need to change and he was shocked. It was the first time he'd seen a perl cgi script that didn't have embedded HTML!
Well that was a bit of a rambly post but I'm sure I have a point somewhere. Sit back, think about what you are doing and try to do it right :)
|
---|