Re^2: 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

Replies are listed 'Best First'.
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.	[reply]
Re^3: Packaging Perl Programs (is) Painful by Marshall (Canon) 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.	[reply]
Re^4: Packaging Perl Programs (is) Painful by jdrago999 (Pilgrim) on Sep 06, 2010 at 07:18 UTC
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).	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks