Newsflash

I hate Windows too but it's definitely in every Perl hacker's interest for Perl on Windows to be working and getting better.

I applaud everyone who uses Perl on Windows and encourage them to go for it no matter what the task is. No tools get better on any platform until a dev faces some problem using them and addresses it.

I hate Windows too but it's definitely in every Perl hacker's interest for Perl on Windows to be working and getting better.

I neither have a love nor a hate for Windows. I just never use it. And I would really like to know why it's in my interest (as I'm a member of the set of Perl hackers, and you're making a statement about each and every member of that set) Perl on Windows is working and getting better.

Having Perl available as 1) a powerful choice, 2) a well supported choice, 3) a friendly choice on as many platforms as possible is in the interest of everyone who wants Perl continuing to be used; which contributes to Perl continuing to be supported and improved; and the CPAN continuing to fill with an index of prefab solutions that other languages can't touch. As well you know Windows is a huge portion of the computer world.

I've owned nothing but Macs (and oh, okay! Tandys) for 25 years. If Perl didn't work on Mac, I'd have moved to Ruby and PHP. And I'd be badmouthing Perl for being a language that didn't care. I've boostered for Perl constantly in many ways and places for more than a decade. Losing even one user like me takes away at least a couple hundred other adopters. I'm sure we've lost plenty because Perl turned off similar WIndows users.

I'm not in the "Perl is Dying" Venn but it's obvious that Perl lost a lot of ground in the last decade and at least some of that is because it was only (easily) accessible to sysadmin *nix types.

And in the "But What About COBOL" camp, I realize plenty of Perl hackers like you, maybe even me at this point, are going to have high paying Perl jobs if they want them for the next 20 years at least even if Perl "dies."

The more life-blood we can take in, the more accessible Perl is to anyone with a programming problem, the more interesting, widespread, widely financially rewarding, and vibrant Perl will remain.

When coding for Windows - use .Net

No!

otherwise why are you using Windows?

Because I prefer windows to the alternatives. (And perl to its alternatives!)

The hours/days/weeks you have wasted/will-waste pining away for a workable Perl solution on windows could have been applied to a finished product in C#

Utter bollocks.

Get Over It

Get over yourself!

Disclaimer - I completely HATE windows, use only Ubuntu for my desktop

So you're another 'me too *nix fanboi' who thinks that the ability to download a tar.gz, unpack it and type configure and make makes him a programmer.

And what about that makes you qualified to answer the OPs question?

So you're another 'me too *nix fanboi' who thinks that the ability to download a tar.gz, unpack it and type configure and make makes him a programmer.

Well it may not make you a programmer, but it sure makes you a better System Administrator. Even at the programming level, compiling your own programs DOES make you a better programmer because building an executable from the code, makes you aware of libraries and how they interact on your system. When you just install pre-built binaries, it's like being thrown a fish, instead of learning how to fish.

---

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

it's like being thrown a fish, instead of learning how to fish.

Nah! Assembling flat-pack furniture makes you an expert in reading self-assembly instructions, not a carpenter.

Besides, the vast majority of *nix software is installed via RPM; or dpkg, or apt-get, or pacman; or ipkg; or ...

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

"So you're another 'me too *nix fanboi' who thinks that the ability to download a tar.gz, unpack it and type configure and make makes him a programmer."

I might not have an accredited Pope-ness degree from years of slacking off at PerlMonks (switched usernames a few times over time, hence my mere Sexton status). However, your excellency isn't exactly writing a How-To response either.

If you're going to call me a "fan-boi" then show what you've got. How would you, your supreme-ness, do this using Perl? How would you, your majesty, solve the OP's dilemma?

No answer?

No working solution? No "Hey look at that!" example? Then why even pipe up? Oh, and thanks for the down-vote.

No answer?

See 858880.

why are you using Windows?

Because that's the system they give me to work on, and because, unlike you, I'm not man enough to bring something else in on my own expense, muscle my way past IT policy and protocols, and use a system that noone else at work can interface with.

The hours/days/weeks you have wasted/will-waste pining away for a workable Perl solution on windows could have been applied to a finished product in C#.

I've spent nearly a decade getting to know the ins and outs of Perl, and because of this I can write the script in a matter of minutes, flush out testing, package, and deploy in under an hour.

While I greatly appreciate your confidence in my skills to learn C# to the same level of competence in merely an hour, I'm not man enough to have that level of confidence in myself.

your time (and your clients'/boss' time) would be best spent on something that will actually work.

What I do works. In under an hour. Including testing. But I suppose I'm not man enough to properly assess what "actually works" and what doesn't.

The free version of Visual Studio will probably do everything you need, for free.

Wow, it compiles my Perl scripts and creates single-step remotely-deployable programs for remote systems that don't have Perl installed? Cool! I'll have to check this out. I hope I'm man enough to find the Perl packager in it. I haven't been doing too well in the manly department, by your standards, though, so I'm not so confident.

I could write the tools in C -- that's what I used to do -- and MinGW does a great job of giving me an easy-to-deploy executable. It's just...well, the development time's a smidge longer. Okay, I admit it -- I'm just not man enough to do it the hard way.

WTF?

Oooh! Oooh! I know the answer to this one! You're man enough to tell everyone else that they must do it your way, and man enough to use TMTOWTDI at the same time.

:: applause ::

Get Over It

I agree that there is one person in this conversation who has demonstrated a need to get over something.

So -- let's face it. You win. You've proven you're better than everyone else here. You can leave, smug in the self-assured knowledge that you are superior, that you have all the right answers, and that you are better than me.

Congratulations.

What I do works

Except it doesn't work, as you found out when you tried to package it. A good programmer considers the whole "development lifecycle", from helping his customer (or employer) to create the spec in the first place, all the way through to deploying it (which you appear to have buggered up) and maintaining it afterwards.

My apologies if I wasn't clear.

What I do now works.

:-)

why are you using Windows?

Because that's the system they give me to work on

I'd quit if that ever would happen to me. I've never taken, and will never take, a job that involves "do this task on an OS I tell you to, and you don't know".

It's unlikely to happen in my current gig though. All production machines (1000+) run some form of Unix^† and for dev machines, they just give us the choice of hardware (x86 or apple), and freedom to run whatever we like. (So we have devs running MacOS, Windows, a bunch of Linux distros, a few BSD boxes, and one guy running OpenSolaris).

^†We may have a few non-client facing, non-Unix systems. Like the SAP boxes. But they run bought, commercial software, not something we develop in-house. But they may run Unix as well (or something completely different) - I just do not know.

If the question were, instead...

"How do I make this completely Microsoft-dependent software system work on Linux?"

...my response would have been basically the same, but in reverse - Use Perl. Sure, there's Mono (which does work fairly well) but for something like this - a piece of software with a GUI that must run on users' desktops - you are asking for trouble if you do anything outside of Microsoft's preordained canon.

If you don't believe me - that writing GUI code on Windows is a pain with Perl - ask the nice folks who have been working on "Padre" for the last few years. Combine a simple language (comparatively) like C# and a drop-dead-simple IDE like Visual Studio and, well, basically anyone capable of right-clicking and typing "Hello World" can make a network-deployable windows GUI application. That bar is set pretty high (I know) but I suppose the line has to be drawn somewhere.

"So -- let's face it. You win. You've proven you're better than everyone else here. You can leave, smug in the self-assured knowledge that you are superior, that you have all the right answers, and that you are better than me."

Smug? Maybe popping one's bubble for their own good will be misread as smug. Your skills as a competent Perl programmer put you in a great position to learn C# (enough, anyway) quickly - very quickly. In fact most of the "innovations" I've seen in C# over the last few years have been in Perl since version 5.0 came out or earlier. To me, C# seems to be stuck in catch-up mode, trying to mimic what's going on in Perl and Ruby.

And what's with all this "Oooh I'm not man enough to xyz" - popping this perceived vibe of "Perl is the only tool in my box so it's the only tool I'll use" in the OP - however rough and bruising to your ego it might have been - was probably necessary.

Sheesh.

And what's with all this "Oooh I'm not man enough to xyz"

:: grin :: Just having a little fun, possibly at your expense, by pretending to presume that you were being over-the-top abrasive on purpose.

Of course I don't expect that was true; more likely you just didn't (and apparently, to some degree, still don't) realize just how much your posting style buries your message.

However, this post was less abrasive, and I even upvoted it. For balance, if nothing else. I see it now has a 1. LOL.

however rough and bruising to your ego it might have been

:: grin :: Actually, I did not have much invested in this portion of the threadlet but my own entertainment; I had rather hoped a side effect might include you becoming more aware of the effect your posting style has on the quality of your message. No matter if that succeeds or fails, though. Doesn't hurt me and the pain you cause yourself is your problem.

Besides, it would take a LOT more than something like this to touch, much less bruise, my ego. Even if I had been the OP.

Here's wishing you a fine and most excellent day on the day you read this reply.

Cheers!

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.

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.

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).

I don't know why this is getting downvotes, for some problems this is certainly true.

Perl is simply not optimized for GUI programming, and the tools for creating standalone executable perl packages, especially ones that can deployed remotely, are simply not on the same level as ones for some of the other technologies mentioned.

I think this is because most perl programmers don't do a lot of work in this area. Perl is indispensable for systems or web programming, but there are just much better solutions out there for Win32 GUI apps. I would applaud the original poster if they set about attempting to correct this imbalance, but I wouldn't blame them if they tried an easier route.

I am primarily a perl programmer working on web applications. Perl/Catalyst/Moose is the best of the options I've tried for that type of development. But it's not the only programming language out there.

C#/Visual Studio is a viable option for this kind of project. If you really don't like Microsoft products, there are many other options like Qt/C++, or Eclipse/Java that are well suited for this sort of problem(both are multiplatform to boot).

Perl has some advantages(CPAN, powerful regular expressions, flexible syntax) and it may provide nicer glue for all the technologies you need for your application, but often installing CPAN modules on windows is an exercise in frustration. And I think you'll find that Java, C# and other languages have ways to glue things together.

I like perl, I know it well, and I like to solve problems with it. However, that doesn't mean it's the optimal tool for every job.

You know Qt, Wx, Gtk, Gtk+, Tk, Fltk, SDL, and Prima work with Windows and Perl, right? Win32::GUI is meant specifically for native graphical Windows programs.

If you're a Perl web developer you've learned more ways to do that than Catalyst and Moose or you haven't been doing it very long. New ways to address problems come along all the time. There are plenty of ways to address graphical applications on Windows using Perl, and many of them keep getting better over time.

Perl isn't indispensable for web programming or systems programming. Plenty of people use PHP, Python, Ruby, Java, JavaScript (yes, even on the server side), or other languages for web work, and some of them never use Perl. The only systems language I know about that could really be called indispensable is C, or maybe Forth on really small systems. I don't even know that Perl should be classified as a systems language. It is general-purpose, but I think its strength falls more in applications. People program in Perl because it fits their needs well enough and they prefer it to some other language that would also meet their needs well enough.

For someone to just flat out say that some other language's benefits and drawbacks will always win out against Perl on a particular platform takes some qualification at least.

There's no way C# can be said to have a smaller framework footprint than Perl, with 3.5 being nearly 200 MB. Not all versions of Windows come with that, you know. Perl's footprint is 74 MB for 5.12.2-RC1 on my Linux box, admittedly without Wx or any of the other graphical toolkits. I think a few might fit in the other 123 MB. Many of the core Perl modules don't have to be left in place if they are sure never to be used on a particular system, but care really needs to be taken with that idea.

C or C++ development typically takes much longer than Perl or Python development for the same complex task. You can statically link libraries in most cases, but that doesn't make for small executables in most cases. Those programs are counting on some framework being in place if they are doing something fancy without linking a lot of static libraries into themselves. If that framework isn't the stock libraries in a particular version of Windows, then the framework footprint and the issue of separate file installation still apply.

If you're going to recommend someone move to C++ from Perl to solve a problem on Windows, you might as well have them solve whatever problem you're having with one of the graphical toolkits for Perl on Windows. That will be much more useful in the long run than writing a one-off application in C++ instead of Perl.

I have a C++/Java background from my university days, so that may have colored my advice a bit. Generally I have a pretty easy time of learning new languages, but I will gladly concede that I can solve most tasks more quickly in Perl than Java or C#, and certainly faster than with C++.

Indeed I have tried half a dozen different perl web frameworks from Mason to CGI::Application to my own custom mod_perl dispatcher before settling on Catalyst.

I also accept your assertion that perl GUI programming has advanced since the last time I threw up my hands in frustration :-)

I have tried several of those GUI solutions. I don't want to minimize any of the hard work people have done on those projects, but I will say that several of the toolkits mentioned are incomplete in terms of documentation or functionality, others have a wildly non-native or primitive look and feel(Tk, Prima, Fltk), and others simply will not build via CPAN on windows, at least not without serious tweaking(PerlQt, and GTK2::GladeXML both fell into the category of unbuildable last time I tried on Win32.)

I think Wx looks great and has the functionality I'd need, but all of the existing documentation is for the C++ version. You need to translate it to perl, and not all concepts map cleanly from one language to the other. And as the original poster pointed out, it's not trivial to deploy a WxPerl application.

More power to the programmers who will try out an incomplete solution and help the dev team make it better by filling out documentation, and fixing bugs or submitting bug reports. That may not be the right approach for every problem, and sometimes considering a solution other than perl is not a bad idea.

I don't know why this is getting downvotes, for some problems this is certainly true.

At a guess, probably because of the condescending one-true-way attitude and the fact that he didn't address the OP's actual question.

I chuckled when I found it was sitting at -7. I figured it would take a hit or two but I didn't realize the number of people who would even bother to vote on it would actually outnumber the number of people who agreed with the technical merits of the post.

I am not disappointed, mind you. Just surprised. Apparently, people on Perlmonks want this to be a place for friendly and useful dialog.

Go figure.

I like perl, I know it well, and I like to solve problems with it. However, that doesn't mean it's the optimal tool for every job.

++thunders

Have a great evening!

For what ever reason, the OP wrote his stuff in Perl. Good for him. Maybe it was the right tool when he started and maybe it's the wrong tool for what he's trying to do now. Maybe he should have just started in .net, or C# or any number of more Windows friendly choices from the get go. I hear even PHP is getting strong support in Windows these days. Regardless that was OP's choice at the time.

The question was not 'should I use .net instead' the question is 'how do I make Perl work in this situation'. We should support that effort, expand the boundaries, look for solutions and encourage the use and knowledge of Perl that it may help others in similar situations. Not troll some hyper marked up 'you idiot' message proclaiming the futility of using non Windows applications in a Windows world.

On a nix system we wouldn't be arguing about how installing CPAN modules is an exercise in frustration (OK we might, but we'd probably be arguing about the different ways it could be done). If installing CPAN modules on windows is ever going to become easier it will only be because brave mis-guided souls dared to buck against flippant advice and find ways to make it work anyway.

Anything else is just walking into a weight watchers meeting and calling everyone fat because they eat too much.