Slashdot Mirror
Where's the "IronPerl" Project?
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?"
Actually, I remember reading somewhere that Microsoft uses build system written in Perl to compile Windows. Ironic, isn't it?
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.
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).
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.
All hope abandon ye who enter here.
Dude, in which world is COM deprecated ? Effectively most of Windows system programming ( plug-ins, filters, extensions yada yada, especially the parts that concern shell, explorer or IE extensions ) are all exposed through COM intefacts still. In some cases we still have simple C interfaces like for device drivers, and a lot of security or crypto related stuff. So WDYM deprecated ?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
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.
Reality is the ultimate Rorschach.
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! :-)
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].
Rich And Stupid is not so bad as Working For Rich And Stupid.
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.
Maybe not
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.
Rethinking email
Perl gives you more than enough rope to hang yourself, that's why you can often see appaling perl code. But the power of perl may also be a boon ; "use strict; use warnings;" , Perl::Tidy, Devel::Refactor, can help you tremendously to refactor bad code.
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.
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,
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.
Just please don't make the argument Python is inherently more readable.
It's not
http://algebraicthunk.net/~dburrows/blog/entry/attachments/debsudoku.py
http://www.blott-online.com/sudoku/sudoku-solver
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
> Based on what I gather in my country the use of Perl is actually in decline
.NET environment for ideological reasons ("managed code" blah blah blah) or in order to attract programmers and/or managers who have bought into the whole .NET thing, but for Perl the only real reason to run perl in the .NET environment, as opposed to the normal way of doing things, would be if it provided some concrete practical advantages; I'm not aware of any. I'm not saying .NET wouldn't provide an advantage for *some* languages. C/C++, for instance, were in dire need of some of the things that .NET can provide, not least higher-level variable types that automatically take care of things like reallocating more space when needed. But for Perl, as far as I'm aware, the .NET environment is a solution in search of a problem.
.NET environment doesn't mean there aren't modules on the CPAN for interfacing with .NET code. Perl is, after all, a major glue language, so it's accustomed to interfacing with code that runs in different environments. There are probably at least three different approaches to it, with different strengths and weaknesses for different situation. I don't happen to know what they are, because I've never had any reason to work with .NET, but I if I wanted to know, I sure wouldn't ask on slashdot and sift through thousands of irrelevant posts in hopes of finding the answer. I'd go straight to a (gasp) Perl forum (e.g., Perlmonks) or a Perl mailing list, someplace with an SNR above 1.
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
Cut that out, or I will ship you to Norilsk in a box.