Where's the "IronPerl" Project? 390
pondlife writes "A friend asked me today about using some Microsoft server components from Perl. Over the years he's built up a large collection of Perl/COM code using Win32::OLE and he had planned on doing the same thing here. The big problem is that as with many current MS APIs, they're available for .NET only because COM is effectively deprecated at this point. I did some Googling, expecting to find quickly the Perl equivalent of IronPython or IronRuby. But to my surprise I found almost nothing. ActiveState has PerlNET, but there's almost no information about it, and the mailing list 'activity' suggests it's dead or dying anyway. So, what are Perl/Windows shops doing now that more and more Microsoft components are .NET? Are people moving to other languages for Windows administration? Are they writing wrappers using COM interop? Or have I completely missed something out there that solves this problem?"
Re:What? (Score:3, Interesting)
Actually, I remember reading somewhere that Microsoft uses build system written in Perl to compile Windows. Ironic, isn't it?
Re:Perl6 is the problem (Score:5, Interesting)
Unfortunately, (as perl fan), Perl6 is the problem. All the bright young things went into the death march that is Perl6 and CPAN stopped getting useful additions. Two burnout cycles later, we still don't have Perl6. Or modern, complete XML/Xpath support. Or a DBI::CSV which can do joins. Or any other number of actually useful code bits.
I'm now tossing up whether to learn Ruby or Python.
Re:Don't fight it - Perl is here to stay! (Score:5, Interesting)
My linux box doesn't have ruby or python installed, and I haven't had any problems. Try deleting perl from yours!
What distribution are you running? Every distribution I've used had Python installed by default for years (and would break terribly if you tried to remove it).
Been in similar shoes (Score:5, Interesting)
I have been in similar shoes some time ago.
I wouldn't elaborate on the all boring details, but just shortly summarize my experience.
If you can Perl, then you better off porting your stuff to Linux. Perl on Windows sounds cool and ActiveState does excellent job. But Perl would always remain underdog, restrained by the fact that its foreign platform - platform where VB rules.
I know I sound impractical, but after two years trying to make some stuff fly reliably on Windows with CygWin and ActiveState, I simply given up. I given up on Windows mostly because I found that all stuff I need, on Linux is very similar and (most importantly) there are no all those stupid CygWin and OLE/ActiveX annoyances and periodic breakages. For my application, near doubled performances was only an extra bonus.
If you plan to remain on Windows, you have to accept and start doing it in VB or C# or whatever is language du jour in Redmond.
If you depend on Perl, then thinking in direction of *nix platform is sound choice. (Or even some VMware or VBox setup with Linux guest.)
P.S. My work was related to processing of .xls files with huge amount of statistical data and making some charts for them. On Linux that was solved beautifully with (1) telling people to export info as CSV (extra bonus: smaller files) and (2) gnuplot output charts to PDF. Frankly, in the end it worked magnitudes better than the setup with ActiveState Perl/Excel/WinWord/etc on Windows.
COM deprecated ?? (Score:3, Interesting)
Re:Been in similar shoes (Score:3, Interesting)
Thanks for the info!
A 100% Open Source CPAN-capable Perl for all your Windows® computers that works exactly the same as Perl everywhere else.
Does that mean it also has fork()?
But honestly, to me properly functioning select() (with both pipes and sockets) is already more than enough.
Though admittedly I do not have plans to go back to Windows.
Re:Don't fight it - Perl is here to stay! (Score:5, Interesting)
Oh and lets not forget how "cool" it'd be if the runtime of every pet scripting language was embedded directly in common web browsers. Yes Cletus, that sure would be 'great'!
My word. You've just described Silverlight.
Re:Perl6 is the problem (Score:5, Interesting)
As a former heavy user of Perl (and now a light user), let me encourage you that you're unlikely to go wrong either way. Both are popular, well-supported dynamic languages with bright futures.
Python is less Perlish than Ruby in syntax, but in the end I found that rather charming and made it my "new" dynamic language. I have no regrets.
Besides, if I want to shred and rebuild a text file in 40 characters of line noise (please understand that I mean that fondly - I like Perl's conciseness), then I've still got Perl 5. Python does many other things well, so I consider them both useful tools to know.
So quit tossing up (ahem), pick one, and get on with it! :-)
The Perl investment (Score:3, Interesting)
I'm still using most of the Perl applications -- on *three different OSs* -- that I wrote before .NET existed, and I expect I'll be using them (on at least three different OSs) long after .NET has been replaced by Monoposoft's next attempt at World Domination[TM].
Not surprising (Score:3, Interesting)
First, as other people have mentioned, Perl use is declining. I love Perl, but it's just not as popular as it used to be.
Second, Perl has always been more popular on, and worked better with, UNIX. That's even more true now that fewer people are using it. Ask 100 Perl developers whether they prefer UNIX or Windows, and 99 of them will say UNIX. So it's not too surprising there's no Windows only rewrite of it.
As for Perl/Windows shops, do they even exist? Seems to me that if there were enough pressure to heavily use Perl, there'd be enough pressure to use something other than Windows.
Re:Don't fight it - Perl is here to stay! (Score:3, Interesting)
As far as I know, popularity-contest doesn't say what goes on bare-bones, you'd need an essential piece of software that depends on Python for including it there. Popularity-contest says what goes on each CD, and I think Python is already at the first one.
Also, really, why do you want to include Python at bare-bones? If you like cluter, use the Desktop install.
Re:That's simply not possible as is. (Score:2, Interesting)
IronPerl. (Score:3, Interesting)
The Iron* family of languages are re-implementations from scratch of a language to run on top of .NET. This approach requires a large time investment to get it working as reimplementing a language and then tuning it to run fast is not a weekend hack.
There is another option, to build bridges from a language to .NET. This is possible because .NET can be used as a library, Perl can host .NET and then create objects and send messages to objects living in the .NET world.
For a language in continuous evolution like Perl, following the Iron* route is more difficult, and the second approach might be better.
I believe there used to be a set of .NET bindings for Perl.
Re:Don't fight it - Perl is here to stay! (Score:3, Interesting)
As a Debian user who always starts from the bare bones install and apt-gets my way to ideal, I agree with you that the base install shouldn't include Python. The base install is an example of something we want to be tight and small.
However, not everything worth writing should be written in C.
In general, writing C is expensive, compared to interpreted languages. More bugs need to be ironed out. There are portability issues, so moving to each new architecture or platform takes more and more effort. The program is longer and more complicated. And, worst of all, you are repeating a lot of work other people have already done. In the end, your C program is going to be tighter and faster than the interpreted one, but at what cost? And what have you gained? The user will not be able to notice the difference between 10ms and 100ms run times. Most desktop software spends almost all of its time waiting on I/O (this includes user input), and there is pretty much nothing that can be done (software-wise) to make I/O faster. Meatspace is too slow.
The interpreted version is usually fast enough and it's easier to write and maintain. To use your example, writing a build system in C is premature optimization, and the general rule for that is Don't Do It. Programs have bottlenecks, which cannot be found until you are done. If you really need speed, use a good profiler to find those bottlenecks and make them faster, which, in the case of interpreted languages, you then write those small parts in C using whatever C interface is provided.
To quote Paul Graham [paulgraham.com],
Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one.
Write in C and assembly when you really need the raw power, such as when you are writing some kind of data compressor or high-precision scientific simulation. For everything else, use a more powerful, higher level language -- especially when doing lots of text processing. You will be done faster and with fewer bugs and security holes.
The reason we have so many interpreters is because no one can agree on which language is the most powerful.
Re:Python is available (Score:3, Interesting)
Just please don't make the argument Python is inherently more readable.
It's not
http://algebraicthunk.net/~dburrows/blog/entry/attachments/debsudoku.py [algebraicthunk.net]
http://www.blott-online.com/sudoku/sudoku-solver [blott-online.com]
Re:Perl in decline, at least here (Score:3, Interesting)
Perhaps. But Perl is so widely used, it could decline steadily for forty years and still be more important than C#.
I think a larger factor is that Perl is not usually given to a strong emphasis on presentation, brand names, buzzwords, and such. Perl is a very *practical* language, grounded in the idea of getting things done, and getting them done quickly, conveniently, and efficiently.
Some languages would want to run in the
Also, just because there's no "IronPerl Project" running around enthusiastically talking about the importance of running Perl in a