Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • So what would Larry (Rosler) say to Larry (Wall)'s (paraphrased?) "I'll be certified before Perl"?
  • Larry's comfortable with keeping his options open. So, in general, am I.

    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.

  • ... but when you're building a house you don't use sand for your foundation.

    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.

  • I'm not so sure; I'm inclined to think Mr. Rosler suffers from the "everything starts to look like a nail" problem.

    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 machi

  • Yes. I am much less convinced about ISO/ANSI than I am about a written standard of some sort.
  • What kind of advantage do you get by making the program not modifiable by the user?

    The perlfaq used to have a statement in it somewhere that there has never been a false bug report on perl due to locally modified source. It doesn't seem to be there now. (I'm not sure if it was an editorial decision or because it was no longer true.)
  • What kind of advantage do you get by making the program not modifiable by the user?

    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.

  • Who is the OTS and why do they care if code is "modifiable" or not?

    And tellers can do that with "unmodifiable" code. Get some UI hacks. Jump in the registry and randomly delete and modify things.
  • Agreed on the .exe front (although it's slightly off topic). A big headache of mine for distributing Perl software has been the lack of a native "bundling" feature. So I'd have to distribute the whole development environment to people who just want my application.

    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

  • Who is the OTS and why do they care if code is "modifiable" or not?

    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 unde

  • In the end, why should we want ISO/ANSI certs? I mean, Perl *is* the thing that you obtain after a successful compilation of the Perl source. I dont thing Larry is going to use £foo instead of $foo in the next release.
    You need a written standard when you have different vendors re-writing compilers from scratch and each putting in all sort of incompatibilities. But when you have an open source reference version, well, if you choose to use £foo what you get is just non-Perl.

    (this reminds me of

    --
    "Love, work and knowledge are the well-springs of our life. They should also govern it." - W. Reich
  • As a side note, the install of Perl onto a metworked drive for various clients is MUCH easier than that. I did it a year ago, by installing Perl once and sharing out the drive. With it and the use of perl2bat, it made for powerful login scripts!
    Using this, you simply don't have to install Perl on the local client, just map to the shared drive and run Perl from there. There are a couple of minor caveats; ask on the Perl-Win32 list if you're curious.
  • for various clients

    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 de

  • ... they're just serial, not parallel: Perl 4, Perl 5, Perl 5.1, Perl 5.2, ...