RE: Question for this Group ... dont flame me :)

[Jenda Krynicky]

From: Jeff Westman <[EMAIL PROTECTED]>
> Guay_Jean-Sébastien <[EMAIL PROTECTED]> wrote:
> > b) As new need arises in your program, using a module gives you
> > access to other functionality which you would have to (again) write
> > yourself if you were not unsing a module.
>
> But would you agree, that at least in some cases, it is "almost" as
> hard to use and understand a CPAN module then to write your own?  Some
> of the documentation out there isn't the greatest :)

Then everyone will be really gratefull if you send some doc patches!

If you spent a lot of time trying to figure out what does the module
du, write your findings down, rewrite the docs and send them to the
author. Some good coders are horrible documentors (and they usualy
know it about themselves) so do make the life easier for those that
come after you.

Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Question for this Group ... dont flame me :)

[drieux]

On Dec 12, 2003, at 10:42 AM, drieux wrote:
[..]
Yes, and No. Again the presumption here is that we
are discussing at the 'professional obligations level'
and not at the academic/hobby level.
[..]


Drieux! You KankerousBoilOnTheBottomSideOfYourSithLord!
That whole academic v. professional issue is CLOSED!!!

someone needed to get seriously flamed in this thread,
and well, we just need to improve the quality
of flaming to begin with.
Then there is the minor mechanical point that has
been missed in the discussion so far
	perldoc -m Foo::Bar

will allow one to see the 'internals' of the
Foo::Bar module itself and not merely the POD.
Unlike the 'standard c libraries' - which tend
to be raw binaries, unless one happens
to have the source tree for them, perl is very
open about the process. Which is both good and bad.
The good side is that one can see how others have
solved various technical issues, the bad of course
is that one can also come across the 'sausage making'
that has encrusted a 'mature and stable module'.
And Yes, you can do

	perldoc -m perldoc

but BE VERY VERY QUITE, it can get way, uh, scary
in there Big Fanged Beasties roaming around...
ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Question for this Group ... dont flame me :)

[drieux]

On Dec 12, 2003, at 8:23 AM, Guay Jean-Sébastien wrote:
[..]
Perhaps the "real" Perl distribution
differs from ActiveState Perl on what modules it includes by default?
[..]

I think the OP has the 'imaginary' Perl distribution.
Cold out of the wrappers the default installation
for various vendor supplied versions of perl 5.8.X
releases do not have "Date::Calc".
Various Linux Vendors have 'base installs' and
'extended installs' and 'hyper-extended installs'
that install "should have been core modules" that
are tilted towards
a. web stuff
b. database stuff
c. Dangerous Perl Sub Cults
Then there are the SysAdds who have their own
suite of OCD's, and hence will take in the vendor
supplied, vendor supported suite of basics, and
then tweak out their own "Minimum to Bid" collections
without which, well, they can become hostile, irratible
and really dangerous if cornered...
Be very Careful Around SysAdds. The Can BITE.

Also worth remembering, the PerlKabal is normally
managed with a SithLord and an Underling. Be Very
careful around them as well - they tend towards
the Dark Side of the Perl...
ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Question for this Group ... dont flame me :)

[drieux]

On Dec 12, 2003, at 7:25 AM, Jeff Westman wrote:
[..]
p0: most of the cool arguments have been generally made.
my kvetching here will therefore be the less cool stuff.
So, installing a module is out-of-the-question.
In my case, I am basically "stuck" with the perl [5.8]
default libraries and modules.
Yes, and No. Again the presumption here is that we
are discussing at the 'professional obligations level'
and not at the academic/hobby level.
I had a contract where the obligation was, well so
tight that I could not even presume that CGI.pm would be installed.
So I wound up documenting the core basic perl modules that had
to be there, I think Socket.pm and one other - as Required to
be there. { note - we will return to this TPFH whine later
in the section on application library, below. This is
forward referencing for the compiler...}
So the 'no' side of that rests upon arguing the case that
the Foo::Bar module HAD to be a part of the 'install' for
the project. Something that I did back when Sys::Syslog
was NOT a part of the default 'core bundle' - since it was
just easier to get it into the required modules lists that
would be installed on the production systems than have to
re-write all of that code.
[..]
While the solutions shown here will most often work,
they aren't practical for Joe Programmer working in the corporate world
(don't flame me! LOL) who doesn't have access to install as root or 
install
on many many servers.
As noted above, unfortunately there is no module

	Fix::Broken::Management::Food::Chain

but I think we would all love to install it if anyone
could get the time to debug it...
{ small technical design problem to note - if folks
thought that keeping track of cross platform OS issues,
including whether to retain support for VMS was ugly,
has anyone even begun to work on the topology of
MangledManagement... I mean, think about the problems
of implementing a simple
$fbmfc->bad_manager_no_banana_for_primate()
method that would allow a simple interface generic
enough to cover all of the primates???}
So one side of the 'joe programmer' problem is how to
get MangleMent to 'get it' about
a. open source solutions
b. getting modules into the build train
so that they will just install as a part of
the overall process
In one organization the PerlKabal had stronger Voodoo
than the PythonKabal in that the PerlKabal just stepped
up to the plate and solved the problem of how to 'pre-build'
the CPAN modules and get those 'pre-builds' into simple
Solaris Pkg installables so that the Solaris Package Management
software would do the whining for us about required package
version control. So from the standpoint of Manglement, they
didn't "know" that the FOOpl was the base perl release and
that the FOOplx were the CPAN module Extensions - even IF
the freaking
	pkginfo -l FOOplx

said that it was our set of CPAN module extensions...
They just went "is solaris package, is required, is on
check list, must be installed, installation good"
So a part of the issue is how to solve the correct brokenness.

[..]
I suppose one way to point to a CPAN module and not have to install
as root would be to install the module in the application library path.
[..]

Now you are starting to have that Decaff Moment.

There are two 'issues' with this 'application library path'
phrase, since it can either mean:
a. relative to the 'bin dir' of the project
b. in my home directory where I stash stuff...
In the former case, I am S there with you. If you look
at the stock Mac OSX model the foo.app is actually a 'directory'
where inside there is an executable and all of the associable
stuff that goes with it. There are many ways of solving the
offset from where the code actually IS when executed,
	cf: perldoc FindBin

and you are so ready to be rocking that solution.

Catch_forward_reference_here:

As noted in the first part, the problem of 'not being
allowed to have CPAN modules' as a part of the project
was driven in part by the problem of needing a 'pure perl
solution' that of course precluded any module that required XS
components, as well as would lead to those unpleasantries were
someone to 'fix' the site_perl section on a host. Fortunately
the GreatLeader was not so JackBooted as to say 'no modules'.
Merely that the modules were NOT going to 'install in the
same old CPAN way' into site_perl - so the work around was
to manually tree them down in
	$INSTALL_DIR/lib//...

hence all of the cgi code had the caveat

	use lib "../lib";

and of course the obligatory form

	use ::Foo::Bar::Baz;

So the same strategy can be re-used for non-cgi code,
one just has to give up on certain luxuries about doing
it the 'traditional perlish way'...
{ yes, it is possible to be APOSTATE about perling...
but be very, very careful about it, and don't tell folks. }
Most of us start laying out our home directories in the form

$HOME/lib
perl5/
 

RE: Question for this Group ... dont flame me :)

[Guay Jean-Sébastien]

> I don't know if this [specific] module is "standard" 
> or not, but it was already installed on the servers, 
> so I am guessing it is.

I don't think it is, or at least it wasn't installed by doing a full install
of ActiveState Perl 5.8 in my case. Perhaps the "real" Perl distribution
differs from ActiveState Perl on what modules it includes by default? If
not, you might just have a precedent you can use to get them to install
other modules! :-)

> But would you agree, that at least in some cases, 
> it is "almost" as hard to use and understand a CPAN 
> module then to write your own?

But using my argument that if you write your own code to do one thing, you
might have to write your own code to do some other related thing in the
future, then learning how to use this module that probably does all you need
to do will pay off in the long run. 

I hear you about docs, though. And sometimes, even good docs don't help that
much, because what you need to do is very very specific... That's just part
of the game.

> But I've used some modules from CPAN just as this 
> group suggest  just to find out it had a bug in it.  

That's one of the evils of the "release early and often" philosophy of Open
Source. The counterpoint of that being that it will probably improve
quickly, especially if you're not the only person who finds that
functionality potentially useful. People (maybe you?) will pick it up, fix a
bug here, another there, and re-upload it. If the maintainer's email is
dead, someone else will probably even take up maintainership of the module!
That's one of the beauties of this model, it's very organic. As long as
someone finds something useful, it will prosper.

> [...] they (naively) feel that it would adversely 
> affect the perl executable itself and/or other 
> application developers using 'perl'.

That's one of the conceptual problems you'll have to work out with them,
unfortunately. You can only remove those false conclusions by telling them
what a module is/does in general, and that code that doesn't 'use' the
module should not be affected.

> Another responder to this question also suggested 
> to at least evaluate the code from the module so 
> as not to completely re-invent the wheen (good
> suggestion, BTW).

I'm not sure if this amounts to the same thing, but you could make a
directory parallel to all your projects (where I assume you have access),
say /prod/lib, and put the modules there, in the same directory structure as
they would be in /usr/perl/lib or /usr/perl/site/lib. From there, you can
add that path to your library path with 'use lib "/prod/lib";' and then
'use' modules from there as if they were in the Perl install. This allows
you to put modules there (be sure to have an identical structure on your
development server) and not actually install anything directly into the Perl
distribution directory.


Good luck,

J-S

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: Question for this Group ... dont flame me :)

[Jeff Westman]

Guay_Jean-Sébastien <[EMAIL PROTECTED]> wrote:

> These answers are of course my own experience, but may be significant to
> understand the bigger picture. I reorder your points a bit in my reply :-)

No problem :)
 
> > So, why is it that most of the solutions represented 
> > in this group tend to point to a CPAN module when 
> > the code for it isn't that hard (usually) to write?  
> 
> a) It may not be hard to write, but it may have implications you don't see
> at first. For example, something dealing with dates. Does it need to deal
> with leap years? Does it need to deal with localized date formats? etc. etc.
> When you use a module like Date::Calc, the writer has thought of this, has
> written it when only thinking of what the module needs to do and do well,
> and has normally well tested each part of the module.

I would definitely agree with you on Date::Calc.  It's saved me more than once :)

I don't know if this [specific] module is "standard" or not, but it was already
installed on the servers, so I am guessing it is.

I have NO problem with using 'standard' modules.  Just like the C library --
it's just part of the industry standard.
 
> b) As new need arises in your program, using a module gives you access to
> other functionality which you would have to (again) write yourself if you
> were not unsing a module.

But would you agree, that at least in some cases, it is "almost" as hard
to use and understand a CPAN module then to write your own?  Some of the
documentation out there isn't the greatest :)

[...]
> The other point is that when you're working on increasingly large projects,
> you reach a point where the amount of work for a given project would be too
> large (in time/money/etc) to be practical. That's when using modules for the
> general "low-level" parts is really useful. 

This is true, and if it is a "tried and tested" module (like Date::Calc or 
Net::FTP), I would totally agree with you.  But I've used some modules from CPAN
just as this group suggest  just to find out it had a bug in it.  When
trying to contact the originator, the email address was defunct.  So (being 
honest here) it makes me a little bit paranoid to use a module out there just
because it is on CPAN.  If it was one I've seen listed here many times, I would
tend to trust that particular one.  But face it, there are hundreds if not
thousands of modules found in CPAN.  And not all of them were written by the
perl gurus :)

>  Using modules can, in some
> cases, prevent you from thinking of a project as code, and more as "how do I
> solve this problem". That's why in large projects, most people will want to
> make modules of their own for some parts of a problem that can be
> generalized (if an existing module doesn't already exist). It factors out
> some parts of the problem (once the module is well tested), and brings you
> to a higher level of abstraction.

For larger projects requiring complex algorithms, I wouldn't hesitate to find 
something in CPAN.  

> > But if any of you are like me, you don't have 
> > access to install modules that run in a production 
> > environment.
> 
> It's pretty easy to download a batch of modules onto one machine, and make a
> script to install them all onto multiple machines. Even if you can't do it
> yourself (because there's an evil SysAdmin who won't give you access) you
> can give him a package, containing the module tar.gz files and the script,
> and it won't be hard for him to install them. Most SysAdmins have developed
> a way of running a given command on the whole farm of servers... (chell
> scripts, normally) 

The admins here are a bit strange.  They see no problem with me adding 
application code to do this or that, but they DO have a problem with code
being added to "/appl/site/perl5.8/lib" [or whatever] since they (naively)
feel that it would adversely affect the perl executable itself and/or 
other application developers using 'perl'.  Yet I can install my own bug-
ridden code code and bring the server to its knees.  Go figure :)

> And if the SysAdmin still doesn't want to, go a bit higher, stating the fact
> that installing these modules will reduce your work load (increase your
> productivity), make your programs require less testing, etc. Managers react
> well to things that translate directly to dollar signs, and you're actually
> telling him the truth to boot!

You're absolutely right, and that is perhaps where *I* need to make 
my case.

Another responder to this question also suggested to at least evaluate the
code from the module so as not to completely re-invent the wheen (good
suggestion, BTW).

> Hope this helps,

Yes it does, thanks.


-Jeff


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Question for this Group ... dont flame me :)

[Wiggins d Anconia]

FLAME! FLAME! ;-)...


> Question for this group.  And please don't flame me for asking this.
> 
> Often times one writes in, asking how to do something fairly trivial,
> such as a date conversion from a non-standard format, or doing something
> else not require too much overhead.  


The problem, is to me, context, if doing date conversion is "fairly
trivial" then why are there so many modules involving it, and why are
they so complex?  There were at least two issues involved in the post
that I assume sparked your questions, 1 the ordering of the parts, some
parts of the world use a mm/dd while others use dd/mm, while I prefer
-mm-dd the people at the bank think I am weird when I date my checks
that way, the other being that the year was stored in two digits instead
of 4.  So often a response is to use a module because a responder has
"been down that path before, you know where it leads..." and doesn't
want that person to have to make the same mistakes again.  Better
examples include CGI header parsing, and e-mail parsing (don't try this
at home boys and girls!) or e-mail sending. While they seem simple
enough, they are actually incredibly complex beasts because they have
"matured" (read: so many people (and large corporations that start with
M) have added so much crud to the original specs that standards no
longer hold and you have to be insane to attmept to tackle all
possibilities yourself).  So while the OP may see them as simple, and in
some cases the context can be narrowed down to such a fine scope that a
module may be over kill, in general this is not known or stated apriori,
so the responder takes them as their normal complex selves. Then there
is that whole re-invent the wheel thing ;-)...


When asked for advice, nine times
> out of ten, the responded will refer the originator to such-and-such
> module at CPAN to download and install.  

Many of them also come with more recent Perl installs. Prior to 5.6 you
didn't get many of the modules commonly noted, after that and depending
on your distribution you do get them with the base install (thank god).

I'm all for not re-inventing
> the wheel -- don't get me wrong.  But if any of you are like me, you 
> don't have access to install modules that run in a production environment.

Right but is this a fault of the responders quoting that a module should
be used, or yours?  (Don't take that negatively).  If we are talking
about a true production environment then surely you have version control
systems, release management tools, automated processes for pushing
software updates into service, etc?  Part of running a "true Perl app"
aka not a bunch of 4 line scripts put in root's cron, is having the
ability to install CPAN modules and keep a local repository.  I would
insist that what you really have isn't a production enviroment.  Also as
I pointed out to Dan, this is an open source world where you can check
for yourself, so often a module may be mentioned as a place to find an
implementation rather than actually sucking it in and using it in whole
(although that meaning may be lost on beginners, especially from
winders, just pop the hood baby!)...

> In my case, we have a couple of test servers and several hundred satellite
> servers that run 'production code'.  So, installing a module is out-of-
> the-question.  In my case, I am basically "stuck" with the perl [5.8]
> default libraries and modules.
> 

How do you distribute your code to the satellite servers?  Couldn't you
do the same with the CPAN modules? Granted we are running a single
server production environment, but we install the modules to Q/A using
CPAN then copy the full repository to production rather than
re-installing. Naturally this relies on Q/A matching Production, but
then I wouldn't want to work where they don't!

> So, why is it that most of the solutions represented in this group tend 
> to point to a CPAN module when the code for it isn't that hard (usually)
> to write?  I'm not sure if using modules is a matter of "convenience"
> or "necessity".  While the solutions shown here will most often work,
> they aren't practical for Joe Programmer working in the corporate world
> (don't flame me! LOL) who doesn't have access to install as root or
install
> on many many servers.
> 

I think the simplicity of the problems mentioned here cause this overall
effect, currently the application I am working on is 15K+ lines (not a
lot) but if you factor in the thousands of lines of code I *didn't* have
to write by using a framework such as POE, logging system Log::Log4perl,
 incredibly complex mail handling by Mail::Box, and the GPG encryption
system then all of a sudden the number of lines has grown
astronomically... and I (well my employer) got all of those without
paying a cent! What a world!

> My point being, it might be helpful to provide a solution such as 
> 
>  See xxx::yyy at CPAN or my solution below
> 

It might, but in many cases "my solution below" would be completely
inap

RE: Question for this Group ... dont flame me :)

[Tom Kinzer]

btw Jeff, good post.

I think this will stimulate a good conversation.  This is a common problem
with lots of different workarounds.

Thanks.

-Original Message-
From: Jeff Westman [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 7:26 AM
To: perl_help
Subject: Question for this Group ... dont flame me :)


Question for this group.  And please don't flame me for asking this.

Often times one writes in, asking how to do something fairly trivial,
such as a date conversion from a non-standard format, or doing something
else not require too much overhead.  When asked for advice, nine times
out of ten, the responded will refer the originator to such-and-such
module at CPAN to download and install.  I'm all for not re-inventing
the wheel -- don't get me wrong.  But if any of you are like me, you
don't have access to install modules that run in a production environment.
In my case, we have a couple of test servers and several hundred satellite
servers that run 'production code'.  So, installing a module is out-of-
the-question.  In my case, I am basically "stuck" with the perl [5.8]
default libraries and modules.

So, why is it that most of the solutions represented in this group tend
to point to a CPAN module when the code for it isn't that hard (usually)
to write?  I'm not sure if using modules is a matter of "convenience"
or "necessity".  While the solutions shown here will most often work,
they aren't practical for Joe Programmer working in the corporate world
(don't flame me! LOL) who doesn't have access to install as root or install
on many many servers.

My point being, it might be helpful to provide a solution such as

 See xxx::yyy at CPAN or my solution below

I tend to believe that most people part this list distribution do coding
for a living, while others just tinker with it on the side or are
students.

I suppose one way to point to a CPAN module and not have to install
as root would be to install the module in the application library path.

Thoughts?


-Jeff


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: Question for this Group ... dont flame me :)

[Guay Jean-Sébastien]

Hello Jeff,

These answers are of course my own experience, but may be significant to
understand the bigger picture. I reorder your points a bit in my reply :-)

> So, why is it that most of the solutions represented 
> in this group tend to point to a CPAN module when 
> the code for it isn't that hard (usually) to write?  

a) It may not be hard to write, but it may have implications you don't see
at first. For example, something dealing with dates. Does it need to deal
with leap years? Does it need to deal with localized date formats? etc. etc.
When you use a module like Date::Calc, the writer has thought of this, has
written it when only thinking of what the module needs to do and do well,
and has normally well tested each part of the module.

b) As new need arises in your program, using a module gives you access to
other functionality which you would have to (again) write yourself if you
were not unsing a module.

There are other reasons, but these are the main ones, and can be distilled
to "foresight is not 20/20". Not even close, in most cases (for most
people).

As a coder, if you have to deal with demands of users, and don't code
strictly for yourself, then you can never know what your users will ask
next. So the previous point is especially important.


The other point is that when you're working on increasingly large projects,
you reach a point where the amount of work for a given project would be too
large (in time/money/etc) to be practical. That's when using modules for the
general "low-level" parts is really useful. Using modules can, in some
cases, prevent you from thinking of a project as code, and more as "how do I
solve this problem". That's why in large projects, most people will want to
make modules of their own for some parts of a problem that can be
generalized (if an existing module doesn't already exist). It factors out
some parts of the problem (once the module is well tested), and brings you
to a higher level of abstraction.


> But if any of you are like me, you don't have 
> access to install modules that run in a production 
> environment.

It's pretty easy to download a batch of modules onto one machine, and make a
script to install them all onto multiple machines. Even if you can't do it
yourself (because there's an evil SysAdmin who won't give you access) you
can give him a package, containing the module tar.gz files and the script,
and it won't be hard for him to install them. Most SysAdmins have developed
a way of running a given command on the whole farm of servers... (chell
scripts, normally) 

And if the SysAdmin still doesn't want to, go a bit higher, stating the fact
that installing these modules will reduce your work load (increase your
productivity), make your programs require less testing, etc. Managers react
well to things that translate directly to dollar signs, and you're actually
telling him the truth to boot!


Hope this helps,

J-S

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Question for this Group ... dont flame me :)

[Rob Dixon]

Jeff Westman wrote:
>
> Question for this group.  And please don't flame me for asking this.
>
> Often times one writes in, asking how to do something fairly trivial,
> such as a date conversion from a non-standard format, or doing something
> else not require too much overhead.  When asked for advice, nine times
> out of ten, the responded will refer the originator to such-and-such
> module at CPAN to download and install.  I'm all for not re-inventing
> the wheel -- don't get me wrong.  But if any of you are like me, you
> don't have access to install modules that run in a production environment.
> In my case, we have a couple of test servers and several hundred satellite
> servers that run 'production code'.  So, installing a module is out-of-
> the-question.  In my case, I am basically "stuck" with the perl [5.8]
> default libraries and modules.
>
> So, why is it that most of the solutions represented in this group tend
> to point to a CPAN module when the code for it isn't that hard (usually)
> to write?  I'm not sure if using modules is a matter of "convenience"
> or "necessity".  While the solutions shown here will most often work,
> they aren't practical for Joe Programmer working in the corporate world
> (don't flame me! LOL) who doesn't have access to install as root or install
> on many many servers.
>
> My point being, it might be helpful to provide a solution such as
>
>  See xxx::yyy at CPAN or my solution below
>
> I tend to believe that most people part this list distribution do coding
> for a living, while others just tinker with it on the side or are
> students.
>
> I suppose one way to point to a CPAN module and not have to install
> as root would be to install the module in the application library path.

One of the most powerful aspects of Perl is that it can be extended so
easily. If a poster made it clear that he was unable to add to the
root or private installations then we wouldn't offer a modular solution.

As you say:

Jeff Westman wrote:
> Most people part this list distribution do coding for a living, while
> others just tinker with it on the side or are students.

So most people should be able to get modules installed, either by
themselves or their sysadmin. But I know that there are non-responsive
adminsitrations about.

I would be a huge waste of time to offer the option of both a CPAN
module and manually-coded solution, to every question. Most modules
represent many hours of coding effort. Quite often, though, I have
often answered a question by saying that you could use module 'X', but
it wouldn't be worthwhile unless you needed the whole of the package
and four lines of Perl will suffice in the simplest case.

HTH,

Rob



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: Question for this Group ... dont flame me :)

[Tom Kinzer]

Well, I'm a professional Perl developer.  I have also been in your position
before Jeff.

I can say that it is just a "best practice" to always use a module.  It's
just smart to reuse modular code.

1) it saves building work
2) it's already tested
3) it's already documented
4) in many cases it's supported by the author(s)
5) it's more maintainable because it usually will have a somewhat standard
interface and/or at least you may have a chance that another team member or
contractor will already know how to use the module somewhere out there.

So, I'd say, if it's in any way feasible to do so, a module makes sense.  If
it's just out of the question, I suppose the poster should state that
constraint.

In any case I don't think it's because people aren't using Perl as a serious
production tool.

As to how to get around it:  You can always install your own version of
perl.  You then have a few perl path issues to deal with, but you can put
whatever modules you want in without mussing any of the "system" perl tools.

-Tom Kinzer

-Original Message-
From: Jeff Westman [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 7:26 AM
To: perl_help
Subject: Question for this Group ... dont flame me :)


Question for this group.  And please don't flame me for asking this.

Often times one writes in, asking how to do something fairly trivial,
such as a date conversion from a non-standard format, or doing something
else not require too much overhead.  When asked for advice, nine times
out of ten, the responded will refer the originator to such-and-such
module at CPAN to download and install.  I'm all for not re-inventing
the wheel -- don't get me wrong.  But if any of you are like me, you
don't have access to install modules that run in a production environment.
In my case, we have a couple of test servers and several hundred satellite
servers that run 'production code'.  So, installing a module is out-of-
the-question.  In my case, I am basically "stuck" with the perl [5.8]
default libraries and modules.

So, why is it that most of the solutions represented in this group tend
to point to a CPAN module when the code for it isn't that hard (usually)
to write?  I'm not sure if using modules is a matter of "convenience"
or "necessity".  While the solutions shown here will most often work,
they aren't practical for Joe Programmer working in the corporate world
(don't flame me! LOL) who doesn't have access to install as root or install
on many many servers.

My point being, it might be helpful to provide a solution such as

 See xxx::yyy at CPAN or my solution below

I tend to believe that most people part this list distribution do coding
for a living, while others just tinker with it on the side or are
students.

I suppose one way to point to a CPAN module and not have to install
as root would be to install the module in the application library path.

Thoughts?


-Jeff


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Question for this Group ... dont flame me :)

[Daniel Staal]

--As off Friday, December 12, 2003 7:25 AM -0800, Jeff Westman is 
alleged to have said:

So, why is it that most of the solutions represented in this group
tend  to point to a CPAN module when the code for it isn't that
hard (usually) to write?  I'm not sure if using modules is a matter
of "convenience" or "necessity".  While the solutions shown here
will most often work, they aren't practical for Joe Programmer
working in the corporate world (don't flame me! LOL) who doesn't
have access to install as root or install on many many servers.
Convenience.  You could always write the code directly in assembly, 
if you really needed to, but just like it is usually easier and 
better to use Perl it is usually easier and better to use a module.

My point being, it might be helpful to provide a solution such as

 See xxx::yyy at CPAN or my solution below
Most modules are Open Source.  If you really can't install them, you 
could use their code directly, or indirectly through a rewrite.  (And 
don't tell me you would then have to give away your application: very 
few Open Source licences require you to give the code to anyone who 
is not using the program.  If it is in-house only you have the code.)

Daniel T. Staal

---
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]