Hi,
Maybe if I explained why I think this is a good thing. As it stands right now, in order to use perl on a Windows box or on a unix/linux box, we need to install a variant of Perl on to it. Well and good except for mom & pop shops, corporate environments, etc. where the IT dept (if there is one) have their hands full with just maintaining the boxes and they really don't need to be installing and maintaining additional software except where absolutely necessary.
If a client machine was running Windows XP and was relatively current on the os patches, we would not have to install Perl on the box. We would write our perl script, send it through the Perl .NET compiler and install the .NET component (remotely maybe) without having to install Perl itself.
One thing I have noticed on PerlMonks, is that many perl coders sometimes forget that writing a script for a single box is not at all like writing a script for 50,000 machines where it has to work on 99.99% of the boxes 100% of the time. By taking the requirement to install perl on all the boxes out of the picture, we are able to reasonably support the 50,000 (or more) machines. Therefore, we would now have a valid argument to take to management about using Perl .NET over VBScript.
comments?
Jason L. Froebe
No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1
| [reply] |
If you compile your Perl code to CLR bytecode (or whatever), how does it handle eval STRING? Does it really work like that?
I think the best general solution to the deployment/distribution problem is PAR/PerlApp/perl2exe + possibly a decent installer.
For the specific problem of wedging Perl into a .NET environment, sure. But won't the C# people have problems with that? I think you'd better find a darn useful solution on CPAN to get away with it, and they'll still try to re-implement it after you solved the problem with an existing module.
/J
| [reply] |
You are probably not alone in terms of your 'main vision'
I have considered a lot of the same things. One problem is
you never know the practicalities until you start writing
code and evaluating for yourself according to your own preferences. (for example, can you tolerate having to use POD sections as part of your perl code, or is that an unacceptably inelegant kludge for you?; are you happy having to 'retrofit' your existing perl code in order to get it to run under dotNet?)
Another problem was eluded to by J ... specifically, the VB dotNet and the CSharp dotNet folks will bristle at the thought of having to look at "ACK!" Perl code. It shouldn't have to be that way, but there is a lot of language zealotry, and fear of "having to learn another language" ... even though the additional knowledge would probably make life easier for all involved. ...
That just seems to be the prevailing pattern.
| [reply] |