Re^4: DBD::CSV and really bad legacy flat file

I need to duplicate the functionality of an existing script which is entirely self contained and uses no modules of any kind and is written with a perl4 mindset and is a PITA to maintain and update and modify.

How the data is handled doesn't matter as long as it stays in the same format, as far as my boss is concerned. I don't have any problems with the duplication of functionality, it's just parsing the data with existing modules rather than writing my own, which almost always takes longer, which is what my boss doesn't want.

Harley J Pig

Comment on Re^4: DBD::CSV and really bad legacy flat file

Replies are listed 'Best First'.
Re^5: DBD::CSV and really bad legacy flat file by jhourcle (Prior) on Jul 19, 2005 at 20:21 UTC
If speed is a significant factor, then Perl probably isn't your best language. In fact, if any of the modules get a speed up, it's probably because they're using compiled parts. They would actually have more overhead, because they need to be made more generic so that they can be applied to generic uses, and to deal with problem input that might not be a factor in your situation. It may be possible to get a speed up by streamlining the logic of your program, or by trading off memory or disk for speed. From what you'r describing, in dealing with legacy code that's difficult to maintain, I'd suggest the Perl Medic book, even if the front page to the site is rather horrible.	[reply]
Re^6: DBD::CSV and really bad legacy flat file by harleypig (Monk) on Jul 20, 2005 at 16:00 UTC
'takes longer' to code, not process. The replacement code is required to be in perl. Harley J Pig	[reply]