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?"
Perl/Windows shops? WTF?
That's like buying an extremely overpowered, difficult to setup and impossible to maintain turbo for your Yugo.
I _love_ perl. It's so simple, anyone can use it. In fact, the other day I found my 1½ yYO in front of the computer, and she had written a fully working email reader in perl. Truely amazing.
SIG: TAKE OFF EVERY 'CAPTAIN'!!
here goes nothing Programming Perl in Dot Net
From my cold, dead hands!
Some people aren't happy until they have the worst of all worlds.
"Because I can".
Deleted
I suspect people are moving to Powershell, since it's a good shell scripting language, and it's easy to load .NET assemblies among other things.
I was able to learn enough powershell to do some rather useful things in a few days, and that's without having a strong shell scripting background.
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.
Why does everyone keep repeating this? Just because you don't do it doesn't mean nobody does. There are tons of large projects in perl. You're using one right now.
Your theory appears to be that Windows is a good web platform, because on netcraft, 2 out of the top 50 sites by uptime are running Windows. Wouldn't the goodness of a web platform depend on a whole bunch of things, only one of which would be uptime? And uptime would be less important than things like availability and ease of installing software. And most importantly, whether the machine has a blue or green LED for the power light. Obviously machines with blue power LEDs suck, but machines with green LEDs rock! And Windows web servers always have blue LEDs for power lights! Windows sucks and always will. They don't even know how to write drivers for green LEDs.
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).
The figures on this simply don't support that claim. Your anecdotal evidence of two places you worked it meaningless.
If anything I'd say this is because many people consider Perl's time to have passed and no longer see a reason to use it in any significant project.
Funny.. I'd like to see the figures behind your claims that "many people consider Perl's time to have passed".
A quote from CIO.com story entitled "PHP, JavaScript, Ruby, Perl, Python, and Tcl Today: The State of the Scripting Universe" (8/29/08)
"Of all the scripting languages, Perl offers the biggest installed base of applications, of code, of integrated systems, of skilled programmers. It has the lowest defect rate of any open-source software product. It is ported to essentially every hardware architecture and operating systems, from embedded control systems to mainframes. It is optimized for speed, for memory footprint, for programmer productivity. It has readily-accessible libraries for all types of programming tasks: Web application development, systems and network integration and management, end-user application development, middleware programming, REST and service-oriented architecture programming. Perl is ideal for the organization that takes charge of its own IT future."
Other interesting stats and info throughout the story..
full article
-Lod
So your arguments for why Perl is great to use are:
1) I know it.
2) I have it.
3) (irrelevant)
4) YAY CPAN
5) Not a reason to use it?
So, uh, yeah, CPAN is awesome, but "I know it and it's installed." aren't really strong advocacy arguments.
No offense, but this isn't exactly Insightful, particularly given that (aside from good old CPAN) there's really nothing in there that isn't true for Python on almost all systems people will encounter these days.
"The wise man proportions his belief to the evidence." -- David Hume
Opinionated post follows, feel free to ignore or disagree....
Perl is the original language that taught a whole generation of programmers that you don't have to write 1000s of lines to do a simple thing. I love its expressiveness, its design philosophy (There's More Than One Way To Do It) and its linguistic roots. Despite being known for write-only shit, actually writing clean, maintainable code in perl is a pure pleasure. It just gives you the extra bit of latitude in your coding, that what you write can express not just what you want done, but a little extra bit of how you think of it... by using "unless" instead of "if" at times, putting the conditionals after the statement at others, you can actually make the code read like the main points are main points, adn the accessory checks are accessory. I love that flexibility.
For years, perl was the secret productivity tool of many. What others would spend weeks writing in C++ or java whatever, a perl coder would prototype in a day or two, and often the result was good enough to be declared final. And with the amazing collaboration experiment called CPAN, there was a good chance you would find a module to do the heavly lifting for you, and the two days could be shortened to a couple hours.
Sadly, the perl development community missed not one, but two boats.
First, it missed the second wave of web programming. Perl was virtually synonymous with CGI programming, but then the web world moved on to embedding code inside the HTML, which is a rather crappy combination but is easy to start with. So the perl guys produce mod_perl and about a thousand templating kits, which all together made mod_perl a powerful, scalable, flexible web platform that was at the same time confusing, hard to learn, and unfriendly towards shared hosts. And then PHP came to fulfil that need, with their bastardized watered down clone of the language, and basically stole the show.
Second, the perl community in all their wisdom, back in 2000, decided that the whole language needed to be redesigned from scratch, and built on a new generic virtual machine for dynamic languages, which would run not only perl6 but also python, tcl, logo, and who knows what else. They embarked on a prolonged process of design by committee, which 8 years later has just managed to produce a variety of incomplete specifications, and two incomplete prototypes of the language interpreter, with no completion date nor any backwards compatibility to be seen. In the meantime, the whole .NET framework has been created and gone through several iterations, Ruby has risen from obscurity to fame, etc. For all we know, perl6 may still one day reach completion, and be a useful language. The design specs are way cool, and the people implementing it sound like they are having fun.
So what happens with perl and .NET? Well, not much. Apparently ActiveState have at some point developped a bridge of some kind, but I can't find it in CPAN. There's Inline::Java, but no Inline::CSharp. Maybe no-one cares enough. It's true that the target demographics for perl and .NET are quite separate, but that should not be a reason for the language that pioneered interfacing with everything on earth.
Actually the problem is that "only Perl (the executable) can parse Perl (the language)". There isn't any formal description of the current language implementation, that effectively renders near to impossible to parse and execute Perl code outside of the perl binary; some edge cases of the syntax particularly are only determined at runtime (instead of compile time).
Perl 6 is among other things an answer to this limitation, because it's thoroughly spec'd in the "synopses", and is actually currently implemented in two different ways (Parrot VM written in C, and Pugs written in Haskell). So it's perfectly possible to make IronPerl6, but no IronPerl.
To be fair, that quote is by Richard Dice, the president of the Perl Foundation, so he might be a little biased. :-)
On the other hand, Perl still gets many more job postings on dice.com than any other interpreted language, including PHP: http://www.presicient.com/langjobs.html