http://qs321.pair.com?node_id=461383

Reverend monks,

I have been vorking for a big IT shop doing development on a hash of platforms thru' the past 20+++ years: IBM zOS=>MVS/CICS PL/I, Un*X=>C, MS-DNA=>VB/COM, and at the moment MS.Net=>C#.

I have being occupied developing apps && setting up courses && guidelines for using these OS'es and development environments, -- Basic (yes), C, C++, ASP/JavaScript (sigh), ASP.NET.The way the ball bounces.

Recently (2 years ago) i faced the task of developing a framework for reverse engineering our =~ 40 calendar year, thousands of man year, >4 bill. Danish Kr (you go figure...) legacy software: 68.392 programs, 90.645 includes, 18.562 DB requests, 2.347 CICS-tabelles, ... Enter AWK.

So, yes, coming from Uni*x, i turned to AWK in v.1 to glue together a toolkit for a lightweight reverse engineering of our legacy software. The main components being (on PC/Windows):
MKS utilities Make, MKS utilities Awk. AT&T Research GraphViz Layout (cmap, svg, ps, pdf... etc) yWorks yEd Layout & Viewing (gml) AFPL GhostScript Viewing (ps) Adobe viewer Viewing (svg) Acrobat Reader Viewing (pdf)
The v.1 did well as a proof of concept, but AWK didn't QUITE fulfill my needs of a flexoble scripting language, so i turned to Perl. Enter :
ActiveState Perl Scripting
What a relief!!! A full blown programming language with built in data structs and a powerfull regex machine that did fit my needs like a glove! And as i looked around, -- behold: a CPAN full of gold. So v.2 of the project was much more powerfull, and a pleasure to develop and maintain. Furthermore, with an interest in (and yes, a degree in, -- years back) computer science, i do enjoy the transparency of the Perl language with resp.to types, objects, closures etc. etc.

Now, i stop and ask myself this question;
Perl is beyond doubt a unique programming language and an exceptional community; I'd like to use the Power-of-Perl in more (technical) development projects at work, but working for a traditional IT shop (with fixed standards and firm strategies), that is far from easy to obtain.

You guys out there, with a firm intesest in Perl : what type of IT organizations are you working for, and what type of projects/tasks are you tacking using Perl as your prefered tool. For what reasons, and to what ends are you using Perl in your dailu work?

I'm asking this partly out of curiosity, but also in the hope that your response may spark some inspiration for me (and others like me) as to new projects for wielding this magical mystery sword.

Best regards,
-- allan

===========================================================
As the eternal tranquility of Truth reveals itself to us, this very place is the Land of Lotuses
-- Hakuin Ekaku Zenji

Replies are listed 'Best First'.
Re: use Perl;
by eyepopslikeamosquito (Archbishop) on May 28, 2005 at 22:34 UTC

    When I arrived at a company with around 40 developers, there were zero Perl programmers. Within three years, that had grown to 20. This happened without an official project and without any management "approval". The trick was to not ask for approval but to simply go out and start solving useful company problems with Perl. If you have enthusiasm and what you are doing is useful, others will follow.

    As for specific tasks, when I started, they were building a multi-platform "glue" tool, using Cygwin on Windows (rather than your MKS) to auto build and test a product across around 15 different platforms. Switching to Perl, I was immediately able to speed up some parts of this process from one hour down to five minutes (which was definitely noticed by the people who used to have to wait for an hour!). Someone in another department noticed what I was doing, and decided Perl was an excellent way to allow power users to extend and script our product -- noting that there is no barrier to bundling Perl with commercial product.

    Outside the Web Application sphere, some areas where Perl might be used:

    • Build and test automation.
    • Adding power user scripting capability to product.
    • Product installation and configuration, e.g. Mandrakelinux.
    • Patch creation, distribution and testing.
    • Bug/request tracking, e.g. Bugzilla, RT.
    • Software configuration management, e.g. SVK (built on top of Subversion).
    • In-house wikis for information sharing, e.g. kwiki.
    • Creating slide presentations, e.g. Spork.
    • Timesheet systems.

Re: use Perl;
by dragonchild (Archbishop) on May 29, 2005 at 01:32 UTC
    90% of every Perl application has already been written.

    Procedure:

    1. Find a process your company has that is inefficient.
    2. Whip up a solution in under 40 hours that saves the company significant resources by streamlining the process.
    3. Do #2 in your spare time.
    4. Demo the solution to upper management, emphasizing the cost/benefit ratio as well as the time-to-market.
    5. Be prepared to be called a liar.
    6. Have a bodyguard for a few days to make sure you don't get jumped by the other developers in the parking lot.
    7. Eventually, upper management will either see the light or you will find a better employer.

  • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
  • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
Re: use Perl;
by jonadab (Parson) on May 29, 2005 at 11:11 UTC
    A lot of times, Perl is used for stuff that doesn't have any official status or formal recognition, i.e., isn't on management's radar. The IT people have a problem of their own and solve it using Perl without going to management, or one of the programmers uses Perl to automate a task he used to spend time on, or cetera. Perl is really great for this sort of thing, partly because it's just generally flexible and capable but mostly because it tends to have a very low per-project overhead and make rapid development of such things practical. Projects that aren't on management's radar don't need a lot of non-programming overhead (i.e., nobody has to waste time doing flowcharts and UML diagrams and PowerPointless presentations and cost-benefit analysis on them), so the low programming overhead is more relevant and saves you a larger percentage of the overall project time.

    "In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68
Re: use Perl;
by Courage (Parson) on May 28, 2005 at 20:44 UTC
    I also used PL/I and IBM 360 at very first PC at university.

    Then at work I became C programmer, and, after a couple of years of ineffective C programming I realized that it benefits a lot to include perl chunks of code to speed up my programming, so I used perl as external library.
    As time passed by, I used Perl more and C less, and then I switched to pure Perl, and I consider that as a very good boost for my efforts.
    Still, I use my C knowledge regularry, but only to find a way how to make perl more capable for my tasks :)

    As for my duties at work - I help to transform text files for language translation process, and many related tasks, which is quite interesting area for Perl programming.

Re: use Perl;
by wazoox (Prior) on May 29, 2005 at 07:41 UTC
    My company set up and sell Linux servers. We use perl for practically everything : management interfaces, backup programs, automatic system upgrade, report generation, customer management, bug tracking and support requests...

    We're also developing some data management applications, all Perl. For instance I just shipped a data management software for INA ( french national media archive), that will manage a pool of 40 servers and monitor and index 160TB of storage in an Oracle database. I wrote it in a couple of months (total ~5000 lines of new code) and it just entered the test phase last week.

    I'm pretty sure it was close to impossible to achieve such a work with most other languages on the time frame and budget. Especially with Java, C, C++ and friends...

Re: use Perl;
by aufflick (Deacon) on May 30, 2005 at 02:42 UTC
    I have three perl experiences.

    I run my own freelance development business and as such I make more money if I do more things in less time. That means re-using as much api as possible. If I'm developing almost any kind of collaboration website that means useing OpenACS (http://openacs.org) if I am developing almost anything else, that means programming in Perl.

    I also contract to a very large ISP - here perl is used for Everything (with a capital E). With the blessing of our division head, amd with the slightly-gritted teeth of the internal IT divisions(who take three times as long to get things done as we do :).

    I did contract to an investment bank - A little perl was used with their C++ and Java. Unfortunately the culture was engineered against wide-spread use of perl, but a few far-sighted managers saw that you could replace people with perl scripts, and when that means saved mony - well you're talking their language!

    I have friends who admin and program windows boxes - they wish they didn't. If they used perl, their life wouldn't be as bad. My 2c ;)

use Perl;
by Luca Benini (Scribe) on May 31, 2005 at 09:12 UTC
    The really question is not "Why Use Perl", but "Why none is using Perl Here?"
    Well, i've developed a lot of think in Perl (mirror checking, testing tools...) and also in a lot of other language.
    All language is good for something, simply the Perl is good for more thing than other.
    CPan say you: "Why use Bash Scripting?"
    The supreme RegExp say you "Why Use python?"
    I could go ahead, but Perl doesn't need presentation (oh well not here ;-).
    I found two introduce Perl:
    1_ Replace something (for example in testing tool).
    2_ Do something new.
    You must pay attention that 1 must be done (the first time) in spare time, because you can't (oh well i can't) say to manager:
    "This morning i've rewritten ..."
    because they will say
    "ok, fine.... WHEN? During your coffe break, i hope!!!"
    Perl is extreme powerfull, but also intertia is...
    In my experience (dev/sysadm for a research group) the best way to introduce Perl is to find new needs, and resolve these with Perl... Every place is different, but if you find a problem and resolve it in Perl, Perl will become (in manager mind) the solution for a problem. If you rewritten a script in Perl it will become only An alternative to XXX
Re: use Perl;
by Ninthwave (Chaplain) on May 30, 2005 at 11:43 UTC

    We moved Perl into the Windows based Financial Company I work for. Simply by using it to automate tasks. We have 15k machines to manage and all of the backend processing on the accounts, the anti-virus and the package distribution slowly became automated, via perl. That was how we got Perl into the company. It wasn't even a conscious effort to get Perl in. When comparing it to other tools Perl was more efficient and allowed us a fast turn around time, and as for cost, it never really showed up on the budget outside of our man hours and the projects we used it for. In any environment Perl can be used in my opinion to efficiently process large volumes of data and automate the response to that data or organise the reports so support staff can respond more quickly. And in any type of shop there are jobs that are being doing daily, weekly, monthly that you can set perl up to do for the company so that it frees up those man hours to focus on the core value of the business. And any manager will appreciate that.

    "No matter where you go, there you are." BB
Re: use Perl;
by Adrade (Pilgrim) on May 31, 2005 at 07:13 UTC
    Dragonchild's points 5 and 6 rather remind me of the following quote, from Epictetus's Handbook.
      22. If you have an earnest desire of attaining to philosophy, prepare yourself from the very first to be laughed at, to be sneered by the multitude, to hear them say,." He is returned to us a philosopher all at once," and " Whence this supercilious look?" Now, for your part, don't have a supercilious look indeed; but keep steadily to those things which appear best to you as one appointed by God to this station. For remember that, if you adhere to the same point, those very persons who at first ridiculed will afterwards admire you. But if you are conquered by them, you will incur a double ridicule.
    It seems to me quite true also - other programmers unfamiliar with Perl don't seem to quite understand how anything happens so easily and so well. I have used Perl in all sorts of environments - in the position of coder, but also interning in a VC and in a leasing company - just to get mundane tasks done easier. Currently, I'm doing some freelance work for this cruise company that needs to accomplish these really simple tasks but can't seem to be able to do so in their current environment. The management constantly thinks its totally amazing, the things that are getting done - and I think some of the full-time programmers feel a bit threatened. I think the thing here is that these tasks mostly have to do with either client-server stuff or reformatting output from other programs, the kinds of things that Perl does really easily but that in some other languages can be really tedious. :-)

    Perly best,
      -Adam
Re: use Perl;
by ady (Deacon) on Jun 01, 2005 at 18:24 UTC
    So, looking at your answers to use Perl; i conclude that you Perl developers out there:
    * rely on the great flexibility and capability of Perl * esp. in the areas of large volume text transformation and report gen +eration * in multi-platform glue tool scenarios * to speed up programming and facilitate process automation * thus saving money and thereby earning management approval Establishing this truth to a traditional big IT-shop management by : * initially flying below the radar, not asking for formal approval * but starting to solve useful company problems * initially as a proof of concept (in your spare time) The apps you mention are typically in the sysadm and tech.tool departm +ent: * sys.automation (patch/upgrade, build/test/backup) * sys.adaptation (install, config, user scripting) * sys.management (customer, interfaces, suport, bugs) * tools (wiki, time managers etc.)
    This is very much what i expected, and to a large degree reflects the process that i have lived through in my own life with Perl: my main Perl app. up till now has been solving a real company need by developing a glue-tool for automated transformation of a large text database to graphics file format, and glueing this to a range of graphic editors and viewers. To some degree in my spare time, and certainly keeping the "Perl part" below the waterline, just mentioning i was using "a scripting techniques" (as opposed to the full blown company sanctioned language environment development platforms) to deliver the product on schedule. On the side i have been setting up a company twiki site and thrown together some Perl scripts to help solve data transformation tasks for colleagues.

    I can see some additional usage scenarios for Perl in our company in build/test automation as some of you mentioned, and i intend to explore this further in the time ahead.

    I still wonder if any one out there use Perl for real enterprise scale end user application development, possibly relying on OO techniques. Though i beliewe Larry Wall has characterized Perl OO as being "bolted through" the Perl5 language (and i must agree that OO is not as elegantly integrated in Perl5 as in many other OO languages), my experience with Perl/Tk has been very positive, so it seems it should be feasible to develop big end customer apps in Perl too. Of course this would hardly be able to fly "below the management radar", so that may explain why no one has mentioned this type of Perl apps...

    Thanks for your feed back fellow monks!
    Best regards,
    -- Allan

    ===========================================================
    As the eternal tranquility of Truth reveals itself to us, this very place is the Land of Lotuses
    -- Hakuin Ekaku Zenji