Re^4: Why Perl is a Valid Choice

[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" :)

[xdg]

Maybe we call it "The Practice of Perl Programming"

So does that come before or after "Mastering Perl" in the series? :-)

[brian_d_foy]

Actually, I think it would come right after "Learning Perl", and maybe that will change in the Perl 6 edition. So far the Llama has always been a programmer's intro to Perl and it assumes the reader already knows how to program. Who knows though. ;)

[glasswalk3r]

I agree with that. And not only about the programming tools (I myself discovered perl.vim only after some years programming): Perl has nice solutions for a lot of things, but they are not integrated. It takes time to put everything together and companies just want to have the application delivered as fast as possible. It's important to get productive if you want to get a share from programming languages like Java.

For example, how many application servers does Perl have? Ok, there is OpenInteract, I must say that I never used it, but all the feedback that I have is not good: the tool looks like too complicated. Do the community have a specification, a "must have list" to create other tools like OpenInteract?

Maybe the community have more options (maybe Maypole?) but the point is: why such information is not in the Perl default documentation?