3 ms·

> http://cautery.blogspot.com/2010/09/concise-perl.html http://cautery.blogspot.com/2010/09/concise-perl.html This illustrates the use of Perl in quick one-lin

> http://cautery.blogspot.com/2010/09/concise-perl.html http://cautery.blogspot.com/2010/09/concise-perl.html This illustrates the use of Perl in quick one-liners and helps understand why Perl isn't suitable for writing maintainable code. I've seen far too many cases of (and done it myself too often) assumptions like "there's no other tags ending in 'nk'" and "I can parse this XML/HTML content with simple regexps" in the quick & dirty code that is typical Perl (it works, let's use it...). This is where much of the productivity gains and "fun" comes from in the short term and where all the maintainability problems come from in the long term. Evangelists will preach "modern Perl", good style and Moose to you, but these are half-baked, tacked-on solutions, they aren't fun and the overhead destroys the perceived advantages over other languages while not alleviating the massive disadvantages Perl has (performance, dynamic typing, lack of proper threading support...) over modern languages for medium to large size projects. So, use if for one-off jobs and one-liners but don't get sucked into it for anything that intends to grow into a few 100 lines or more. Disclaimer: I've used mostly Perl for ~15 years now and built a company with assorted technical debt, so this is biased on my personal hindsight. YMMV.

kbenson 14y ago
> This illustrates the use of Perl in quick one-liners and helps understand why Perl isn't suitable for writing maintainable code. That's seems like a bit of a stretch to accept from a single anecdote. > I've seen far too many cases of (and done it myself too often) assumptions like "there's no other tags ending in 'nk'" and "I can parse this XML/HTML content with simple regexps" in the quick & dirty code that is typical Perl (it works, let's use it...) So you blame Perl for programmers making poor choices in how they parse their data? > Evangelists will preach "modern Perl", good style and Moose to you, but these are half-baked, tacked-on solutions How are they half-baked and tacked on? > while not alleviating the massive disadvantages Perl has (performance, dynamic typing, lack of proper threading support...) You mind supplying evidence for any of these? For some, dynamic typing is a feature. As for threads, I make heavy use of them every day, and while they have their quirks, they work quite well in some circumstances. Performance?
- ceautery 14y ago
  > 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...

kbenson 14y ago

> This illustrates the use of Perl in quick one-liners and helps understand why Perl isn't suitable for writing maintainable code. That's seems like a bit of a stretch to accept from a single anecdote. > I've seen far too many cases of (and done it myself too often) assumptions like "there's no other tags ending in 'nk'" and "I can parse this XML/HTML content with simple regexps" in the quick & dirty code that is typical Perl (it works, let's use it...) So you blame Perl for programmers making poor choices in how they parse their data? > Evangelists will preach "modern Perl", good style and Moose to you, but these are half-baked, tacked-on solutions How are they half-baked and tacked on? > while not alleviating the massive disadvantages Perl has (performance, dynamic typing, lack of proper threading support...) You mind supplying evidence for any of these? For some, dynamic typing is a feature. As for threads, I make heavy use of them every day, and while they have their quirks, they work quite well in some circumstances. Performance?

ceautery 14y ago
> 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...