in reply to why i may have to leave perl...

I feel your pain

I wish that my openning line was funnier than it is but I find myself in a very similar position. I have been trying for several months to write a whitepaper for bringing perl into a large, closed, cathedralesque financial organization.

Every methodology I try to establish just seems to take the fun out of perl by taking the creativity and freedom out of the code itself. CPAN, version control, support, style conventions, security, All seem like round holes and all I have are square pegs to deal with.

At the Perl 4.0 Conference I made a great effort to find out the size and scope of the businesses that 'deploy' perl. The term 'deploy' confused 99.9% of everyone I asked and seemed to catch even merlyn by surprise.

My conclusion is that Enterprise perl does not exist and like my perl predecessors it's up to me, and other's like me to make it exist. It may not be as romantic as cleaning up garbage collection in perl 6, but I believe that it is even more important to the immediate growth of perl as an industry accepted language.

Most perl people have no clue that roadblocks exits. The dumbfounded and shaking heads I ran into in Monterey could have shifted tetonic plates when I explained that Perl was not an approved development language in our organization.

As for solutions the three primary things I see that need to be created are:

  1. An internal CPAN module that logs and tracks module installation for version control.
  2. Separating the system perl (especially in the case of Solaris) from the individual developers perl enviornments.
  3. Creation of an internal perl support site where the same type of interaction that occurred in your small team can be shared and participated in by the entire organization.
  4. Strict enforcement of some style conventions such as:
    1. perl -Tw (at least through the system test/readiness phases
    2. Embedded POD documentation
    3. Utilization of perl's internal VERSION control

I'm onto about my 30th crack at this whitepaper so if you come up with anything please share!

coreolyn Duct tape devotee.

Replies are listed 'Best First'.
RE: RE: why i may have to leave perl...
by knight (Friar) on Aug 07, 2000 at 23:29 UTC
    Excellent points. I think the Perl community does have its head in the sand about some of the realities facing acceptance of Perl in other computing environments, especially traditional IT or MIS departments. I know just enough about those places to know that it's a different world from the cozy UNIX environments I grew up in.

    Separating the system perl... from the individual developers perl environments.

    A lot of Open Source projects assume that either you have root access to the system yourself, or have really friendly administrators that will install whatever you want just for the asking. Neither is true for a lot of people out there.

    I think it would help the more widespread acceptance of Perl (and other tools) if they supported real relocatable installation, beyond the ability to specify your own absolute path name at compilation time. The idea is for the tool to support a library and directory structure with relative paths, not absolute paths, so you can check in a verified copy of the tool and know that it's not pulling in any library or module from outside the source tree.

    I haven't tried to concoct a version of Perl that does this, although I did try to create a similar version of GCC once. (It can be made to work, but requires a lot of really fragile symlinking and oddball configuration.) Perl allows you to rely on a specific tool version better than a lot of other systems by supporting side-by-side /usr/lib/perl5/$VERSION/ directory structures, but this still relies on coordinating with the sysadmins to install new versions and modules. I have this gut belief that using Perl in a traditional IT environment would be a lot simpler for all involved if it could be used without relying on installation outside of the source tree, but maybe I'm making this up.

    Does any of this apply to the environment you're targetting?
[reply]

      Knight,

      Your comments are on target for the type of enviornment(s) I'm working to deploy. In the 6 months that I've been pinging on this topic on the various mailing lists. This current thread seems to have recieved more understanding readers than anywhere else ( Yay PerlMonks.org! :)

      I'm going to put together a new thread that points to the various links (sometime today) with a Title of "Perl In The Enterprise" In the hopes of bringing more attention to this issue, and getting as much information on what has been done, and should be done in this area.


      coreolyn Duct tape devotee.

[reply]
RE: RE: why i may have to leave perl...
by Anonymous Monk on Aug 08, 2000 at 07:24 UTC
    There exists within Perl the ability to support such a development and deployment framework. I know, I built one for a Fortune 1000 (620's). It requires dedication to the process and framework, and most important of all, a toolmaster. The easy part is the coding standards surrounding use of the framework to implement override libraries. Then, your applications deploy with whatever versions of libraries you want to use. You can even tier the libraries for enterprise, platform (e.g. dev/stg/prd), and project. Regardless of the complexity of the framework, it must be trivially easy to embed within your applications. Otherwise, your programmers will find the path of least resistance, and following your framework won't be it. I'd be glad to post some code if desired.
[reply]

      I would be VERY interested to see any code, and hear any more comments you might have on this subject.

      coreolyn Duct tape devotee.

[reply]

In Section Meditations