Joe Johnston (one of our illustrious use Perl authors) interviewed Hewlett-Packard's Larry Rosler for www.perl.com. Rosler discussed standards, using and optimizing Perl, and his pet peeves of programming.
But the question must be asked: Is Larry's personal comfort level more important than the future of Perl?
I think it would be wonderful to have a more formal and complete reference document specifying what can be depended on and what cannot. Whether such a thing were eventually blessed by ISO/ANSI is a separate question, really.
We've been so successful in making a useful tool that we're now being held to tool standards instead of toy standards. Is this what we (there is no `we') intended? Maybe not. But it has happened.
To whatever degree we as individuals have contributed to Perl's popularity, we are responsible for dealing with the consequences.
While standardization is certainly a nice thing (she said, having just re-coded a major app that got bit by undocumented changes in the behavior of a library, albeit not a core one), my experience (limited) has been that the "Why can't I get a hello.pl.exe?" issue has been a bigger one. It's not an issue in cgi apps, but when you're rolling out something to a whole truckload of Windows machines, installing all of Perl and *then* your app starts to look like a Microsoft Bloatware install (granted, you only have to install Perl once, and then the individual apps are much simpler, assuming you've got a shared library area).
Additional gripe, although not a built-into-the-language problem: there's no (in the version I had, at least) "client" install for Activestate Perl on Windows. Installing it to a drive named F: (mapped to a standard network location) works real good up to a point... it just overwrites the existing Perl install each time, blissfully unaware that all the other clients are using it, which is okay. Unfortunately, it merrily removed any non-core libraries that had been installed. But I digress.
Anyway, just having a nice
In the banking industry, you get little advantages like "The OTS doesn't shut you down."
Even assuming you've just got client-side-type code out at the teller station, and all the transactional security really is at the host end, and you've convinced the OTS, FFIEC, and FDIC that this is Really Okay, the idea of a teller dinking around with his/her interface is kind of a support person's nightmare.
I've become a religious user of perl2exe and then taking the result and bundling it into a Winzip self-extracting install-shield load.
The ususal arguments (they should get all of perl! it's bloatware! you're obfuscating! you're source hiding!) don't phase me a bit. The people I distribute to don't care about source (I'll give it to them if they ask), they don't care about bloat, and they really don't want to program. They just want software that works.
Office of Thrift Supervision, if I remember correctly. (There's an equivalent critter for national banks; I work (past tense in a week) for a community bank that is growing up from an S&L.)
Anyway, they audit everything about a (thrift) bank, including computer security. Right now, they've got a whole bunch of IT-oriented auditors left over from Y2K certification, so they've got nothing better to do than put banks' IT practices under a microscope. Which is probably a good thing, to an extent.
And tellers can do that with "unmodifiable" code.
Oh, without question... nothing is completely userproof. But given the choice between something that requires being able to modify an
(this reminds me of a nightmare i've had: I imagined win32 versions of perl doing everything with activex create object.... that could be a real incompatibility issue)
And for various packages of Perl, I imagine. For some reason, under NT Workstation, and with that particular flavor of Activeware's, it insisted on weird registry entries and/or envariables. It was probably do-able without the InstallShield package, but when you're sending the package out for end users and/or Grade 4 techmonkeys to install, that was even more complicated.
But that's not really something inherent in Perl, just a sideline whine. And after Friday, I'll never have to deal with NT again. Whee.
