Perl usage

I was wondering if someone on this group could help out here. I know
there are alot of positions posted on this, but was hoping someone had
some solid info to point to.

I have used Perl for projects here and there. However my manager
keeps telling me that Perl should not be used for real projects. It
seems like a pretty solid language to me. Are there certain types of
applications that Perl should not be used for? I am trying to put
together feedback from experts as to why perl is just as valid as many
other languages. Can someone help?

http://expertcodeadvice.com/index.php?topic=7.msg14#msg14

Re: Perl usage

Kevin wrote:
> seems like a pretty solid language to me. Are there certain types of
> applications that Perl should not be used for? I am trying to put

perldoc -q perl:
"Can I do [task] in Perl?"
"When shouldn't I program in Perl?"
"How can I convince my sysadmin/supervisor/employees to use [...] Perl
instead of some other language?"

jue

Re: Perl usage

On Mon, 26 Nov 2007 13:47:54 -0800, Kevin wrote:

> I was wondering if someone on this group could help out here. I know
> there are alot of positions posted on this, but was hoping someone had
> some solid info to point to.
>
> I have used Perl for projects here and there. However my manager keeps
> telling me that Perl should not be used for real projects. It seems
> like a pretty solid language to me. Are there certain types of
> applications that Perl should not be used for? I am trying to put
> together feedback from experts as to why perl is just as valid as many
> other languages. Can someone help?

Your manager probably wants someone to take the blame when things go
wrong. Saying "It's a (Microsoft|Oracle|Sun|Whatever) bug that took out a
half year's worth of data" just is more acceptable than "It's a bug in an
Open Source tool we use".

There is not much you can change about that. Even if it doesn't make
sense.

Other than that, Perl is a tool, and as always use the right tool for the
job. Sometimes that's Perl, sometimes it's not.

One good reason not to use Perl is if no one at your job can maintain
your Perl code. Although I don't think it's a great idea to develop a MSVC
++ program that takes a week to develop and another to get the bugs out
where a Perl one liner would have done, it is a valid viewpoint. It's the
reason a colleague of mine develops everything in ksh, even if Perl would
be much better suited to some tasks.

Another good reason not to use Perl is performance, although in practice
that is seldom a real reason. I do develop programs in other languages
when Perl is to slow. Mostly after first proving Perl is to slow, btw.
And, as said, that's pretty seldom, Perl is pretty fast and more often
than not fast enough.

A real good reason not to use Perl in my opinion, although many will
disagree, is when developing big projects. By all means, use it as a glue
language, the language for the web front-ends, for small specific
programs within the larger project. But don't use it for projects that
require millions of lines of code. (I won't go into what language you
should use here, except to note that more important than the language is
experienced seniors, good project management, a solid design that gets
amended as the project goes along, solid regression testing and a solid
development strategy).

But often there are many reasons why you should use Perl. Strong at text
manipulation. Many, many good (although not always perfect) libraries.
Strongly cross platform. Quick development. Once learned, pretty readable
imo, but ymmv, some people think all Perl code is line noise. Good
support for UTF-8. Comes pre-installed with many OSses. Good
interoperation with the outside world.

Some of these reasons may apply to you, some may not. If you're in a
Cobol shop, using Perl may make sense, but it's probably to much of a
culture shock. If you're in a Java shop, the added cost of using an extra
language may not be worth it. If you are in a php shop, ditto. If you are
in a Windows only shop, installing Perl on all machines may take some
persuasion.

Without knowing the reasons your manager has to state that he will not
allow the use of Perl, all is just speculation, but maybe the above is of
some help.

HTH,
M4

Re: Perl usage

Kevin wrote:
> I was wondering if someone on this group could help out here. I know
> there are alot of positions posted on this, but was hoping someone had
> some solid info to point to.
>
> I have used Perl for projects here and there. However my manager
> keeps telling me that Perl should not be used for real projects.

Did your manager tell you why? If not, then we probably can't give you
anything better than the FAQs that have already been created on this topic:

perldoc -q convince

perldoc -q shouldn

If the manager did give you reasons (not covered in the FAQs), we could
possibly formulate rebuttals to do them, if we knew what those reasons
were.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

Re: Perl usage

On Nov 26, 4:26 pm, Martijn Lievaart wrote:
> On Mon, 26 Nov 2007 13:47:54 -0800, Kevin wrote:
> > I was wondering if someone on this group could help out here. I know
> > there are alot of positions posted on this, but was hoping someone had
> > some solid info to point to.
>
> > I have used Perl for projects here and there. However my manager keeps
> > telling me that Perl should not be used for real projects. It seems
> > like a pretty solid language to me. Are there certain types of
> > applications that Perl should not be used for? I am trying to put
> > together feedback from experts as to why perl is just as valid as many
> > other languages. Can someone help?
>
> Your manager probably wants someone to take the blame when things go
> wrong. Saying "It's a (Microsoft|Oracle|Sun|Whatever) bug that took out a
> half year's worth of data" just is more acceptable than "It's a bug in an
> Open Source tool we use".
>
> There is not much you can change about that. Even if it doesn't make
> sense.
>
> Other than that, Perl is a tool, and as always use the right tool for the
> job. Sometimes that's Perl, sometimes it's not.
>
> One good reason not to use Perl is if no one at your job can maintain
> your Perl code. Although I don't think it's a great idea to develop a MSVC
> ++ program that takes a week to develop and another to get the bugs out
> where a Perl one liner would have done, it is a valid viewpoint. It's the
> reason a colleague of mine develops everything in ksh, even if Perl would
> be much better suited to some tasks.
>
> Another good reason not to use Perl is performance, although in practice
> that is seldom a real reason. I do develop programs in other languages
> when Perl is to slow. Mostly after first proving Perl is to slow, btw.
> And, as said, that's pretty seldom, Perl is pretty fast and more often
> than not fast enough.
>
> A real good reason not to use Perl in my opinion, although many will
> disagree, is when developing big projects. By all means, use it as a glue
> language, the language for the web front-ends, for small specific
> programs within the larger project. But don't use it for projects that
> require millions of lines of code. (I won't go into what language you
> should use here, except to note that more important than the language is
> experienced seniors, good project management, a solid design that gets
> amended as the project goes along, solid regression testing and a solid
> development strategy).
>
> But often there are many reasons why you should use Perl. Strong at text
> manipulation. Many, many good (although not always perfect) libraries.
> Strongly cross platform. Quick development. Once learned, pretty readable
> imo, but ymmv, some people think all Perl code is line noise. Good
> support for UTF-8. Comes pre-installed with many OSses. Good
> interoperation with the outside world.
>
> Some of these reasons may apply to you, some may not. If you're in a
> Cobol shop, using Perl may make sense, but it's probably to much of a
> culture shock. If you're in a Java shop, the added cost of using an extra
> language may not be worth it. If you are in a php shop, ditto. If you are
> in a Windows only shop, installing Perl on all machines may take some
> persuasion.
>
> Without knowing the reasons your manager has to state that he will not
> allow the use of Perl, all is just speculation, but maybe the above is of
> some help.
>
> HTH,
> M4

Thanks, these are some very good perspectives.

Re: Perl usage

Jürgen Exner wrote:
> Kevin wrote:
>> seems like a pretty solid language to me. Are there certain types of
>> applications that Perl should not be used for? I am trying to put
>
> perldoc -q perl:
> "Can I do [task] in Perl?"
> "When shouldn't I program in Perl?"
> "How can I convince my sysadmin/supervisor/employees to use [...] Perl
> instead of some other language?"


And this mailing list:

http://lists.cpan.org/showlist.cgi?name=advocacy

Summary:
A discussion list for Perl advocacy. There are usually success
stories, news stories about or involving Perl and discussions
about how to make Perl be accepted in the workplace.


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

Re: Perl usage

On Mon, 26 Nov 2007 13:47:54 -0800 (PST), Kevin
wrote:

>I was wondering if someone on this group could help out here. I know
>there are alot of positions posted on this, but was hoping someone had
>some solid info to point to.
>
>I have used Perl for projects here and there. However my manager
>keeps telling me that Perl should not be used for real projects. It
>seems like a pretty solid language to me. Are there certain types of
>applications that Perl should not be used for? I am trying to put
>together feedback from experts as to why perl is just as valid as many
>other languages. Can someone help?

This is often discussed. In addition to the good pointers you've
already been given, a recent discussion in a Perl community about what
people actually use Perl for is reachable at:

http://perlmonks.org/?node_id=652612


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: Perl usage

>>>>> "x" == xhoster writes:

x> If the manager did give you reasons (not covered in the FAQs),
x> we could possibly formulate rebuttals to do them, if we knew
x> what those reasons were.

It's also worth reiterating here that you can't reason someone out of
a position that he or she didn't get to by reason in the first place.
In other words, no matter what reason he gives, if your manager
arrived at the decision not to use Perl based on gut feelings and
subjective impressions, you most likely won't be able to argue him out
of it with facts.

I've been in this situation a couple times. When you have more than 3
or 4 people in the organization, the options really boil down to
these: first, you can get a consensus among 2/3 of the people working
there that they would be better off in another language; second, you
can get a new VP who thinks the old way is bad and the Perl way is
clearly the way of the future, and who has enough credibility with his
fellow VPs to make that pronouncement stick; third, you can stick with
whatever the dominant programming language there is; fourth, you can
find a job somewhere that they use Perl.

Managers think, and by and large correctly, that they're better off
sticking with a language that their team is comfortable and productive
in, even if it has clear technical shortcomings, than switching to a
new and untested language, even if it has clear technical advantages.
Some of this is merely being conservative, but managers are also more
concerned with clear forecasting: you can get a more reliable
estimate of how long a project will take with a tool you know than
with a tool you don't know, and it's better from a business point of
view to have a reliable estimate than to have a chance of finishing it
in half the time but a comparable chance that it will take twice as
long.

Charlton



--
Charlton Wilbur
cwilbur@chromatico.net