Re^3: Why Perl is a Valid Choice

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.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

Comment on Re^3: Why Perl is a Valid Choice

Replies are listed 'Best First'.
Re^4: Why Perl is a Valid Choice by xdg (Monsignor) on Jan 31, 2006 at 23:47 UTC
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. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^5: Why Perl is a Valid Choice by brian_d_foy (Abbot) on Feb 01, 2006 at 00:26 UTC
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" :) -- brian d foy <brian@stonehenge.com> Subscribe to The Perl Review	[reply]
Re^6: Why Perl is a Valid Choice by xdg (Monsignor) on Feb 01, 2006 at 03:19 UTC
Maybe we call it "The Practice of Perl Programming" So does that come before or after "Mastering Perl" in the series? :-) -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^7: Why Perl is a Valid Choice by brian_d_foy (Abbot) on Feb 01, 2006 at 04:07 UTC
Re^6: Why Perl is a Valid Choice by glasswalk3r (Friar) on Feb 01, 2006 at 13:15 UTC
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? Alceu Rodrigues de Freitas Junior --------------------------------- "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill	[reply]