Re^2: Why Perl is a Valid Choice

[xdg]

Lately I've been busy correcting the work of lots of unsupervised programmers

Hmmm. Maybe Perl::Critic needs some greater publicity as an automated management tool. :-)

[brian_d_foy]

I don't think this is a technical problem, or one that we'll solve with technology. It's a people problem. If you already have a bad situation, an automated tool isn't going to make it any better. I know you said this with the smiley face attached, but the problem isn't the language. By the time people get to quibbling about the actual code, they've already passed through most of other problems that allowed that to happen.

The best thing that people can do, I think, is work together. Programmers (or any other sort of worker) aren't veal calves to shove in cubicles. Although I won't go as far as recommending company retreats, people in the same organization should know each other, and know what other people are doing.

For managers, this means actually inspecting the work of their subordinates and tracking its progress. You don't do that with an automated tool. You actually have to look at the code, and you have to think about it in terms of everything else. It's not just the syntax that's important, but how it relates to everything else. What does the code let you do? More importantly, what does it keep you from doing? What decisions does the code make for you if you allow a certain design?

A good manager could use Perl::Critic, but tools don't and won't make good managers.

[xdg]

Turning off the smiley-face mode, let me say that on the topic of why Perl is a valid choice, I think the availability of tools or lack thereof does matter. One thing that the Agile movement has (re)discovered is the value of people over process. While that is true, managers of all stripes in all businesses still seem to want a magic bullet and get very excited about platform and tools -- probably because they are tangible when lists of abstract pros and cons are not always so easy to appreciate. That's an important consideration in making a case for a certain language.

Look at the Software Magazine 2005 Jolt Awards. While I'm sure there's guru/advertiser bias, still, how many of those are for Perl, specifically? How many are written in Perl? If there are -- it was certainly hard to tell. Why doesn't Perl get more credit in this area?

Perl has some good tools beyond just CPAN. To expand the attractiveness of Perl to IT managers, it's well worth playing up the tools it provides. Articles like the original post would be stronger for an articulation of the Perl tool chain as well.

Of course, good managers will always benefit more from good tools than bad managers will -- that's almost a truism. But good tools can help good managers allocate their time more wisely.

[brian_d_foy]

I certainly agree that managers should choose the languages with good tools, but I think Perl came to that game pretty late. Over the past couple of years we've gotten a lot better, certainly, but that's pretty recent.

Honestly, we have to admit that for a very long time we (as a community) promoted Perl as a language that didn't need tools: you could just use your favorite text editor and command line. Beyond that, we really didn't provide that much. In my opinion, there still isn't a good Perl project tool. We have debuggers and code editors, but not something that can look at the whole project. Some people like EPIC, but is that really the best we can do? Komodo recently made its way to Mac OS X, but I haven't tried the latest version yet.

So, I'm pretty sure we agree and that we're just talking about different sides of the same thing. Maybe we need a guide to Perl programming in the spirit of Sam Tregar's "Writing Perl Modules for CPAN" that takes the user all the way from logging in, writing code, testing, and so on all the way up to releasing it. Along the way we show all of the tools and provide crib notes for managers about what they should be doing at that point. Maybe we call it "The Practice of Perl Programming" :)