Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^2: Packaging Perl Programs (is) Painful

by Sue D. Nymme (Monk)
on Sep 04, 2010 at 00:02 UTC ( #858823=note: print w/ replies, xml ) Need Help??


in reply to Re: Packaging Perl Programs (is) Painful
in thread Packaging Perl Programs (is) Painful

When coding for Windows - use .Net - otherwise why are you using Windows?

There's some truth to that.

I have been holding out for Perl, because so many data-oriented things are just plain easier in Perl. Connecting to data sources, collating data (push @{ $group{$row->{key}} }, $row; is a beautiful thing), dealing with NULL/undefined values, pattern matching, and so on. Perl makes the easy things easy.

GUIs are more work in Perl than in .NET, sure. But WxPerl is quite good if you can work with the documentation (which is slowly getting better).

But when it comes to getting Windows system information, networking to Windows services, and packaging final products for delivery, .NET wins hands down. Perl is stuck in Unixland, with assumptions about where libraries are going to exist and what sorts of things users are expected to have installed.

I would far and away rather be developing on Ubuntu or some other *nix variant than on Windows. I had hoped that Perl would make Windows programming less painful. And in part, it does! But only so long as you have a full Perl distribution installed and don't have to mess too much with C compilers. (Ever try getting Curses.pm to work on Windows?)

I've been resisting giving in to the Dark Side and going over to C#.NET, but maybe it's time.


Comment on Re^2: Packaging Perl Programs (is) Painful
Download Code
Re^3: Packaging Perl Programs (is) Painful
by ruzam (Curate) on Sep 04, 2010 at 02:11 UTC
    Resist the urge. It's still a Dark Side after all. There's no coming back and sooner or later you're going to find yourself on the wrong side of a Death Star explosion.
Re^3: Packaging Perl Programs (is) Painful
by Marshall (Prior) on Sep 05, 2010 at 11:25 UTC
    giving in to the Dark Side and going over to C#.NET

    It is possible to make a Perl module available to the .NET framework so that any language in .NET can use it. It is also possible to use a .NET object from a Perl script.

    This sounds as bizarre as mating a giraffe with a turtle, but evidently ActiveState has figured out how to do it. This link ActiveState PerlNET Overview shows an example of shows an example of a Perl module (WWW::Babelfish) being called from within a .NET C# program.

    Anyway, it would seem that it would be possible to say build a GUI within .NET and use Perl for say the DB code or use some other kind of functionality provided by an existing CPAN module.

    I have never personally used PerlNET. But if some mixed Perl and .NET implementation were desired, then PerlNET seems like something to consider. Of course this isn't freeware and you would have to have an AS PDK license.

      I don't know where you've been since, oh, 2002, but PerlNET was stillborn.

      You're better off using something like Inline::MonoCS to communicate with C# code. (Yes, I wrote it).

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://858823]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (6)
As of 2014-09-20 08:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (157 votes), past polls