Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Client prefers java, but wants to hear a case for Perl

by Ovid (Cardinal)
on Apr 17, 2001 at 03:27 UTC ( [id://72994]=perlquestion: print w/replies, xml ) Need Help??

Ovid has asked for the wisdom of the Perl Monks concerning the following question:

Well, I'm back in the US (and missing Amsterdam a little, but happy to be back). Today is my first day on the job and one of my tasks is outside of my expertise.

We are bidding on a Web-based project for a government agency. While I am not at liberty to discuss the specifics of the project, some of the general functionality is as follows:

  1. Accept credit cards.
  2. Manage user accounts.
  3. Serve information from databases.
  4. Handle several XML interfaces to external systems.
Additionally, due to the sensitive nature of the data that will be managed, security is a very strong concern.

Nothing's terribly complicated, but here's my problem: a rather large corporation is also bidding on the project and has convinced the client that IBM Web Sphere and IBM Visual Age for Java are the optimal tools for development of this software. The client is willing to hear us make a case for Perl, but we don't have any Java programmers.

I could probably toss out a few of the standard comparisons between Java and Perl -- issues related to CPAN, OO, and the like -- but given the specifics of what is listed above, I'm at a loss. I can do a great job of explaining why taint checking is an invaluable tool for Web security, but I'm not sure on the other issues. Any Javamonks out there willing to deal with specifics? I've read through many of the Java vs. Perl threads that I found through Super Search, but the information didn't seem as useful as I was hoping for. I'm not doing this just so I can advocate for Perl. After all, maybe Java is a better choice for our potential client. I just want to make sure I can pay my rent :)

Summary of the above ramble: How would you show Perl in the best light in terms of the above requirements, especially vis-a-vis Java?


Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

  • Comment on Client prefers java, but wants to hear a case for Perl

Replies are listed 'Best First'.
Re: Client prefers java, but wants to hear a case for Perl
by tinman (Curate) on Apr 17, 2001 at 04:04 UTC

    First of all, a bit of background: I work for a company that is a near 100% Java shop. Most of the projects that they've done have had similar requirements to the ones you mention. After a long (well, 6 month) battle (its still ongoing, I assure you), I've managed to convince the software development lead to let me use Perl for a project.

    I will also tell you that I do a lot of Java coding, unfortunately, Java and DB jobs are far more frequently found than Perl jobs, at least where I come from :o)

    This post is one where I make some points about the differences between Java and Perl.. I'll tell you some other reasons that I used to convince my dev lead that trying out Perl is a good idea.

    I know you've mentioned it before, but I can't stress enough on how incredibly useful it is to have a central repository of code like CPAN. That is one place where Java fails to some extent, because to be honest, most Java resources are pretty fragmented. From a software development perspective, there are two immediate advantages, there is a free code base to start on (most useful Java classes and beans cost big bucks), and its all in one place, so no one needs to search the Net looking for the best tool to do the job. So, there are immediate savings there.

    The node referred above mentioned code size, and similar sentiments can be found throughout that thread and many others. Java is detail oriented, and well, the more code, the potential difficulties in debugging and maintenance are there..Perl is much better in that it can get the job done faster and smaller.

    Performance and widespread use: just mention Slashdot, Perlmonks and other sites with lots of "eyeballs".. Perl has no difficulty handling large volumes of traffic.. and its widely used.

    Its been my general observation (I've done and shown small tests to my dev lead) that DBI is generally faster than JDBC.. besides, one big problem that they (the java folk) encountered was that JDBC drivers for ODBC data sources that approached production quality, were expensive as well... so, database access is taken care of..

    As for XML, well the project that I'm currently doing requires several large XML feeds to be parsed and thrown into a database. XML::Parser and all the higher level XML modules are readily available, and I've not found Java equivalents for all the diverse XML related modules found on CPAN.

    So, in short, what I did with my project lead was ask what Java could do that Perl could not... and the answer is: not much.. Yes, Java has certified, standardized APIs and reams of documents supporting. Yes, Java is much further along threading than Perl is... but that is balanced by cost effectiveness, equivalent or better speed, and most times, much faster time to deliver (I'm betting that you're more productive than any two average Java programmers, even on a bad day ;o)

    Summary of my long ramble:Perl is cheaper to use when considering the bells and whistles needed for a production system, faster to code, equivalent or better than Java at almost all jobs that you want to do.
    As you can see, I convinced my lead mainly of the economic benefits of using Perl.(He heard me because its the era of tight budgets ;o) I know there are lots of programmers in my company who are my equal or superior in terms of skill, but I know I have the better tool for this kind of job (I'm doing something very similar with Perl now.. just no secure transactions), and that gives me a lot of confidence...

    HTH, and good luck..! :o)

    Update: Yes, I used the same links that dws pointed out, showed them to my lead too ;o)

    Edited 2001-04-16 by Ovid

Re: Client prefers java, but wants to hear a case for Perl
by dws (Chancellor) on Apr 17, 2001 at 03:31 UTC
      Yes, and we used perl to implement the on-line Census 2000 form last year and had no security problems. We've used Perl/Apache implementations and Web Sphere for different projects and while they're all successful. the perl/Apache ones sure are cheaper.
Re: Client prefers java, but wants to hear a case for Perl
by Anonymous Monk on Apr 17, 2001 at 05:50 UTC
    Java seems to be higher on the buzzword list than Perl these days, and managers gravitate towards buzzwords and glossy brochures like moths towards light. You have my deepest sympathies in having to explain to non-technical managers the various benefits and drawbacks of using Perl vs. Java because I've been there, man, done that.

    However, based on experience coding web applications in Perl and Java, I can tell you from experience that there is virtually nothing that can be done in Java that cannot be done in Perl.

    For credit card processing, I've used the Signio Perl client. (Signio was bought by Verisign, I believe, so it may now the the Verisign Perl client.) It works beautifully.

    For managing user accounts and session information, my company built a simple application server (I can give you details if you e-mail me) for use in a mod_perl environment which worked flawlessly. It was extremely reliable, customizable (because we built it!), and fast fast fast. It serves out millions of web pages a month, and benchmarks show that if we bring all 3 of our app servers online, we could handle peak loads which, normalized for load distributions, would project to hits in the low hundreds of millions a month. We had uptimes of about 200 days, and only needed to reboot to add memory or other hardware.

    If you're not inclined to build a simple application server of your own, check out Velocigen. They provide a fully featured, robust, and well-tested application server built on Apache/mod_perl for a price. I've heard good things about them.

    In comparison to Cold Fusion, upon which a couple of my comany's other products were built: (i) The entire site would break when one Cold Fusion page was snookered, (ii) (I kid you not!) 18 Windows NT application servers were required to support 23 million page views per month and (iii) (really, I kid you not) the Windows NT servers had to be rebooted on a rotating schedule nightly. And yet, I found myself often having to justify the use of Perl to management-types who more strongly associated the word "enterprise" with Cold Fusion, understood that Cold Fusion was a commercial product, and didn't quite know what to make of Open Source as a concept.

    For handling database information, DBI is your best friend. And processing and organizing the information in Perl is so much easier once you've got it from the database that any comparison to Java is meaningless.

    For handling XML, there are (at my last count) over 150 modules on the CPAN to parse XML. Over 150!

    For writing template-driven web applications, my experience with the CPAN's Template module is that it gives you all the advantages of Cold Fusion's template-driven web application development, or JSPs for that matter, and is just as easy to master.

    Finally, if an IDE is really important to the powers that be (I don't find it all that important, and even when I write Java, I build code skeletons in Visual Age then write the code itself in Emacs because it's so much more efficient for me), ActiveState just released V1.0 of Komodo, an IDE for Perl. Apparently they need to speed up the rendering a bit, but it's got all the basic features you need.

    So in terms of your requirements, there is nothing that you need that hasn't been done, and been done very well, in Perl.

    Now that we've established that all your requirements can be met by reliable and well-tested Perl tools, here is what I would base my assessment on:

    1) Unless what you need to build is already readily available in Java, it is much faster (in terms of coding time) to build applications in Perl than in Java. Period. I know of 2 shops that tried to build what had originally been speced for Perl in Java, and gave up because both the development and the applications themselves were too slow. (They went back to Perl.)

    2) The Apache/mod_perl combination provides tremendous speed and reliability.

    3) Java is seen as more of an "enterprise" solution (I put the word in quotes because it is so often abused), but unless you're building the next Yahoo, your requirements will not exceed Perl's ability to serve out web pages. If you need to build application components, which would involve storing and retrieving or transmitting objects (i.e., serialization/deserialization), then Java is your tool of choice. It doesn't sound like that is a requirement for you, however.

    4) Java has more robust coding tools and commercial support for various products such as application servers (although there is nothing you've stated in your requirements that Perl cannot do).

    5) Java coders are a dime a dozen these days. Experienced Perl coders are not. Though my experience managing developers is that experienced Perl coders are far more technically literate in general than your average Java coder with equivalent experience. I'd rather have a stable of Perl coders any day than a stable of Java coders with equivalent experience if getting a product out the door in a limited amount of time was the objective.

    So given the contents of the diatribe above, if I were making technical recommendations again, I would certainly advocate Perl (or PHP or a combination) for most web projects over Java provided I had the personnel with the experience to execute. Would management at your average company agree with me? If they knew what I know, they would agree with me. If their eyes glaze over when a glossy brochure is put in front of them, they would not.

    Hope this helps!

Re: Client prefers java, but wants to hear a case for Perl
by diskcrash (Hermit) on Apr 17, 2001 at 08:41 UTC
    Brother Ovid (possibly sister, who is to know...) -

    Some thoughts-

    • Check out what "Web Sphere" actually is (for all the licensing costs) its major component is the Apache Web Server, with some bags hung on the side. I understand many of the bags aren't bug free.
    • Appeal to their government procurement concerns; what vendors can provide Visual Age and Web Sphere? - only one - IBM. Not by any means a bad company, but it is a sole source decision. Who can you "buy" Perl from? - show them the supported platform lists. A huge and positive delta.
    • Consider complexity management. Show them a comparison of code snippets. Perl, even clearly written Perl, is generally more maintainable and concise.
    • Don't let them be snookered in by the "power" of Object Oriented development. Its valuable in many cases, but not neccesarily for their applications. Well written structured code often beats OO for clarity and maintainability. Yes you can OO in Perl, but that's not its fundamental beauty.
    • Whip through a list of the modules that give great strength to Perl, the NET:: stuff, the business:: stuff. They will recognize and value these existing code assets.
    • Web Sphere and Visual Age have a lot of black box componentry. Who is to know what is in there? The Perl components can be inspected and re-built by a security team at any time to validate their internal functions. Try that with proprietary tools. You can also do a digital signature on the Perl source and use Federal standards to validate the integrity of this code, over time.
    • The Perl community probably has 1000 to 3000 serious contributors. (Someone who knows for real please give an accurate count.) How many developers are on the IBM team? Can't be that many.

    Now, don't get me wrong, Java beats the living, brown &%&*^ out of C++, but Perl can do the heavy lifting and be far more maintainable. Hope this helps, please let us know the outcome.


Re: Client prefers java, but wants to hear a case for Perl
by Daddio (Chaplain) on Apr 17, 2001 at 05:04 UTC

    My employers are moving from "some Perl and lots of C CGIs" to basically a complete Java shop. One of their major arguments for not using Perl at all is that "it is not supported." What they meant by that, to the best of my knowledge, is that there isn't any paid support for Perl.

    We did a little searching and found that ActiveState has Commercial Support available for Perl (and I am sure there are others).

    Now the "powers that be" are reconsidering their stand, especially after my group of three pumped out some quick code to do some pretty involved statistics and data mining, all in less time than it took them to put "formal requirements" around the project.

    So, I don't know if "support" may be part of the argument for Java (and possibly against Perl), but it shouldn't be.

Java v. Perl at our company
by gregw (Beadle) on Apr 17, 2001 at 15:35 UTC
    Sorry this is long, but I've spent the last six months co-writing a Perl application that does exactly those four things(!) And interestingly for your purposes, our startup was so intent on making sure that our project got done ASAP to beat competitors to market that, as a risk-management insurance policy, we hired an outside firm to implement the project in Java. So this is an issue dear to my heart. (A couple of us inside guys have been building it in Perl.)

    I'm tempted to give you my perception of the Java/Perl tradeoffs straight but I understand that's not what you're asking for. ;) To answer your immediate question: "How would you show Perl in the best light..." your best approach is to define or redefine the problem as a text-manipulation problem. Perl is just a much, much better and easier tool for handling text, due largely to regexp stuff that is awkward, missing, or slow in add-on Java libraries and oh-so-useful when you know how to employ it. And XML at least, and to a lesser degree, 'serving database information' (redefined as formatting db info for viewing) both tend to be heavily text-manipulation-intensive tasks, right? So that shouldn't be a hard sell.

    Credit card stuff may be a little tricky until you get it working, but frankly, it's only a page of code or so and its been done a zillion times in either language. Use LWP or Net::SSLeay to open a secure (SSL) connection and munge your data so it fits the format the credit card processing company wants. And besides various libraries (signio? haven't used it), some credit card companies will point you to sample perl source which demonstrates my point that its really not much more than a page of code you stick in a subroutine somewhere. (Plus whatever custom exception handling you want to perform when cards are rejected.)

    Managing user accounts? Well, I can't think of an advantage one way or the other unless you try to develop some scheme to piggyback your application's user account mechanisms on top of system-wide usernames/passwords in which case perl may have UNIX hooks (or string processing) which make it better.

    Taint is clearly a unique feature useful for the highly-important security aspects. Depending on the client's biases, you may be able to convince them that obscurity is not security, and that critical open source perl/cpan hashing and encryption routines are heavily scrutinized by black and white hats worldwide and not just thrown together in some ISV's back room with a hope that since nobody sees the source, they'd have to get lucky to break it and that's an acceptable business risk for the ISV.

    Taking my advocate's cap off, it's not the quality of the language; the quality of the programmers is a much bigger factor that swamps language differences. The following paper gave me some empirical data that validated my perceptions on that score, as an interesting attempt to quantify productivity and other issues among the various languages: An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program. (Note that the task that was studied was text/script oriented to begin with and thus not fully representative of any/all situations. I wouldn't depend on the paper for gospel truth, but it's great when you can make a nice generality about Java code-bloat and then, when challenged, be able to point to at least one academic study investigating that. It's not proof, but its better evidence than handwaving.)

    So how did our Java and Perl teams fare when going head-to-head? Well, the details get complicated but basically, the 2 Perl coders beat out the 2-5 (it varied over time) Java programmers in delivering something to ship to market that runs reasonably reliably and scales at least decently under mod_perl. Now Perl-vs-Java wasn't the only variable at work, so there could be other factors coming into play (motivation differences, understanding of the specs and application were different, start/finish goal posts were not identical, etc). So it's not a clean win. But perl can definitely compete for these mid-size projects; don't let some fancy Java shop intimidate you! :)

    While I'm only a Java novice, from what I can tell, Java forces you to do a lot of extra typing/infrastructure work to get something done. (Visual Age might reduce that somewhat, although it wouldn't seem to reduce the ongoing maintenance burden of that infrastructure.) So its not necessarily optimal for time-to-market. (Better than tracking down C buffer overflows or pointer errors though, true. Which is precisely how corporate America got sold on Java- as a internet-(buzzword)-oriented 3x programmer productivity boost over C, a better C++.) But I do have the suspicion that as you start to grow projects beyond, say, 5-10 programmers, you end up having to mimic a lot of the practices Java forces on you that otherwise Perl makes optional. But it sounds like for your client this won't be a critical issue.

    I'd say sell him on your excellence, and make sure that such excellence comes across as 'responsible excellence' (documentation, coding stds, etc.), avoiding cowboy stereotypes. You already know you won't get shot down for pure buzzword compliance, since they're willing to consider Perl. Just portray yourself as the leaner, meaner competitor to a shop that probably does Java just because they can charge the client more for it, not because its a better solution. ;)

Re: Client prefers java, but wants to hear a case for Perl
by clemburg (Curate) on Apr 17, 2001 at 15:50 UTC

    I would play on:

    • licensing costs (WebSphere is expensive)
    • training costs (WebSphere with VisualAge for Java is a sure productivity killer - just been there)
    • rapid development and incremental approach (Perl) vs. framework/waterfall/customization approach (WebSphere)
    • interfaces to external systems - Perl is adaptable, WebSphere either provides adapters or you are lost
    • complexity - is something like WebSphere really needed
    • how big will the development team be - with Perl you can get something done with a few people (one to five), with WebSphere you will have to have many different specialists (three upwards) to get anything done
    • show the client a convincing solution for support, with respectable names on this
    • provide respectable references that use Perl for commercial applications, e.g., from the DBI references list

    I think you will lose, though. I have tried to argue this exact case with several big clients, and lost all arguments (might be my fault, of course). Try to define a cut-off point to decide how much resources you will spend on trying to convince the client. Otherwise this might become an acquisition resources black hole. (Extremely sorry to say this, but it is my experience.)

    Christian Lemburg
    Brainbench MVP for Perl

      Ironically even the Java fans that I know have generally bad things to say about VA, but it seems to have a strange appeal to the PHBs...

      Anyways, you might try to find someone who has used it extensively and can give you a view from the trenches about its true resource requirements, instability, bugs, etc. (That person would not be me, but it should not be too hard to find someone, I know that several at IWETHEY liked complaining about it.)

        Oh, I did not say I lost due to "objective" reasons, like technical features, stability and so on. I lost due to a very strong belief of the client that said "I want a standard product from a known company with a strong brand name". I was not able to successfully argue Perl against that belief.

        For the technical perspective: I have worked with VisualAge for Java and WebSphere, and my conclusion is that this combination is a sure productivity killer (we spent days just configuring WebSphere), and unstable on top of that (deployment of EJBs is a true nightmare, with version incompatibilities and everything).

        For more on the WebSphere technical side of this, see this collection of reviews.

        VisualAge for Java is also highly unusual in its IDE approach, at least for those not having a Smalltalk background, and will guarantee a lot of confusion for people coming from a "normal" IDE background. (VisualAge takes the approach that you browse a class hierarchy, modifying attributes of classes and inventing new ones along the way. So, e.g., you will usually work on the source code of a single method only, with the rest of the class not shown in the editor window. To see code in another method, you have to change to a new window (or "frame"), forcing you to decide on a commit/cancel for your changes. But who cares anyway.)

        Christian Lemburg
        Brainbench MVP for Perl

Re: Client prefers java, but wants to hear a case for Perl
by Anonymous Monk on Apr 17, 2001 at 08:13 UTC

    The choice depends on what you want your company to achieve with the project. Do you want to get the job done quickly, effectively and at an agreed to price? Then the answer is use perl, document well, collect your payment and be sure to ask if you can use them as a reference as a satisfied customer.

    On the other hand you mentioned that this is a government contract job. In such a situation do you want to ride the Java gravy train of no foreseeable code freeze? Do you want to charge your client to do various web searches for regular expression and printf() replacement libraries? Do you want to re-write most things again and again as the political bickering within you and your client's organization draws the project out longer and longer and ...

    Such bloatware is the key to financial success. Just look at IBM and Microsoft today.

(atl: Selling a project) Re: Client prefers java, but wants to hear a case for Perl
by atl (Pilgrim) on Apr 17, 2001 at 17:47 UTC

    quite some things were said about the how or why, mostly on technical terms or money. Taking the viewpoint of a salesperson (yuck!) I think three steps are required:

    1. Convince your customer that your technology (and people) can do the job. Easily. Have done it before. Many times. ;-)

      For each of your points:

      • Accept credit cards.
        No prob, someone above pointed out perl examples.
      • Manage user accounts.
        No prob, we can interface with the OS user management or implement our own.
      • Serve information from databases.
        DBI rulez (at least I never had probs getting what I wanted from a database via DBI; let's you switch databases if you want, just as JDBC). If I remember correctly, btrott has deeper knowledge of DBI, check his home node.
      • Handle several XML interfaces to external systems.
        Currently I am using XML::Parser and XML::XSLT with _great_ success. Main problem may become memory usage, but that is inherent in the DOM specification, anyway, so no different in Java.
    2. Point out at least one critical weakness in the other approach. One might ask: how do I handle many concurrent sessions without the need for a very big (read: expensive) machine like IBM SP or Sun E?k ?
    3. Make your offer (how much, how long).
    Hope this helps ...


Re: Client prefers java, but wants to hear a case for Perl
by princepawn (Parson) on Apr 17, 2001 at 04:14 UTC
    I would like to hear what you have to say about Perl and security. I have heard of some different things like Net::SSLeay but don't know much about Perl security.
Re: Client prefers java, but wants to hear a case for Perl
by mamboking (Monk) on Apr 17, 2001 at 17:25 UTC

    I would focus on the cost issue. If they are going to be using Websphere, then they will need to use VAJ Enterprise Edition. VAJ EE is $2800 per developer (site licenses or government discounts would make it less). WAS Advanced Edition is $10,000+ depending on how many processors are involved.

    BTW, there are some non-development issues in regards to using WAS. One of the really nice administrative features is cloning. With minimal effort, an administrator can clone a server onto another server and have the two machines be load balanced.

Re: Client prefers java, but wants to hear a case for Perl
by mothra (Hermit) on Apr 17, 2001 at 21:44 UTC
    From perlfaq1:

    How can I convince my sysadmin/supervisor/employees to use version (5/5.005/Perl instead of some other language)?

    If your manager or employees are wary of unsupported software, or software which doesn't officially ship with your operating system, you might try to appeal to their self-interest. If programmers can be more productive using and utilizing Perl constructs, functionality, simplicity, and power, then the typical manager/supervisor/employee may be persuaded. Regarding using Perl in general, it's also sometimes helpful to point out that delivery times may be reduced using Perl, as compared to other languages.

    If you have a project which has a bottleneck, especially in terms of translation or testing, Perl almost certainly will provide a viable, and quick solution. In conjunction with any persuasion effort, you should not fail to point out that Perl is used, quite extensively, and with extremely reliable and valuable results, at many large computer software and/or hardware companies throughout the world. In fact, many Unix vendors now ship Perl by default, and support is usually just a news-posting away, if you can't find the answer in the comprehensive documentation, including this FAQ.

    See for more information.

    If you face reluctance to upgrading from an older version of perl, then point out that version 4 is utterly unmaintained and unsupported by the Perl Development Team. Another big sell for Perl5 is the large number of modules and extensions which greatly reduce development time for any given task. Also mention that the difference between version 4 and version 5 of Perl is like the difference between awk and C++. (Well, OK, maybe not quite that distinct, but you get the idea.) If you want support and a reasonable guarantee that what you're developing will continue to work in the future, then you have to run the supported version. That probably means running the 5.005 release, although 5.004 isn't that bad. Several important bugs were fixed from the 5.000 through 5.003 versions, though, so try upgrading past them if possible.

    Of particular note is the massive bug hunt for buffer overflow problems that went into the 5.004 release. All releases prior to that, including perl4, are considered insecure and should be upgraded as soon as possible.

    And while you're at it, you might as well read this.

Re: Client prefers java, but wants to hear a case for Perl
by gregor42 (Parson) on Apr 17, 2001 at 17:36 UTC

    Brothers, I wish to tread as lightly here as the beating of a butterfly's wings....and try not to start a Tidal Wave.

    This is, after all, Flame Bait ..

    Lest not we start a(n) (un)Holy War, I will say that truly IMHO either approach is valid. However, that was not your question. Your question was how to make a case for PERL.

    First of all it is correct to point out that IBM's WebSphere, etc. is amongst the poorer choices one might make for a Java Application Server. In my experience they'd be better off buying into ATG Dynamo or at worst BEA Weblogic. So right there, it shows that they have not done their homework. That should cast doubt immediately on their plans.

    Secondly, I'd like to state that there is no disparity of toolkits available in the Java realm, however... And this is an important point.. You have to pay for them. Whereas PERL is free to all who care to learn. That reduces the project overhead to a manhours driven budget. Much simpler.

    Third, if you dare, slip them the URL for perlmonks on a piece of paper (ack! Dead Trees! Better to beam them on their Palm. Electrons aren't clearpathed..) and show them the wide availability of resources available. (Not to mention your monstrous XP. ;-))

    Wait! This isn't a Parachute, this is a Backpack!

      It is interesting that you say "IBM's WebSphere, etc. is amongst the poorer choises..." because my company is currently using iPlanet's Application Server, but is switching, after long debate and evaluation, to IBM's WebSphere.

      This really scares me now, as we have had enough problems with iAS, and I was hoping WS would be better, especially with all the evaluation they did.

      Unfortunately, I don't get a say in the evaluation or decision, I just get to make it work...

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://72994]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (6)
As of 2024-06-18 00:33 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.