3 ms·

> So you blame Perl for programmers making poor choices in how they parse their data? That wasn't a poor choice. I didn't propose "si.+?nk" as a general rule,

> So you blame Perl for programmers making poor choices in how they parse their data? That wasn't a poor choice. I didn't propose "si.+?nk" as a general rule, and I would have used another method if there had been conflicting tags in the file. I also take issue with the parent comment about perl not being usable for long scripts; that's nonsense. A comm framework I wrote in perl in '04 still sends payroll data for our 18k employees to the bank. It weighs in at around 400 lines, makes calls to gnupg, a database, has a scheduling engine that can parse cron entries, has support for EDI wrapping/unwrapping functions, logging, error alerting, other bells and whistles I'm forgetting right now. There was nothing in the language that made this absurd or unsupportable.

kbenson 14y ago
> That wasn't a poor choice. I didn't propose "si.+?nk" as a general rule, and I would have used another method if there had been conflicting tags in the file. I wasn't really speaking to any criticism of you in particular, but to the general statement about assumptions when using Perl. I myself have used a regex to pull out well formed XML chunks and then re-parse them with a regex to build a hash out of the attributes of each chunk. It turns out it's 10x faster that any XML solution I could find (and there's quite a lot on CPAN!). The fact that it was a few hundred MB of XML and with a regex I could step my way through it probably had a lot to do with that...