He’s upset that he can’t tell the difference between building your own tool and using one that someone else has already written. He shows a Perl program using Text::CSV_XS (the correct way to do that). The program looks well written and reasonable; it’s even commented. Nightmare?

On the other side, he shows the command-line use of csvcut, a program written in Python. I think it’s a nice program; when I saw this defective tweet I downloaded csvcut and tried it. Nice job, programmers! However, @Nolaan_boy is not writing Python and is not dealing with the Python language. I’m sure he’d have an equally hard time dealing with the Python source.

He could have posted that csvcut was a really nice program that solved his problem. He could have used it and been done with life. But, that’s not what he wanted to do. He wanted to bash Perl. I don’t mind if you don’t like Perl, but if you’re done with it, you don’t have an ongoing emotional response to it. That means you’re still letting it influence you.

But this really isn’t about Perl. This is about a particular Python failure mode where programmers reinforce their bonds by attacking a common target. They don’t need Perl to be that target, but it’s what the Python in-crowd has latched on to. Instead of talking about the great things coming out of Python, they have to bash things they don’t understand.

As I emphasize in Mastering Perl, faster code comes from better algorithms instead of different syntax. The difference between tr/// and y, for instance, is so insignificant that the real problem is the time you waste thinking about it.

But, the big problem with these benchmarks and the people who tout the results is that they don’t run them more than once. They get an answer and stop thinking about it.

Benchmarking is dangerous because there’s not an answer. There are many answers and many things to consider. After I run a benchmark, I run it again to see if I get the same answer. Typically, the percentages change a bit, but in this case the two snippets trade places too:

If I thought that these two operators were different, I might be confused by these. Instead of stopping here, I want to try something else. I’ll benchmark y against itself. I should get the same times for each snippet because it’s the same thing:

Comparing the y to itself shows that there’s some inherent uncertainty in the measurement. And, there always will be. Ignore that to your own embarrassment.

Notice that across the runs that the rate ranges from 4612502/s to 5324464/s. That’s a difference of about 700,000 iterations, or 15% of 4,612,502 or 13% of 5,324,464. Those differences are much greater than the relative percentages in the reports. That’s a problem. Running another test right after a test gives different results even if the percentages within the test are the same. Damn you multi-tasking computers!

Gervase Markham writes about a New Class of Vulnerability that shows the unbridled ego that leads to someone blaming the language and ignoring their own lack of competence.

He writes about a new class vulnerability for what he labels a bug. It’s neither new nor a bug. Miyagawa wrote about this in 2009 in Perl: Why parameters() sucks and what we can do, and that’s still not the origin of it. I know about in the 90s when I was making these mistakes. If you think you’ve found something new, you’re probably wrong. Don’t get too excited too soon.

Gervase is writing about the param method from CGI.pm. In particular, in list context it returns a list of all the form fields with that name:

my @params = $cgi->param( $field );

If there are no form fields with that name, it returns the empty list. That means when Bugzilla used it in list context to create a hash, it was courting disaster by not properly checking its return value:

If there’s no realname, param returns an empty list and cryptpassword becomes the value for realname.

This is a problem with the competence of the Bugzilla developers. Hey, it happens. But, it’s how you react when you mess up that matters. Blaming the language is the wrong move. It’s not even a language issue. It’s a misuse of a designed and documented API.

But, that’s not the real problem here. The syntax and API misuse is the problem. The Bugzilla developers are taking unfiltered and invalidated input directly from the user and doing things with it. Even if the param method did what they expected, they are still wrong.

This sensationalist posts then make the rounds of the internet, amplified by people who never bothered to learn the tool. It fits their uninformed mental models of the world. Other ignorant people are quick to jump onto that bandwagon because they mirror the behavior of the group they want to belong to. And, most everyone ends up worse for it.

If you mess up, take the blame for it and move on. It makes life so much easier.

Perl gets us used to the idea that we can throw a list at a function and it all works out. The first item in the list becomes the first parameter, the second list item becomes the next parameter, and so on. We expect these two calls to some_sub to act the same: » Read more…

Can’t use CPAN modules? If you can’t, you have company, whether you want it or not. CPAN Dependency Hell is a real problem, and it’s much worse if you’re an experienced Perl programmer. Management might want to clamp down on third-party, unsupported code. Lawyers might be afraid. I don’t want to get into that bit though. I’ll concede, for the purposes of this post, that these people can’t use any CPAN module. » Read more…